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 written consent of Huawei Technologies Co., Ltd.

Trademarks and Permissions and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd. All other trademarks and trade names mentioned in this document are the property of their respective holders.

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

Huawei Technologies Co., Ltd. Address:

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

Website:

http://www.huawei.com

Email:

[email protected]

Issue 01 (2011–8–17)

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

i

GBSS9.0 Troubleshooting Guide

About This Document

About This Document Overview This 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 Version The 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 Audience This document is intended for: l

Maintenance engineers

l

Field engineers

Issue 01 (2011–8–17)


ii


About This Document

Organization 1 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.

Conventions Symbol Conventions The symbols that may be found in this document are defined as follows. Issue 01 (2011–8–17)


iii


About This Document

Symbol

Description Indicates a hazard with a high level of risk, which if not avoided, will result in death or serious injury. Indicates a hazard with a medium or low level of risk, which if not avoided, could result in minor or moderate injury. Indicates a potentially hazardous situation, which if not avoided, could result in equipment damage, data loss, performance degradation, or unexpected results. Indicates a tip that may help you solve a problem or save time. Provides additional information to emphasize or supplement important 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 in boldface. For example, log in as user root.

Italic

Book titles are in italics.

Courier New

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

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

Issue 01 (2011–8–17)

Convention

Description

Boldface

The keywords of a command line are in boldface.

Italic

Command arguments are in italics.

[]

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

{ x | y | ... }

Optional items are grouped in braces and separated by vertical bars. One item is selected.

[ x | y | ... ]

Optional items are grouped in brackets and separated by vertical bars. One item is selected or no item is selected. Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

iv


About This Document

Convention

Description

{ x | y | ... }*

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

[ x | y | ... ]*

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

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

Description

Boldface

Buttons, menus, parameters, tabs, window, and dialog titles are in boldface. For example, click OK.

>

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

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

Description

Key

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

Key 1+Key 2

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

Key 1, Key 2

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

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

Issue 01 (2011–8–17)

Action

Description

Click

Select and release the primary mouse button without moving the pointer.

Double-click

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

Drag

Press and hold the primary mouse button and move the pointer to a certain position. Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

v


Contents

Contents About This Document.....................................................................................................................ii 1 Change in the GBSS Troubleshooting Guide.........................................................................1 2 Troubleshooting Procedure.........................................................................................................2 2.1 Troubleshooting Flowchart.................................................................................................................................3 2.2 Collecting Fault Information..............................................................................................................................3 2.3 Determining a Fault Type...................................................................................................................................6 2.3.1 Fault Types................................................................................................................................................6 2.3.2 Methods for Determining a Fault Type.....................................................................................................7 2.4 Identifying Fault Causes.....................................................................................................................................8 2.5 Troubleshooting Faults.......................................................................................................................................9 2.5.1 Overview...................................................................................................................................................9 2.5.2 Methods for Troubleshooting Faults.........................................................................................................9 2.5.3 Follow-up Procedure...............................................................................................................................10

3 Common Maintenance Functions............................................................................................11 3.1 Maintenance Functions for Identifying Voice Problems..................................................................................12 3.1.1 Querying Call Resource Usage of an MS................................................................................................12 3.1.2 External Voice Loopback........................................................................................................................12 3.1.3 One-Way Audio Detection......................................................................................................................18 3.1.4 Crosstalk Detection..................................................................................................................................18 3.1.5 Optimizing Um Interface Crosstalk.........................................................................................................19 3.2 Maintenance Functions for Identifying Transmission Problems......................................................................19 3.2.1 Crossed Pair Detection............................................................................................................................20 3.2.2 Monitoring Port BER Seconds................................................................................................................22 3.3 Maintenance Functions for Identifying Um and RF Problems.........................................................................22 3.3.1 Monitoring Channel Interference Bands.................................................................................................23 3.3.2 Detecting Intermodulation Interference by Testing Idle Timeslots.........................................................23 3.3.3 Scanning Uplink Frequencies..................................................................................................................25 3.4 Maintenance Functions Related to Interface Tracing.......................................................................................28 3.4.1 Tracing CS Domain Messages of a Single Subscriber............................................................................28 3.4.2 Tracing PS Domain Messages for a Single Subscriber...........................................................................29 3.5 Maintenance Functions for Identifying PS Problems.......................................................................................31 3.5.1 Monitoring Channel Status......................................................................................................................31 Issue 01 (2011–8–17)


vi


Contents

3.6 Maintenance Functions for Identifying Clock Problems..................................................................................33 3.6.1 Querying BSC Clock Source Status........................................................................................................33 3.6.2 Querying BSC Board Clock Status.........................................................................................................34 3.6.3 Maintaining BTS Clock...........................................................................................................................35

4 Handover Problems.....................................................................................................................37 4.1 Handover Principles.........................................................................................................................................38 4.1.1 Handover Procedure................................................................................................................................38 4.1.2 Handover Success Rate...........................................................................................................................40 4.2 Locating Handover Problems...........................................................................................................................43 4.2.1 Principles.................................................................................................................................................43 4.2.2 Procedure for Locating Handover Problems...........................................................................................43 4.3 Troubleshooting Handover Problems Due to Hardware Faults........................................................................45 4.4 Handover Problems Due to Incorrect Data Configurations..............................................................................48 4.5 Troubleshooting Handover Problems Due to Traffic Congestion in the Target Cell.......................................52 4.6 Troubleshooting Handover Problems Due to Poor Um Interface Quality.......................................................54 4.7 Troubleshooting Handover Problems Due to NE Faults..................................................................................58 4.8 Troubleshooting Handover Problems Due to Inappropriate Inter-BSC/Inter-MSC/Inter-RAT Interaction ................................................................................................................................................................................61

5 Call Drops.....................................................................................................................................66 5.1 Call Drop Rate..................................................................................................................................................67 5.2 Locating Call Drops..........................................................................................................................................68 5.2.1 Procedure for Locating Call Drops..........................................................................................................68 5.2.2 Counters Related to Call Drops...............................................................................................................70 5.2.3 Types of Call Drops.................................................................................................................................72 5.3 Troubleshooting Call Drops Due to Poor Um Interface Quality......................................................................75 5.4 Troubleshooting Call Drops Due to Equipment Faults....................................................................................80 5.5 Troubleshooting Call Drops Due to Transmission Faults................................................................................83 5.6 Troubleshooting Call Drops Due to Incorrect Parameter Settings...................................................................84

6 Access Faults.................................................................................................................................91 6.1 Access Principles..............................................................................................................................................93 6.2 Locating Access Faults.....................................................................................................................................94 6.2.1 Procedure for Locating Access Faults.....................................................................................................95 6.2.2 Common Causes for Access Faults.........................................................................................................99 6.3 Troubleshooting Access Faults Due to Poor Um Interface Quality...............................................................103 6.4 Troubleshooting Low Immediate Assignment Success Rates Due to SDCCH Congestion..........................108 6.5 Troubleshooting Low Immediate Assignment Success Rates Due to Hardware or Transmission Faults ..............................................................................................................................................................................113 6.6 Troubleshooting Low Immediate Assignment Success Rates Due to Location Updates of Problem MSs ..............................................................................................................................................................................116 6.7 Troubleshooting Low Assignment Success Rates Due to TCH Congestion..................................................119 6.8 Troubleshooting Low Assignment Success Rates Due to Hardware or Transmission Faults........................123 6.9 Troubleshooting Low Assignment Success Rates Due to Inappropriate BSC Configuration.......................127 Issue 01 (2011–8–17)


vii


Contents

7 Voice Problems..........................................................................................................................131 7.1 GSM CS Signal Flow.....................................................................................................................................132 7.2 Common Voice Problems and Problem Location Methods...........................................................................137 7.3 Troubleshooting One-Way Audio or No Audio.............................................................................................138 7.4 Troubleshooting Noise...................................................................................................................................140 7.5 Troubleshooting Crosstalk..............................................................................................................................142 7.6 Troubleshooting Echoes.................................................................................................................................144 7.7 Troubleshooting Discontinuous Voice or Low MOS.....................................................................................146

8 PS Counter Problems................................................................................................................149 8.1 PS Counters....................................................................................................................................................150 8.2 Locating PS Counter Problems.......................................................................................................................151 8.2.1 Principles for Locating PS Counter Problems.......................................................................................151 8.2.2 Procedure for Locating PS Counter Problems.......................................................................................151 8.3 Troubleshooting Low TBF Establishment Success Rates..............................................................................152 8.4 Troubleshooting High TBF Call Drop Rates..................................................................................................158 8.5 Troubleshooting Low Average Throughput at the RLC Layer......................................................................163 8.6 Troubleshooting Low Percentage of High-Rate Coding Schemes to All Coding Schemes...........................168 8.7 Troubleshooting High RLC Data Block Retransmission Rates.....................................................................173

9 PS Channel Faults......................................................................................................................177 9.1 Identifying PS Channel Faults........................................................................................................................178 9.2 Locating PS Channel Faults...........................................................................................................................178 9.3 Troubleshooting PDCH Faults Due to Channel Inactivity.............................................................................180 9.4 Troubleshooting PDCH Faults Due to Channel Asynchronization................................................................183

10 Cell PS Service Faults.............................................................................................................188 10.1 Remarks on Cell PS Service Faults..............................................................................................................189 10.2 Locating Cell PS Service Faults...................................................................................................................189 10.3 Troubleshooting Cell PS Service Faults Due to Incorrect Data Configurations..........................................190 10.4 Troubleshooting Cell PS Service Faults Due to Hardware Issues................................................................192 10.5 Troubleshooting Cell PS Service Faults Due to Incorrect Cable Connections Inside the BSC...................194 10.6 Troubleshooting Cell PS Service Faults Due to Gb Interface Issues...........................................................195

11 IP Transmission Faults...........................................................................................................198 11.1 Troubleshooting FE/GE Transmission Faults..............................................................................................199 11.2 Troubleshooting IP Layer Faults..................................................................................................................204 11.3 Troubleshooting PPP or MLPPP Link Faults...............................................................................................206 11.4 Troubleshooting LAPD Link Faults.............................................................................................................209 11.5 Troubleshooting SCTP Link Faults..............................................................................................................216 11.6 Troubleshooting IP Path Problems...............................................................................................................221 11.7 Troubleshooting DHCP Problems................................................................................................................223 11.8 Troubleshooting IP PM Activation Failures.................................................................................................227 11.9 Troubleshooting IP Clock Faults..................................................................................................................229

Issue 01 (2011–8–17)


viii


Contents

12 Interference Problems.............................................................................................................236 12.1 Interference...................................................................................................................................................237 12.2 Locating Interference Problems....................................................................................................................238 12.3 Troubleshooting Co-channel or Adjacent-Channel Interference..................................................................239 12.4 Troubleshooting Intermodulation Interference.............................................................................................241 12.5 Troubleshooting Interference from the CDMA Network.............................................................................246 12.6 Troubleshooting External Interference.........................................................................................................249

13 Faults on Main and Diversity RX Channels.......................................................................252 13.1 Principles of Main and Diversity Reception.................................................................................................253 13.2 Locating Faults on Main and Diversity RX Channels..................................................................................253 13.3 Troubleshooting Faults on Main and Diversity RX Channels Due to Incorrect Data Configurations.........254 13.4 Troubleshooting Faults on Main and Diversity RX Channels Due to Incorrect Antenna Connections.......256 13.5 Troubleshooting Faults on Main and Diversity RX Channels Due to Hardware Faults..............................261

14 No Traffic..................................................................................................................................263 14.1 Introduction to No Traffic............................................................................................................................264 14.2 Locating No Traffic......................................................................................................................................264 14.3 Troubleshooting No Traffic Due to No Calls...............................................................................................266 14.4 Troubleshooting No Traffic Due to Transmission or Equipment Faults......................................................268 14.5 Troubleshooting No Traffic Due to Incorrect Data Configurations.............................................................270 14.6 Troubleshooting No Traffic Due to Poor Um Interface Quality..................................................................271 14.7 Troubleshooting No Traffic Due to Antenna System Faults........................................................................273 14.8 Resetting.......................................................................................................................................................276

Issue 01 (2011–8–17)


ix


1

1 Change in the GBSS Troubleshooting Guide

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.

Issue 01 (2011–8–17)


1


2 Troubleshooting Procedure

2

Troubleshooting Procedure

About This Chapter This chapter describes the basic troubleshooting procedure and each step. 2.1 Troubleshooting Flowchart This section shows the troubleshooting flowchart. 2.2 Collecting Fault Information This section provides methods for collecting information about faults and describes the fault information types. 2.3 Determining a Fault Type After collecting fault information, analyze the symptoms to determine a fault type. 2.4 Identifying Fault Causes To identify the specific cause of a fault, exclude possible causes by analyzing the symptoms. 2.5 Troubleshooting Faults This section provides the methods for troubleshooting faults as well as follow-up procedures.

Issue 01 (2011–8–17)


2



2.1 Troubleshooting Flowchart This section shows the troubleshooting flowchart. Figure 2-1 shows the troubleshooting flowchart. Figure 2-1 Troubleshooting flowchart

2.2 Collecting Fault Information This section provides methods for collecting information about faults and describes the fault information types.

Methods for Collecting Fault Information Before troubleshooting a fault, collect the following information: l Issue 01 (2011–8–17)

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

3



l

Time, place, and frequency of the fault

l

Fault range and impact

l

Equipment operating status before the fault occurs

l

Operations performed on the equipment before the fault occurs and the operation results

l

Alarms generated when the fault occurs and the associated alarms

l

Board indicator status when the fault occurs

l

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 and technical support engineers.

l

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

l

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

l

Simulate services, measure performance, and trace interface signaling messages to understand the fault range and impact. NOTE

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

Fault Information Types l

Alarm information Alarm information is exported by the BSS alarm system and reported with any combination of the following: sounds, lights, indicators, or onscreen indications. Viewing the alarm information is a common method for analyzing faults. Alarm information includes a description of the fault symptoms and causes, as well as fault rectification 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. NOTE

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

l

Indicator status Indicators 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. Because indicator status is generally not informative enough to locate a fault, this information is often used with the alarm information to locate a fault. Table 2-1 uses the SCUa as an example to describe the board indicators. Table 2-1 LEDs on the SCUa board

Issue 01 (2011–8–17)

LED

Color

Status

Description

RUN

Green

ON for 1s and OFF for 1s

The board is functional.


4



LED

Color

ALM

Red

ACT

Green

LINK (at the Ethernet port)

ACT (at the Ethernet port)

Green

Green

Status

Description

ON for 0.125s and OFF for 0.125s

The board is in loading state.

ON

There is power supply, but the board is faulty.

OFF

There is no power supply, or the board is faulty.

OFF

There is no alarm.

ON or blinking

There is a fault alarm.

ON

The board is in active mode.

OFF

The board is in standby mode.

ON

The link is well connected.

OFF

The link is disconnected.

OFF

There is no data transmission over the Ethernet port.

Blinking

There is data transmission over the Ethernet port.

NOTE

For 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 fault location.

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. Instrument measurement results are widely used for power supply tests, signaling analysis, wave analysis, and bit error detection. For example, the procedure for troubleshooting high call drop 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.

Issue 01 (2011–8–17)


5


2 Troubleshooting Procedure NOTE

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

l

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

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

l

Signaling messages traced over interfaces Signaling messages are generally used to identify causes of call connection failures or intersite signaling interaction failures.

2.3 Determining a Fault Type After collecting fault information, analyze the symptoms to determine a fault type. You can also Contact Huawei Customer Service Center to determine a fault type. NOTE

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

2.3.1 Fault Types This section lists the fault types covered in this document. l

CS voice problems

l

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 NOTE

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

Issue 01 (2011–8–17)


6



2.3.2 Methods for Determining a Fault Type This section describes methods for determining a fault type. l

Monitoring Monitoring 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 counters This method can determine a fault type when performance counters deteriorate. With this method, 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 BSC deteriorate. For specific cases, see 4 Handover Problems.

l

Loopback tests Loopback tests can locate transmission, link, and voice problems. Loopback tests are classified into hardware loopback tests and software loopback tests. For specific cases, see 3.1.2 External Voice Loopback. You can determine whether equipment operates normally and software parameters are set correctly by checking the status of the transmission equipment, transmission channels, services, and signaling interaction status after loop back tests are performed. Loopback tests can also be performed to determine whether transmission faults occur or trunk parameters are set incorrectly. During site deployment or trunk capacity expansion, BSS trunk loopback tests can help determine whether trunk parameters and signaling link data are configured correctly. NOTE

Loopback tests are also performed to locate transmission faults.

l

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

l

Regularity identification Identifying problem regularity helps to narrow the fault range. When narrowing the fault range, consider the following factors:

Issue 01 (2011–8–17)

1.

Whether a certain board is faulty

2.

Whether a certain DSP is faulty

3.

Whether a certain transmission path is faulty

4.

Whether a certain TRX is faulty

5.

Whether a certain type of MS is faulty

6.

Whether a certain type of channel is faulty

7.

Whether an enabled feature is abnormal, such as Flex TSC, downlink power control, or BCCH power consumption reduction

8.

Whether an alarm is reported multiple times Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

7



For example, if a Cell Out of Service alarm is reported, check whether one or multiple cells are out of service. – If only one cell is out of service, the TRX serving this cell may be faulty, or the cell data configurations may be incorrect. – If multiple cells are out of service, determine whether these cells are served by one or multiple BTSs. – If these cells are served by one BTS, check whether any transmission alarms (such as LAPD or E1 alarms) are reported. If any transmission alarms are reported, a power failure or transmission faults may have occurred at the BTS. – If these cells are served by multiple BTSs, check whether these BTSs are located in the same area. If these BTSs are located in the same area, the power may have failed or the optical fibers in the area may be damaged. l

Comparison/Interchange Problems can be identified by comparing faulty components with normal components or by 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 be used 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 after troubleshooting cable connection faults, interchange the antenna system for the abnormal cell with that for a normal cell. If the interference is eliminated, the original antenna system is faulty. For details, see the typical case in 12.4 Troubleshooting Intermodulation Interference.

2.4 Identifying Fault Causes To 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 determine whether 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 tracing signaling messages. Then, determine the fault location according to protocols.

l

Subsystem faults Subsystem faults include clock, interface link, and equipment faults. These faults have narrow ranges and are generally associated with alarms. In addition, information including board indicators and error messages is available. Therefore, it is easy to identify the causes of subsystem faults.

Issue 01 (2011–8–17)


8



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

2.5.1 Overview Troubleshooting faults is a process of taking proper measures to rectify faults and restore a system to good working order. Methods for troubleshooting faults include cable connection check, board replacement, data configuration modification, board switchover, and board resetting. 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, and provide preventive and improvement measures. NOTE

When severe faults occur, Contact Huawei Customer Service Center.

2.5.2 Methods for Troubleshooting Faults This section provides methods for troubleshooting faults. l

Fault isolation Isolation is the act of isolating the fault location from the surrounding service unit to prevent the 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 in 7.4 Troubleshooting Noise.

l

Switchover/resetting During a switchover, services are switched from an active device to a standby device. You can compare the system operating status before and after the switchover. By resetting part of 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 equipment faults or operation instability. Resetting may lead to service interruptions or even system crash, affecting normal BSS operations. For example, some or all services over the A interface are interrupted. In this case, perform the following operations:

Issue 01 (2011–8–17)

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. Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

9


l


4.

When the BSC works in BM/TC separated mode, switch over the active and standby Ater 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.

Replacement If other methods are ineffective, replace faulty equipment such as boards, cables, or antennas. NOTE

1. If a fault persists after a board is replaced, reinsert the board instead of shipping the board back to Huawei headquarters. 2. If no equipment is available for replacing the faulty equipment, remove and then reinstall the equipment.

2.5.3 Follow-up Procedure This 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 verify that the faulty NE is operating normally. In addition, perform dialing tests and check traffic statistics to verify that services are operating properly.

l

If the fault persists, Contact Huawei Customer Service Center.

Issue 01 (2011–8–17)


10


3 Common Maintenance Functions

3

Common Maintenance Functions

About This Chapter This chapter describes common maintenance functions used during fault location. 3.1 Maintenance Functions for Identifying Voice Problems This section describes maintenance functions for identifying voice problems. 3.2 Maintenance Functions for Identifying Transmission Problems This section describes maintenance functions for identifying transmission problems. 3.3 Maintenance Functions for Identifying Um and RF Problems This section describes maintenance functions for identifying Um and RF problems. 3.4 Maintenance Functions Related to Interface Tracing This section describes maintenance functions related to interface tracing. 3.5 Maintenance Functions for Identifying PS Problems This section describes maintenance functions for identifying PS problems. 3.6 Maintenance Functions for Identifying Clock Problems This section describes maintenance functions for identifying clock problems.

Issue 01 (2011–8–17)


11



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

3.1.1 Querying Call Resource Usage of an MS This 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 identify BSS voice problems. The query can be performed by entering the MS's Mobile Station International ISDN Number (MSISDN), International Mobile Subscriber Identity (IMSI), Temporary Mobile Subscriber Identity (TMSI), or International Mobile Equipment Identity (IMEI).

Procedure 1.

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(By MSISDN), 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 of the peer end. When querying the call resource usage of the calling MS, set the MSISDN to the called number. When querying the call resource usage of the called MS, set the MSISDN to the calling 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 the reallocation policy configured on the MSC side. If the MS's TMSI is used to set up a call, set User Query Type to BYTMSI(By TMSI) to query the call resource usage. If the MS's IMSI is used to set up a call, set User Query Type to BYIMSI(By IMSI) to query the call resource usage. l If you set User Query Type to BYIMEI(By IMEI), determine whether the MSC can obtain the IMEI.

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 BM subrack, TC link, A interface, and Ater interface. The query result also includes information such as digital signal processor (DSP) number, channel number, service type, circuit identification codes (CICs) on the A interface, as well as timeslots occupied by the GEIUA, GEIUB, and GEIUT.

3.1.2 External Voice Loopback This section describes how to start or stop external voice loopback and query the status of the current voice loopback. Issue 01 (2011–8–17)


12



Function Description Voice 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 identified segment 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. Figure 3-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

Issue 01 (2011–8–17)


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 loopback testing on the TRU. Only IP BTSs and high-speed data link control (HDLC) BTSs support both MSCoriented 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/s whereas services are processed over the two interfaces at 16 Kbit/s or 8 Kbit/s. As a result, a loopback test of the channel used by one subscriber may lead to loopback tests of the channels used by other subscribers on the same 64 Kbit/s timeslot.

Procedure l

Choosing menu items 1.

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

2.

On the BSC Maintenance tab page, choose BSC Maintenance > Maintain User Resources > Remote Speech Channel Loopback. The Remote Speech Channel Loopback 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 is successfully started. NOTE

l If you select MSISDN in the Trace Object Symbol Type area, set the MSISDN to the number 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 Line Identification Presentation function must be enabled). l If you select TMSI or IMSI in the Trace Object Symbol Type area, confirm the reallocation 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 Object Symbol 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 to query the call resource usage. l If you select IMEI in the Trace Object Symbol Type area, determine whether the MSC can obtain the IMEI.

Issue 01 (2011–8–17)


14



4.

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

5.

Click Cancel stop the remote speech loopback. NOTE

To end a remote speech loopback, select IMSI, IMEI, TMSI, or MSIDSN in the Trace Object Symbol Type area to ensure that the parameter setting in the Trace Object Symbol Type area is 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 on the 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 stop the loopback.

Operation Results 1.

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 the channel used by subscriber A, subscriber A can hear his or her own voice and subscriber B 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 loopback on subscriber A.

2.

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

3.

When FG2a is configured over the A, Abis, or Ater interface, a subscriber can hear his or her own voice and the peer end's voice during a loopback over these interfaces, but the peer end 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 peer end's voice, but the peer end cannot hear any voice regardless of whether the loopback is MSC-oriented or MS-oriented.

5.

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

Interface Board Type

Subscriber A

Subscriber B

NSS Interface Unit (MSC Direction)

TDM interface board

Can hear B but not self

Can hear self but not A

IP/HDLC interface board

Cannot hear self or B


TDM interface board

Can hear self but not B

Can hear A but not self

NSS Interface Unit (MS Direction)

Issue 01 (2011–8–17)


15



Loopback Position and Direction


Subscriber A

Subscriber B



Cannot hear A or self

NSS TC (Near Abis Interface) (MSC Direction)



NSS TC (Near Abis Interface) (MS Direction)



NSS TC (Near A Interface) (MSC Direction)



NSS TC (Near A Interface) (MS Direction)



NSS TNU (Near Abis Interface) (MSC Direction)



NSS TNU (Near Abis Interface) (MS Direction)



NSS TNU (Near A Interface) (MSC Direction)



NSS TNU (Near A Interface) (MS Direction)



TDM interface board






TDM interface board






TDM interface board






NSS Ater Interface Unit (MSC Direction)

NSS Ater Interface Unit (MS Direction)

BSS Ater Interface Unit (MSC Direction)

Issue 01 (2011–8–17)


16





Subscriber A

Subscriber B

BSS Ater Interface Unit (MS Direction)

TDM interface board






BSS TC (Near Abis Interface) (MSC Direction)



BSS TC (Near Abis Interface) (MS Direction)



BSS TC (Near A Interface) (MSC Direction)



BSS TC (Near A Interface) (MS Direction)



BSS TNU (Near Abis Interface) (MSC Direction)



BSS TNU(Near Abis Interface) (MS Direction)



BSS TNU (Near A Interface) (MSC Direction)



BSS TNU (Near A Interface) (MS Direction)



TDM interface board






TDM interface board






Non-IP BTS



IP BTS



BSS Interface Unit (MSC Direction)

BSS Interface Unit (MS Direction)

TMU/PTU (MSC Direction)

Issue 01 (2011–8–17)


17





Subscriber A

Subscriber B

TMU/PTU (MS Direction)

Non-IP BTS



IP BTS



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

Function Description This function is used to detect one-way audio or no audio by checking uplink and downlink voice 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 the problems. 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 enabling one-way audio detection, ensure that the local switching function is disabled.

Procedure 1.

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 the log, 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 Detection This section describes how to detect crosstalk on the BSS. Issue 01 (2011–8–17)


18



Function Description 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

CAUTION This 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 Cross Call 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 recorded together with one-way audio logs. You can run the MML command COL LOG to obtain oneway 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 Crosstalk This section describes how to enable crosstalk optimization for the Um interface.

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

When this function is enabled, the BSC sends a Channel Rel message to the MS after a call is dropped. In addition, 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 by default.

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

3.2 Maintenance Functions for Identifying Transmission Problems This section describes maintenance functions for identifying transmission problems. Issue 01 (2011–8–17)


19



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

Function Description A crossed pair is classified into big crossed pair and small crossed pair. A big crossed pair refers to crossed TX/RX between two pairs of E1 cables, as shown in Figure 3-4. A small crossed pair refers to crossed TX/RX between an E1 cable in a pair and an E1 cable in another pair, as shown in Figure 3-5. When a crossed pair occurs on an E1 port of a device, the physical layer signals are available and no alarm is triggered. However, upper-layer links are disconnected and services are 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 crossed pair is occurring on E1 ports and provides the relevant problem location information. Crossed pair 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-based detection. If alarm-based detection is used, ensure that the connection to the peer port is normal and that no loopback occurs. If loopback detection is used, perform remote loopback by Issue 01 (2011–8–17)


20



connecting TX and RX ports (physical loopback) or by sending commands. Only physical loopback 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 loopback or physical loopback without modifying configuration data. Import the test data (containing the port number) into the local E1 port. After performing the loopback, check whether the received port information is the same as the imported data. If the received port information is the same as the imported data, the E1 cables are connected correctly. If the received port information is not the same as the imported data, the cables are crossed. 2. To perform alarm-based detection, do as follows: Disable the TX function of the local E1 port, which causes 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 local port 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 PEUa boards. l If the RX and TX connectors of the E1 cable for one port are incorrectly connected as a selfloopback 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 only on the active board. l When the E1 interface boards work in active/standby mode, alarm-based detection can be performed 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-based detection for online maintenance. l Crossed pair detection commands must be executed in sequence. The next command for crossed pair 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-based detection 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 whether cable connections are faulty, as shown in the following figure. +++ HUAWEI 2009-06-15 16:43:29 O&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. 0 15 0 (Number of results = 1) ---

Issue 01 (2011–8–17)

Check Result Not Cross

Cross Link No.

END


21



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

Function Description If 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 can evaluate the operating status of the transmission network and identify the causes for the bit errors in combination with the performance of the peer end. The AEUa/PEUa/EIUa/OIUa/POUc board supports this function.

Procedure 1.

On the LMT, click Monitor. The Monitor tab page is displayed.

2.

In the Monitor Navigation Tree, choose Monitor > Common Monitoring. Then, doubleclick BERS Monitoring.

3.

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

Operation Results After the monitoring task is started, a monitoring window is displayed, showing the real-time monitoring result by list and chart. The task name and related parameters are displayed in the title bar of the window, as shown in Figure 3-6. Figure 3-6 Monitoring results

3.3 Maintenance Functions for Identifying Um and RF Problems This section describes maintenance functions for identifying Um and RF problems. Issue 01 (2011–8–17)


22



3.3.1 Monitoring Channel Interference Bands This section describes how to view the interference band of idle channels to monitor interference on these channels.

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

Procedure l


On the LMT, click Device Maintenance. The Device Maintenance tab page is displayed.

2.

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

3.

On the displayed Monitor Channel Interference Band tab page, set the relevant parameters. Then, click Start. NOTE

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

l

Running MML commands Run the MML command DSP CHNJAM to monitor the interference band on a channel.

Operation Results Figure 3-7 is an example of the menu operation results. The interference bands on all the channels are displayed and refreshed every 10s. Figure 3-7 Monitor Channel Interference Band dialog box

3.3.2 Detecting Intermodulation Interference by Testing Idle Timeslots This section describes how to detect intermodulation interference to a network by testing idle timeslots on the network. Issue 01 (2011–8–17)


23



Function Description In the network optimization phase, to determine whether a certain network is experiencing intermodulation interference, dummy bursts are sent to all idle timeslots in a specific area to cause the strongest interference to the network. A dummy burst test can take between 1 and 24 hours. 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 within the specified test time. The idle timeslot test is used to test the power on top of the cabinet for a TRX 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 idle timeslot test.

l

Choosing menu items

Procedure 1.


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

l

Running MML commands Start or stop the operation by running the following commands:

Issue 01 (2011–8–17)


24



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

Operation Results l

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 whether intermodulation interference increases.

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

Issue 01 (2011–8–17)


25



Function Description This function is performed on idle channels to obtain the interference level of configured frequencies. This function is used to identify frequencies with minor interference by determining whether one or more frequencies are experiencing interference.

Procedure 1.


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

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

CAUTION Start querying the frequency scan results immediately after the frequency scan is configured. Otherwise, the query results cannot be reported. Figure 3-11 Querying frequency scan results

Operation Results Figure 3-12 shows an example of frequency scan results. The scan results may be reported about five to six minutes after the scan is started. After the scan results are reported, record the data about the scanned frequencies by copying and pasting the data in an .xls document. Issue 01 (2011–8–17)


26



Figure 3-12 Frequency scan results

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

Issue 01 (2011–8–17)


27



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

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

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

Procedure 1.

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 internal modules. 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 Other tab page.

Issue 01 (2011–8–17)


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 the peer 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 the called MS. l If you trace the user messages by TMSI or IMSI, check the reassignment policies on the MSC side: 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 Results l

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 Traced Messages Offline. – A window shown in Figure 3-15 is displayed if the Report trace mode is selected. The message browsing window displays information about each traced message, including the 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 Subscriber This section describes how to trace messages of a single subscriber on the Gb, Abis, or Um interface as well as trace internal messages or Um data blocks for a single subscriber. Issue 01 (2011–8–17)


29



Function Description 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 the subscriber by the IMSI or temporary link level identity (TLLI). You can perform this task to locate a fault in the PS domain in the following procedures: PS service channel assignment failure, abnormal TBF release, and PS packet loss or disconnection.

Procedure 1.

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 selected under Trace Interface Type. – If you start tracing by TLLI, query the TLLI of the MS by running the DSP MSCONTEXT command. During the PS service, the TLLI may be reassigned to the MS. In this case, run this command to query the new TLLI for the tracing operation. l Report Mode: When Trace Um Datablock Message is selected, Um datablock messages are reported. When Abis Interface is selected, MAC Report must be selected

Issue 01 (2011–8–17)


30



and TRAU Report must be deselected. In this case, messages are reported in the message format of the Um interface. l For the description of Trace Mode, see Trace Mode. 4.

Click Submit.

Operation Results l

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 Traced Messages Offline. – A window shown in Figure 3-17 is displayed if the Report trace mode is selected. The message browsing window displays information about each traced message, including the 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 Problems This section describes maintenance functions for identifying PS problems.

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

Function Description If a built-in PCU is configured, you can query the LMT for information about the physical data channel (PDCH) by using the channel status monitoring function. The information includes Applied Bandwidth, Available Bandwidth, Uplink GPRS TBF, Downlink GPRS TBF, Uplink EGPRS TBF, and Downlink EGPRS TBF. Issue 01 (2011–8–17)


31



Procedure NOTE

In the Device Navigation Tree, right-click the target BTS, cell, or TRX, and choose Monitor Channel Status 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 has eight sub-channels, the full-rate TCH has only one sub-channel, and the half-rate TCH has two subchannels. 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 corresponding indicator, you can view the current channel type, applied bandwidth, and available bandwidth from the pop-up information. The applied bandwidth and the available bandwidth are equal and both bandwidths are greater than or equal to 16 Kbit/s. The number of uplink or downlink TBF blocks is 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 popup information. The applied bandwidth is not equal to the available bandwidth, or the available bandwidth 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 Results Figure 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.

Issue 01 (2011–8–17)


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 channel is 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 Problems This section describes maintenance functions for identifying clock problems.

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

Function Description 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 switching clock sources. If the clock source level is Unavailable, or Phase-locked loop state of current clock is Unknown, the clock source is lost. In this case, contact the maintenance engineers to resolve the problem until the clock source level is Available, or Phase-locked loop state of current clock is Trace.

Issue 01 (2011–8–17)


33



Procedure l



2.

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

3.

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

Figure 3-20 Querying BSC clock source status

l

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

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

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

Issue 01 (2011–8–17)


34



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

Procedure l



2.

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

3.

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

Figure 3-21 Querying results of BSC Board Clock Status

l

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

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

Function Description This function is used to query the board clock information and clock type of a BTS. Issue 01 (2011–8–17)


35



Procedure l

Choosing menu items – 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

l

Running MML commands – 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.

Issue 01 (2011–8–17)


36


4 Handover Problems

4

Handover Problems

About This Chapter This chapter describes how to locate and troubleshoot handover problems. 4.1 Handover Principles Handovers are performed to ensure service continuity during MS movement and to optimize network performance. 4.2 Locating Handover Problems This section describes how to locate handover problems. 4.3 Troubleshooting Handover Problems Due to Hardware Faults This section describes how to troubleshoot handover problems due to hardware faults. 4.4 Handover Problems Due to Incorrect Data Configurations This section describes how to troubleshoot handover problems due to incorrect data configurations. 4.5 Troubleshooting Handover Problems Due to Traffic Congestion in the Target Cell This section describes how to troubleshoot handover problems due to traffic congestion in the target cell. 4.6 Troubleshooting Handover Problems Due to Poor Um Interface Quality This section describes how to troubleshoot handover problems due to poor Um interface quality. 4.7 Troubleshooting Handover Problems Due to NE Faults This section describes how to troubleshoot handover problems due to NE faults. 4.8 Troubleshooting Handover Problems Due to Inappropriate 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.

Issue 01 (2011–8–17)


37


4 Handover Problems

4.1 Handover Principles Handovers are performed to ensure service continuity during MS movement and to optimize network performance. Before a handover, the in-service MS and the serving BTS evaluate the quality of downlink and uplink radio links respectively and submit the measurement reports to the BSC.The BSC then determines whether to trigger a handover based on the measurement reports and actual network conditions.

4.1.1 Handover Procedure This section describes the handover procedure. The intra-BSC handover is used as an example. Figure 4-1 shows an intra-BSC handover procedure.

Issue 01 (2011–8–17)


38


4 Handover Problems

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 the Um 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 Channel Activation message to BTS 2 (the target BTS).

4.

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

Issue 01 (2011–8–17)


39


4 Handover Problems

5.

The BSC sends a Handover Command message to BTS 1, which forwards this message to the 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 this message, 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 be reassigned.

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

Formula Handover 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 Procedures Figure 4-2 and Figure 4-3 show the measurement points in the signaling procedures for intraBSC handovers and inter-BSC handovers respectively.

Issue 01 (2011–8–17)


40


4 Handover Problems

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-Cell Handover Requests B1: CH321: Number of Incoming Internal Inter-Cell Handover Responses and CH301:Internal Intra-Cell Handover Commands C1: CH323:Number of Successful Incoming Internal Inter-Cell Handovers and CH303:Successful Internal Intra-Cell Handovers

Issue 01 (2011–8–17)


41


4 Handover Problems

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

A2: CH340:Incoming External Inter-Cell Handover Requests B2: CH341:Incoming External Inter-Cell Handover Responses C2: CH343:Successful Incoming External Inter-Cell Handovers A3: CH330:Outgoing External Inter-Cell Handover Requests B3: CH331:Outgoing External Inter-Cell Handover Commands C3: 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-Cell Handovers + C3)/(A1: CH320:Number of Incoming Internal Inter-Cell Handover Requests + A3)

l

Radio handover success rate = (C1: CH323:Number of Successful Incoming Internal InterCell Handovers + C3)/(B1: CH321: Number of Incoming Internal Inter-Cell Handover Responses + 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

Issue 01 (2011–8–17)


42


l

4 Handover Problems

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

You can compare the handover success rate with the radio handover success rate to determine whether a handover is caused by Um interface problems. l If the handover success rate is lower than the radio handover success rate, check for problems related to terrestrial links and network capacity. l If both the handover success rate and the radio handover success rate are low and nearly equal, check for interference and coverage problems.

4.2 Locating Handover Problems This section describes how to locate handover problems.

4.2.1 Principles Handover problems may be caused by inappropriate data configurations, hardware faults, interference, or poor Um interface quality. Determine the specific cause of a handover problem before resolving the problem. Determine whether a handover problem occurs on an entire network or in a cell based on the fault range and background information. l

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

l

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

Handover problems can be located using the following methods: 1.

Analyzing handover traffic statistics

2.

Checking for top N cells with severe handover problems

3.

Checking for equipment and transmission alarms

4.

Checking for interference and coverage problems

5.

Checking neighboring cell planning data

6.

Checking parameter settings

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

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

Issue 01 (2011–8–17)


43


4 Handover Problems

Figure 4-4 Common procedure for locating handover problems

Location Procedure 1.

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.

Issue 01 (2011–8–17)


44


4 Handover Problems

– 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 InterBSC/Inter-MSC/Inter-RAT Interaction. Then, check whether the handover problem is resolved. – If yes, no further action is required. – If no, go to Step 3.

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. – If yes, no further action is required. – If no, go to Step 4.

4.

Check whether handover data configurations are correct. l If yes, go to Step 5. l If no, go to 4.4 Handover Problems Due to Incorrect Data Configurations. Then, check whether the handover problem is resolved. – If yes, no further action is required. – If no, go to Step 5.

5.

Check whether the channels of the target cell are congested. l If no, go to Step 6. l If yes, go to 4.5 Troubleshooting Handover Problems Due to Traffic Congestion in the Target Cell. Then, check whether the handover problem is resolved. – If yes, no further action is required. – If no, go to Step 6.

6.

Check whether the Um interface quality is poor. l If no, go to Step 7. l If yes, go to 4.6 Troubleshooting Handover Problems Due to Poor Um Interface Quality. Then, check whether the handover problem is resolved. – If yes, no further action is required. – If no, go to Step 7.

7.

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

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

Issue 01 (2011–8–17)


45


4 Handover Problems

Symptom When a hardware fault occurs in a cell, the alarm system reports correlated alarms such as transmission alarms and TRX alarms. If a handover problem occurred but data configurations are not modified for the problem cell and its neighboring cells, check for BTS hardware faults.

Background Information The alarms related to hardware faults are as follows: l

ALM-21807 OML Fault Link access procedure on the D channel (LAPD) links are required for communication over the data link layer between the BSC and a BTS. Links used for receiving and transmitting operation 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 that the LAPD_OML to a BTS is interrupted, or that the handshake between the BSC and a BTS 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 alarm These alarms are reported when a LAPD link is interrupted and the related TRX cannot communicate with the BSC. As a result, the TRX cannot provide services and shuts down the power amplifier. If this TRX is a BCCH TRX, the cells served by the TRX cannot provide services.

l

ALM-2204 TRX Communication Alarm This alarm is reported when the communication between a TRX and the TMU failed. When this 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 Crossed These alarms are reported when the voltage standing wave ratio (VSWR) detected over a TRX power output port exceeds 3 or when the cable is not properly connected to a DTRU power output port (TX1, TX2, or TCOM). When this alarm is reported, the services processed by the TRX are interrupted.

l

ALM-28008 Radio Link Failure This 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

Issue 01 (2011–8–17)


46


4 Handover Problems

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

Location Procedure Figure 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 Procedure 1.

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 Case Symptom The success rate for handovers between all the cells under a BTS and their neighboring cells under another BTS is 10.7%, whereas normally the success rate should be at least 98%. The success rate for handovers between the cells under the same BTS is 99.2% during peak hours. Cause Analysis Issue 01 (2011–8–17)


47


4 Handover Problems

Possible causes for this problem are: hardware faults, cell channel congestion, incorrect neighboring cell configurations, and clock source exceptions. Troubleshooting Procedure 1.

Check whether neighboring cells are configured properly using a network optimization tool. Then, check whether any neighboring relationships are missing or redundant on the LMT. 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 TRX alarms listed in Background Information are reported.

3.

Check the TMU. A clock source exception alarm listed in Background Information is reported.

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 Data Configurations This section describes how to troubleshoot handover problems due to incorrect data configurations.

Symptom l

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 the number of call drops.

l

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

Background Information l

Impact of handover threshold settings Edge handovers are performed when the receive level is continuously less than the value of Edge HO UL RX_LEV Threshold or Edge HO DL RX_LEV Threshold during a specified period. Generally, Edge HO UL RX_LEV Threshold is set to 10, and Edge HO DL RX_LEV Threshold is set to 20 in handover algorithm I or 15 in handover algorithm II. If Edge HO UL RX_LEV Threshold or Edge HO DL RX_LEV Threshold is set too low, a handover cannot be initiated when it should be. If Edge HO UL RX_LEV Threshold or Edge HO DL RX_LEV Threshold is set too high, handovers are performed frequently, which reduces the cell coverage area and leads to call drops. Therefore, set Edge HO UL RX_LEV Threshold and Edge HO DL RX_LEV Threshold to appropriate values based on the cell coverage. Changing the value of Edge HO UL RX_LEV Threshold 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_LEV Threshold or Edge HO DL RX_LEV Threshold by 2 dB to 5 dB to expedite handovers to a suitable neighboring cell.

l

Impact of neighboring cell configurations If neighboring relationships are not configured or configured incorrectly even though the signal level of a neighboring cell is high, the MS may report incorrect neighboring cell

Issue 01 (2011–8–17)


48


4 Handover Problems

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

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

l

Inappropriate data configurations for cells with repeaters or RXU co-cells Inappropriate data configurations for cells with repeaters or RXU co-cells may lead to asynchronous handover failures.

l

Impact of hysteresis configurations The difference between the signal level of a candidate cell and that of the serving cell must be greater than the handover hysteresis. Therefore, a large handover hysteresis may lead to handover failures. If the serving cell coverage is weak, decrease the handover hysteresis by 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 time During common handovers, an MS selects the target cell according to the N/P criteria. That is, the MS selects the optimal cell for P seconds in N seconds as the target cell. If two cells are the optimal cell alternatively, a handover may fail because the handover algorithm cannot determine the target cell. In this case, reduce the optimal cell measurement time by adjusting the values of N and P and ensure that the handover decision is more sensitive to level changes. Handover failures may also occur when the receive level of a moving MS fluctuates significantly in a serving cell with complex topography, which makes it difficult for 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 Procedure Figure 4-6 shows the procedure for locating handover problems due to incorrect data configurations.

Issue 01 (2011–8–17)


49


4 Handover Problems

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


Run the MML command LST GCELLHO2GBA2 to check whether neighboring cells are configured correctly, especially whether any neighboring cells are missing based on measurement reports, onsite network planning data, and engineering parameter settings. Then, run the MML command LST GCELLIDLEBASIC to check whether NCC permitted for the serving cell is set correctly. l If yes (see Background Information), go to Step 2.

Issue 01 (2011–8–17)


50


4 Handover Problems

l If no, adjust neighboring cell configurations, or run the MML command SET GCELLIDLEBASIC to set NCC permitted to its correct value 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. 2.

Check whether the problem cell is configured with a repeater or an RXU co-cell based on the 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 is resolved. – 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 UL RX_LEV Threshold and Edge HO DL RX_LEV Threshold are set correctly by referring to 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 HO Hysteresis 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, check whether the handover problem is resolved. – If yes, no further action is required. – If no, go to Step 5.

5.

Run the MML command LST GCELLHOBASIC to check whether parameters relevant to optimal cell measurement time such as Handover algorithm II Edge HO Watch Time and Handover algorithm II Edge HO Valid Time are set correctly by referring to Background Information. l If yes, go to Step 6. 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 6.

6.


Typical Case Symptom Issue 01 (2011–8–17)


51


4 Handover Problems

The handover success rates for some cells are low. The outgoing handovers in these cells are normal, but the number of incoming cell handovers is 0. Cause Analysis Possible causes for this problem are: incorrect data configurations, interference. Troubleshooting Procedure 1.

Check whether the neighboring cells of the problem cell work on the same frequency and have 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 small number of call drops and handovers due to poor voice quality in the problem cell. Even if there is strong interference for the problem cell, at least one handover can be performed successfully. 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 the neighboring cells has not been changed. As a result, the BSC cannot locate the target cell after 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 Traffic Congestion in the Target Cell This section describes how to troubleshoot handover problems due to traffic congestion in the target cell.

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

Background Information The 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: Issue 01 (2011–8–17)


52


l

4 Handover Problems

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 TCH

l

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 Procedure Figure 4-7 shows the procedure for locating handover problems due to traffic congestion in the target cell. Figure 4-7 Procedure for locating handover problems due to traffic congestion in the target cell


View the traffic statistics associated with TCH congestion rates listed in Background Information over several periods to determine whether serious TCH congestion occurred in 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 is set 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 is resolved.

Issue 01 (2011–8–17)


53


4 Handover Problems

– 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 to Yes. 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 the handover problem is resolved. If yes, no further action is required. If no, go to Step 3. 3.


Typical Case Symptom 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.


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 congested and handover resources are insufficient.

5.

Expand the BTS capacity. The handover problem is resolved.

4.6 Troubleshooting Handover Problems Due to Poor Um Interface Quality This section describes how to troubleshoot handover problems due to poor Um interface quality. Issue 01 (2011–8–17)


54


4 Handover Problems

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


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 intermodulation interference, CDMA network interference, and uplink or downlink intra-system interference. – The common methods for locating interference are as follows: – Interference bands are the bands of uplink interference levels on each TCH that the BTS reports to the BSC when TCHs are in the idle state. There are five interference bands. The higher the interference band, the higher the interference level. The level ranges for the five interference bands are as follows: – Interference band 1: -105 to -98 dBm – Interference band 2: -98 to -90 dBm – Interference band 3: -90 to -87 dBm – Interference band 4: -87 to -85 dBm – Interference band 5: -85 to -47 dBm – Analyze Interference Band Measurement per TRX (MR.Iterf.TRX). If the number of interference levels in the high interference bands is great, for example, if the percentage of interference levels in interference bands 4 or 5 exceeds 30%, there is interference. – 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 on the live network. Then eliminate the interference by changing the frequency, or by adjusting the antenna tilt, transmit power, or cell coverage.

l

If the Um interface quality is poor, MSs cannot receive any handover commands or physical information. As a result, MSs send handover failure messages with one of the following cause values: unspecified, timer expiry, protocol error, and other causes. – The method for checking the Um interface quality is described as follows:

Issue 01 (2011–8–17)


55


4 Handover Problems

Analyze Receive Quality Measurement Distribution per TRX (MR.RecvQualOrig.TRX) to check the Um interface quality. Receive Quality Measurement Distribution per TRX(MR.RecvQualOrig.TRX) measures the distribution of receive quality in the measurement reports received on TCHs. The receive quality is divided into eight bands ranging from band 0 to 7. Each receive quality band corresponds to a bit error rate (BER) range. A higher receive quality band indicates a higher BER and poorer receive quality. If the percentage of uplink or downlink receive quality bands 6 and 7 exceeds 10%, the uplink or downlink transmission quality on the Um 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 interface quality is not improved, perform DTs to locate and resolve the problem associated with the receive quality and receive level. This is especially important if the problem is a high receive level and poor receive quality.

Location Procedure Figure 4-8 shows the procedure for locating handover problems due to poor Um interface quality. Figure 4-8 Procedure for locating handover problems due to poor Um interface quality

Issue 01 (2011–8–17)


56


4 Handover Problems


View the traffic statistics associated with interference bands listed in Background Information to determine whether there is interference in the cell. Generally, there is interference in the cell if the percentage of interference levels in interference bands 4 and 5 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 yes, no further action is required. – 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 percentage of 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 yes, no further action is required. – If no, go to Step 3.

3.


Typical Case Symptom The intra-BSC incoming radio handover success rate for a cell under a BTS is between 10% and 30%, 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 is weak. Troubleshooting Procedure 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 frequently performed. If the MS fails to hand over to the target cell, the MS attempts to hand over back to the source cell. Handovers to the source cell are sometimes successful, but the call is 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 calling MS, the dialing tests fail. When the MS serves as the called MS, calls are connected but dropped immediately. The problem location result indicates that the faulty components in

Issue 01 (2011–8–17)


57


4 Handover Problems

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

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

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

Symptom Handover failures occur in most cells under a BSC, but there are no top N cells with sluggish performance.


Handover failures occur when the BSC clock source operates abnormally. You can run the MML command DSP CLK to check whether the BSC clock source operates 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 board that retrieves line clock signals reports any of the following alarms. If any of the following 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. If Phase-locked loop state of current clock is set to Trace or any of the following alarms are not reported, switch over the active and standby GCUa boards or replace the active GCUa with a new one to resolve the BSC clock source problem. If the BSC clock source problem persists, Contact Huawei Customer Service Center. ALM-21201 E1/T1 Loss of Signal ALM-21202 E1/T1 Loss of Frame Alignment ALM-21203 E1/T1 Remote Alarm Indication Signal ALM-21204 E1/T1 Alarm Indication Signal ALM-21205 E1/T1 Loss of Multiframe Alignment ALM-21206 E1/T1 Loopback ALM-21207 E1/T1 Excessive Bit Error Rate ALM-21208 E1/T1 Excessive Slip Frames ALM-21209 E1/T1 Online Loopback Detection ALM-21252 SDH/SONET Loss of Signal ALM-21253 SDH/SONET MS Remote Defect Indication ALM-21254 SDH/SONET Loss of Frame ALM-21255 SDH/SONET Loss of Frame Alignment ALM-21256 SDH/SONET Loss of Cell Delineation

Issue 01 (2011–8–17)


58


4 Handover Problems

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 operates normally.

Location Procedure Figure 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


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.

2.


Typical Case Symptom There are 140 BTSs served by a BSC. The TMU clocks for 27 of the 140 BTSs are in the pullin state, and the TMU clocks for 38 BTSs are in the free-run state. The handover success rate of the 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. Issue 01 (2011–8–17)


59


4 Handover Problems


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 the handover 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 or free-run state. Regarding the BTSs that properly trace the BSC clock, the current values of these clocks are not between 1500 and 1900 and largely different from the default values and standard values. The difference values are larger than 1000. This indicates that the BSC clock may be unreliable. However, the BSC clock check result shows that the BSC clock is operating properly.

5.

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

Figure 4-10 Network topology

6.

Issue 01 (2011–8–17)

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 locked state, but clocks for 42 BTSs are still in the pull-in state and clocks for 15 BTSs are still in the free-run state. Six hours later, all clocks for the problem BTSs under the BSC are in the locked state. According to the traffic statistics, the handover success rate has increased from 84% to 97%.


60


4 Handover Problems

4.8 Troubleshooting Handover Problems Due to Inappropriate 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.

Symptom l

The inter-BSC handover failure rate is high.

l

The inter-RAT handover failure rate is high.

Background Information The 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 includes cell 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 Procedure Figure 4-11 shows the procedure for locating handover problems due to inappropriate interBSC, inter-MSC, or inter-RAT interaction.

Issue 01 (2011–8–17)


61


4 Handover Problems

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


Issue 01 (2011–8–17)

Run the MML command DSP CLK to check whether the BSC properly traces the upperlevel clock (MSC clock). Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

62


4 Handover Problems

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 correct based on the network planning data and engineering parameters of the live network. Also check 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. The data includes CGI, LAC, and handover number as well as the office to which the problem cell 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 the signaling 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 interactions between 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 between networks. Then, check whether the handover problem is resolved. – If yes, no further action is required. – If no, go to Step 6.

6.


Typical Case 1 Symptom According to traffic statistics, the handover success rate for BSC A is lower than the handover success rates for other BSCs. However, the historical traffic statistics show that the handover success rate for BSC A is about 88%. Issue 01 (2011–8–17)


63


4 Handover Problems

Cause Analysis The MSC is not configured with any external LAC data. Troubleshooting Procedure 1.

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

2.

View the cell-level inter-BSC handover success rates. The inter-BSC handover success rates for some cells are small. The geographic display of these problem cells shows that these 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 not synchronized because modifications to data configurations for vendor B's equipment were performed without notification. However, the check result of neighboring cell data shows that the data is configured correctly.

3.

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

4.

Contact MSC maintenance engineers to analyze the problem. The MSC is not configured with 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 success rate for vendor M's network is low, but other performance counters are normal. BSC TP 01 and BSC 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 is incorrect. As a result, the encryption algorithm used by the MS is not the same as that used by vendor M's BTS during handovers. Troubleshooting Procedure 1.

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

2.

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

3.

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

Issue 01 (2011–8–17)


64


4 Handover Problems

4.

The BSC does not obtain the encryption algorithm change information from the HO REQ ACK 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 Info message from vendor M's BTS because the Physical Info message is encrypted by the A5/1 algorithm. As a result, the MS fails to access vendor M's network and is handed over back to the original channel.

6.

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

Issue 01 (2011–8–17)


65


5 Call Drops

5

Call Drops

About This Chapter This chapter describes how to locate and troubleshoot call drops. 5.1 Call Drop Rate The call drop rate indicates the probability with which an MS will release ongoing calls unexpectedly after accessing a TCH. A high call drop rate may significantly deteriorate user experience. 5.2 Locating Call Drops This section describes how to locate call drops. 5.3 Troubleshooting Call Drops Due to Poor Um Interface Quality This section describes how to troubleshoot call drops due to poor Um interface quality. 5.4 Troubleshooting Call Drops Due to Equipment Faults This section describes how to troubleshoot call drops due to equipment faults. 5.5 Troubleshooting Call Drops Due to Transmission Faults This section describes how to troubleshoot call drops due to transmission faults. 5.6 Troubleshooting Call Drops Due to Incorrect Parameter Settings This section describes how to troubleshoot call drops due to incorrect parameter settings.

Issue 01 (2011–8–17)


66


5 Call Drops

5.1 Call Drop Rate The call drop rate indicates the probability with which an MS will release ongoing calls unexpectedly after accessing a TCH. A high call drop rate may significantly deteriorate user experience.

Formula See the online help for the formulas for calculating the following counters associated with call drops: 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 stable state. With regard to the formulas for calculating the two counters, the numerators in both formulas 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 Procedure See 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 two types: l

Call drops in the stable state, as shown in Figure 5-1

l

Call drops in the handover state, as shown in Figure 5-2

Issue 01 (2011–8–17)


67


5 Call Drops

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 Drops This section describes how to locate call drops.

5.2.1 Procedure for Locating Call Drops Before locating call drops, determine the fault range. Issue 01 (2011–8–17)


68


5 Call Drops

Principles l

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 drops are caused by poor Um interface quality. – If the values of CM333:Call Drops due to Abis Terrestrial Link Failure (Traffic Channel) 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 equipment and transmission faults. – If the counters indicating call drops due to poor Um interface quality increase, check for 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

Issue 01 (2011–8–17)


69


5 Call Drops

5.2.2 Counters Related to Call Drops The counters related to call drops are classified according to call drop type for easy troubleshooting. 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 Traffic Channel

CM33C:Call Drops on Radio Interface (Traffic Channel)

CM330:Call Drops on Radio Interface in Stable State (Traffic Channel) CM331:Call Drops on Radio Interface in Handover State (Traffic Channel)

CM332:Call Drops Due to No MR from MS for a Long Time (Traffic Channel)

/

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

/

CM334:Call Drops due to Equipment Failure (Traffic Channel)

/

CM335:Call Drops due to Forced Handover (Traffic Channel)

/

CM397:Call Drops due to local switching Start Failure

/

CM385:Call Drops due to Failures to Return to Normal Call from local switching

/

CM33C:Call Drops on Radio Interface (Traffic Channel) indicates call drops due to poor Um interface quality, which is the most common cause of call drops on a network. CM333:Call Drops due to Abis Terrestrial Link Failure (Traffic Channel) and CM334:Call Drops due to Equipment Failure (Traffic Channel) indicate call drops due to transmission and equipment faults, 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.

Issue 01 (2011–8–17)


70


5 Call Drops

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 Radio Interface (Traffic Channel)

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

CM3300:Call Drops on Traffic Channel in Stable State (Error Indication) CM3301:Call Drops on Traffic Channel in Stable State (Connection Failure) CM3302:Call Drops on Traffic Channel in Stable State (Release Indication)

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

H3027Ca:Failed Internal Intra-Cell Handovers (Timer Expired) (TCHF) (Traffic Channel) H3028Ca:Failed Internal Intra-Cell Handovers (Timer Expired) (TCHH) (Traffic Channel) H3127Ca:Number of Unsuccessful Outgoing Internal Inter-Cell Handovers (Timer Expired) (TCHF) (Traffic Channel) H3128Ca:Number of Unsuccessful Outgoing Internal Inter-Cell Handovers (Timer Expired) (TCHH) (Traffic Channel) H3327Ca:Failed Outgoing External Inter-Cell Handovers (T8 Expiry) (TCHF) (Traffic Channel) H3328Ca:Failed Outgoing External Inter-Cell Handovers (T8 Expiry) (TCHH) (Traffic Channel)

l

Issue 01 (2011–8–17)

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


71


5 Call Drops

l

In the handover state, focus on H3127Ca:Number of Unsuccessful Outgoing Internal InterCell Handovers (Timer Expired) (TCHF) (Traffic Channel) and H3128Ca:Number of Unsuccessful Outgoing Internal Inter-Cell Handovers (Timer Expired) (TCHH) (Traffic Channel) 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 special attention.

5.2.3 Types of Call Drops Classifying call drops into different types helps troubleshoot call drops. Figure 5-4 describes the types and common causes of call drops.

Issue 01 (2011–8–17)


72


5 Call Drops

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 the following messages: Issue 01 (2011–8–17)


73


l

5 Call Drops

ERROR INDICATION – When the BTS sends an I frame, the timer T200 starts. If the BTS does not receive an acknowledgment message from the BSC before the timer expires, it resends the I frame for a maximum of 200 times. If the BTS still does not receive an acknowledgment message, the BTS sends the BSC an ERROR INDICATION message with a cause value of 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 sequence error (0x07). – When the BTS receives an unexpected DM frame, the BTS sends the BSC an ERROR INDICATION with a cause value of unsolicited DM response (0x05). – The call drops indicated by the ERROR INDICATION message are generally caused by interference or coverage problems, though they may also be caused by inappropriate antenna installation, TRX faults, or incorrect data configurations.

l

CONNECTION FAILURE INDICATION – If the BTS detects that uplink SACCH decoding fails repeatedly within the value specified by SACCH Multi-Frames, the BTS sends a CONNECTION FAILURE INDICATION message to the BSC. – The call drops indicated by the ERROR INDICATION message are generally caused by interference or coverage problems, though they may also be caused by inappropriate antenna 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 RELEASE INDICATION message seldom occur. They may be caused by inappropriate signaling interaction problems between the MS and the BSS/NSS, not by poor Um interface quality.

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 an acknowledgment message before the relevant timer expires. l

Intra-cell handovers When Intracell HO Allowed is set to YES(YES) by using the MML command SET GCELLHOBASIC, 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-cell handovers may increase the call drop rate.

l

Inter-cell handovers Call drops during inter-cell handovers are generally caused by interference or coverage problems, though they may also be caused by inappropriate antenna installation, TRX faults, incorrect neighboring cell configurations, or a large clock frequency offset.

l

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

Issue 01 (2011–8–17)


74


5 Call Drops

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

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 BSC does not receive any measurement reports from an MS within a specified period (five minutes by 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 interaction between the BSS and the MS. For example, check whether the BTS can decode the extended measurement 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 BSC detects that radio signaling links (RSLs) are interrupted because the Abis transmission or the BSC/BTS LAPD link transmission is faulty. In this case, check the relevant alarms, Abis transmission, 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 incorrect data configurations. It may also occur in cases of dynamic data configuration (such as frequency modification or cell deletion) or internal BSC network connection failures. When this type of call 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 triggered by the following causes time out: TRX cooperation, channel preemption, cell/TRX/channel blocking, or OM. Dynamic channel adjustment, TRX cooperation, and channel preemption are the most common causes. If there are a large number of such call drops, check whether the data configuration is correct and whether TRXs become faulty frequently.

5.3 Troubleshooting Call Drops Due to Poor Um Interface Quality 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 the stable state and call drops for the Um interface in the handover state. l

Issue 01 (2011–8–17)

With regard to the signaling on the Abis interface, call drops for the Um interface in the stable state refer to the call drops that occur after the BTS sends an ERROR INDICATION, CONNECTION FAILURE INDICATION, or RELEASE INDICATION message to the BSC. Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

75


l

5 Call Drops

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

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


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 call drops are caused by incorrect BSC handover parameter settings or incorrect neighboring cell configuration for handover, analyze the problem by referring to 4 Handover Problems. 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 proportion of uplink receive quality in receive quality bands 5, 6, and 7 exceeds 20%, there is a high probability that call drops will occur.

2.

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

3.

Use either of the following methods to determine whether call drops are caused by interference. One method is to analyze the signaling on the Abis interface. If the measurement reports (MRs) before call drops show that both the uplink and downlink levels are satisfactory but the receive quality is poor, call drops are caused by interference. The other method is to analyze the TEMS signaling collected when call drops 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 Procedure Figure 5-5 shows the procedure for locating call drops due to poor Um interface quality.

Issue 01 (2011–8–17)


76


5 Call Drops

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


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 interference sources exist onsite or perform drive tests (DTs) to locate the interference source. In addition, check whether repeaters have been installed or whether installed repeaters are faulty 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 BTS Flag is set to Yes. If Directly Magnifier BTS Flag is set to Yes, the cell is configured with repeaters. If Directly Magnifier BTS Flag is set to No, check whether other operators' repeaters are installed near the cell or whether any repeaters are installed without permission.

Issue 01 (2011–8–17)


77


5 Call Drops

(2) If repeaters are installed, check whether they are wideband repeaters. If they are wideband repeaters, check whether the uplink or downlink gain is large. If the uplink or downlink gain is large, reduce it as required. Shut down the repeaters if they have great impact on the call drop rate. (3) Check whether repeaters are faulty or whether the uplink or downlink gain is beyond the normal range. If repeaters are faulty or the uplink or downlink gain is beyond the normal range, the actual BTS coverage may change, which increases the call drop rate. If any repeater problem occurs in the cell, the number of MRs with a large timing advance (TA) value measured for Number of MRs based on TA 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 or 11 to all uplink and downlink level balance classes exceeds 30%, the uplink and downlink levels are unbalanced. NOTE

Uplink-and-Downlink Balance Measurement per TRX(MR.BalanceOrig.TRX) indicates the statistical result of MRs. If the MRs before call drops show that the uplink and downlink levels are unbalanced, then this 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 to the following description. 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. – 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 the downlink signal level, and call drops are likely to occur in a cell far away from the BTS. 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 drops occur with a high probability. Locate these kinds of problems by referring to ALM-4144 TRX VSWR alarm, ALM-2156 TRX VSWR Alarm, or ALM-26529 RF 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 are high, and the uplink and downlink receive quality is totally different or both the uplink and downlink receive quality is poor. 4.


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

Issue 01 (2011–8–17)


78


5 Call Drops

(MR.RecvLevlOrigHalfRate.TRX) to analyze the mapping between the receive quality 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 from coverage problems. (2) Analyze Number of MRs based on TA per TRX(MR.TaDistribOrig.TRX). If there are many MRs with a large TA value, the call drops are caused by too-wide coverage or 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 large when 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 value is 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 is less than 90%, check for a coverage problem in the cell based on the coverage scenario and 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 6 l If no, go to Step 7. 6.


7.

Check the Um interface quality. Query TCHF Receive Level Measurement per TRX(MR.RecvLevlOrigFullRate.TRX) or TCHH Receive Level Measurement per TRX(MR.RecvLevlOrigHalfRate.TRX). If the proportion of receive quality bands 6 and 7 to all receive quality bands exceeds 10%, the uplink 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.

8.


9.

Perform DTs to check whether either of the following problems occur: high receive level and 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 Case Symptom The call drop rate of CELL3 under a BTS reaches 10%, but the call drop rate and congestion rate of CELL1 and CELL2 are normal. Cause Analysis Issue 01 (2011–8–17)


79


5 Call Drops

There is external interference or the coverage is weak. Troubleshooting Procedure 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 during off-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 spectrum analyzer. The test result shows that there is a constant signal with a center frequency of 904.14 MHz and a spectrum bandwidth of 300 kHz, which is similar to the signal from an analog spectrum. The signal strength at the divider ports for CELL3, CELL2, and CELL1 is -27 dBm, -40 dBm, and -60 dBm respectively. The higher the signal strength, the greater the interference. The traffic volume in the daytime is greater than that at night, and therefore intermodulation probably occurs. The root cause of the problem appears to be an external interference source with a center frequency of 904 MHz. The interference source cannot be located after DTs are performed by using the spectrum analyzer. Therefore, all tests must be performed on the rooftop. The test result shows that the interference source is an antenna on a repeater. Interrupt the signal and perform the test again. The test result verifies that 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 Faults This section describes how to troubleshoot call drops due to equipment faults.

Symptom On 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 drops are indicated by the cause value equipment failure (0x20) carried in the CLEAR REQ message in 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 call drops 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. This leads to an increase in the call drop rate.

Background Information Call drops due to equipment faults are classified into the following types: l

Call drops due to faults in the MSC

l

Call drops due to BSC or BTS software defects

l

Call drops due to BSC or BTS hardware faults

l

Call drops due to dynamic configuration

l

Call drops due to transmission faults

l

Call drops due to insufficient BSC resources

Issue 01 (2011–8–17)


80


5 Call Drops

The following alarms are associated with call drops due to equipment faults. l

ALM-21807 OML Fault

l

ALM-2204 TRX Communication Alarm

l

ALM-2156 TRX VSWR Alarm

l

ALM-4144 TRX VSWR alarm

l

ALM-26529 RF Unit VSWR Threshold Crossed

l

ALM-3606 DRU Hardware alarm

l

ALM-20241 Board Unavailable

l

ALM-20243 Board Hardware Fault

l

ALM-20254 DSP Unavailable

l

ALM-20231 Link Between TDM Switching Boards in Different Subracks Faulty

l

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

Issue 01 (2011–8–17)


81


5 Call Drops


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.

2.


3.

Check whether the operations, such as dynamically deleting cells or TRXs and modifying channel attributes or base station identity codes (BSICs), are performed when call drops occur. 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 to Step 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.

Typical Case 1 Symptom A large number of call drops due to equipment faults occur within a measurement period after cell BSICs are modified after absolute radio frequency channel number (ARFCN) information is imported during peak hours. Cause Analysis Dynamically deleting cells or TRXs and modifying channel attributes or BSICs may cause call drops due to equipment faults. Troubleshooting Procedure 1.

Check the traffic statistics measured when call drops occur. Call drops due to equipment faults 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 hardware alarms.

3.

Check the BSC operation logs. The cell BSICs are modified when call drops occur. When a cell BSIC is dynamically modified on the BSC, calls in the cell are released automatically and measured as call drops due to equipment faults. In conclusion, call drops are caused by dynamic BSIC modification.

4.

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

Issue 01 (2011–8–17)


82


5 Call Drops

Typical Case 2 Symptom 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. Troubleshooting Procedure 1.

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

2.

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

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 is determined that call drops due to equipment faults occur because the circuits on the MSC side are reset.

5.

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

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

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


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/A interface transmission faults may lead to an increase in the value of CM334:Call Drops due to Equipment Failure (Traffic Channel).

l

Abis/Ater/A transmission link instability may increase the call drop rate. Check the relevant alarms to determine the link transmission status. If there are a large number of relevant alarms, 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 Alarm ALM-2114 TRX LAPD Link Interrupt Alarm ALM-3052 LAPD alarm ALM-3572 LAPD alarm – BSC LAPD alarms

Issue 01 (2011–8–17)


83


5 Call Drops

ALM-21511 LAPD Link Congestion ALM-21512 LAPD Link Fault – Optical interface MSP alarms ALM-21311 MSP Multiplex Section K1/K2 Mismatch ALM-21312 MSP Multiplex Section K2 Mismatch ALM-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 Procedure None


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 Case Symptom The value of CM333:Call Drops due to Abis Terrestrial Link Failure (Traffic Channel) is high. Cause Analysis Abis transmission links are interrupted intermittently. Troubleshooting Procedure 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 out of service, leading to call drops.

3.

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

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

Symptom The 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 Issue 01 (2011–8–17)


84


5 Call Drops

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


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. T308 is used to monitor the resource release procedure. All of these timers must be set during BSC data configuration. If any is set to an invalid value or too large a value, the MSC takes a long time to clear a call after the subscriber hangs up. Then, timers such as Radio Link 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 is set to too large a value, the MSC does not clear any short messages received during a link release. Instead, the MS sends a release message to the BTS, which then sends a Release Indication message to the BSC. The BSC then sends the MSC a Clear Request message, 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 upon receiving a Call Confirm message and stops it upon receiving an Alerting, Connect, or Disconnect message. If this timer is set to too large a value, the value of the timer SACCH Multi-Frames or Radio Link Timeout on the BSS side may decrease to 0 in a poor radio environment. As a result, the MSC releases the call and the call drop rate increases. – T313 The MSC uses this timer to monitor the call connection procedure. The MSC starts this timer upon sending a Connect message and stops it upon receiving a Connect ACK message. 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 Clear Request message to the MSC after the value of the timer SACCH Multi-Frames or Radio Link Timeout on the BSS side decreases to 0 in the following scenario: The MSC sends the BSS a Connect message and waits for a Connect ACK message, but the BSS does not receive the Connect message in a poor radio environment or cannot correctly decode the message. As a result, the call is dropped and the call drop rate increases. – T301 This timer specifies the period during which a phone is ringing. The MSC starts this timer upon receiving an Alerting message and stops it upon receiving a Connect or Disconnect message. If this timer expires before the MSC receives either message, the MSC sends the calling MS a Disconnect message containing the cause value #19 user alerting, 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 #102 recovery on timer expiry or cause value #31 normal, unspecified, instructing the called MS to clear the current call. If this timer is set to too large a value, the BSC sends the MSC a Clear Request message before this timer expires due to poor radio

Issue 01 (2011–8–17)


85


5 Call Drops

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. The MSC starts this timer upon sending a SETUP message and stops it upon receiving a Call Confirm or Release Complete message. If this timer expires before the MSC receives either message, the MSC clears the current call. If this timer is set to too large a value, the BSS sends the MSC a Clear Request message after the value of the timer SACCH Multi-Frames or Radio Link Timeout on the BSS side decreases to 0 in a poor 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. If the MS does not respond with a CP_ACK message before the timer expires, the MSC sends the BSC a Clear Command message, instructing the BSC to release radio resources. If this timer is set to too large a value, the MSC does not release the current call or clear terrestrial resources and TCH resources over the Um interface after the Disconnect message is issued. Because the MS does not receive a short message from the network, the MS sends the BTS a Disconnect message, requesting the BTS to release layer-2 links. In this case, the BTS sends a Release Indication to the BSC, and then the BSC sends a Clear Request message to release the current call. As a result, the call drop rate 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 BTS fails to decode measurement reports sent by the MS over the SACCH, the value of this parameter decreases by 1. Each time the BTS successfully decodes measurement reports sent by the MS over the SACCH, the value of this parameter increases by 2. If the value of this parameter is 0, the BTS assumes that the uplink radio link is faulty. 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 calls drop due to poor radio environment. 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 decode the messages over the SACCH. Once a dedicated channel is allocated to an MS, the counter S is enabled and the initial value is set to the value of this parameter. Each time the MS fails to decode an SACCH message, the counter S decreases by 1. Each time the MS correctly decodes an SACCH message, the counter S increases by 2. When the counter S is equal to 0, the downlink radio link is considered as failed. Therefore, when the voice or data quality deteriorates to an unacceptable situation and cannot be improved using power control or channel handover, the connection is re-established or released. 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 calls drop 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 this parameter is set to a small value, some MSs with low signal levels may attempt to access the network and call drops are likely to occur. To reduce the call drop rate, set this parameter to a large value. A large value, however, may affect the call setup success rate and traffic volume.

Issue 01 (2011–8–17)


86


5 Call Drops

– CS RACH Min. Access Level This parameter specifies the signal level threshold for an MS to access the network over the RACH. If this parameter is set to a small value, some MSs with low signal levels may attempt to access the network and call drops are likely to occur. To reduce the call drop rate, set this parameter to a large value. A large value, however, may decrease the call setup success rate and paging success rate. – Handover Completion Message Timers Handover completion message timers consist of T3103A, T3103C, and T8. If any of these timers is set to a small value, the BSC may receive no message after timers T3103A and T3103C expire. Therefore, the BSC assumes that a radio link fails in the source cell. 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 (Traffic Channel) is large, set this parameter to a large value. A large value, however, may lead to TCH congestion. – T3109 This parameter specifies the period during which a BSC waits for a Release Indication message after issuing a Channel Release message. If this parameter is set to a small value, 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 longer than the value of Radio Link Timeout. – T3111 This parameter specifies the period during which channel deactivation is delayed when the main signaling link is disconnected. Delaying channel deactivation allows for a period of time for link reconnection. If this parameter is set to a small value, a channel may be deactivated before the link has had a chance to reconnect, resulting a call drop. – TCH Traffic Busy Threshold If 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 the network. TCHHs do not have good anti-interference capabilities. Therefore, the call drop rate may increase if a large number of TCHHs are occupied. Do not set this parameter to a small value during light congestion. – Call Reestablishment Forbidden Blind spots caused by tall buildings or abrupt interference may lead to radio link failures and call drops. This parameter specifies whether an MS can initiate a call reestablishment procedure to re-establish a dropped call in such a scenario. To reduce the call 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 reestablishment generally takes a long time, and therefore some subscribers may hang up before the call is re-established successfully. – Handover-related Parameters If handover-related parameters are not set correctly, handovers may not be performed in time, leading to call drops. To reduce the call drop rate, modify the handover-related parameters so that handovers can be performed in time. For details, see Troubleshooting Handovers. – Power Control Parameters If the power control level and quality thresholds are set to small values, call drops are likely to occur because of low signal level and poor signal quality. Issue 01 (2011–8–17)


87


5 Call Drops

– T200 and N200 If T200 FACCH/F, T200 FACCH/H, N200 of FACCH/Full Rate, or N200 of FACCH/Half Rate is set to a small value, the BSC may release data links before a call is terminated, resulting a call drop. If the value of M3100A:Call Drops due to ERR IND Received on TCHF (Traffic Channel) in Stable State (T200 Expired) is large, set T200 and N200 to large values. – Neighboring Relationship If only some neighboring cells are configured in the BA2 list, no neighboring cells may be 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 data and electronic map to prevent call drops due to unavailability of neighboring cells. – MAIO In 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, frequency collision can occur during FH, resulting call drops. – Disconnect Handover Protect Timer This is a BSC soft parameter. After receiving a Disconnect message from an MS, the BSC cannot hand over the MS within the period specified by this parameter. When this parameter is not configured, after being handed over to a target cell, an MS cannot hang up 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 this parameter to a small value. – Directly Magnifier BTS Flag If repeaters are installed under a BTS, handovers between repeaters can only be asynchronous because the repeaters are far apart. If synchronous handovers are performed, the handovers may fail, resulting in call drops. Therefore, when repeaters are installed under a BTS, set Directly Magnifier BTS Flag to Yes to prevent synchronous handovers between cells under the same BTS.

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

Issue 01 (2011–8–17)


88


5 Call Drops

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


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 modified on 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.

3.


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, undo the parameter setting modification. Then, go to Step 5. l If no, go to Step 6.

5. Issue 01 (2011–8–17)

Check whether the call drop problem is resolved. Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

89


5 Call Drops

l If yes, no further action is required. l If no, go to Step 6. 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, undo the 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 Case Symptom 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. Troubleshooting Procedure 1.

Analyze the signaling, traffic statistics, and parameter settings. The values of the timers T310, T313, Short Message ACK Timer, and Terminate Short Message Timer after the MSC cutover are larger than those before the MSC cutover. Therefore, there is a high probability that the BSS will release the links. After timers such as Radio Link Timeout and 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 parameter values before and after the MSC cutover. Table 5-3 Parameter values before and after the MSC cutover

2.

Issue 01 (2011–8–17)

Timer

Value Before the MSC Cutover (s)

Value After the MSC Cutover (s)

T310

20

30

T313

10

30

Short Message ACK Timer

15

20

Terminate Short Message Timer

30

42

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


90


6 Access Faults

6

Access Faults

About This Chapter This chapter describes how to locate and troubleshoot access faults. 6.1 Access Principles Access performance reflects how much difficulty MSs have in accessing the network. Poor access performance may degrade subscriber satisfaction. 6.2 Locating Access Faults This section describes how to locate access faults. 6.3 Troubleshooting Access Faults Due to Poor Um Interface Quality This section describes how to troubleshoot access faults due to poor Um interface quality. 6.4 Troubleshooting Low Immediate Assignment Success Rates Due to SDCCH Congestion This section describes how to troubleshoot low immediate assignment success rates due to standalone dedicated control channel (SDCCH) congestion. 6.5 Troubleshooting Low Immediate Assignment Success Rates Due to Hardware or Transmission Faults This section describes how to troubleshoot low immediate assignment success rates due to hardware or transmission faults. 6.6 Troubleshooting Low Immediate Assignment Success Rates Due to Location Updates of Problem MSs This section describes how to troubleshoot low immediate assignment success rates due to location updates of problem MSs. 6.7 Troubleshooting Low Assignment Success Rates Due to TCH Congestion This 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 Faults This section describes how to troubleshoot low assignment success rates due to hardware or transmission faults. 6.9 Troubleshooting Low Assignment Success Rates Due to Inappropriate BSC Configuration

Issue 01 (2011–8–17)


91


6 Access Faults

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

Issue 01 (2011–8–17)


92


6 Access Faults

6.1 Access Principles Access performance reflects how much difficulty MSs have in accessing the network. Poor access performance may degrade subscriber satisfaction.

Access Faults l

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, which could negatively affect subscriber satisfaction. The network access performance improves with the immediate assignment success rate or assignment success rate.

l

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

l

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

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

Issue 01 (2011–8–17)


93


6 Access Faults

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 (Circuit Service)

A4

CA310:Assignment Requests

A5

CA313:Successful Assignments

6.2 Locating Access Faults This section describes how to locate access faults.

Issue 01 (2011–8–17)


94


6 Access Faults

6.2.1 Procedure for Locating Access Faults Before locating access faults, determine whether they occur during immediate assignment or assignment.

Possible Causes l

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 random access requests from MSs, the BSC sends an immediate assignment rejection message because no standalone dedicated control channel (SDCCH) is available.

SDCCH congestion and equipment faults

Channel activation

The BSC sends the Channel Act message to the BTS, and the BTS responds with the Channel Act Nack message.

Equipment faults

The BSC sends the Channel Act message to the BTS, but the BTS does not respond.

Equipment and transmission faults

After channels are activated successfully, the BSC sends immediate assignment messages, but the MSs do not access the assigned channels. As a result, the BSC does not receive any EST IND messages.

Um interface faults and MS faults

Immediate assignment delivery

– Use a defined formula to calculate immediate assignment success rates, and determine the possible causes of low immediate assignment success rates according to the calculation results. Table 6-3 lists the mapping relationship between user-defined formulas and possible causes.

Issue 01 (2011–8–17)


95


6 Access Faults

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

l

Possible Cause Um Interface Fault

Channel Activation Failure (Equipmen t and Transmissi on Faults)

SDCCH Congestion

MS Fault

Immediate assignment success rate = [CA303J:Call Setup Indications (Circuit Service)/ K3100:Immediate Assignment Requests] x 100%

√

√

√

√

Immediate assignment success rate = {CA303J:Call Setup Indications (Circuit Service)/ [K3100:Immediat e Assignment (K3101:Immediat e Assignment Commands CA303J:Call Setup Indications (Circuit Service))]} x 100%

-

√

√

-

Immediate assignment success rate = [CA303J:Call Setup Indications (Circuit Service)/ K3101:Immediate Assignment Commands] x 100%

√

-

-

√

Possible causes of low assignment success rates Table 6-4 lists the possible causes of low assignment success rates.

Issue 01 (2011–8–17)


96


6 Access Faults

Table 6-4 Possible causes of low assignment success rates Counter

Possible Cause

CA312:Failed Assignments (Channel Unavailable)

TCH congestion

A3169A:Failed Assignments (Um Cause)

Um interface faults

A3129B:Failed Assignments (First Hardware faults, transmission faults, and Assignment, Terrestrial Resource Request incorrect BSC configuration Failed) A3129E:Failed Assignments (CIC Unavailable)

BSC faults and MSC faults

A3129E:Failed Assignments (CIC Unavailable)

BSC faults and MSC faults

A3129H:Failed Assignments (Clear Commands Sent By MSC)

Normal release and misoperations of peer end users

Location Procedure Check whether immediate assignment success rates or assignment success rates are low according 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.

Issue 01 (2011–8–17)


97


6 Access Faults

Figure 6-2 Procedure for locating low immediate assignment success rates

Issue 01 (2011–8–17)


98


6 Access Faults

Figure 6-3 Procedure for locating low assignment success rates

6.2.2 Common Causes for Access Faults This section describes common causes for low immediate assignment success rates and low assignment success rates.

Common Causes for Low Immediate Assignment Success Rates Figure 6-4 shows common causes for low immediate assignment success rates.

Issue 01 (2011–8–17)


99


6 Access Faults

Figure 6-4 Common causes for low immediate assignment success rates

l

Issue 01 (2011–8–17)

Um interface faults


100


6 Access Faults

– The BTS may mistakenly process interference on the Um interface as pseudo-random access signals. This may lead to immediate assignment failures and standalone dedicated control channel (SDCCH) congestion. – In a cell configured with multiple TRXs, the combination loss of broadcast control channel (BCCH) TRXs is different from that of non-BCCH TRXs. Therefore, their coverage areas are also different. If an SDCCH is configured on a non-BCCH TRX, a call far away from the serving cell may fail to access the SDCCH when the call is assigned 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 Access Faults 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 is out 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 MSs perform location updates or initiate calls in these cells. After sending channel requests for location updates, the problem MSs fail to set up links on SDCCHs, leading to low immediate assignment success rates on SDCCHs. – Low immediate assignment success rates because of location updates of problem MSs are caused by MS faults and cannot be resolved on the BSS side. No layer 3 information is available due to location update failures and therefore the faulty MS cannot be determined. – For details about how to locate this problem, see 6.6 Troubleshooting Low Immediate Assignment Success Rates Due to Location Updates of Problem MSs.

Common Causes of Low Assignment Success Rates Figure 6-5 shows common causes for low assignment success rates.

Issue 01 (2011–8–17)


101


6 Access Faults

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-network interference occurs because of insufficient frequencies and tight frequency reuse, MSs may fail to parse information about the assigned traffic channel (TCH) properly. As a result, they fail to occupy the TCH, leading to low assignment success rates.

Issue 01 (2011–8–17)


102


6 Access Faults

– If the signal level is low due to poor coverage, MSs may fail to parse the assigned TCH properly. As a result, they fail to occupy the TCH, leading to low assignment success rates. – For details about how to troubleshoot this problem, see 6.3 Troubleshooting Access Faults 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 low assignment success rates. – Poor link transmission quality over the Abis interface and unstable transmission links may also lead to TCH assignment failures. – For details about how to troubleshoot this problem, see 6.8 Troubleshooting Low Assignment 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 is faulty, TCH assignment may be initiated when CICs on the A interface are not idle, leading to assignment failures. This problem is quite complicated. Therefore, MSC engineers and BSC engineers need to team up to troubleshoot such problems.

l

MSC faults If the MSC delivers the Clear CMD message during assignment, the assignment fails. To troubleshoot this problem, contact MSC engineers.

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

Symptom l

The result of signaling tracing over the Abis interface shows that MSs cannot access channels after the BSC delivers the immediate assignment command during immediate assignment. As a result, the BSC does not receive link establishment indications from BTSs and releases local channels. In addition, the immediate assignment success rate calculated with the following formula decreases: Immediate assignment success rate = (CA303J:Call Setup Indications (Circuit Service)/K3101:Immediate Assignment Commands) x 100%.

l

The result of signaling tracing over the Abis interface shows that the timer specified for assignment completion responses expires or MSs fail to access new channels after the BSC delivers the assignment command during assignment. As a result, MSs return to their

Issue 01 (2011–8–17)


103


6 Access Faults

original channels and send assignment failure messages. In addition, the value of A3169A:Failed Assignments (Um Cause) increases noticeably.


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 percentage of uplink receive quality in receive quality bands 5, 6, and 7 exceeds 20%, there is a high probability that access faults occur.

2.

Analyze Interference Band Measurement per TRX(MR.Iterf.TRX). If the percentage of interference levels in the high interference bands is great, for example, the percentage of interference levels in interference bands 4 or 5 exceeds 10%, access faults are caused by uplink interference.

3.

Analyze the signaling collected by the TEMS during drive tests (DT) to determine whether the downlink C/I is normal when MSs access channels. If the signal level is proper but the C/I is poor, access faults are caused by interference.

Location Procedure Figure 6-6 shows the procedure for locating access faults due to poor Um interface quality.

Issue 01 (2011–8–17)


104


6 Access Faults

Figure 6-6 Procedure for locating access faults due to poor Um interface quality


Check for interference. For details, see Background Information. l If access faults are caused by interference, check for interference sources onsite or perform DTs to locate the interference sources. In addition, check whether repeaters have 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 Interference Problems. Then, go to Step 2. (1) Run the MML command LST GCELLSOFT to check whether Directly Magnifier BTS Flag is set to Yes. If Directly Magnifier BTS Flag is set to Yes, the cell is configured with repeaters. If Directly Magnifier BTS Flag is set to No, check whether other operators' repeaters are installed near the cell or whether any repeaters are installed without permission. (2) If repeaters are installed, check whether they are wideband repeaters. If they are wideband repeaters, check whether the uplink or downlink gain is large. If the uplink or downlink gain is large, reduce it as required. Shut down the repeaters if they have great impacts on the access success rate.

Issue 01 (2011–8–17)


105


6 Access Faults

(3) Check whether the repeaters are faulty or whether the uplink or downlink gain is beyond 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 of MRs with a large timing advance (TA) value measured for Number of MRs based on 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. l If yes, no further action is required. l If no, go to Step 3.

3.

Check whether the uplink and downlink signal levels are balanced. Check Uplink-and-Downlink Balance Measurement per TRX(MR.BalanceOrig.TRX). If the percentage of the uplink and downlink signal level balance class 1 or 11 to all uplink and downlink signal level balance classes exceeds 30%, the uplink and downlink signal levels 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 the following 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 lower than the downlink signal level and access faults are likely to occur in a cell far away from the BTS. In this case, reconnect the jumpers. – If the feeders are damaged, wet, or distorted, or if the connectors are not tight, both the transmit power and receive sensitivity are reduced and access faults occur as a result. 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.


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 receive quality and receive signal levels. If receive quality is generally poor at low receive signal levels, access faults in the cell may be caused by poor receive quality, resulting from coverage problems. (2) Analyze Number of MRs based on TA per TRX(MR.TaDistribOrig.TRX). If many MRs have large TA values, access faults are caused by wide coverage or coverage overlap. Otherwise, access faults are caused by weak coverage. If the percentage of TA values at levels 0 to 5 is less than 90%, check for coverage problems in the cell based on the coverage scenario and DT result. l If yes, contact network optimization engineers to resolve the problem, and then go to Step 6.

Issue 01 (2011–8–17)


106


6 Access Faults

l If no, go to Step 7. 6.


7.

Check the Um interface quality. Check TCHF Receive Level Measurement per TRX(MR.RecvLevlOrigFullRate.TRX) or TCHH Receive Level Measurement per TRX(MR.RecvLevlOrigHalfRate.TRX). If the percentage of receive quality bands 6 and 7 exceeds 10%, the uplink or downlink receive quality 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.


9.

Perform DTs to check whether high receive signal levels with poor receive quality or low receive 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 Case Symptom After a BSC is swapped at a first office application (FOA) site, the immediate assignment success rates in multiple cells are less than 93% during peak hours due to co-channel and adjacentchannel interference. Cause Analysis The cells work on the same frequency and use the same base transceiver station identity code (BSIC), leading to interference. Troubleshooting Procedure 1.

Issue 01 (2011–8–17)

Analyze the signaling traced at the problem site. The signaling shows that most access attempts fail because the BTS delivers the immediate assignment commands upon receiving channel requests from MSs, but the MSs do not return any messages. An analysis of the channel requests shows that the access uplink signal level is about -80 dB and the TA values are 0 and 1, which are normal. For details about how to parse the TA value and uplink access signal level from channel request messages, see Figure 6-7.


107


6 Access Faults

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 two BSICs for the broadcast control channel (BCCH) frequencies at the junction are different but the signal levels of the BCCH frequencies are similar. This indicates that co-channel interference occurs. One BCCH frequency belongs to cell A and the other BCCH frequency belongs to cell B.

3.

After the BCCH frequency of cell A is modified, the traffic statistics shows that the immediate assignment success rate in cell A increases noticeably.

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

Symptom The values of CA300J:Channel Requests (Circuit Service) and RR370:Congestion Rate on SDCCH per CELL (due to Busy) or the values of K3004:Traffic Volume on SDCCH, Issue 01 (2011–8–17)


108


6 Access Faults

K3000:SDCCH Seizure Requests, and K3001:Failed SDCCH Seizures due to Busy SDCCH increase noticeably, but the immediate assignment success rate decreases.


SDCCH congestion is probably caused by one of the following causes: – The traffic volume on an SDCCH increases sharply. As a result, new services cannot be assigned to the SDCCH, leading to an immediate assignment failure. – The configuration data is inappropriate, such as the location area (LA) planning, dualband network parameters, and timer settings. – The number of functional SDCCHs decreases because some TRXs carrying SDCCHs are 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 dynamic adjustment. – SDCCH congestion caused by traffic bursts such as group sending of short messages and location update at the portal of a tunnel cannot be completely resolved. Relieve the SDCCH congestion by Configuring SDCCH Dynamic Adjustment. – For SDCCH congestion caused by a decrease in the number of functional SDCCHs due to hardware faults, rectify the hardware faults. For details, see 6.5 Troubleshooting Low Immediate Assignment Success Rates Due to Hardware or Transmission Faults.

l

The related parameters are as follows: – CELL_RESELECT_OFFSET (CRO) This parameter specifies the likelihood with which MSs select a cell. If the communication quality in a cell is poor due to heavy traffic or for other causes, ensure that MSs do not work in this cell. In this case, if you set PENALTY_TIME (PT) to 31, TEMPORARY_OFFSET (TO) becomes invalid. C2 equals C1 minus CRO. Users can 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 will select the cell. – CELL_RESELECT_HYSTERESIS This parameter specifies whether to perform inter-LA reselection. It prevents an increase in the network signaling volume due to frequent location updates and reduces the possibility of losing paging messages. This parameter is generally set to 6. For dualband networks in urban areas belonging to different LAs, the value of this parameter ranges from 8 to 10. – When the traffic volume in an area is heavy and the signaling flow is overloaded frequently, increase the CRH of neighboring cells that belong to different LACs in this area. – When the overlapping coverage of neighboring cells that belong to different LAs is large, increase the CRH. – When the border coverage of the neighboring cells that belong to different LAs is poor 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

Issue 01 (2011–8–17)


109


6 Access Faults

– SDCCH Dynamic Allocation Allowed When this parameter is set to YES(Yes), dynamic conversion between SDCCHs and traffic 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 this parameter, the BSC uses the channel allocation algorithm to attempt to find a TCHF that can be converted to an SDCCH. This parameter is one of the conditions for dynamically converting a TCHF to an SDCCH. – Cell SDCCH Channel Maximum Before initiating dynamic conversion from the TCH to the SDCCH, the BSC checks whether the number of SDCCHs in a cell after the conversion will exceed Cell SDCCH Channel Maximum. If the number will exceed Cell SDCCH Channel Maximum, the BSC does not initiate the conversion. – TCH Minimum Recovery Time This parameter specifies the minimum duration for converting an SDCCH back to a TCH. – Related timers – T3101 Timer T3101 monitors the immediate assignment procedure. Setting timer T3101 to a small value can effectively reduce the SDCCH congestion rate. If timer T3101 is set to a large value, the invalid duration for occupying signaling resources is prolonged, resulting in waste of signaling resources. To optimize signaling resource usage, set timer T3101 to a small value, especially when the queuing function is enabled. – T3122 An MS starts timer T3122 when receiving the IMMEDIATE ASSIGN REJECT message and sends a new channel request message after timer T3122 expires. Increasing the value of timer T3122 can prevent the MS from sending channel request messages frequently when no system resource is available, preventing increases in the load on random access channels (RACH) and common control channels (CCCH). – T3212 Timer T3212 monitors the location update period. Appropriately increasing the value of timer T3212 can minimize the SDCCH load, which becomes heavy due to periodic location updates. – T3111 Timer T3111 specifies the connection release delay. This timer is used to delay channel deactivation after the main signaling link is disconnected. This is to reserve some time for another disconnection, if necessary. Timer T311 starts when a TCH is released and when an SDCCH is released. The value of timer T3111 must be the same as that of timer T3110 on the MS side and is generally two seconds. If timer T3111 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 request SDCCHs to access the network, leading to the SDCCH congestion. If the parameter is set to a large value, call failures may occur even when signals are available. Therefore, Issue 01 (2011–8–17)


110


6 Access Faults

set this parameter according to the actual BTS sensitivity, the lowest MS access signal level, and the interference. – Late Assignment This function is set on the MSC side. If late assignment is enabled, the calling MS always occupies 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 request the SDCCH, leading to SDCCH congestion. – Minimum Access RXLEV If this parameter is set to a small value, the requirement for the access signal level is low. As a result, a large number of MSs attempt to camp on this cell, increasing the cell load and call drop rate and leading to SDCCH congestion. – TX-integer When the network traffic volume is heavy, the immediate assignment success rate is low if the sum of S and T is low. You can adjust the value of T within reason to increase the sum of S and T. For details about S and T, see the description about TX-integer contained in the MML command SET GCELLIDLEBASIC. – CELL BAR ACCESS (CBA) This parameter specifies whether accessing a cell is allowed. 0 indicates that accessing a cell is allowed, and 1 indicates that accessing a cell is prohibited. This parameter can be 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 Selection Priority

Cell Reselection Priority

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 Procedure Figure 6-8 shows the procedure for locating low immediate assignment success rates due to SDCCH congestion.

Issue 01 (2011–8–17)


111


6 Access Faults

Figure 6-8 Troubleshooting low immediate assignment success rates due to SDCCH congestion


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 in Background Information. If the problem persists, expand the capacity to resolve the problem. If the problem is resolved after capacity expansion, no further action is required. 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 Low Immediate Assignment Success Rates Due to Hardware or Transmission Faults. If the problem is resolved after the hardware and transmission faults are rectified, no further action is required. If the problem persists, return to Procedure for locating access faults. l If no, return to Procedure for locating access faults.

Typical Case Symptom The immediate assignment success rate of a BSC is low. According to the traffic statistics, certain BTSs are experiencing SDCCH congestion. Cause Analysis SDCCH become congested easily when the traffic volume increases sharply. In addition, low SDCCH availability due to hardware faults may also lead to SDCCH congestion. Issue 01 (2011–8–17)


112


6 Access Faults


Check RR300:SDCCH Availability. The SDCCH availability is 100%. Therefore, SDCCH congestion is not caused by hardware faults.

2.

Check K3000:SDCCH Seizure Requests and K3001:Failed SDCCH Seizures due to Busy SDCCH. The number of SDCCH seizures is about 300 to 400 during peak hours for cells served by a BTS in S1/1/1 mode. Each cell is configured with eight SDCCHs, which can process 300 to 400 SDCCH seizures during peak hours. However, SDCCH congestion occurs dozens of times in each cell during peak hours.

3.

Check Counters Related to Call Setup Indication. Most SDCCH seizures are caused by location updates. Most BTSs experiencing SDCCH congestion are located at the junction of two LAs along railways. According to the train schedule, four to five trains pass through the junction at about the time the SDCCHs become congested. When multiple trains pass through the junction, a large number of location updates occur abruptly during a very short period, leading to SDCCH congestion.

4.

Run the MML command SET GCELLBASICPARA with SDCCH Dynamic Allocation Allowed 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 Success Rates Due to Hardware or Transmission Faults This section describes how to troubleshoot low immediate assignment success rates due to hardware or transmission faults.

Symptom The symptoms of low immediate assignment success rates due to hardware or transmission faults are 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 BTS responds with a Channel Activation Nack message or does not respond.

l

After successful channel activation, the BSC delivers an immediate assignment message but 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 unavailable standalone dedicated control channels (SDCCHs). The SDCCHs are unavailable because the TRX carrying the requested SDCCHs is faulty and reports a large number of Overload messages.

l

For details about the hardware or transmission fault alarms, see Background Information.

Issue 01 (2011–8–17)


113


6 Access Faults NOTE

l If the BTS returns a Channel Activation Nack message, check the following performance counters based on the channel types: R3300B:CHAN ACTIV NACK Messages Sent by BTS in Immediate Assignment Procedure (SDCCH), R3307B:CHAN ACTIV NACK Messages Sent by BTS in Immediate Assignment Procedure (TCHF), and R3308B:CHAN ACTIV NACK Messages Sent by BTS in Immediate Assignment Procedure (TCHH). l If the BTS does not respond to the channel activation initiated by the BSC, check the following performance counters based on the channel types: R3300C:Channel Activation Timeouts in Immediate Assignment Procedure (SDCCH), R3307C:Channel Activation Timeouts in Immediate Assignment Procedure (TCHF), and R3308C:Channel Activation Timeouts in Immediate Assignment Procedure (TCHH).


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 Assignment Procedure – The following are the alarms related to BTS or BSC hardware faults that can result in access 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 Fault

l

If transmission faults occur (for example, delay and frame loss), immediate assignment fails because channel activation times out or the immediate assignment command fails to be delivered to the MS. You can find transmission faults by checking the following alarms related to transmission faults that can result in access faults: – OML fault alarms ALM-21807 OML Fault – BTS LAPD link alarms ALM-4102 TRX LAPD Link Interrupt Alarm ALM-2114 TRX LAPD Link Interrupt Alarm ALM-3052 LAPD alarm ALM-3572 LAPD alarm – BSC LAPD link alarms ALM-21511 LAPD Link Congestion

Issue 01 (2011–8–17)


114


6 Access Faults

ALM-21512 LAPD Link Fault – Alarms related to the Multiplex Section Protection (MSP) of optical ports ALM-21311 MSP Multiplex Section K1/K2 Mismatch ALM-21312 MSP Multiplex Section K2 Mismatch ALM-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 Procedure Figure 6-9 shows the procedure for locating low immediate assignment success rates due to hardware or transmission faults. Figure 6-9 Procedure for locating low immediate assignment success rates due to hardware or transmission faults


Issue 01 (2011–8–17)

Check whether any of the hardware fault alarms listed in Background Information are reported. Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

115


6 Access Faults

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 the Overload messages and replace the TRX. Then, check whether the immediate assignment success 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 the performance counters listed in Background Information to determine whether channel activation fails or the timer for waiting for the Establish Indication message expires. If the immediate 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) are idle. According to the traffic statistics during peak hours, the value of K3001:Failed SDCCH Seizures due to Busy SDCCH is about one thousand. In addition, a large number of LAPD link fault 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 data configurations cannot be ruled out as the cause, the problem is more likely to have resulted from transmission faults, because a large number of LAPD link fault alarms and clear alarms have been frequently reported. Troubleshooting Procedure 1.

Check the data configurations. The data configurations are correct. Then, exchange the transmission port on the problem BTS with that on another BTS of the same type. The latter BTS operates properly, but the problem persists. Therefore, the problem is not caused by incorrect 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 Success Rates Due to Location Updates of Problem MSs This section describes how to troubleshoot low immediate assignment success rates due to location updates of problem MSs. Issue 01 (2011–8–17)


116


6 Access Faults

Symptom The immediate assignment success rates are low in some cells because of location updates of problem MSs in these cells. After the problem MSs send channel requests to the BSC because of location updates, the BSC assigns standalone dedicated control channels (SDCCHs) to the problem MSs and sends immediate assignment messages to the problem MSs. The problem MSs, however, do not access these SDCCHs. As a result, a timeout occurs when the BSC waits for the ESTABLISH INDICATION messages, leading to low SDCCH immediate assignment success rates.

Background Information The characteristics of low immediate assignment success rates due to location updates of problem 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:Call Setup Indications Timed Out (SDCCH), the low immediate assignment success rates are due to location updates of problem MSs. However, the service type contained in the channel requests sent by some MSs may not be location updates. In this case, you need to determine the 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-peak hours.

l

Calls are not affected. Aside from the immediate assignment success rates of some cells during certain periods, all key performance indicators (KPIs) are normal. In addition, drive test results are normal, and no subscribers complain about call drops because the MSs retry periodically 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 by MS faults and therefore cannot be resolved on the BSS side.

Location Procedure None


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 Case Symptom A customer complains that the SDCCH immediate assignment success rates in some cells are low because of location updates. Issue 01 (2011–8–17)


117


6 Access Faults

Cause Analysis Low SDCCH immediate assignment success rates in some cells may be caused by Um interface faults, hardware faults, transmission faults, and SDCCH congestion. According to the onsite symptom, the SDCCH immediate assignment success rates are low only in certain cells and the immediate assignment failures are due to location updates. Therefore, the problem is most likely to have resulted from MS faults. Troubleshooting Procedure 1.

Deduce that the problem is caused by MS faults because the problem occurs only in certain cells.

2.

Analyze traffic statistics to check whether the low immediate assignment success rates are caused by location updates. The difference between A300F:Channel Requests (Location Updating) and A3030F:Call Setup Indications (Location Updating) (SDCCH) is similar to A3040:Call Setup Indications Timed Out (SDCCH), which indicates that the SDCCH setup failures 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, the TA values are small and the signal level values are large. In addition, the uplink signal strength measured by the BTS is lower than -110 dBm during the period in which the BSS waits for MSs to access the assigned SDCCHs, which indicates that the MSs do not access the SDCCHs. As a result, the immediate assignment fails. NOTE

For details about how to query TA values, see the typical case in 6.3 Troubleshooting Access Faults Due 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, which matches the value of MS MAX Retrans. NOTE

MS MAX Retrans specifies the maximum number of Channel Request messages sent by an MS during an immediate assignment process. You can query the value of this parameter by running the MML command LST GCELLCCBASIC and set the value of this parameter by running the MML command SET GCELLCCBASIC.

Issue 01 (2011–8–17)


118


6 Access Faults

Figure 6-11 Channel Request messages consecutively sent by an MS

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

Symptom 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 No radio resource available. In addition, the values of the following counters increase significantly: ZTA3129J:Failed Assignments per BSC (Channel Unavailable), CA312:Failed Assignments (Channel Unavailable), and K3011A:Failed TCH Seizures due to Busy TCH (Traffic Channel).


The following is the formula for calculating the TCH congestion rate:

(K3021:Failed TCH Seizures due to Busy TCH (Signaling Channel) + K3011A:Failed TCH Seizures due to Busy TCH (Traffic Channel) + K3011B:Failed TCH Seizures in TCH Handovers due to Busy TCH (Traffic Channel))/(K3020:TCH Seizure Requests (Signaling Channel) + Issue 01 (2011–8–17)


119


6 Access Faults

K3010A:TCH Seizure Requests (Traffic Channel) + KK3010B:TCH Seizure Requests in TCH Handovers (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 common causes 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 Procedure Figure 6-12 shows the procedure for locating low assignment success rates due to TCH congestion.

Issue 01 (2011–8–17)


120


6 Access Faults

Figure 6-12 Procedure for locating low assignment success rates due to TCH congestion


Issue 01 (2011–8–17)

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 command LST GTRXDEV to check whether TCH Rate Adjust Allow is set to YES(Yes). Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

121


6 Access Faults

l If yes, go to Step 2. l If no, perform the following operations to enable the half-rate speech versions 1 and 3 when the speech quality meets the requirement: (1) Run the MML command SET GCELLCCACCESS with Speech Version set to HALF_RATE_VER1(Half-rate VER 1) and HALF_RATE_VER3(Half-rate VER 3). (2) Run the MML command SET GTRXDEV with TCH Rate Adjust Allow set to YES(Yes). (3) Check whether the assignment success rate returns to normal. – If yes, no further action is required. – 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, check whether the assignment success rate returns to normal. If yes, no further action is required. 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 assignment success rate returns to normal. If yes, no further action is required. If no, go to Step 4. NOTE

If TCHs become congested abruptly in the cell because of emergencies such as a gathering, no action 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 processes PS services preferentially. l If yes, reduce the number of PDCHs. Then, check whether the assignment success rate returns 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 Immediate Assignment set to NO(No) to disable very early assignment. Alternatively, perform capacity 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 or run the MML command DSP CHNSTAT to check channel status, and rectify TRX or channel faults. Then, check whether the assignment success rate returns to normal. If yes, no further action is required. If no, return to Procedure for locating access faults. l If no, return to Procedure for locating access faults.

Issue 01 (2011–8–17)


122


6 Access Faults

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, hardware faults, and large traffic volumes. Troubleshooting Procedure 1.

Analyze the traffic statistics of one of the cells where TCHs are congested. The cell is configured with 12 TCHs, and the TCHs are congested twice at a certain time and R3561:Maximum Number of Busy Channels (TCHF) measured at the time is 12. This indicates that all TCHs are occupied at the time, resulting in TCH congestion. This indicates that 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 of these cells during the measurement period is low but all the TCHs are occupied within a short period. In this case, TCHs are congested when new calls access these cells, leading to 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 Busy Threshold set to a required value. (3) Run the MML command SET GCELLCHMGBASIC with Enhanced TCH Adjust Allowed set to YES(Yes).

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

Symptom l

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. In addition, the values of ZTA312L:Failed Assignments per BSC (Equipment Failure) and A3129B: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 connected incorrectly, some channels are unavailable, leading to assignment failures. The signaling tracing result shows that MSs fail to access traffic channels (TCHs) and send assignment failure messages on standalone dedicated control channels (SDCCHs).

Issue 01 (2011–8–17)


123


6 Access Faults


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 cable connections between TNUs on the BSC side. On the BTS side, pay attention to BTS alarms or check BTS hardware status on the Web LMT; 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 are lost, leading to assignment failures. You can verify whether transmission faults occur by checking transmission fault alarms. The following are the common transmission fault alarms that can result in access faults: – OML fault alarms ALM-21807 OML Fault – BTS LAPD link alarms ALM-4102 TRX LAPD Link Interrupt Alarm ALM-2114 TRX LAPD Link Interrupt Alarm ALM-3052 LAPD alarm ALM-3572 LAPD alarm – BSC LAPD link alarms ALM-21511 LAPD Link Congestion ALM-21512 LAPD Link Fault – Alarms related to the MSP of optical ports ALM-21311 MSP Multiplex Section K1/K2 Mismatch ALM-21312 MSP Multiplex Section K2 Mismatch ALM-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 Procedure Figure 6-13 shows the procedure for locating low assignment success rates due to hardware or transmission faults. Issue 01 (2011–8–17)


124


6 Access Faults

Figure 6-13 Procedure for locating low assignment success rates due to hardware or transmission faults


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 are reported. 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 Case Symptom 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. Issue 01 (2011–8–17)


125


6 Access Faults

Cause Analysis This problem occurs after capacity expansion and TNU switchover. Therefore, it is most probably caused by incorrect cable connections between subracks of the BSC. Troubleshooting Procedure 1.

View historical alarms. The alarm ALM-20231 Link Between TDM Switching Boards in Different Subracks Faulty is reported when the problem occurs.

2.

Check the cable connections between TNUs on different subracks. The cable connections between TNUs on different subracks are incorrect, as shown in Figure 6-14. Figure 6-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

Issue 01 (2011–8–17)


126


3.

6 Access Faults

Correct the cable connections between the TNUs by referring to Figure 6-15. This correction resolves the problem.

6.9 Troubleshooting Low Assignment Success Rates Due to Inappropriate BSC Configuration This section describes how to troubleshoot low assignment success rates due to inappropriate BSC configuration.

Symptom A large number of assignment failures occur during peak hours. The cause value is equipment failure or requested terrestrial resource unavailable and the values of ZTA312L:Failed Assignments per BSC (Equipment Failure) and A3129B:Failed Assignments (First Assignment, Terrestrial Resource Request Failed) increases.

Background Information When 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 Hardware Description. 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 BTS are 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 an assignment request delivered by the mobile switching center (MSC) is incorrect.

l

If cable connections between the TNUs on different subracks are not configured, intersubrack call assignment fails.

l

After A over IP transformation, assignment fails if the BSC is not reset.

Location Procedure Figure 6-16 shows the procedure for locating low assignment success rates due to inappropriate BSC configuration

Issue 01 (2011–8–17)


127


6 Access Faults

Figure 6-16 Procedure for locating low assignment success rates due to inappropriate BSC configuration

Issue 01 (2011–8–17)


128


6 Access Faults


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 interface resources are blocked or faulty by referring to Maintaining Ater Interface Resources. If any Ater interface resources are blocked, unblock them. If any Ater interface resources are faulty, replace the transmission cables for the faulty Ater timeslots. If the problem persists, run the MML command ADD ATERCONPATH to add Ater interface resources. If the problem is resolved, no further action is required. If the problem persists, go to Step 2. l If no, go to Step 2.

2.

Check whether the number of CICs over the A interface exceeds the number of calls that all DPUs support. l If yes, reduce the number of CICs over the A interface or add DPUs. Then, check whether the problem is resolved. If yes, no further action is required. If no, go to Step 3. l If no, go to Step 3.

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 IPPATH with IP path type being EF is configured. l If yes, go to Step 5. l If no, run the MML command ADD IPPATH to add an IPPATH with IP path type being EF(EF). Then, check whether the problem is resolved. If yes, no further action is required. If no, go to Step 5.

5.

In Abis over IP mode, if the problem occurs only during peak hours and the value of A312F:Number of Assignment Failures (No Abis Resource Available) increases significantly, run the MML command LST IPLOGICPORT to check whether the problem BTS is configured with logical ports. l If yes, go to Step 6. l If no, run the MML command ADD IPLOGICPORT to add a logical port. Then, check whether the problem is resolved. If yes, no further action is required. If no, go to Step 6.

6.

Run the MML command LST SRCONPATH to check whether inter-subrack connections are configured. l If yes, go to Step 7. 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 transformation engineers to check whether the BSC is reset after the A over IP transformation. l If yes, go to Step 9.

Issue 01 (2011–8–17)


129


6 Access Faults

l If no, reset the BSC. Then, check whether the problem is resolved. If yes, no further action 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 IP address carried by the assignment request delivered by the MSC is on the destination IP network 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, modify the IP data configuration based on the actual situation. Then, check whether the problem is 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 the processing 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 exceed the processing capacity of these BSC boards. Then, check whether the problem is resolved. If yes, no further action is required. If no, Contact Huawei Customer Service Center. l If no, Contact Huawei Customer Service Center.

Typical Case Symptom A BSC uses one POUc as the A interface board and the POUc is configured with more than 7000 CICs. When the traffic volume exceeds 4000 Erl, the assignment success rate decreases and 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 most assignment failures are due to equipment faults. Therefore, this problem is mostly probably caused by inappropriate BSC configuration. Troubleshooting Procedure 1.

Check the traffic statistics collected during the period this problem occurs. The value of A3129T:Failed Assignments (No Ater Resource Available) is 0 and therefore the problem is 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. When 3906 CICs over the A interface are occupied, a new call can apply for a CIC over the A interface successfully but fails to request low voltage differential signal (LVDS) resources because the LVDS resources are used together with the CICs and the POUc supports a maximum 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.

Issue 01 (2011–8–17)


130


7 Voice Problems

7

Voice Problems

About This Chapter This chapter describes how to locate and troubleshoot voice problems. 7.1 GSM CS Signal Flow After a CS call is established in the GSM network, the MS and the network communicate with each other through the CS signal flow. The method of processing the GSM CS signal flow varies according to the transmission mode adopted on the Abis and A interfaces and the configuration mode of the BSC6900 subracks. 7.2 Common Voice Problems and Problem Location Methods This section describes common voice problems and the methods used to locate them. 7.3 Troubleshooting One-Way Audio or No Audio This section describes how to troubleshoot one-way audio or no audio. 7.4 Troubleshooting Noise This section describes how to troubleshoot noise. 7.5 Troubleshooting Crosstalk This section describes how to troubleshoot crosstalk. 7.6 Troubleshooting Echoes This section describes how to troubleshoot echoes. 7.7 Troubleshooting Discontinuous Voice or Low MOS This section describes how to troubleshoot discontinuous voice or low mean opinion score (MOS).

Issue 01 (2011–8–17)


131


7 Voice Problems

7.1 GSM CS Signal Flow After a CS call is established in the GSM network, the MS and the network communicate with each other through the CS signal flow. The method of processing the GSM CS signal flow varies according to the transmission mode adopted on the Abis and A interfaces and the configuration mode 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, and BM/TC separated mode. NOTE

l The Abis, Ater, and A interface boards can be the EIUa/OIUa/POUc board. The boards shown in Figure 7-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 CS signals 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 signal uses 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 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.

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. Issue 01 (2011–8–17)


132


7 Voice Problems




2.

The CS signals are demultiplexed in the Abis interface board. Each CS signal uses a 64 Kbit/s timeslot. The CS signals are transmitted to the TNUa board and then to the DPUc board.

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.


6.

The CS signals are demultiplexed in the Ater interface board of the TCS. Each CS signal uses 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 speech codec 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.

The downlink flow is the reverse of the uplink flow. In the case of BM/TC combined mode, the Ater interface does not exist. Figure 7-3 shows the CS signal flow in Abis over TDM and A over TDM mode. Figure 7-3 GSM CS signal flow (3)

As shown in Figure 7-3, the CS signal flow on the uplink is as follows: Issue 01 (2011–8–17)


133


7 Voice Problems

1.


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 DPUc board.

3.


The downlink flow is the reverse of the uplink flow.

Abis over IP and A over TDM Figure 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 A interface boards can be the EIUa/OIUa/POUc board. The boards shown in Figure 7-4, Figure 7-5, and Figure 7-6 are only examples. l The INT in the figure stands for the interface board. You can use different interface boards as required.




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 then to the Ater interface board.

4.

The CS signals are multiplexed in the Ater interface board in the MPS/EPS, and then are transmitted to the Ater interface board in the TCS.

5.

The CS signals are demultiplexed in the Ater interface board of the TCS. Each CS signal uses a 64 Kbit/s timeslot and is transmitted to the TNUa board and then to the DPUc board.

6.


The downlink flow is the reverse of the uplink flow. Issue 01 (2011–8–17)


134


7 Voice Problems

Figure 7-5 shows the CS signal flow in Abis over IP, Ater over IP, A over TDM, and BM/TC separated mode. Figure 7-5 GSM CS signal flow (5)



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 SCUa board and then to the Ater interface board.

3.


4.

The CS signals are demultiplexed in the Ater interface board of the TCS. Each CS signal uses 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 speech codec 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.

The downlink flow is the reverse of the uplink flow. In the case of BM/TC combined mode, the Ater interface does not exist. Figure 7-6 shows the CS signal flow in Abis over IP and A over TDM mode. Figure 7-6 GSM CS signal flow (6)

As shown in Figure 7-6, the CS signal flow on the uplink is as follows: Issue 01 (2011–8–17)


135


7 Voice Problems

1.


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 and rate 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 flow in 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. l The INT in the figure stands for the interface board. You can use different interface boards as required.




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 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 transmits the 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 flow in Abis over IP and A over IP transmission mode. Issue 01 (2011–8–17)


136


7 Voice Problems NOTE

l The Abis interface board can be the PEUa/FG2a/GOUa/POUc/FG2c/GOUc board, and the A interface board can be the FG2a/GOUa/PEUa/FG2c/GOUc/POUc board. The boards shown in Figure 7-8 are only examples. l The INT in the figure stands for the interface board. You can use different interface boards as required.




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 Location Methods This section describes common voice problems and the methods used to locate them.

Common Voice Problems Common voice problems include one-way audio, no audio, noise, crosstalk, echo, discontinuous voice, 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 caused by weak coverage, interference (for example co-channel, adjacent-channel, external, or intermodulation interference), or frequent cell handovers. Common symptoms of poor Um interface quality are discontinuous voice and temporarily muted voice.

l Issue 01 (2011–8–17)

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

137


7 Voice Problems

The following chips become faulty with a relatively high probability: DSP chips on the DPU, as well as TDM chips on the DPU, TNU, or interface boards. Chip faults may lead to one-way audio or noise. l

Transmission faults Common symptoms of transmission faults include the following: one-way audio or crosstalk due to incorrect cable connection or incorrect timeslot connection in the transmission equipment, noise or long delay in the case of satellite or microwave transmission, one-way audio due to packet loss on the IP transmission equipment, and discontinuous 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 IP mode, one-way audio and call drops may easily occur especially when AMR is used or during 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 the BTS/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 configured according to the configuration rules.

Problem Location Methods l

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 Audio This 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. When no audio occurs, neither party can hear the other party's voice.


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 and the controlling BSC. One-way detection cannot detect one-way audio or no audio on the Um interface or between the BSC and the MSC.

Issue 01 (2011–8–17)


138


7 Voice Problems

Location Procedure Figure 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


If the IP networking mode is used, go to Step 3. If the TDM networking mode is used, run the MML command SET GCELLSOFT with Mute 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 INH DSP 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 crossed pairs. – 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.

Issue 01 (2011–8–17)

Perform mass dialing testing. When one-way audio or no audio occurs, run the MML command STR CALLRESLOP with Loop Position set to NSSAINTF(NSS Interface Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

139


7 Voice Problems

Unit). Then, determine whether one-way audio or no audio occurs on the NSS or BSS. For details, 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 Um interface. 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 Customer Service Center. l If one-way audio or no audio does not occur over the Um interface, Contact Huawei Customer Service Center.

Typical Case Symptom A large number of subscribers experience no audio and some subscribers encounter crosstalk with a probability of about 30% at a site. Cause Analysis The cables between TNUs are not connected properly. Troubleshooting Procedure 1.

Enable one-way audio detection. Ten minutes later, the one-way audio logs show that oneway audio occurs in calls from subrack 0 to subrack 3.

2.

View the historical alarms. ALM-20231 Link Between TDM Switching Boards in Different Subracks Faulty is generated. The alarm information shows that inter-subrack cables are not connected properly.

3.

Check the cable connections. A cable from subrack 0 is mistakenly connected to subrack 4. When the cable is connected to subrack 3, the no audio and crosstalk problems are resolved.

7.4 Troubleshooting Noise This section describes how to troubleshoot noise.

Symptom One party in a call can hear certain noises, including bubbling sounds, clicking, and metallic sounds. When the noises are severe, subscribers may not even hear the other party's voice.


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

Issue 01 (2011–8–17)


140


7 Voice Problems

– Interference on radio links – Frame losses or slips due to clocks being out of synchronization – Incorrect DIP switch configurations, for example inconsistent impedance configurations l

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 regularly and fluctuates slightly, because the pulse code modulation (PCM) sample value is affected. – If the noise is due to line bit errors on the BSS side, it fluctuates noticeably, because compressed voice signals are affected. In this case, parties in a call may hear bubbling sounds, discontinuous voice, or metallic sounds and have difficulty recognizing the other party's words. – If the noise is due to regular frame losses or slips due to clock problems, it occurs at a specific 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 causing the noises.

Location Procedure Figure 7-10 shows the procedure for locating noise. Figure 7-10 Procedure for locating noise


Issue 01 (2011–8–17)

Determine whether the noise lasts a long time. A noise is considered long if it lasts more than 10s. Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

141


7 Voice Problems

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 STR CALLRESLOP 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 External Voice 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 resources and save the results. Then, find out the resource usage regularity. If the noise occurs on a fixed DSP chip of a specific board, replace the board, or run the MML command INH DSP to disable the DSP chip.

4.

Perform dialing testing to check whether noise is eliminated. l If yes, no further action is required. l If no, Contact Huawei Customer Service Center.

Typical Case Symptom A site experiences noises with a probability of about 2% and the calling/called party can hardly hear 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 unit is stored abnormally. Troubleshooting Procedure 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 on the board in slot 11 of subrack 1.

2.

Run the MML command INH DSP to disable the DSP. Then, perform dialing tests 200 times. The noise does not occur.

3.

During off-peak hours, enable DSP 7 on the board in slot 11 of subrack 1, and disable DSPs on other boards to enable calls to use DSP 7 on the board in slot 11 of subrack 1. The noise occurs every time DSP 7 is used.

4.

Replace the board in slot 11 of subrack 1. The problem is resolved.

7.5 Troubleshooting Crosstalk This 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 instead of the voice of the speaking party. Issue 01 (2011–8–17)


142


7 Voice Problems

Background Information Common causes of crosstalk include poor Um interface quality, incorrect cable connections, or incorrect timeslot connections on a switching board. The most common cause is poor Um interface 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 controlling BSC. 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 a BSC and an MSC.

Location Procedure Figure 7-11 shows the procedure for locating crosstalk. Figure 7-11 Procedure for locating crosstalk


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. l If yes, no further action is required. l If no, go to Step 3.

Issue 01 (2011–8–17)


143


3.

7 Voice Problems

Enable the 3.1.4 Crosstalk Detection function to check whether the crosstalk logs contain abnormal 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. Troubleshooting Procedure 1.

Check whether the crosstalk is due to a problem on the Um interface. One party cannot hear the voice of the other party. Several seconds later, the party hears the voice of two other 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 poor signal coverage and a large number of call drops occur over the Um interface.

3.

Run the MML command SET GCELLSOFT with Um Interface Crosstalk Optimization Allowed set to YES(Allowed). The problem is resolved.

7.6 Troubleshooting Echoes This 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.


Echoes can be either acoustic or electrical. – An acoustic echo occurs when the earphone and microphone of an MS (especially a low-end MS) are not properly isolated from each other. – An electrical echo occurs when the impedance of the two-wire connector for the hybrid converter at the public switched telephone network (PSTN) end does not match that of the four-wire connector and therefore transmitted signals are coupled to the four-wire connector at the receiving end.

l

Issue 01 (2011–8–17)

The BSS side eliminates only acoustic echoes. Electrical echoes must be eliminated by the universal media gateway (UMG). In A over IP mode, acoustic echoes must also be eliminated by the UMG because the transcoder (TC) is moved to the UMG. Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

144


7 Voice Problems

Location Procedure Figure 7-12 shows the procedure for locating an echo. Figure 7-12 Procedure for locating an echo


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, it is an acoustic echo. If you hear an echo when you use an MS to call a fixed-line phone, it is 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. NOTE

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

Issue 01 (2011–8–17)


145


7 Voice Problems

l If no, Contact Huawei Customer Service Center.

Typical Case Symptom A subscriber complains that he always hears an echo when using his MS to call a specific MS and occasionally hears an echo when calling other MSs. Cause Analysis The earphone and microphone of some MSs are not properly isolated from each other. Troubleshooting Procedure 1.

Check the model of the MS the subscriber is using and confirm that the MS is served by a Huawei BSC.

2.

Lab tests show that acoustic echoes occur with a high probability. Determine that it is an acoustic echo because the earphone and microphone of the MS are not properly isolated from 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 MOS This 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 call cannot hear enough words to understand the other party.

l

Low MOS The MOS does not meet the customer's requirement.


MOS Used to reflect the voice quality of a call, the mean opinion score (MOS) ranges from 1 to 5, where 1 indicates the lowest voice quality and 5 indicates the highest voice quality. A specialized instrument is required for measuring the MOS, which meets the perceptual evaluation 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, during which certain speech signals are lost. To resolve this problem, TFO is introduced. With TFO, when the calling and called parties use the same voice coder, neither party needs to have the transcoder (TC) activated and nor speech signals are transparently transmitted between them, as shown in Figure 7-13.

Issue 01 (2011–8–17)


146


7 Voice Problems

Figure 7-13 TFO

Location Procedure l

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 the voice quality and signal level in the measurement reports. If the voice quality is poor or the signal level is low, check the Um interface. Otherwise, Contact Huawei Customer Service Center.

l

Low MOS The 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 does not meet the customer's requirement, analyze the test report or Contact Huawei Customer Service Center.

Troubleshooting Procedure The method described in the previous part Location Procedure is recommended when troubleshooting discontinuous voice and low MOS. If the problems persist, Contact Huawei Customer Service Center.

Typical Case Symptom Field engineers report that the MOS at a site is 3.0 when the AMR is enabled, whereas the minimum 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 lost during an AMR TCHF-to-TCHH conversion. Troubleshooting Procedure 1.

Analyze the test report. During testing, the MOS is low each time an AMR TCHF-to-TCHH conversion is performed.

2.

Contact onsite testing engineers for information about the site. Words are lost on the downlink 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

Issue 01 (2011–8–17)


147


7 Voice Problems

not request the MSC to set up a downlink conference bridge when an AMR TCHF-toTCHH conversion is performed. As a result, a large number of frames are lost on the downlink, leading to a low MOS. 4.

Issue 01 (2011–8–17)

Run the MML command SET OTHSOFTPARA: BSCRESERVEDPARA3=8191; to change 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

8

PS Counter Problems

About This Chapter This chapter describes how to locate and troubleshoot PS counter problems. 8.1 PS Counters This section describes the formulas for calculating the values for PS counters. 8.2 Locating PS Counter Problems This section describes how to locate PS counter problems. 8.3 Troubleshooting Low TBF Establishment Success Rates This section describes how to troubleshoot low temporary block flow (TBF) establishment success rates. 8.4 Troubleshooting High TBF Call Drop Rates This section describes how to troubleshoot high TBF call drop rates. 8.5 Troubleshooting Low Average Throughput at the RLC Layer This 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 Schemes This section describes how to troubleshoot low percentage of high-rate coding schemes to all coding schemes. 8.7 Troubleshooting High RLC Data Block Retransmission Rates This section describes how to troubleshoot high radio link control (RLC) data block retransmission rates.

Issue 01 (2011–8–17)


149



8.1 PS Counters This section describes the formulas for calculating the values for PS counters. l

PS counters include TBF Establishment Success Rate, TBF Drop Rate, Average Throughput of RLC, Rate of RLC with High Coding, and Retransmission Rate of RLC Data 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 PDCH measurement]) – Rate of RLC with High Coding = [Total number of valid RLC data blocks with high coding] x {100}/[[Total number of valid RLC data blocks with ALL coding]] – Retransmission Rate of RLC Data Block = ([Total number of RLC data blocks] - [Total number 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

Issue 01 (2011–8–17)


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 Problems This section describes how to locate PS counter problems.

8.2.1 Principles for Locating PS Counter Problems This 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 certain cells. – 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 Problems This section describes the procedure for locating PS counter problems. Figure 8-1 shows the procedure for locating PS counter problems.

Issue 01 (2011–8–17)


151



Figure 8-1 Procedure for locating PS counter problems

8.3 Troubleshooting Low TBF Establishment Success Rates This section describes how to troubleshoot low temporary block flow (TBF) establishment success rates.

Symptom TBF establishment success rates do not meet customer requirements and PS calls are difficult to set up.

Issue 01 (2011–8–17)


152



Background Information TBFs are used to transmit PS services. If TBFs fail to be established, PS services cannot be performed successfully. The TBF establishment success rate indicates the capacity of a data service 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 transmission

l

Insufficient channel resources

l

Poor Um interface quality

l

Incorrect parameter settings

Location Procedure Figure 8-2 shows the procedure for locating low TBF establishment success rates.

Issue 01 (2011–8–17)


153



Figure 8-2 Procedure for locating low TBF establishment success rates


Issue 01 (2011–8–17)

Select the top N cells with lower TBF establishment success rates.


154


8 PS Counter Problems 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, bit errors 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 than 10. If yes, the CCCH is seriously overloaded. In this case, run the MML command SET GTRXCHAN 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 no MS response. l If TBF establishment failures are caused by insufficient channel resources, the values for 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 following counters are large: – 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 l If TBF establishment failures are caused by insufficient channel resources, go to Step 5. 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, perform the following steps: (1) Run the MML command LST GTRXCHAN to check whether Channel Type for the problem cell is set to PDTCH. If no, run the MML command SET GTRXCHAN to reconfigure the parameter. (2) Run the MML command DSP PSCELL to check whether the value for R9506:Maximum Number of PDCHs Occupied on DSP is 48 on the digital signal processor (DSP) that serves the problem cell. If yes, run the MML command SET PSCELLTODSP to migrate the problem cell to the DSP with the smallest value for R9506: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 Rate Threshold of PDCHs in a Cell for the problem cell is smaller than 30. Issue 01 (2011–8–17)


155



l If yes, run the MML command SET GCELLPSCHM and set Maximum Rate Threshold 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 following parameters: l Maximum Number of PDCH: The recommended value is 8. l Maximum Number of Occupied Abis Timeslots: The recommended value is 32. If the two parameters are not set to the recommended values, run the MML command SET GTRXBASE to reconfigure the parameters. (5) Run the MML command LST GCELLPSCHM to query the values for PDCH Uplink Multiplex Threshold and PDCH Downlink Multiplex Threshold. l If the value for PDCH Uplink Multiplex Threshold is smaller than 70, run the MML command SET GCELLPSCHM and change the value to 70. l If the value for PDCH Downlink Multiplex Threshold is smaller than 80, run the 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 the subrack accommodating the Abis interface board. l Run the MML command DSP PSCELL to query the value for Subrack No., which is 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 Subrack No., which is the number of the subrack accommodating the Abis interface board. If the two subrack numbers are different, run the MML command SET PSCELLTODSP to migrate the problem cell to the DSP that is located in the subrack accommodating the Abis interface board. (7) Run the MML command LST BSCPSSOFTPARA to check whether Allow E Down G Up Switch is set to Open. If no, run the MML command SET BSCPSSOFTPARA to reconfigure the parameter.

CAUTION Setting Allow E Down G Up Switch to Open may decrease the EDGE download rate. 6.

To troubleshoot TBF establishment failures due to no MS response, perform the following steps: (1) Set the following parameters: l If the uplink TBF establishment success rate is low, run the MML command SET GCELLEGPRSPARA to set Uplink Default MCS Type for the problem cell to MCS1. l If the downlink TBF establishment success rate is low, run the MML command SET GCELLEGPRSPARA to set Downlink Default MCS Type for the problem cell to MCS2.

Issue 01 (2011–8–17)


156



(2) Check the interference band counters to determine whether interference exists in the problem cell. If yes, eliminate the interference or change the interfered ARFCN. (3) Check the uplink and downlink quality counters to determine whether the Um interface quality 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 not more than 2000. A small value indicates a short interval for an MS to determine a TBF establishment failure. As a result, when a TBF fails to be established, the average delay for PS service access decreases, but the TBF establishment success rate in an adverse radio environment also decreases. In addition, the probability of PS service reaccess increases. Consequently, the number of reassignments increases, wasting system resources. A large value indicates a long interval for an MS to determine a TBF establishment failure. As a result, when a TBF fails to be established, the average delay for PS service access increases, but the TBF establishment success rate in an adverse radio environment also increases. (2) Run the MML command SET GCELLPSPWPARA to change the values for ALPHA and GAMMA. Small values for the two parameters indicate a high output power for MSs and a strong 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 cell interference, but a weak signal strength received by BTSs. Therefore, change the values for these two parameters according to site requirements. Generally, smaller values are appropriate for densely populated areas and larger values for remote areas. (3) Run the MML command SET GCELLCCACCESS to increase the value for PS RACH Min. Access Level. The recommended value is -109. Increasing the value for PS RACH Min. Access Level improves the TBF establishment success rate, but decreases the number of admitted subscribers and the traffic volume. (4) Run the MML command SET GCELLCCACCESS to increase the value for Random Access Error Threshold. The recommended value is 225. A small value allows more random access signal errors and easier MS random access, but leads to a high misreporting rate. A large value reduces the misreporting rate, but reduces the number of admitted subscribers 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 of Downlink TBF Reassignment to 4. A large value increases the downlink TBF establishment success rate, but increases the congestion rate during peak hours too. A small value decreases the congestion rate during peak hours, but decreases the downlink TBF establishment success rate too.

Issue 01 (2011–8–17)


157



(2) Run the MML command LST BSCPSSOFTPARA to check whether Retry Times of Downlink TBF Polling is set to 5. If no, run the MML command SET BSCPSSOFTPARA to reconfigure the parameter. A large value increases the downlink TBF establishment success rate, but increases the congestion rate during peak hours too. A small value decreases the congestion rate during peak hours, but decreases the downlink 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. Troubleshooting Procedure 1.

Analyze related counters. The TBF establishment success rates are lower than 80% for 10 cells.

2.

Check the frame error rates for Abis transmission in these cells. The frame error rates are all lower than 1‰.

3.

Check the causes of TBF establishment failures. All TBF establishment failures are caused by insufficient channel resources.

4.

Check parameter settings. PDCHs are configured, and Allow E Down G Up Switch is set to Open.

5.

Check the counters related to the DSPs serving the problem cells. The value for R9506:Maximum Number of PDCHs Occupied on DSP is smaller than 48 for all the problem cells.

6.

Check the value for Maximum Rate Threshold of PDCHs in a Cell. The value is 10 for problem cells but 30 for normal cells.

7.

Change the value for Maximum Rate Threshold of PDCHs in a Cell to 30 for the problem cells. The TBF establishment success rates return to normal.

8.4 Troubleshooting High TBF Call Drop Rates This 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 high during web browsing, web pages open slowly or even fail to open.

Background Information The TBF call drop rate is the ratio of the number of abnormal TBF releases to the number of TBF establishment successes. The causes of high TBF call drop rates are as follows: Issue 01 (2011–8–17)


158



l

No MS response due to poor Um interface quality

l

Loss of MS uplink messages due to network transmission faults or resource preemption

l

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 N3105

l

Cell reselection

l

Channel preemption

Location Procedure Figure 8-3 shows the procedure for locating high TBF call drop rates.

Issue 01 (2011–8–17)


159



Figure 8-3 Procedure for locating high TBF call drop rates

Troubleshooting Procedure 1. Issue 01 (2011–8–17)

Check whether any cells meet the standard for high TBF call drop rates. Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

160



l If yes, select the top N cells with higher TBF call drop rates. 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 EGPRS call drop rate is high, run the MML command LST GCELLEGPRSPARA 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, decrease the value for this parameter. – Downlink Default MCS Type: Check whether the value for this parameter is smaller 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 SET GCELLEGPRSPARA to change the settings. l If the GPRS call drop rate is high, run the MML command LST 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 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 SET GCELLEGPRSPARA to change the settings. l Run the MML command LST GCELLEGPRSPARA to check whether Bep Period is set to 5. If no, run the MML command SET GCELLPSPWPARA to change the value for this parameter to 5. l Run the MML command LST GCELLSTANDARDOPTPARA to check the values for 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 SET GCELLSTANDARDOPTPARA to change the settings.

3.

For the top N cells with higher TBF call drop rates, check whether the value for RL9A08: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 transmission engineers.

4.

Check the causes of abnormal TBF releases. Abnormal TBF releases are generally caused by 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:

Issue 01 (2011–8–17)


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 N3105 Overflow – A9306:Number of Downlink EGPRS TBF Abnormal Releases due to N3105 Overflow l If abnormal TBF releases are caused by lack of channel resources, the values for the following 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 following counters 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 frequency hopping (FH), or uplink and downlink imbalance may lead to RLC block decoding failures and N3101/N3103/N3105 overflow, resulting in abnormal TBF releases. In this case, 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 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 two counters are large, dynamic PDCHs have been preempted by CS services during peak hours. In this case, expand the BTS capacity. l Cell reselection Check whether the cells and routing areas are properly planned. If no, replan them.

6.




162



The TBF call drop rate at a site increases by 3%. Cause Analysis Frequency interference and insufficient channel resources Troubleshooting Procedure 1.

Check that the parameters for the cells with high TBF call drop rates are set to recommended values.

2.


3.

Analyze the counters reported by the field engineers. The causes of high TBF call drop rates 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 frequency planning. ARFCN 7 experiences interference from a nearby BTS. The related TRX is configured with PDCHs. Change the ARFCN, the number of N3105 overflows decreases from several hundred times to about 30 times. l Lack of channel resources The values for R9343:Number of Reclaimed Dynamic PDCHs and R9344:Number of Reclaimed Busy Dynamic PDCHs for the problem cells are high. The reason is that call drops occur when TBFs are transmitted over TCHs that are converted from dynamic PDCHs 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 RLC Layer This section describes how to troubleshoot low average throughput at the radio link control (RLC) layer.

Symptom The download rate is low. The values for the following counters do not meet the standard for low average throughput at the RLC layer. l

TL9333:Average Throughput of Downlink EGPRS RLC

l

TL9114:Average Throughput of Downlink GPRS RLC

l

TL9232:Average Throughput of Uplink EGPRS RLC

l

TL9014:Average Throughput of Uplink GPRS RLC

Background Information Throughput is the amount of data transmitted per time unit. The higher the throughput, the higher the PS transmission rate. The causes of low average throughput at the RLC layer are as follows: Issue 01 (2011–8–17)


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 Multiplex Threshold, Channel Type, and Bep Period.

l

Low MS capabilities, such as low buffer capability, low packet assembly and disassembly capability, low multislot capability, and low EGPRS service support capability.

Location Procedure Figure 8-4 shows the procedure for locating low average throughput at the RLC layer.

Issue 01 (2011–8–17)


164



Figure 8-4 Procedure for locating low average throughput at the RLC layer


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

Issue 01 (2011–8–17)


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. For details, see 8.6 Troubleshooting Low Percentage of High-Rate Coding Schemes to All Coding Schemes. l If no, go to Step 3.

3.

Check whether the related parameters are set correctly. l If the EGPRS throughput is low, run the MML command LST GCELLEGPRSPARA 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 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 SET GCELLEGPRSPARA to change the settings. l If the GPRS throughput is low, run the MML command LST 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 SET GCELLEGPRSPARA to change the settings. l Run the MML command LST GCELLEGPRSPARA to check whether Bep Period is set to 5. If no, run the MML command SET GCELLPSPWPARA to change the value for this parameter to 5. l Run the MML command LST GCELLPSCHM to query the value for Timer of Releasing Abis Timeslot. – If the value for Timer of Releasing Abis Timeslot is larger than 15, run the MML command 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 PDCH Downlink Multiplex Threshold. – If the value for PDCH Downlink Multiplex Threshold is larger than 80, run the MML command SET GCELLPSCHM to change the value for this parameter to 80. – If the value for PDCH Downlink Multiplex Threshold is smaller than or equal to 80, retain the value. l Run the MML command LST BSCPSSOFTPARA to check whether Allow E Down G Up Switch is set to Open. If yes, run the MML command SET

Issue 01 (2011–8–17)


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 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 transmission engineers.

5.

Poor Um interface quality may lead to a low bit error probability (BEP). Poor Um interface quality may be caused by co-channel or adjacent-channel interference, frequency collision due to frequency hopping (FH), or uplink and downlink imbalance. As a result, high-rate coding schemes cannot be used, resulting in a decrease in the average throughput at the RLC layer. In this case, 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 Poor Um Interface Quality.

6.

If the percentage of high-rate coding schemes to all coding schemes and the number of available packet data channels (PDCHs) increase, the average throughput at the RLC layer increases. To prevent an increase in the RLC data retransmission rate and occupation of more transmission resources, change the values for the following parameters according to site 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 formula for calculating the number of sufficient idle Abis timeslots is as follows: Number of sufficient idle Abis timeslots = (Number of static PDCHs + Number of TCHFs) x Maximum 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 can still use high-rate coding schemes, increasing the percentage of high-rate coding schemes 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 Preempting Dynamic Channel to 15. – Advantage: The coding schemes can be adjusted quickly. – Disadvantage: The upload rate may decrease.

Issue 01 (2011–8–17)


167


7.



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.


Check the settings of the parameters for the cells with low average throughput at the RLC layer. These parameters are set to recommended values.

2.


3.

Perform a drive test to obtain the Tems log and check the Um interface quality of these cells. 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, the average 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 cells are insufficient. After more idle Abis timeslots are added, the average throughput at the RLC layer in these cells returns to normal.

8.6 Troubleshooting Low Percentage of High-Rate Coding Schemes to All Coding Schemes This section describes how to troubleshoot low percentage of high-rate coding schemes to all coding schemes.

Symptom The percentage of high-rate coding schemes to all coding schemes indicates data transmission performance. If this percentage is low during web browsing, web pages open slowly or even fail to open.

Background Information The percentage of EDGE high-rate coding schemes to all coding schemes refers to the ratio of radio link control (RLC) data blocks that use coding schemes MCS7 through MSC9 (including MSC6 at certain sites) to all data blocks. The percentage of GPRS high-rate coding schemes to all coding schemes refers to the ratio of RLC 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 transmission rate 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: Issue 01 (2011–8–17)


168


l


Poor Um interface quality Poor Um interface quality may lead to a low bit error probability (BEP). In this case, highrate coding schemes cannot be used. Poor Um interface quality may also lead to an automatic switchover to the LA mode, in which data blocks are segmented and retransmitted. In this case, the percentage of highrate coding schemes to all coding schemes decreases.

l

Insufficient idle Abis timeslots, which may affect the coding scheme adjustment. In this case, the percentage of high-rate coding schemes to all coding schemes and the transmission rate significantly decrease.

l

High frame error rates for Abis transmission, which may lead to loss and retransmission of data blocks. In this case, the percentage of high-rate coding schemes to all coding schemes decreases.

l

Abnormal temporary block flow (TBF) releases, which may lead to data transmission using low-rate coding schemes. In this case, the percentage of high-rate coding schemes to all coding schemes decreases.

Location Procedure Figure 8-5 shows the procedure for locating low percentage of high-rate coding schemes to all coding schemes.

Issue 01 (2011–8–17)


169



Figure 8-5 Procedure for locating low percentage of high-rate coding schemes to all coding schemes


Issue 01 (2011–8–17)

Check whether any cells meet the standard for low percentage of high-rate coding schemes to all coding schemes. Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

170



l If yes, select the top N cells with low percentage of high-rate coding schemes to all coding 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, run the MML command LST GCELLEGPRSPARA 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 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 SET GCELLEGPRSPARA to change the settings. l If the percentage of GPRS high-rate coding schemes is low, run the MML command LST 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 SET GCELLEGPRSPARA to change the settings. l Run the MML command LST GCELLPSCS to check whether the thresholds of the uplink and downlink TBF retransmission rates are set to recommended values. If no, run the MML command SET GCELLPSCS to set these parameters to recommended values. 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 to 5. If no, run the MML command SET GCELLPSPWPARA to change the value for Bep Period to 5. l Run the MML command LST GCELLPSCHM to query the value for Timer of Releasing Abis Timeslot. If the value for Timer of Releasing Abis Timeslot is larger than 15, run the MML command SET GCELLPSCHM to change the value for Timer of Releasing Abis Timeslot to 15. l Run the MML command LST BSCPSSOFTPARA to check whether Allow E Down G Up Switch is set to Open. If yes, run the MML command SET BSCPSSOFTPARA 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 transmission engineers.

4.

Poor Um interface quality may lead to a low BEP. Poor Um interface quality may be caused by co-channel or adjacent-channel interference, frequency collision due to FH, or uplink and downlink imbalance. As a result, high-rate coding schemes cannot be used. In this case,

Issue 01 (2011–8–17)


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 Poor Um Interface Quality. 5.

Run the MML command LST BTSIDLETS to check whether idle Abis timeslots configured for the BTS are sufficient. If Number of idle Abis timeslots ≥ (Number of static PDCHs + Number of TCHFs) x Maximum 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 add idle Abis timeslots.

6.

Check whether there are a large number of abnormal TBF releases. If yes, see 8.4 Troubleshooting 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 following parameters according to site 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 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 can still use high-rate coding schemes, increasing the percentage of high-rate coding schemes 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 Preempting Dynamic Channel to 15. – Advantage: The coding schemes can be adjusted quickly. – Disadvantage: The upload rate may decrease. 8.


Typical Case Symptom The percentage of high-rate coding schemes to all coding schemes used at the RLC layer is only about 74% at a site. Cause Analysis High-rate coding schemes cannot be used due to insufficient idle Abis timeslots. Issue 01 (2011–8–17)


172




Check the settings of the parameters for the cells with low percentage of high-rate coding schemes to all coding schemes. These parameters are set to recommended values.

2.


3.

Check the traffic statistics about interference bands as well as uplink and downlink balance in these cells. The traffic statistics are normal.

4.

Query the number of idle Abis timeslots in problem cells. The idle Abis timeslots in these cells are insufficient. After more idle Abis timeslots are added, the percentage of high-rate coding schemes to all coding schemes in these cells returns to normal.

8.7 Troubleshooting High RLC Data Block Retransmission Rates This section describes how to troubleshoot high radio link control (RLC) data block retransmission rates.

Symptom The RLC data block retransmission rate indicates data transmission performance. If the RLC data block retransmission rate is high or the percentage of high-rate coding schemes to all coding schemes is low during web browsing, web pages open slowly or even fail to open.

Background Information The RLC data block retransmission rate is the ratio of the number of retransmitted RLC data blocks to the total number of RLC data blocks. This rate is closely related to the percentage of high-rate coding schemes to all coding schemes. If the percentage of high-rate coding schemes to all coding schemes increases, this rate may increase accordingly. Therefore, it is recommended that these two KPIs be compromised. High RLC data block retransmission rates are also caused by: l

Poor Um interface quality Poor Um interface quality may lead to incorrect RLC data blocks received by MSs. In this case, the number of RLC data retransmissions increases. Poor Um interface quality may also lead to an automatic switchover to the LA mode, in which data blocks are segmented and retransmitted. In this case, the percentage of highrate coding schemes to all coding schemes decreases.

l

High frame error rates for Abis transmission, which may lead to loss and retransmission of data 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 data blocks

Location Procedure Figure 8-6 shows the procedure for locating high RLC data block retransmission rates.

Issue 01 (2011–8–17)


173



Figure 8-6 Procedure for locating high RLC data block retransmission rates


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. 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 EGPRS retransmission rate is high, run the MML command LST GCELLEGPRSPARA 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.

Issue 01 (2011–8–17)


174



– Uplink Default MCS Type: The recommended value is MCS2. If the uplink EGPRS retransmission rate is high, decrease the value for this parameter. – Downlink Default MCS Type: The recommended value is MCS6. If the downlink EGPRS retransmission rate is high, decrease the value for this parameter. If the parameters are not set to the recommended values, run the MML command SET GCELLEGPRSPARA to set the parameters to the recommended values. l If the GPRS retransmission rate is high, run the MML command LST 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 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 SET GCELLEGPRSPARA to change the settings. l Run the MML command LST GCELLPSPWPARA to check the values for the following 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 SET GCELLPSPWPARA to change the settings. 3.

For the top N cells with higher RLC data block retransmission rates, 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 transmission engineers.

4.

Poor Um interface quality may lead to a low BEP. Poor Um interface quality may be caused by co-channel or adjacent-channel interference, frequency collision due to frequency hopping (FH), or uplink and downlink imbalance. As a result, high-rate coding schemes cannot be used. In this case, 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 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.

6.


Typical Case Symptom 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 uplink retransmission rates at 21:00. All problem cells are P-GSM900 cells. Troubleshooting Procedure 1.

Issue 01 (2011–8–17)

Check whether the parameters for the cells with high RLC data block retransmission rates are set to recommended values. The parameter settings are correct. Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

175



2.


3.

Analyze the traffic statistics. The uplink RLC data block retransmission rate and the percentage of interference bands 4 and 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 county boundaries.

5.

Issue 01 (2011–8–17)

Optimize the network. The Um interface quality becomes satisfactory and the retransmission rate problem is resolved.


176


9 PS Channel Faults

9

PS Channel Faults

About This Chapter This chapter describes how to locate and troubleshoot PS channel faults. 9.1 Identifying PS Channel Faults This section describes how to identify PS channel faults. You can identify PS channel faults by monitoring the PS channel status on the LMT or querying the PS channel status using an MML command. 9.2 Locating PS Channel Faults This section describes how to locate PS channel faults. 9.3 Troubleshooting PDCH Faults Due to Channel Inactivity This section describes how to troubleshoot packet data channel (PDCH) faults due to channel inactivity. 9.4 Troubleshooting PDCH Faults Due to Channel Asynchronization This section describes how to troubleshoot packet data channel (PDCH) faults due to channel asynchronization.

Issue 01 (2011–8–17)


177


9 PS Channel Faults

9.1 Identifying PS Channel Faults This section describes how to identify PS channel faults. You can identify PS channel faults by monitoring the PS channel status on the LMT or querying the PS channel status using an MML command.

Monitoring the PS Channel Status on the LMT For details, see Monitoring Channel Status.

Querying the PS Channel Status Using an MML Command Run the MML command DSP PDCH to query the PS channel status of a cell. The PS channels whose Channel Operation State is Unavailable are faulty.

9.2 Locating PS Channel Faults This section describes how to locate PS channel faults.

Principles If the packet data channels (PDCHs) of all cells under a BTS are faulty, check whether the transmission and operating status of the BTS are normal. If the PDCHs of some cells under different BTSs are faulty, check whether these cells are assigned to the same digital signal processor (DSP). If only certain PDCHs are faulty, refer to Troubleshooting PDCH Faults Due to Channel Inactivity or Troubleshooting PDCH Faults Due to Channel Asynchronization.

Location Procedure Figure 9-1 shows the procedure for locating PS channel faults.

Issue 01 (2011–8–17)


178


9 PS Channel Faults

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 whether the transmission and operating status of the BTS and its carriers are normal. If the transmission 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 are assigned to the same DSP based on the values of Subrack No., Slot No., and DSP No. in the command output. If yes, run the SET PSCELLTODSP command to assign these cells to DSPs carrying light load. If the faults persist, go to Step 3.

Issue 01 (2011–8–17)


179


9 PS Channel Faults

CAUTION Assign the problem cells to different DSPs to ensure that the number of activated channels on 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 to Channel Inactivity and Troubleshooting PDCH Faults Due to Channel Asynchronization.

9.3 Troubleshooting PDCH Faults Due to Channel Inactivity This section describes how to troubleshoot packet data channel (PDCH) faults due to channel inactivity.

Symptom When monitoring the channel status is enabled on the LMT, the icon under a PDTCH of a cell is 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, the channel is not activated. Figure 9-2 Monitor Channel Status tab page

Background Information The 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.

Issue 01 (2011–8–17)


180


9 PS Channel Faults NOTE

One DPUP is configured with 22 DSPs, where 21 DSPs are configured with 192 LVDS timeslots each and one DSP is configured with 48 LVDS timeslots. Therefore, you need to query the DSP link status 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. The DSP with the greatest number of LVDS timeslots with these parameter settings has the lightest load.

Location Procedure Figure 9-3 shows the procedure for locating PDCH faults due to channel inactivity.

Issue 01 (2011–8–17)


181


9 PS Channel Faults

Figure 9-3 Procedure for locating PDCH faults due to channel inactivity


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 the command output, these cells are not properly assigned to a DSP. Run the MML command SET PSCELLTODSP to assign these cells to a DSP with a light load.

2.

Run the MML command DSP PSCELL to check whether Cell Um Administration State 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 upper threshold. If yes, run the MML command SET PSCELLTODSP to assign the cells whose PDCHs are faulty to a DSP with a light load.

Issue 01 (2011–8–17)


182


9 PS Channel Faults NOTE

To 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 the cells whose PDCHs are faulty. 2. Run the MML command DSP PDCHNUM to check whether Number of Active Channels of the DSP is 48. If yes, the number of activated channels on the DSP has reached the upper threshold.

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 following steps: (1) Run the MML command DSP PSCELL to query Subrack No., Slot No., and DSP No. of the cells whose PDCHs are faulty. (2) Run the MML command DSP DSPLINK. If the DSP is configured with 48 LVDS links and the DSP does not have an LVDS timeslot whose Allocate State is Normal and Not Assigned, the LVDS timeslots on the DSP are insufficient. (3) Run the MML command SET PSCELLTODSP to assign the cells whose PDCHs are faulty to a DSP with a light load.

5.

If the faults persist, Contact Huawei Customer Service Center.

Typical Case Symptom 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. Troubleshooting Procedure 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 Channel Asynchronization This section describes how to troubleshoot packet data channel (PDCH) faults due to channel asynchronization.

Symptom The 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 PS services are being processed, uploading and downloading data may be interrupted and some ping packets may be lost. If a PDCH is faulty, detailed information about the channel status is Issue 01 (2011–8–17)


183


9 PS Channel Faults

displayed when you click the red icon under the PDCH. If Applied Bandwidth is inconsistent with Available Bandwidth as shown in Figure 9-4, the PDCH fault is caused by channel asynchronization. Figure 9-4 Monitor Channel Status tab page

Background Information To 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 Board ClockStatus, as shown in Figure 9-5. If Phase-locked loop state of clock source is Lock, the DTMU clock synchronizes with the 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:

Issue 01 (2011–8–17)


184


9 PS Channel Faults

l ALM-20204 Clock Signal Inputs Faulty l ALM-20209 Faulty Phase-Locked Loop of the Board Clock l ALM-20208 Clock Reference Source of Main Control Board Unavailable l ALM-20207 Failure in Locking System Clock Source l ALM-20206 Current System Clock Reference Source Status Abnormal 3.

On the LMT, choose Device Maintenance > BSC Maintenance > Query BSC Board Clock 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 Procedure Figure 9-7 shows the procedure for locating PDCH faults due to channel asynchronization.

Issue 01 (2011–8–17)


185


9 PS Channel Faults

Figure 9-7 Procedure for locating PDCH faults due to channel asynchronization


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 PDCH faults persist, go to Step 3.

3.

Check whether the DTMU clock synchronizes with the BSC clock by referring to Background Information. If yes, go to Step 4. If no, lock the BSC clock according to the instructions in Background Information.

4.

If the PDCH faults persist, Contact Huawei Customer Service Center.

Typical Case Symptom According to the channel status on the LMT at a site, some PDCHs are faulty. After the query result is refreshed, the channel status returns to normal. Issue 01 (2011–8–17)


186


9 PS Channel Faults

Cause Analysis The E1 cables are faulty. Troubleshooting Procedure 1.

Check the BTS version at the site. The BTS version is not one of the BTS versions that have asynchronization problems.

2.

Query traffic statistics. The FER over the Abis interface is high and the LAPD Link Interrupt Alarm is reported.

3.

Troubleshoot transmission faults and replace the E1 cables. The PDCH faults are rectified.

Issue 01 (2011–8–17)


187


10 Cell PS Service Faults

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 Faults In this chapter, cell PS service faults refer to failures to provide PS services for all subscribers in a cell. If a cell fails to provide PS services for some subscribers, the MSs used by these subscribers are probably incompatible with the network. Cell PS service faults of this type can be rectified with tracing signaling and are not discussed in this document. 10.2 Locating Cell PS Service Faults This section describes how to locate cell PS service faults. 10.3 Troubleshooting Cell PS Service Faults Due to Incorrect Data Configurations This section describes how to troubleshoot cell PS service faults due to incorrect data configurations. 10.4 Troubleshooting Cell PS Service Faults Due to Hardware Issues This 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 BSC This section describes how to troubleshoot cell PS service faults due to incorrect cable connections inside the BSC. 10.6 Troubleshooting Cell PS Service Faults Due to Gb Interface Issues This section describes how to troubleshoot cell PS service faults due to Gb interface issues.

Issue 01 (2011–8–17)


188



10.1 Remarks on Cell PS Service Faults In this chapter, cell PS service faults refer to failures to provide PS services for all subscribers in a cell. If a cell fails to provide PS services for some subscribers, the MSs used by these subscribers are probably incompatible with the network. Cell PS service faults of this type can be 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 mobile communications system. Packet switched entities are added to the GSM mobile communications system to implement data transmission in packet mode, enabling subscribers to access the Internet or other packet data networks by using mobile terminals that support packet data services. Cells require the following resources to perform PS services: transmission resources, packet data channels (PDCHs), digital signal processors (DSPs), and Gb interface resources. Cell PS services will fail if any of these resources are unavailable or insufficient.

10.2 Locating Cell PS Service Faults This section describes how to locate cell PS service faults.

Principles Signaling tracing is commonly used to locate cell PS service faults. With tracing signaling, you can locate the points where cell PS services are congested. Before tracing signaling, you can troubleshoot the following problems or faults to locate cell PS service faults: 1.

Incorrect data configurations

2.

Hardware faults

3.

Incorrect cable connections inside the BSC

4.

Gb interface faults

Location Procedure Figure 10-1 shows the procedure for locating cell PS service faults.

Issue 01 (2011–8–17)


189



Figure 10-1 Procedure for locating cell PS service faults

10.3 Troubleshooting Cell PS Service Faults Due to Incorrect Data Configurations This section describes how to troubleshoot cell PS service faults due to incorrect data configurations.

Symptom All or some of the cells under a BSC fail to provide PS services.

Background Information In addition to the basic parameters for PS services, pay attention to the following configurations: l

Um Interface Tag, Abis Interface Tag, and A Interface Tag

l

The mapping between IPPATH and TRMMAP in Abis over IP mode

Issue 01 (2011–8–17)


190



Location Procedure Figure 10-2 shows the procedure for locating cell PS service faults due to incorrect data configurations. Figure 10-2 Procedure for locating cell PS service faults due to incorrect data configurations


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 Interface Tag are all GSM_PHASE_2. If no, run the MML command SET BSCBASIC to modify the parameter settings.

2.

If some IP BTSs under a BSC fail to provide PS services, perform the following operations to 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 IP path type for all IP paths. If no IP path type is QOS, go to Step c. Otherwise, go to Step 3. (3) Run the MML command LST TRMMAP to query PS high PRI data path and PS low PRI data path. (4) Check whether the query results of PS high PRI data path and PS low PRI data path contain IP path type. If neither PS high PRI data path nor PS low PRI data path contains IP path type, run the MML command ADD TRMMAP to add IP path type.

3.

Issue 01 (2011–8–17)

If the cell PS service faults persist, refer to 10.4 Troubleshooting Cell PS Service Faults Due to Hardware Issues. Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

191



Typical Case Symptom 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 been modified. As a result, the PS services fail. Troubleshooting Procedure 1.

View the operation logs. GSM Phase has been modified. The records in the operation logs are 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 are rectified.

10.4 Troubleshooting Cell PS Service Faults Due to Hardware Issues This section describes how to troubleshoot cell PS service faults due to hardware issues.

Symptom Cells that fail to provide PS services are assigned to the same digital signal processor (DSP) and board fault alarms are reported.

Background Information CS service faults caused by hardware issues are not discussed in this section. The following are the hardware faults that affect PS services: l

DPUd faults

l

Gb interface board faults

l

DSP faults

Location Procedure Figure 10-3 shows the procedure for locating cell PS service faults due to hardware issues.

Issue 01 (2011–8–17)


192



Figure 10-3 Procedure for locating cell PS service faults due to hardware issues


Check whether the DPUd, FG2a, FG2c, and PEUa report any board fault alarms such as ALM-20241 Board Unavailable, ALM-20242 Board Subsystem Unavailable, and ALM-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 other cells assigned to the same DSP as the problem cell. If the following conditions are met, the DSP is faulty: 1) All the cells assigned to the DSP fail to provide PS services; 2) After these cells 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 Incorrect Cable 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. Troubleshooting Procedure 1. Issue 01 (2011–8–17)

View the alarm logs. No board alarms are reported. Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

193



2.

Run the MML command DSP PSCELL. All problem cells are assigned to DSP 10 in slot 8 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 8 of subrack 0, they fail to provide PS services again. Therefore, DSP 10 in slot 8 of subrack 0 is faulty.

4.

Run the MML command INH DSP to disable the faulty DSP because there is no spare DPUd at the site. The faults are rectified.

10.5 Troubleshooting Cell PS Service Faults Due to Incorrect Cable Connections Inside the BSC This section describes how to troubleshoot cell PS service faults due to incorrect cable connections inside the BSC.

Symptom Some cells fail to provide PS services.

Background Information The Abis interface board and the DPUd board serving the same cell may be installed in different subracks because DPUb boards work as a resource pool. If cable connections between subracks are 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 cable connections inside the BSC. Figure 10-4 Procedure for locating cell PS service faults due to incorrect cable connections inside the BSC

Issue 01 (2011–8–17)


194




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 serves the problem cells. All the problem cells are assigned to a DSP on the subrack. Run the MML command LST GTRX to query Out-BSC Subrack No., which specifies the number of the subrack accommodating the Abis interface board. Check whether the values of Subrack No. and Out-BSC Subrack No. are the same. If no, run the MML command SET PSCELLTODSP to assign the problem cells to the DSP on the subrack accommodating the Abis interface board. If the subrack numbers are the same but PS services still fail, refer to 10.6 Troubleshooting Cell PS Service Faults Due to Gb Interface Issues.

Typical Case Symptom Some cells fail to provide PS services at a site. Cause Analysis The cable connection between port 0 in slot 5 of subrack 0 and port 0 in slot 4 of subrack 1 is abnormal. Troubleshooting Procedure 1.

Analyze the Abis interface board and service board serving the problem cells. The Abis interface 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 between subrack 1 and subrack 0. The cable connection between port 0 in slot 5 of subrack 0 and port 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 slot 5 of subrack 0 is loose.

4.

Tighten the cable. The cable connections between subrack 1 and subrack 0 return to normal and the faults are rectified.

10.6 Troubleshooting Cell PS Service Faults Due to Gb Interface 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 of the MML command DSP PSCELL.

Background Information Cell PS service faults are sometimes caused by the following issues with the Gb interface: Issue 01 (2011–8–17)


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 mobility management (GMM) signaling.

Location Procedure Figure 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


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 Um Administration State is Unblocked, the cell PS service faults are caused by Gb interface issues.

2.

Clear the following Gb interface alarms by referring to the alarm help: l ALM-21385 Gb BC Failure l ALM-22005 NSE Faulty l ALM-22003 NSVC Disconnection l ALM-22004 NSVL Faulty l ALM-22009 NSVL Dynamic Configuration Procedure Failure l ALM-22008 PTP BVC Faulty

3.

If the faults persist, Contact Huawei Customer Service Center.

Typical Case Symptom Some cells fail to provide PS services at a site. Cause Analysis The NSVC is interrupted because the data configuration on the BSC is inconsistent with that on the SGSN. Issue 01 (2011–8–17)


196




Run the MML command DSP PSCELL. The Cell Gb Administration State in the command output is Blocked.

2.

Check for BC, NSVC, and NSE fault alarms on the BSC. The alarm ALM-22003 NSVC Disconnection is reported.

3.

Refer to the alarm help. The alarm is reported because the data configuration on the BSC is inconsistent with that on the SGSN.

4.

Modify the data configurations to ensure that the data configuration is consistent on both the BSC and the SGSN. The NSVC interruption alarm is cleared.

5.

Run the MML command DSP PSCELL. The Cell Gb Administration State in the command output is Unblocked.

6.

The faults are rectified.

Issue 01 (2011–8–17)


197


11 IP Transmission Faults

11

IP Transmission Faults

About This Chapter This chapter describes how to locate and troubleshoot IP transmission faults. 11.1 Troubleshooting FE/GE Transmission Faults This section describes how to troubleshoot fast Ethernet or gigabit Ethernet (FE/GE) transmission faults. 11.2 Troubleshooting IP Layer Faults This section describes how to troubleshoot IP layer faults. 11.3 Troubleshooting PPP or MLPPP Link Faults This section describes how to troubleshoot Point-to-Point Protocol (PPP) or Multi-Link Pointto-Point Protocol (MLPPP) link faults. 11.4 Troubleshooting LAPD Link Faults This section describes how to troubleshoot Link Access Protocol on the D channel (LAPD) link faults. 11.5 Troubleshooting SCTP Link Faults This section describes how to troubleshoot Stream Control Transmission Protocol (SCTP) link faults. 11.6 Troubleshooting IP Path Problems This section describes how to troubleshoot IP path problems. 11.7 Troubleshooting DHCP Problems This section describes how to troubleshoot Dynamic Host Configuration Protocol (DHCP) problems. 11.8 Troubleshooting IP PM Activation Failures This section describes how to troubleshoot IP performance monitor (IP PM) activation failures. 11.9 Troubleshooting IP Clock Faults This section describes how to troubleshoot IP clock faults.

Issue 01 (2011–8–17)


198



11.1 Troubleshooting FE/GE Transmission Faults This section describes how to troubleshoot fast Ethernet or gigabit Ethernet (FE/GE) transmission faults.

Symptom l

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 Check Failure

21347

ALM-21347 IP Address Conflict

21351

ALM-21351 IP Excessive Frame Error Rate

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 faults The 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 faults The faults at the data link layer are generally caused by incorrect VLAN IDs or transport network interruption.


Port interworking parameters The port interworking parameters are ETHPORT SPEED and Auto negotiation. Their respective settings for both interconnected ports must be consistent based on negotiation. For example, ETHPORT SPEED for both interconnected ports must be set to either 100M or AUTO, and the settings of Duplex for both interconnected ports must also be consistent. Table 11-2 lists the recommended values for the two parameters. Table 11-2 Recommended values for the ETHPORT SPEED and Duplex parameters

Recommended value 1

Issue 01 (2011–8–17)

ETHPORT SPEED

Duplex

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 the settings 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 BTS first queries the next-hop media access control (MAC) address according to the mapping between the IP routing table and the ARP table, and then sends the ICMP, SCTP, or UDP packets. If there is no corresponding ARP table, the BSC or BTS sends an ARP request to query the next-hop MAC address or the peer IP address on the Layer 2 (L2) network. Figure 11-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.


Physical layer faults Figure 11-2 shows the procedure for locating physical layer faults.

Issue 01 (2011–8–17)


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.

Issue 01 (2011–8–17)


201



Figure 11-3 Procedure for locating data link layer faults

Troubleshooting Procedure l

Physical layer faults 1.

Check whether the Ethernet cable is normal. For example, the maximum transmission distance of an Ethernet cable is 100 m. If the Ethernet cable is defective, replace it and check whether the alarms related to FE/GE transmission faults are cleared. If an optical fiber is used to connect two ports, check whether the optical modules in use meet the specifications. For example, a 100 Mbit/s optical module is not applicable to a 1000 Mbit/s port. Replace any optical modules that do not meet the specifications and check whether the alarms related to FE/GE transmission faults are cleared. If the alarms persist, go to Step 2.

2.

Run the MML commands DSP ETHPORT and LST ETHPORT to check whether the settings of the port interworking parameters, especially ETHPORT SPEED and Duplex, 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 are cleared. If the alarms persist, go to Step 3.

3.

Check whether the two interconnected ports are normal by using either of the following fault isolation methods: (1) Connect a PC to the Ethernet port of the BSC or BTS and check whether the physical layer faults are rectified. (2) Connect a PC to the peer device and check whether the PC indicator that shows the Ethernet cable connection status is ON.

Issue 01 (2011–8–17)


202


11 IP Transmission Faults NOTE

If the alarms related to FE/GE transmission faults are cleared but the PC indicator is OFF, the peer port is faulty. If the alarms related to FE/GE transmission faults persist but the PC indicator is ON, errors may have occurred on the BSC or BTS. If errors occurred on the BSC, switch over the IP interface 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 port interworking parameter settings for the two interconnected ports are consistent. Correct any inconsistent settings and check whether the alarms related to FE/GE transmission faults are cleared.

4. l

If the alarms persist, Contact Huawei Customer Service Center.

Data link layer faults 1.

Run the MML command DSP ARP to check whether there is an ARP table corresponding to the next-hop IP address. If there is, the connection between the BSC and the peer device is normal. Check whether the connection between the peer device and 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 the number of data packets received and sent on the BSC port twice at a 3s interval, and record the query results. On the local maintenance terminal (LMT), ping the peer IP address and run the MML command DSP ARP to check whether there is an ARP table corresponding to the next-hop IP address. If there is no ARP table corresponding to the next-hop IP address, the faults occur because the corresponding ARP table fails to be generated. Run the MML commands DSP ETHVLAN and DSP ETHPORT again to query the number of data packets received and sent on the BSC. Compare this query result with the preceding query results to check whether the number of data packets received and sent on the BSC port increased. If it increased, go to Step 3. If not, go to Step 4.

3.

Have the peer device maintenance engineers check whether VLAN ID has been set on 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 transmission faults are cleared. If the alarms persist, go to Step 4. – If not, have the peer device maintenance engineers check whether the peer IP address is set correctly. If the setting is incorrect, change the peer IP address to ensure that the BSC can communicate with the peer device properly.

4.

If the data link layer faults persist, Contact Huawei Customer Service Center.

Typical Case Symptom Ongoing services become abnormal after A over IP reconstruction. Cause Analysis l

The data configurations may be incorrect.

l

The FE/GE transmission may fail.

Troubleshooting Procedure 1. Issue 01 (2011–8–17)

Query the data configurations. The data configurations are correct. Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

203



2.

View the alarm information and check the Ethernet cable. The alarm ALM-21345 Ethernet Link 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 the BSC side. The query result shows that Duplex is set to Half and Auto negotiation is set to Enable. Therefore, the working mode of the peer port may be configured in forcible mode.

4.

Query the status of the peer port. The result shows that Duplex is set to FULL and ETHPORT SPEED is set to 100M. After Duplex is set to the same value for the two interconnected ports, ongoing services return to normal.

11.2 Troubleshooting IP Layer Faults This section describes how to troubleshoot IP layer faults.

Symptom When the IP layer is faulty, the destination IP address cannot be pinged and the alarms in Table 11-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


IP route Each host or gateway has a routing table that specifies the routes to the destination IP address. When sending a packet, a host, gateway, or router can obtain a route to the destination 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 Procedure Figure 11-4 shows the procedure for locating IP layer faults.

Issue 01 (2011–8–17)


204



Figure 11-4 Procedure for locating IP layer faults


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. If there is no routing table corresponding to the destination IP address, manually configure a route to the destination IP address and check whether the alarms related to IP layer faults are cleared. If the alarms persist, go to Step 3.

3.

Run the MML command DSP ARP to check whether there is an ARP table corresponding to the destination IP address. If not, refer to Procedure for locating data link layer faults in section 11.1 Troubleshooting FE/GE Transmission Faults. Then check whether the 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 a route from the source IP address to the destination IP address and to determine at which hop the route is interrupted. Have the transmission maintenance engineers resolve the

Issue 01 (2011–8–17)


205



problem and check whether the alarms related to IP layer faults are cleared. If the alarms persist, go to Step 5. 5.

Capture relevant packets and Contact Huawei Customer Service Center.

Typical Case Symptom Transmission links fail to be set up after the A over IP and signaling data configurations are complete. Cause Analysis 1.

The BSC boards may be faulty.

2.



Query the data configurations and alarm information for the BSC boards. The data configurations are complete and correct, and no boards report hardware alarms.

2.

Have the MSC maintenance engineers check the port interworking parameters. The settings of these parameters are correct.

3.

Ping the IP address of the MSC on the BSC side. The IP address of the MSC cannot be pinged.

4.

Run the MML command TRC IPADDR to query the route information. A router is not forwarding packets.

5.

Determine that relevant routes are not configured on the router. After a route to the destination IP address is configured, transmission links can be set up successfully.

11.3 Troubleshooting PPP or MLPPP Link Faults This section describes how to troubleshoot Point-to-Point Protocol (PPP) or Multi-Link Pointto-Point Protocol (MLPPP) link faults.

Symptom l

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

l

Issue 01 (2011–8–17)

Alarm ID

Alarm Name

11342

ALM-11342 PPP Link Excessive Frame Error Rate

21343

ALM-21343 PPP/MLPPP Link Fault

21344

ALM-21344 MLPPP Group Failure

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. Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

206




PPP PPP is a link layer protocol that supports point-to-point data transmission on full-duplex synchronous 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 Abis interface in IP over E1 mode.

l

MLPPP MLPPP is an extensible protocol that supports binding multiple PPP links into a logical channel, which helps to increase bandwidth. These PPP links belong to an MP group and this logical channel is an MLPPP link. In the Huawei BSS system, the MP technology is used for transmission on the Abis interface in IP over E1 mode.

Location Procedure Figure 11-5 shows the procedure for locating PPP or MLPPP link faults. Figure 11-5 Procedure for locating PPP or MLPPP link faults


Issue 01 (2011–8–17)

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 GSM Alarm Reference. If none of the alarms are reported, go to Step 2. Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

207



Table 11-5 Alarms related to E1/T1 transmission faults

2.

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 Reception Abnormal

20203

ALM-20203 Clock Signal Outputs Faulty

20204

ALM-20204 Clock Signal Inputs Faulty

20205

ALM-20205 System Clock Reference Source Unavailable

20206

ALM-20206 Current System Clock Reference Source Status Abnormal

20207

ALM-20207 Failure in Locking System Clock Source

20208

ALM-20208 Clock Reference Source of Main Control Board Unavailable

20209

ALM-20209 Faulty Phase-Locked Loop of the Board Clock

Query data configurations for PPP or MLPPP links. l Run the MML command LST PPPLNK or LST BTSPPPLNK to query data configurations for PPP links. l Run the MML command LST MPLNK or LST BTSMPLNK to query data configurations for MLPPP links. l If the BTS communicates with the BSC using a router, run the MML command LST BTSPPPLNK or LST BTSMPLNK to query data configurations for PPP or MLPPP links. Then, query the related PPP or MLPPP parameters on the router, such as the PPP negotiation duration and check format. If the data configurations are incorrect, correct them and check whether the alarms related to 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 Monitor Navigation Tree pane, choose Monitor > Common Monitoring > Link Performance Monitoring and select the PPP link or MLPPP link whose traffic can be monitored in real time. Compare the traffic statistics measured at both ends of the PPP link or MLPPP link to check whether any packets are lost during transmission. If any packets are lost, check the 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.



208



The IP over E1 reconstruction based on the time division multiplexing (TDM) bearer network fails, 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. Troubleshooting Procedure 1.

Query the BTS data configurations. The port number of the PPP link is not the actual number of the physical port.

2.

Change the port number and restart the BTS. The BTS starts up successfully.

11.4 Troubleshooting LAPD Link Faults This section describes how to troubleshoot Link Access Protocol on the D channel (LAPD) link faults.

Symptom l

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 TRX software fails to be loaded. In addition, the alarms in Table 11-6 may be reported. Table 11-6 Alarms related to LAPD link faults

l

Alarm ID

Alarm Name

21511

ALM-21511 LAPD Link Congestion

21512

ALM-21512 LAPD Link Fault

When LAPD link faults occur, the query result of the MML command DSP LAPDLNK shows that UsageStatus is set to Faulty or Congested.

Background Information LAPD is used for transmission on the Abis interface. LAPD links are categorized into OML, RSL, ESL, and extended maintenance link (EML).


LAPD link or one-way disconnection Figure 11-6 shows the procedure for locating the source of LAPD link or one-way disconnection.

Issue 01 (2011–8–17)


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 link disconnection or congestion.

Issue 01 (2011–8–17)


210



Figure 11-7 Procedure for locating the source of intermittent LAPD link disconnection or congestion


Issue 01 (2011–8–17)

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 links are faulty, locate and rectify the faults by referring to 11.1 Troubleshooting FE/GE Transmission Faults or 11.3 Troubleshooting PPP or MLPPP Link Faults and check 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 Configuration Protocol (DHCP) process is complete. If the DHCP process failed, locate and rectify the faults by referring to 11.7 Troubleshooting DHCP Problems and check whether the alarms related to LAPD link faults are cleared. If the alarms persist, go to Step 3.

3.

Run the MML command LST BSCABISPRIMAP or LST BTSVLAN to check whether the VLAN ID settings for the uplink or downlink LAPD links and transmission 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 1473byte ping packets to ping the destination IP address. Then, set the differentiated services code point (DSCP) to the value the transport network planned for LAPD messages. If any packets are lost or the transmission delay is long, have the transmission engineers locate and rectify the faults, and check whether the alarms related to LAPD link faults are cleared. If the alarms persist, go to Step 5. Table 11-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 Counter s for the Abis over IP Transm ission QoS

One-Way Delay (ms)

One-Way Jitter (ms)

Packet Loss Rate (% or 10-x)

Scenari o

Recom mended Value

Maxim um Value

Recom mended Value

Maxim um Value

Recom mended Value

Maxim um Value

Terrestri al transmiss ion

< 15 ms

< 40 ms

< 8 ms

< 15 ms

< 0.05%

< 0.1%

Satellite transmiss ion

< 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 BTS ID alone to trace OML, EML, or RSL messages or enter both the BTS ID and TRX ID to trace RSL messages. Tracing these messages helps to check whether the transmission is normal and whether any packets are lost. If the transmission is abnormal or any packets are lost, have the transmission engineers locate and rectify the faults and check whether the alarms related to LAPD link faults are cleared. If the alarms persist, go to Step 6.

6.

Run the MML command DSP INTERWPFM to query the number of packets received, sent, and discarded as measured by the interworking module. NOTE

The interworking module measures the number of LAPD packets received and sent by the interface board.

Before this operation, you can run the MML command LST LAPDLNK to query data 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; Issue 01 (2011–8–17)


212



The query results are displayed as follows: +++ PTRM_B012 2011-02-27 10:47:12 O&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) NOTE

The text following // is a detailed explanation of the query results.

In normal cases, the packet receiving and sending process is integrated. If multiple query results show that the number of received and sent packets increases, the transmission is normal. If the number of discarded packets increases, the transmission is abnormal. In this case, Contact Huawei Customer Service Center. In the case of one-way LAPD link disconnection (packets can only be sent), if the query 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 the interface to check whether the problem is caused by faulty NEs or abnormal transmission. – 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 to local loopback mode and trace LAPD signaling messages. If a packet can be sent and received properly, the LAPD link between the XPU and the interface board is normal. – Perform an LAPD hardware loopback test on the intermediate transmission devices. Connect the TX end to the RX end using an E1/T1 cable and do not connect the E1/T1 cable to the BTS. Then, trace LAPD signaling messages to locate the faulty NE.

8. l

Issue 01 (2011–8–17)

If the problem persists, capture relevant packets and Contact Huawei Customer Service Center.

Intermittent LAPD link disconnection or congestion


213



1.

Query the measurement results of K3004:Traffic Volume on SDCCH and A3039J:SDCCH Seizures for Speech Service to check whether the problem is caused by a heavy traffic volume. If the traffic volume is heavy, add standalone dedicated control channels (SDCCHs) or expand the transmission capacity. If the traffic volume is 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 Customer Service 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 the transmission device connected to the LAPD link. If the VLAN priority is low or the DSCP settings are incorrect, some packets are lost during the transmission. Correct any 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 1473byte ping packets to ping the destination IP address. If any packets are lost, the transmission delay is long, or the jitter is large, have the transmission engineers locate and rectify the faults, and check whether the alarms related to LAPD link faults are cleared.

Issue 01 (2011–8–17)


214


11 IP Transmission Faults NOTE

The following methods can be used to check the transport network quality on the user plane of the Abis interface. The operation results can serve as reference for checking the transport network 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 command DSP IPPATH or query the traffic statistics to check whether any packets are lost, whether the 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 whose software 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 real time 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.


Typical Case Symptom An RSL disconnects intermittently. Cause Analysis l

The signaling traffic volume may be heavy.

l

Some packets may be lost during transmission.


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 and 48, but the uplink and downlink DSCP values for CS services on the user plane are 38 and 46. 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 priority settings are incorrect.

Issue 01 (2011–8–17)


215


5.


Increase the router bandwidth and correct the DSCP and queue priority settings. The problem is resolved.

11.5 Troubleshooting SCTP Link Faults This section describes how to troubleshoot Stream Control Transmission Protocol (SCTP) link faults.

Symptom l

There are two types of SCTP link faults: – SCTP link disconnection or one-way disconnection: The TX end sends packets to the RX end but does not receive any response packets from the RX end. – Unexpected SCTP link disconnection: The SCTP link is intermittently disconnected or congested.

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

l

Alarm ID

Alarm Name

21541

ALM-21541 SCTP Link Fault

21542

ALM-21542 SCTP Link Congestion

22915

EVT-22915 SCTP Link Destination IP Changeover

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.


SCTP The Stream Control Transmission Protocol (SCTP) is a transport layer protocol used for reliable transmission between the SCTP user application and a connectionless packet network (such as the IP network). In the Huawei BSS system, the SCTP technology is usually used for A over IP.

l

To troubleshoot SCTP link faults, trace SCTP messages on the A interface by referring to Tracing SCTP Messages on the A Interface. SCTP messages are categorized into INIT, INIT, ACK, DATA, SACK, ABORT, SHUTDOWN, ERROR, COOKIEECHO, and HEARTBEAT.

l

Figure 11-8 shows the message interaction process during an SCTP link setup. The first four messages are handshake messages, the last four messages are heartbeat messages, and the rest are data interaction messages.

Issue 01 (2011–8–17)


216



Figure 11-8 Message interaction process during an SCTP link setup


SCTP link or one-way disconnection Figure 11-9 shows the procedure for locating the source of SCTP link or one-way disconnection.

Issue 01 (2011–8–17)


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 link disconnection.

Issue 01 (2011–8–17)


218



Figure 11-10 Procedure for locating the source of unexpected SCTP link disconnection


Issue 01 (2011–8–17)

SCTP link disconnection or one-way disconnection 1.

Run the MML command PING IP to ping the peer IP address. If the peer IP address cannot be pinged, check the router and transport network. If the peer IP address can be pinged, go to Step 2.

2.

Check whether the transmission devices require all packets sent by the BSC to carry VLAN IDs. If the packets carry VLAN IDs, run the MML commands LST VLANID and LST SCTPLNK to check whether the VLAN IDs are correct. If the VLAN 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 SCTP interworking parameters, especially the IP address, port number, and maximum transmission unit (MTU), for the BSC and the MSCare consistent. In addition, ensure that the MTU value on the transport network is greater than the MTU values on the BSC and MSC sides. If the settings of the SCTP interworking parameters are inconsistent, correct them. If the settings of the SCTP interworking parameters are consistent, go to Step 4.

4.

Check whether the SCTP link is configured with upper-layer applications, such as M3UA configuration data. If not, configure upper-layer applications. If the configurations are incorrect, correct them. If the SCTP link is configured with correct upper-layer applications, go to Step 5.

5.

On the LMT, trace SCTP messages on the A interface by referring to Tracing SCTP Messages on the A Interface. Set SCTP Link No to the number of the congested SCTP Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

219



link and enable the SCTP link tracing function. Compare the traced messages with normal interaction messages to check whether any packets are lost during transmission. If any packets are lost during transmission, have the transmission engineers locate and rectify the faults. If no packets are lost during transmission, go to Step 6.

l

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 packet from the MSC, capture packets on the MSC side to check whether the COOKIEECHO packet was sent. To capture packets, use the Ethereal (Wireshark) software or connect a PC to the mirrored port on the switch installed between the output port and the transport network. If the COOKIEECHO packet was sent, it may have been lost on the transport network or BSC interface board. In this case, have the transmission engineers locate and rectify the faults. If no COOKIEECHO packet was sent, errors may have occurred on the MSC side. In this case, have the MSC vendor for technical support. If the transmission is normal and the MSC operates properly, go to Step 7.

7.


Unexpected SCTP link disconnection 1.

Check whether related transmission alarms, such as the FE or E1 fault alarms, are reported when the problem occurs. If the alarms are reported, optimize the transport network. 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 SCTP Messages on the A Interface. Compare the traced messages with normal interaction messages to check whether any packets are lost during transmission. Analyze the received and sent packets to identify the possible causes. For example, the problem may occur because heartbeat messages cannot be received or one end sends the Abort message. If the transmission is abnormal, have the transmission engineers locate and rectify 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 during transmission, check whether the FE port attributes for the two ends are consistent by referring to 11.1 Troubleshooting FE/GE Transmission Faults. If the FE port attributes are consistent, run the MML command PING IP to calculate the packet loss rate on the transport network and have the transmission engineers locate and rectify the 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 be pinged, run the MML command MOD SCTPLNK to initiate link negotiation again. If the link negotiation fails, go to Step 5.

5.


Typical Case Symptom The SCTP link fails to be set up after the A over IP reconstruction and signaling data configurations are complete. Cause Analysis l

The BSC boards may be faulty.

l


Issue 01 (2011–8–17)


220




Query the data configurations and alarm information for the BSC boards. The data configurations are complete and correct, and no boards report hardware alarms.

2.

Have the MSC maintenance engineers query the settings of the SCTP interworking parameters. 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 MSC side. The SCTP link can be set up successfully.

11.6 Troubleshooting IP Path Problems This section describes how to troubleshoot IP path problems.

Symptom l

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

l

Alarm ID

Alarm Name

21581

ALM-21581 Path Fault

21582

ALM-21582 Path Congestion

21352

ALM-21352 IP Path Excessive Packet Loss Rate

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 has occurred.

Background Information An IP path is a logical link carried on the physical link on an IP transport network. Each IP path is allocated virtual bandwidth. An IP path is used to perform admission control. During network access, the system performs admission control based on the service type and bandwidth used by the IP path. An IP path manages only the transmission resources occupied by subscriber services.

Location Procedure Figure 11-11 shows the procedure for locating IP path problems.

Issue 01 (2011–8–17)


221



Figure 11-11 Procedure for locating IP path problems


Check whether the IP path configurations are correct. l Run the MML command LST IPPATH to check whether Local IP address and Peer IP address are set correctly. l Run the MML command DSP IPPATH to check whether the IP path status is normal and the bandwidth is configured correctly. If Operation state is set to Unavailable or the 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 route devices and core network configurations. l Run the MML commands LST IPRT and DSP IPRT to query the routing tables for the interface boards and check whether there is a route to the peer IP address of the IP path. 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 when configuring an IP path or running the MML command ADD VLANID. You are advised to run the MML command ADD VLANID to configure a VLAN ID

Issue 01 (2011–8–17)


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 the CS voice, CS data, high-priority PS, low-priority PS, signaling, or other data packets are configured correctly. l Run the MML command PING IP on the LMT to ping the gateway address and peer IP address of the IP path, respectively. If the peer IP address of the IP path cannot be pinged, run the MML command TRC IPADDR with Destination IP address set to the 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 Case Symptom After data is configured for A over IP reconstruction, the signaling becomes normal, but calls fail 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.


Query data configurations and alarm information about the BSC boards. Data configurations 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 IP path 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 Problems This section describes how to troubleshoot Dynamic Host Configuration Protocol (DHCP) problems.

Symptom When a DHCP interaction failure occurs, the BTS software fails to be loaded for an excessive long period of time


Issue 01 (2011–8–17)

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 BSC responds 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 management link (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 followup procedures. Figure 11-12 shows a typical DHCP interaction procedure. Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

223



Figure 11-12 Typical DHCP interaction procedure

Location Procedure Figure 11-13 shows the procedure for locating DHCP problems. Figure 11-13 Procedure for locating DHCP problems


Issue 01 (2011–8–17)

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.1 Troubleshooting FE/GE Transmission Faults. If the E1/T1 transmission is used at the Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

224



physical layer, check whether the alarms in Table 11-10 are reported. If the alarms are reported, clear them by referring to the BSC6900 GSM Alarm Reference. If the alarms are not reported, go to Step 2. Table 11-10 Alarms related to E1/T1 transmission faults

2.

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 Reception Abnormal

20203

ALM-20203 Clock Signal Outputs Faulty

20204

ALM-20204 Clock Signal Inputs Faulty

20205

ALM-20205 System Clock Reference Source Unavailable

20206

ALM-20206 Current System Clock Reference Source Status Abnormal

20207

ALM-20207 Failure in Locking System Clock Source

20208

ALM-20208 Clock Reference Source of Main Control Board Unavailable

20209

ALM-20209 Faulty Phase-Locked Loop of the Board Clock

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 the BTS gateway must be configured. l Run the MML command LST BTSVLAN to check whether VLAN IDs are correctly configured for the packets of different service types. If packets whose service type is Other Data are not configured with VLAN IDs, IP addresses cannot be pinged. When this occurs, the ARP table of the peer device may fail to be updated, and the BTS may fail to trace a clock. l If the BTS is configured with a VLAN ID, enable the VLAN detection function for the BSC during remote commissioning. To enable the BTS detection function, run the MML command SET BTSOTHPARA to set BTS Detect Switch to OPEN(OPEN). When the BTS detection function is enabled, the BSC performs addressing based on the BTS IP address and sends the BTS a UDP packet containing the VLAN ID information. After BTS remote commissioning is successful, run the MML command SET BTSOTHPARA to set BTS Detect Switch to CLOSE(CLOSE) to disable the BTS detection function. If data

Issue 01 (2011–8–17)


225



configurations are incorrect, correct the data configurations. Then, check whether the alarms 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 transmission device has been commissioned successfully, the DHCP problem may lie in data configurations. l Check whether the data configurations for packet transport network (PTN) devices and Layer 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 the port. – Check whether VLAN configurations for Layer 2 switches are the same as those for the BTS. If the data configurations are incorrect, correct them and check whether the alarms are cleared. If the alarms persist, go to Step 4.

4.

Perform the following operations to check whether the BSC collects statistics on the DHCP packets reported by an unknown electronic serial number (ESN): Run the MML command CLR BTSESN. Then, wait for five minutes and run the MML command DSP BTSESN to query BTS ESNs. If any BTS ESNs are queried, the DHCP problem may result from incorrect ESN configurations. In this situation, modify the incorrect ESN and check whether 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 the BSC or BTS mirrored port. If the BSC or BTS has sent a DHCP packet but the packet fails to be captured at the peer end, contact transmission engineers to identify the reason why the packets are discarded. Then, check whether the DHCP problem is resolved. If the DHCP problem persists, go to Step 6.

6.

Check whether the BTS sends any DHCP packets or the BSC responds to the BTS after receiving any DHCP request packets. Record the fault symptom and save the location information. Then, go to Step 7.

7.

If the DHCP problem persists, Contact Huawei Customer Service Center.

Typical Case Symptom When a test is performed in Abis over IP, two newly deployed BTSs, BTS B with VLAN 101 and 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 B configured with VLAN 100 operates properly. The gateway addresses of BTS B and BTS C cannot 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.

Troubleshooting Procedure Issue 01 (2011–8–17)


226



1.

Check whether BTS ESN configurations are correct. If the check result is correct and BTS B configured with VLAN 100 operates properly after the data configurations for BTS A and BTS B interchange, the BTS ESN configurations are correct.

2.

Check whether the Layer 3 switch is configured with the DHCP relay function. The check result 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 signaling plane on the BSC. The check result shows that VLAN configurations for the three BTSs are the same except the VLAN IDs and the Layer 3 switch uses the same mechanism to process VLAN IDs 100, 101, and 102. After the BTS VLAN self-learning switch is turned on, the DHCP problem persists.

4.

Check the BSC route configurations. The check result shows that the route configurations for BTS A are different from those for BTSs B and C. BTS A is configured with a network segment route and a BTS route. However, both BTS B and BTS C are configured with a BTS route. After BTSs B and C are configured with network segment routes, the two BTSs can 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 relay agent (BTS gateway) and the DHCP server (BSC). Use the unicast DHCP Discover packet as an example. The source IP address of the DHCP Discover packet is the IP address of the DHCP relay agent and the destination IP address of the DHCP Discover packet is the IP address of the DHCP server. After receiving a DHCP Discover packet, the DHCP server needs to send a DHCP Offer packet to the DHCP relay agent. In this situation, the DHCP server must be configured with a network segment route or with two routes: one route to the BTS and one route to the DHCP relay agent.

11.8 Troubleshooting IP PM Activation Failures This 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. During packet capturing, the BTS or BSC does not receive any IPPM ACT ACK frames after sending IPPM ACT frames.


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 end of the number of sent packets. Then, the Rx end responds with BR frames and notifies the Tx 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 the bandwidth change when BR frames are sent from the Rx end to the Tx end. The interval for sending FM frames or the number of FM frames sent by the Tx end each time can be specified.

Location Procedure Figure 11-14 shows the procedure for locating IP PM activation failures.

Issue 01 (2011–8–17)


227



Figure 11-14 Procedure for locating IP PM activation failures


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 the problem persists, go to Step 2.

2.

Compare the packets captured on the BSC and BTS to check whether the DSCP values in the IP PM activation response packets from the BTS are consistent with those in the IP PM activation request packets from the BSC. During packet transmission, the intermediate transmission device may modify the DSCP values in the packets based on the data configurations for the intermediate transmission device. If the DSCP values are inconsistent, contact maintenance engineers who manage the intermediate transmission device to modify the data configurations. Then, check whether the problem is resolved. If the problem persists, go to Step 3.

3.

Check whether the BSC sends FM frames and receives BR frames by capturing packets on the BSC mirrored port, and check whether the BTS sends BR frames and receives FM frames 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 is resolved. If the problem persists, go to Step 4.

4.


Typical Case Symptom The IP PM function on the Abis interface fails to be activated. Cause Analysis Issue 01 (2011–8–17)


228



l

The DSCP values in packets may be modified by the transmission device.

l

Packets may be discarded on the transport network.


Check whether packets are discarded on the transport network. The result shows that no packets are discarded on the transport network.

2.

Analyze the captured packets. The DSCP values in the IP PM activation response packets from the BTS are inconsistent with those in the IP PM activation request packets from the BSC. During packet transmission, the intermediate transmission device changes the DSCP values in packets.

3.

Modify data configurations for the intermediate transmission device to ensure that DSCP values in packets cannot be changed.

4.

Run the MML command ACT IPPM on the LMT to activate IP PM.

11.9 Troubleshooting IP Clock Faults This 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 preceding faults 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 Reference Problem

26263

ALM-26263 IP Clock Link Failure


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 IEEE 1588v2 protocol. l After the BTS3900 or BTS3012 is upgraded to V900R011C00 in Abis over IP, the IP clock server version 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 voltage output to adjust the oscillator for generating an output signal based on the DA value. The

Issue 01 (2011–8–17)


229



DA value is derived from the frequency offset between the clock source and the current clock.


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.

Issue 01 (2011–8–17)


230



Figure 11-16 Procedure for locating IP clock lock failures


IP Clock Link Setup Failures 1.

Check whether the BTS IP address can be pinged on the IP clock server LMT. If the BTS IP address cannot be pinged, rectify the fault by referring to 11.1 Troubleshooting FE/GE Transmission Faults and 11.2 Troubleshooting IP Layer Faults. Then, check whether the problem is resolved. If the problem persists, go to Step 2.

2.

Run the MML command DSP LICUSAGE to check whether the IP clock license is available. If the IP clock license is not available, apply for a license file. Then, check whether 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 configured correctly (for example, the 1588v2 precision time protocol (PTP)). Also, check whether the IP address of the clock source is configured correctly and whether the Domain values of the two ends are the same. To query the Domain value, run the MML command DSP PTPPARA on the Huawei IP clock server LMT. – In Layer 3 networking mode, run the MML command LST BTSIPRT on the BSC LMT 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 the routes to the IP clock servers are configured. – Check whether the VLAN configurations for the uplink and downlink are consistent with those on the transport network.

Issue 01 (2011–8–17)


231



– Run the MML command LST SRVVLANPARA on the IP clock server LMT to query the VLAN configurations for the downlink. – Run the MML command LST BTSVLAN on the BSC LMT to query the VLAN configurations for the uplink. If the VLAN configurations for the uplink and downlink are inconsistent with those on the transport network, correct the VLAN configurations. Then, check whether the 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 to check 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 is resolved. 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 to check whether the current client mode, Ethernet port type, and number of BTSs meet the requirements. (2) In Layer 3 networking mode, run the MML command LST IPRT on the IP clock server 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 of the 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 clock and the BTS. Figure 11-17 shows the procedure for clock packet interaction between the IP clock and BTS.

Issue 01 (2011–8–17)


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 and BTS clock. This means that the first four steps shown in the preceding figure are performed. The activation status refers to the status of sending or receiving clock synchronization packets. If clock synchronization packets are sent or received successfully, the link activation succeeds. This indicates that interactions in Steps 5 through 7 shown in Figure 11-17 are performed successfully. If no clock synchronization packets are sent or received, the link activation has failed. – If Link State is DOWN, trace IP clock messages and capture packets on the BTS mirrored port. NOTE

To trace IP clock messages, perform the following operations: 1. Log in to the IP clock server LMT, select Trace Management in the maintenance window, and double-click IPCLK_TRACE. 2. In the displayed window, type the BTS IP address in ClientIP. Type 319 or 320 in CLIENT PORT to trace packets on any port for five minutes. Port 320 is used to trace link setup packets and port 319 is used to trace clock packets. 3. Check whether signaling can be traced on the ports and whether any interaction operations fail to be performed in any step. If any packets fail to be sent, an NE may be faulty. In this situation, Contact Huawei 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.

– If Link State is UP and Activate State is Not Activated, start message tracing by using the method shown in Note and check whether Step 5, 6, or 7 shown in Figure 11-17 fails to be performed. – If any packets fail to be sent, certain NEs may be faulty. In this situation, Contact Huawei 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.

Issue 01 (2011–8–17)


233



CAUTION Check whether packets are lost on the transmission device close to the BTS or the transmission 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 the transmission 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. If the BTS has sent request packets, certain request packets may be discarded by the transport network. If there is no Hub or switch between the BTS and the transmission device, use the Huawei proprietary protocol as the BTS IP clock protocol. Then, check whether clock packets can be captured on the transmission device that is closest to the BTS. If any clock packets can be captured, the transmission device may have discarded some clock packets. After the preceding operations are performed, the faulty NE can be located. If the transmission device does not discard any packets, go to Step 7. 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. If the BTS fails to lock the IP clock because of an incorrect DA value and the ALM-26262 External Clock Reference Problem is reported, run the MML command SET BTSCLKPARA on the BSC LMT to change the DA value or turn off the trace range 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. Restart the IP clock server after setting this parameter. (2) View the messages traced on the IP clock server to check whether clock synchronization packets are sent successfully. For details, see the description of IP Clock Link Setup Failures. (3) Run the MML command DSP IPCLKLNK on the IP clock server LMT. View the number of clock synchronization packets sent on the link specified in the MML command and check whether clock synchronization packets are sent successfully. (4) Capture packets on the transmission device close to the IP clock to check whether clock synchronization packets are sent successfully. If clock synchronization packets fail to be sent, modify the data configurations or Contact Huawei Customer Service Center to resolve the IP clock problem. Then, check whether the problem is resolved. If the problem persists, go to Step 3. Issue 01 (2011–8–17)


234



3.

Check whether the quality of service (QoS) indicator of the transport network is normal and whether the jitter is too large. If the jitter is too large, improve the transport network quality. Then, check whether the problem is resolved. If the problem is not resolved, go to Step 4.

4.


Typical Case Symptom An IP clock link fails to be set up, but the IP address for the communication between the IP clock and 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.


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 the Announce request messages fail to be received on the IP clock server. The possible cause may be that the transmission device discards packets.

3.

Locate the faults in NEs. The location result shows that a switch imposes limitations on the 1588v2 clock packets, which results in packet losses. After the limitations are removed, the BTS locks the IP clock successfully.

Issue 01 (2011–8–17)


235


12 Interference Problems

12

Interference Problems

About This Chapter This chapter describes how to locate and troubleshoot interference problems. 12.1 Interference Interference affects many aspects of network performance, such as voice quality, network coverage 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 Problems This section describes how to locate interference problems. 12.3 Troubleshooting Co-channel or Adjacent-Channel Interference This section describes how to troubleshoot co-channel or adjacent-channel interference. 12.4 Troubleshooting Intermodulation Interference This section describes how to troubleshoot intermodulation interference. 12.5 Troubleshooting Interference from the CDMA Network This section describes how to troubleshoot interference from the CDMA network. 12.6 Troubleshooting External Interference This section describes how to troubleshoot external interference.

Issue 01 (2011–8–17)


236



12.1 Interference Interference affects many aspects of network performance, such as voice quality, network coverage 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 enables cells that are far enough away from each other to use the same frequency. The distance between the cells is the reuse distance, and the ratio of the reuse distance to the cell radius is the reuse factor. 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-system interference, and external interference. Interference caused by frequency reuse is internal interference. Other types of internal interference include intermodulation, spurious, and blocking interference. 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 nonlinear 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 strong interference 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 frequency band 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 the noise 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 to unclear voice signals for the called MS.

l

Both originated- and terminated-calls fail to be set up. A call easily drops after the prompt tone starts.

Strong network interference has the following impacts on traffic statistics: l

Uplink interference is detected by using interference band traffic statistics along with the interference band thresholds and usage scenarios. For example, if interference band 2 is recorded in traffic statistics for boundary networks with loose frequency reuse, interference may occur. If interference band 4 or 5 is recorded in traffic statistics for urban areas with tight frequency reuse, strong interference may occur.

l

The values of RA303G:Success Rate of Immediate Assignments and RCA313:Assignment Success Rate are small.

l

The values of ZTR104C:Call Drop Rate on SDCCH and ZTR304:Call Drop Rate on TCH per cell(including Handover) are large.

l

The value of RH303:Handover Success Rate is small.

Issue 01 (2011–8–17)


237


l


The measurement results of TCHF Receive Level Measurement and TCHH Receive Level Measurement 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 Problems This section describes how to locate interference problems.

Principles for Locating Interference Problems The following are common types of uplink interference on the GSM network: l

Passive intermodulation interference

l

Co-channel interference or adjacent-channel interference

l

Interference from repeaters

l

Interference from the CDMA network

l

External interference

Use the interference characteristics to determine the interference type.


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 specified area to cause the strongest interference to a network. A dummy burst test can take between 1 and 24 hours. The test can be configured to stop automatically or stopped manually on the LMT. For details about how to perform a dummy burst test, see 3.3.2 Detecting Intermodulation Interference by Testing Idle Timeslots.

Procedure for Locating Interference Problems Figure 12-1 shows the procedure for locating interference problems.

Issue 01 (2011–8–17)


238



Figure 12-1 Procedure for locating interference problems

12.3 Troubleshooting Co-channel or Adjacent-Channel Interference This section describes how to troubleshoot co-channel or adjacent-channel interference.

Symptom As with intermodulation interference, co-channel interference or adjacent-channel interference during peak hours greatly differs from that during off-peak hours. However, co-channel or adjacent-channel interference does not affect the downlink power of interfered cells because these types of interference are caused by MSs in other cells. Cells with co-channel or adjacent-channel interference are not affected by dummy burst tests performed in the early morning. You can determine which cells are affected by these types of interference according to the interference band traffic statistics at different measurement points.

Issue 01 (2011–8–17)


239



Background Information Frequencies 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 reflection may 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 is interference on the networks.

Location Procedure Figure 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


Check whether co-channel or adjacent-channel interference occurs in a cell. Import the engineering parameters of both serving cell and neighboring cells into a frequency analysis tool, and use the frequency check function to check whether some neighboring cells share the same or adjacent ARFCN that causes the strongest interference with 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.



240



Dialing tests are conducted by locking the ARFCNs of some cells. The test results show that voice quality is acceptable for calls that use the traffic channel (TCH) on broadcast control channel (BCCH) TRXs of the cells but is poor for calls that use the TCHs on non-BCCH TRXs of the cells. Cause Analysis Adjacent-channel interference occurs between the BCCH TRXs and the non-BCCH TRXs. To resolve this problem, replan the ARFCNs. Troubleshooting Procedure 1.

Check Interference Band Measurement per TRX(MR.Iterf.TRX) of these cells. The interference band decreases during off-peak hours whereas the interference band increases during 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 that the interference band does not increase noticeably, indicating that the adjacent-channel interference in these cells is the major source of interference.

3.

Check the frequency plan. The cells in urban areas use 1x3 frequency reuse mode and frequency hopping (FH). The ARFCN for the BCCH TRXs of the cells with blocked ARFCNs 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 for the non-BCCH TRXs.

4.

Make calls to occupy TCHs on the BCCH TRXs. ARFCN 110 configured for the nonBCCH TRXs causes little adjacent-channel interference and has little impact on voice quality.

5.

Make calls to occupy TCHs on the non-BCCH TRXs. The BCCH TRXs continuously transmit signals and therefore the decreasing strength of uplink and downlink signals due to power control causes strong adjacent-channel interference and greatly impacts voice quality.

6.

Change the hopping sequence for these cells. Voice quality on the non-BCCH TRXs improves.

12.4 Troubleshooting Intermodulation Interference This section describes how to troubleshoot intermodulation interference.

Symptom Passive intermodulation interference is broadband interference caused by the downlink signals in the BTS antenna system. This type of interference is closely related to BTS downlink transmit power and cell traffic. According to the traffic statistics on interference bands, the passive intermodulation interference is stronger during peak hours than during off-peak hours. However, passive intermodulation interference cannot be determined simply by the difference in strength between peak and offpeak hours. Co-channel or adjacent-channel interference or interference from the CDMA network 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. Issue 01 (2011–8–17)


241



If the percentage of interference bands 4 and 5 increases by 10% or above, passive intermodulation interference is the interference type.

Background Information When two radio frequency (RF) signals are received by a non-linear device or discontinuous transmission medium, new absolute radio frequency channel numbers (ARFCNs) are generated. The formula for determining the relationship between input signals and intermodulation products based on the typical non-linear model is as follows:

x indicates the input signals and f(x) indicates the final products. When two monophonic signals are used as input signals, new ARFCNs are also generated. Signals from the new ARFCNs are considered intermodulation products. Based on the trigonometric sum-to-product formulas, the intermodulation results of the nonlinear products (X1^2) x X2 and X1 x (X2^2) are as follows: The third-order intermodulation products 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 intermodulation results at other levels are calculated the same way. Generally, the higher the intermodulation level, the lower the frequencies of the intermodulation products. The antenna is a passive device used to transmit RF signals. The possible causes of intermodulation 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 Procedure Figure 12-3 shows the procedure for locating intermodulation interference.

Issue 01 (2011–8–17)


242



Figure 12-3 Procedure for locating intermodulation interference

Issue 01 (2011–8–17)


243




Check whether any BTS connectors are loose. Check all the BTS connectors, including the connectors of cables between the combiner and 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 3012 series base stations, the DFCU and DDPU implement signal combining. For 3006C series base stations, the DDPM implements signal combining. For 3900 series base stations, the signal 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.

4.


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.

6.


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.

8.


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.

10. Check whether the intermodulation interference is eliminated. l If yes, no further action is required. l If no, 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 scanning speed is less than 0.1s, connect the spectrum analyzer to the uplink output connector of the Issue 01 (2011–8–17)


244



combiner. Then, gently shake the antenna jumper for about 30 seconds. Ensure that the distance between the connector and the shaking point is 20 to 40 cm, the amplitude is 3 to 5 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 the feeder 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 downlink jumpers, and reassemble the feeder connector. Then, go to Step 12. 12. Check whether the intermodulation interference is eliminated. l If yes, no further action is required. l If no, go to Step 13. 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 900 MHz frequency band is persistently affected by interference band 5. Traffic statistics collected for a few weeks also indicate that interference band 5 persists. In addition, cells under another BTS 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. Troubleshooting Procedure 1.

Replan frequencies in the problem cell and observe the traffic statistics on frequency scanning. The interference persists after the frequency replanning, and all three ARFCNs of the cell are changed. Therefore, there is a low probability that frequency replanning caused the interference. In addition, the main and diversity signal levels of ARFCNs on all the frequency bands exceed -80 dBm, which indicates that the interference is not caused by improper frequency planning.

2.

Conduct tests on site. The voltage standing wave ratio (VSWR) and the TRX power are normal, but the interference persists after the TRXs and DDPUs of the problem cell and a normal cell are switched. This indicates that the interference is not caused by hardware faults.

3.

Conduct drive tests in the surrounding areas of the BTS. The voice quality is poor (level 7) when a call is set up only in the problem cell. The voice quality is good when a call is set up in other cells. This indicates that the interference is not caused by external interference.

Issue 01 (2011–8–17)


245



4.

Check the antenna system on the rooftop. The horizontal spacing between antennas of the 900 MHz and 1800 MHz cells exceeds 5 m, indicating that the interference is not caused by antenna spacing. The type of antennas for one 900 MHz cell is different from the other cells and this type of antenna looks older than others. Therefore, antennas of this type might be faulty. After the antennas of the problem cell and a normal cell are switched, the interference disappears from the problem cell but occurs in the normal cell. This indicates that the interference is caused by faulty antennas.

5.

Replace the faulty antennas. The interference is eliminated.

12.5 Troubleshooting Interference from the CDMA Network This section describes how to troubleshoot interference from the CDMA network.

Symptom Interference from the CDMA network is generated when the CDMA downlink signals block the GSM 900 MHz uplink frequency bands or reach the GSM receivers at GSM uplink receive frequency bands (885 MHz to 925 MHz). There is only a slight difference in the level of interference from the CDMA network between peak hours and off-peak hours. CDMA downlink signals are transmitted at the frequency band of 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 example of the CDMA interference spectrum scanned using the uplink frequency scanning function. Figure 12-4 CDMA interference spectrum

Background Information CDMA 800 MHz frequency bands and GSM 900 MHz frequency bands use adjacent frequencies. If the CDMA network is not sufficiently isolated from GSM BTSs, interference Issue 01 (2011–8–17)


246



may be generated. In particular, the CDMA downlink signals are likely to affect GSM 900 MHz uplink frequency bands, increasing the receive noise floor. The closer the CDMA downlink signals are to GSM frequency bands, the lower the anti-interference capability of the GSM network. The smaller the ARFCNs configured for TRXs, the stronger the interference. The types of CDMA network interference are as follows: l

Blocking interference Blocking interference, also known as intermodulation interference, is generated when strong CDMA downlink signals are received by the GSM receivers. This type of interference is determined by detecting uplink receive signals using a spectrum analyzer. Generally, if the level of the detected CDMA downlink signals exceeds -20 dBm, GSM uplink receive quality is affected.

l

Tailing interference Tailing interference, also known as spurious interference, is a type of co-channel interference generated when CDMA transmit signals are received on GSM uplink frequency 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 noise floor of the TRXs configured with larger ARFCNs is lower, tailing interference or spurious interference is generated.

To prevent the signals generated on CDMA 800 MHz frequency bands from affecting GSM 900 MHz frequency bands, use one of the following methods: l

Add frequency guard bands. This optimizes the spurious emission performance of power amplifiers, and the blocking and intermodulation performance of receivers. This is the optimal method for eliminating interference 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 polar diagram. During installation, the antenna isolation must exceed 50 dB. The formulas for calculating the 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 indicate the 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 the connection direction, and λ indicates the carrier wavelength. According to the two formulas, the vertical antenna isolation is generally larger than the horizontal antenna isolation. Therefore, place the transmit antenna 2 m away from the receive antenna vertically when CDMA and GSM are co-sited. The relative gains of the transmit antenna and receive antenna should be as small as possible when CDMA and GSM are not co-sited or the antennas are installed at the same height. To ensure small relative gains for the transmit and receive antennas, the main lobes of the two antennas must be parallel or the back lobes of one antenna must face the other antenna with a horizontal spacing of 6 m or more.

l

Install filters. This helps to eliminate spurious interference from the CDMA network, or blocking and intermodulation interference from the GSM network, but requires additional installation costs.

Issue 01 (2011–8–17)


247



Location Procedure Figure 12-5 shows the procedure for locating interference from the CDMA network. Figure 12-5 Procedure for locating interference from the CDMA network


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.



248



Voice quality deteriorates in several cells under a GSM BTS in a city. According to the traffic statistics analysis, the high quality indicator (HQI) decreases, the percentage of interference bands 3 to 5 increases, the radio access success rate decreases, and the call drop rate increases in 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 smaller the ARFCNs configured for TRXs, the stronger the interference. The frequencies of the CDMA transmit signals range from 870 MHz to 880 MHz and a CDMA antenna is installed 5 m away from the GSM antenna. Therefore, you determine that the interference in the problem cells is from the CDMA network. Troubleshooting Procedure Install a CDMA network filter on the GSM BTS and perform a dialing test. The dialing test results show that the voice quality is good, the uplink HQI increases to about 95%, the percentage of interference bands 3 to 5 decreases noticeably, and the related KPIs return to normal.

12.6 Troubleshooting External Interference This section describes how to troubleshoot external interference.

Symptom External interference is generated irregularly and its sources are difficult to identify. To locate the sources of external interference, analyze long-term traffic statistics on interference bands to find out at what time external interference occurs, and scan frequencies when external interference is most likely to be generated.


Interference from repeaters Repeaters are used to extend the BTS coverage during the early phase of network deployment. However, a repeater may cause interference to BTSs in the following situations: – The donor antenna and the service antenna are not sufficiently isolated because the repeaters are not installed properly. This causes self oscillation and affects the BTS. – The intermodulation signal level of repeaters using non-linear wideband amplifiers is much greater than the standard level. Repeaters working at high power are likely to cause strong intermodulation interference to neighboring BTSs. – Cascaded repeaters amplify the same frequencies of the transmitted signals, which causes 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 metropolitan areas.

l

Interference from radar stations The decimeter wave radar of the 1970s or 1980s uses frequencies that are the same as or adjacent to GSM frequencies. The decimeter wave radar transmits at between tens to

Issue 01 (2011–8–17)


249



hundreds of kilowatt power, causing a great volume of out-band spurious emissions as well as interference to neighboring BTSs. l

Interference from cordless telephone sets operating at 900 MHz In certain areas, the bandwidth for analog 900 MHz cordless telephones is 30 kHz and the bandwidth for digital 900 MHz cordless telephones is 2 MHz. These telephones transmit signals between 902 MHz to 920 MHz in frequency hopping (FH) mode. Therefore, if an outdoor antenna provides high power for these telephones, it may cause interference to neighboring BTSs.

l

Interference from other radio devices or interference generators on the same frequencies Certain types of radio devices use GSM frequency resources, which may cause interference to neighboring BTSs.

Location Procedure Figure 12-6 shows the procedure for locating external interference. Figure 12-6 Procedure for locating external interference


Check whether there are external interference sources. Identify the external interference sources by analyzing 24-hour or even 7-day traffic statistics on uplink interference bands for all the cells. Signals from one interference source may affect multiple cells. Therefore, traffic statistics on interference bands for neighboring cells are also required. If the interference affects multiple cells and/or is eliminated from multiple cells at the same time, these cells are probably affected by the same interference source. Knowing this helps locate the interference source. (1) To locate the interference source onsite, perform the following operations: 1. Place a Yagi antenna and a scanner on a rooftop in a problem cell when the interference is the strongest. Connect the Yagi antenna to the scanner with the frequency range set to 870 MHz to 915 MHz. 2. Use the Yagi antenna to scan for interference in different directions and monitor the frequencies of interference signals displayed on the scanner. 3. Use a compass to locate the source of the strongest interference and keep a record of the direction. Then, change the Yagi antenna direction to within 30 degrees

Issue 01 (2011–8–17)


250



of the line indicating the direction of the strongest interference source and observe the interference amplitude for 2 to 5 minutes. Then, repeat steps 1 through 3 in other problem cells and use the Yagi antenna to triangulate the location of the source of the strongest interference. (2) To locate the interference source in the surrounding areas of a problem site, you can carry 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, to narrow down the search range. You need to determine whether there are schools, government offices, or public security agencies in the search area because they may use interference devices. Then, repeat the preceding operations in all other areas where interference 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 Case Symptom 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. Troubleshooting Procedure 1.

Change the absolute radio frequency channel numbers (ARFCNs) and FH groups for the cell. The problem persists. Therefore, this problem is not caused by co-channel or adjacentchannel interference.

2.

Switch the feeders for cell 1 (a severely interfered cell) and cell 2 (a normal cell) to the jumper connectors of the DDPU. All the channels in cell 1 can process services properly but the interference band in cell 2 changes to band 3. Therefore, the antenna connections are 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 cell 1 return to normal but all the channels in cell 2 are affected by interference band 3. In addition, the antenna was only recently installed. Therefore, this problem may be caused by external interference.

4.

A television antenna is installed on the tower where the antenna for cell 1 is located and the 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.

Issue 01 (2011–8–17)


251


13

13 Faults on Main and Diversity RX Channels

Faults on Main and Diversity RX Channels

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 Reception When main and diversity RX channels are faulty, related alarms are reported. 13.2 Locating Faults on Main and Diversity RX Channels This 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 Data Configurations This section describes how to troubleshoot faults on main and diversity RX channels due to incorrect data configurations. 13.4 Troubleshooting Faults on Main and Diversity RX Channels Due to Incorrect Antenna Connections This section describes how to troubleshoot faults on main and diversity RX channels due to incorrect antenna connections. 13.5 Troubleshooting Faults on Main and Diversity RX Channels Due to Hardware Faults This section describes how to troubleshoot faults on main and diversity RX channels due to hardware faults.

Issue 01 (2011–8–17)


252



13.1 Principles of Main and Diversity Reception When 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 channel alarm and ALM-4178 Diversity receive channel alarm. The alarms can be triggered only when there is a certain amount of traffic. Therefore, do not check for faults on main and diversity RX channels 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 is reported.

l

When the diversity RX signal level is lower than the main RX signal level and the difference exceeds the upper threshold (32 dB), the alarm ALM-4178 Diversity receive channel alarm is reported.

Only the main or diversity RX channels receive signals when the alarms related to diversity or main RX channels are reported. As a result, the BTS coverage decreases.

13.2 Locating Faults on Main and Diversity RX Channels This section describes how to locate faults on main and diversity RX channels.

Principles of Locating Faults on Main or Diversity RX Channels When an alarm related to main and diversity RX channels is reported, check for the following problems or faults: l

Incorrect data configurations

l

Incorrect feeder connections

l

Hardware faults

Procedure for Locating Faults on Main and Diversity RX Channels Figure 13-1 shows the procedure for locating faults on main and diversity RX channels.

Issue 01 (2011–8–17)


253



Figure 13-1 Procedure for locating faults on main and diversity RX channels

13.3 Troubleshooting Faults on Main and Diversity RX Channels Due to Incorrect Data Configurations This section describes how to troubleshoot faults on main and diversity RX channels due to incorrect data configurations.

Symptom Alarms such as ALM-4176 Main receive channel alarm and ALM-4178 Diversity receive channel alarm are reported.


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 then transmitted 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 multipath effect, increasing the downlink RX signal level of an MS.

Issue 01 (2011–8–17)


254


l


4-way diversity: The 4-way RX signals are transmitted to one carrier.

Location Procedure Figure 13-2 shows the procedure for locating faults on main and diversity RX channels due to incorrect data configurations. Figure 13-2 Procedure for locating faults on main and diversity RX channels due to incorrect data configurations


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 paths are required for a cell configured with four carriers and send mode set to No Combining but only one DDPU is configured, the data configuration is incorrect. Run the MML command LST BTSANTFEEDERCONNECT to query the configuration

Issue 01 (2011–8–17)


255



for antenna connections. If the configuration is inconsistent with the physical connections, run the MML command SET BTSANTFEEDERCONNECT to modify the configuration. l For the BTS3900, check whether the data configuration is consistent with the physical connections based on TRX type. For example, if the only one carrier on a DRFU is bound 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 MML command LST GTRX to query the TRX data configuration. If the data configuration is inconsistent with the physical connections, run the MML command RMV TRXBIND2PHYBRD to delete the binding relationship between the carriers and the paths on the TRXs. Then, run the MML command ADD TRXBIND2PHYBRD to add the 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 to Step 4. l If yes, return to Procedure for locating main and diversity receive channel faults. 4.

Check whether the alarms are cleared. l If yes, no further action is required. 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-4176 Main 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. Troubleshooting Procedure On the LMT, run the MML command SET GTRXDEV with Receive Mode set to INDEPENDENT(Independent Receiver) and Send Mode set to DTIC(Transmit Independency or Combination).

13.4 Troubleshooting Faults on Main and Diversity RX Channels Due to Incorrect Antenna Connections This section describes how to troubleshoot faults on main and diversity RX channels due to incorrect antenna connections.

Symptom Alarms such as ALM-4176 Main receive channel alarm and ALM-4178 Diversity receive channel 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 to handovers increase, and the packet switched (PS) service rate decreases. Issue 01 (2011–8–17)


256



Swapped BTSs are more likely to encounter antenna connection errors than newly deployed BTSs. Field engineers can use traffic statistics and signaling data in the early phase to locate such problems.

Background Information The following are the performance counters related to main and diversity RX channels: l

S4556:Average Main Level in the Customized MR

l

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) - 120

l

Diversity RX signal level (dB) = 10 x log10(S4556) - 120

Location Procedure Figure 13-3 shows the procedure for locating faults on main and diversity RX channels due to incorrect antenna connections. Figure 13-3 Procedure for locating faults on main and diversity RX channels due to incorrect antenna connections

Issue 01 (2011–8–17)


257




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 formulas mentioned in background information. For the carriers of the TRXs connecting to the same RF 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. l If no, 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 a jumper or feeder connected to an antenna connector for the RF module is faulty. Calculate the main and diversity RX signal levels according to the preceding formulas mentioned in background information. For the carriers of all the TRXs connecting to the same antenna connector, if the main RX signal level is different from the diversity RX signal level, check whether a jumper or feeder connected to an antenna connector for the RF module is faulty. l If yes, replace the faulty jumper or feeder. Then, go to Step 4. l If no, go to Step 5.

4.

Check whether the alarms are cleared. l If yes, no further action is required. l If no, go to Step 5.

5.

Check whether the antenna connections between two cells are crossed. Calculate the main and diversity RX signal levels according to the preceding formulas mentioned in background information. For the carriers of all the TRXs in two cells under the 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. l If no, return to Procedure for locating main and diversity receive channel faults.

6.

Check whether the alarms are cleared. l If yes, no further action is required. l If no, return to Procedure for locating main and diversity receive channel faults.

Typical Symptoms of Incorrect Antenna Connections

Issue 01 (2011–8–17)

BTS Type

Fault Type

Symptom

BTS3012

Faults in cables between the TRXs and the DFCU or DDPU

For the carriers of some TRXs connected to the DFCU or DDPU, if the main RX signal level is different from the diversity RX signal level, the RXM or RXD cables between the TRXs and the DFCU or DDPU may be faulty.


258


BTS Type

BTS3900


Fault Type

Symptom

Faults in the feeder or jumper connected to an antenna connector for the DFCU or DDPU

For the carriers of all the TRXs connected to the same antenna connector, the main RX signal level is different from the diversity RX signal level.

Crossed pairs between the main and diversity RX channels of the two cells

For the carriers of all the TRXs in two or more cells under the same BTS, the main RX signal level is different from the diversity RX signal level.

Incorrect configuration of the TRX send and receive modes

For all carriers of a TRX connected to an RF module, the main RX signal level is different from the diversity RX signal level.

Faults in antennas connected to TRXs

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 cell under the BTS. l For all carriers of one TRX, the main RX signal level is lower than the diversity RX signal level; for all carriers of another TRX, the diversity RX signal level is lower than 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 cell under the BTS. l For all carriers of the TRX, the main RX signal level is different from the diversity RX signal level.

Crossed pairs between the main and diversity RX channels of two cells

Issue 01 (2011–8–17)

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 cells under the BTS. l For all carriers of one TRX, the main RX signal level is lower than the diversity RX signal level; for all carriers of another TRX, the diversity RX signal level is lower than the main RX signal level.


259



BTS Type

Fault Type

Symptom 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 cells under the BTS. l For all carriers of the TRX, the main RX signal level is different from the diversity RX signal level.

Inappropriate For the BTS3012, the threshold is set to 6 dB or larger; for thresholds for the BTS3900, the threshold is set to 10 dB or larger. the RX signal level of the main and diversity RX channels

BTS3900/ BTS3012

Low RX signal level of main and diversity RX channels

The main and diversity RX signal level is lower than -98 dB. (This can be used as a supplementary method to determine incorrect antenna connections.)

Typical Case Symptom A site frequently encounter problems such as interference, one-way audio, sharp decreases in the 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, the main and diversity RX signal level difference exceeds 10 dB. Location Procedure 1.

Query the performance measurement results by choosing MR Measurement(MR) > User defined 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 preceding formulas.

3.

Analyze the main and diversity RX signal level of all carriers in the two cells. The main and diversity RX signal level difference exceeds 10 dB. In addition, the RX signal level of path A in cell 1 is high and that of path B in cell 1 is low, whereas the RX signal level of path A in cell 2 is high and that of path B in cell 2 is low. This indicates that the antenna connections between the two cells are crossed.

4.

Check for crossed pairs of feeders onsite and reconnect the feeders. The alarms are cleared.

Issue 01 (2011–8–17)


260



13.5 Troubleshooting Faults on Main and Diversity RX Channels Due to Hardware Faults This section describes how to troubleshoot faults on main and diversity RX channels due to hardware faults.

Symptom Alarms such as ALM-4176 Main receive channel alarm and ALM-4178 Diversity receive channel alarm are reported.

Location Procedure Figure 13-4 shows the procedure for locating faults on main and diversity RX channels due to hardware faults. Figure 13-4 Procedure for locating faults on main and diversity RX channels due to hardware faults


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-4178 Diversity receive channel alarm are cleared. l If yes, no further action is required. l If no, Contact Huawei Customer Service Center.



261



After the capacity expansion from S3 to S3/2, the BTS312 operates properly. During the two days after capacity expansion, the newly added TRXs report the alarm ALM-4178 Diversity receive 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 the top 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.


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.

Issue 01 (2011–8–17)


262


14 No Traffic

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 Traffic When no traffic occurs, subscribers cannot initiate calls in a normal cell or a normal cell cannot be occupied. 14.2 Locating No Traffic This section describes how to locate no traffic. 14.3 Troubleshooting No Traffic Due to No Calls This section describes how to troubleshoot no traffic due to no calls. 14.4 Troubleshooting No Traffic Due to Transmission or Equipment Faults This section describes how to troubleshoot no traffic due to transmission or equipment faults. 14.5 Troubleshooting No Traffic Due to Incorrect Data Configurations This section describes how to troubleshoot no traffic due to incorrect data configurations. 14.6 Troubleshooting No Traffic Due to Poor Um Interface Quality This section describes how to troubleshoot no traffic due to poor Um interface quality. 14.7 Troubleshooting No Traffic Due to Antenna System Faults This section describes how to troubleshoot no traffic due to antenna system faults. 14.8 Resetting This section describes how to perform resetting.

Issue 01 (2011–8–17)


263


14 No Traffic

14.1 Introduction to No Traffic When no traffic occurs, subscribers cannot initiate calls in a normal cell or a normal cell cannot be occupied.

Introduction When no traffic occurs, a cell or some TRXs serving the cell become faulty. As a result, cell coverage 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 a BTS, cell, board, or TRX on the board, depending on the cell configurations.

Associated Alarm The ALM-28008 Radio Link Failure alarm with Specific Problem of No Traffic on TRX is associated with no traffic. This alarm is reported when a TRX does not detect any traffic (no calls can be set up in a cell) during a consecutive period of time. The alarm is cleared when a call 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 traffic distribution.

Symptom When 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 Traffic This section describes how to locate no traffic.

Principles Resource 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 troubleshoot the problems based on the live network conditions. To locate the problems, first determine the search scope, such as site, cell, or TRX according to the problem feedback information and traffic statistics. If no fault is found after the location procedure is performed on the site, cell, or TRX, reset the software and hardware to restore services. The location procedure involves the following operations: Issue 01 (2011–8–17)


264


14 No Traffic

l

Analyzing the KPIs associated with a cell or TRX

l

Checking the alarm parameter settings

l

Handling the transmission and equipment alarms

l

Checking the parameter settings

l

Locating interference

l

Resetting the faulty board to check whether the board software is faulty

l

Locating antenna system faults

Location Procedure Figure 14-1 shows the procedure for locating no traffic.

Issue 01 (2011–8–17)


265


14 No Traffic

Figure 14-1 Procedure for locating no traffic

14.3 Troubleshooting No Traffic Due to No Calls This section describes how to troubleshoot no traffic due to no calls.

Symptom The ALM-28008 Radio Link Failure alarm with Specific Problem of No Traffic on TRX is reported, or the value of K3014:Traffic Volume on TCH is zero. Issue 01 (2011–8–17)


266


14 No Traffic

This problem may be caused by special coverage conditions. For example, there are no travelers at a popular tourist attraction during the off-season, no subscribers in certain districts or no students in schools during holidays, or there is no traffic in some cells in the early morning. In these conditions, change the settings of the correlated alarm parameters to improve alarm detection accuracy.

Background Information The parameters associated with this alarm are Wireless Link Alarm Flag, Statistical Period of No-traffic, Begin Time of WLA Detection, and End Time of WLA Detection. You can run the LST GTRXRLALM command to query the settings of the preceding parameters and run the SET GTRXRLALM command to change the settings.

Location Procedure Figure 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


Check whether the settings of the correlated alarm parameters are correct. Begin Time of WLA Detection, End Time of WLA Detection, and Statistical Period of No-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.



267


14 No Traffic

The ALM-28008 Radio Link Failure alarm with Specific Problem of No Traffic on TRX is frequently 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 because no phone calls were made during summer vacation. Troubleshooting Procedure 1.

Trace the RSL signaling on the Abis interface for the problem cell. No channel requests are 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 are normal.

2.

Perform drive tests (DTs). Subscribers can make calls in the area covered by the cell. This indicates that the BTS is operating properly.

3.

Change the settings of the correlated alarm parameters to ensure that the ALM-28008 Radio Link Failure alarm is not reported during summer vacation.

14.4 Troubleshooting No Traffic Due to Transmission or Equipment Faults This section describes how to troubleshoot no traffic due to transmission or equipment faults.

Symptom When a transmission or equipment fault occurs in a cell, the alarm system reports alarms such as RF Unit VSWR Threshold Crossed, Trx Temperature Alarm, Transmission alarm, and TRX Config Mismatch Alarm. In this situation, the cell may be out of service, or the TRX may be shut down.

Background Information Transmission or equipment faults include: l

Faults in the BTS transmission management unit

l

BTS TRX faults

l

BTS antenna faults

The following alarms are associated with hardware or antenna faults: l

ALM-21807 OML Fault

l

ALM-26235 RF Unit Maintenance Link Failure

l

ALM-26529 RF Unit VSWR Threshold Crossed

l

ALM-11272 Hardware Alarm

l

ALM-26503 RF Unit Optical Module Transmit/Receive Fault

The following alarms are associated with transmission faults: l

ALM-21807 OML Fault

l

ALM-11280 E1/T1 remote alarm

l

ALM-25800 E1/T1 Loss of Signal

Issue 01 (2011–8–17)


268


l

14 No Traffic

ALM-25803 E1/T1 Loss of Frame Alignment

Location Procedure Figure 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


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.

2.


Typical Case Symptom An onsite MRFU has no traffic and reports the ALM-4812 Optic Module Abnormal Alarm and the 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 between the TRX and the BBU is disconnected. Troubleshooting Procedure 1.

Analyze the RSL signaling on the Abis interface. All calls assigned to the MRFU fail to be initiated because the MRFU does not receive any link setup indication messages after the assignment command is delivered.

2.

Query the alarm information on the LMT. The alarms associated with optical module faults are reported.

Issue 01 (2011–8–17)


269


3.

14 No Traffic

Replace the onsite optical module with a new one. The no traffic problem is resolved.

14.5 Troubleshooting No Traffic Due to Incorrect Data Configurations 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 of No Traffic on TRX.

Background Information The ALM-28008 Radio Link Failure is reported if certain parameters are set incorrectly or certain functions 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 may occur.

l

Enabling energy saving functions may result in no traffic. For example, when the intelligent shutdown 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 traffic volume of a cell or TRX is low, the BTS powers off the cell or TRX to reduce power consumption. After the cell or TRX is powered off, there is no traffic in the cell or on the TRX.

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

Issue 01 (2011–8–17)


270


14 No Traffic


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.

2.


Typical Case Symptom The traffic volumes of three cells under a BSC at site A suddenly decrease to zero and no channel requests are reported in these cells. However, the traffic volumes of the cells are restored to normal after several hours. Cause Analysis The dynamic cell shutdown function is enabled. Troubleshooting Procedure 1.

View the traffic statistics. Several hours before no traffic occurs, the number of channel requests reported in the cell gradually decreases. When the no traffic problem occurs, the number of channel requests decreases to zero.

2.

Analyze the operation logs when the problem occurs and when it is resolved. Before the problem occurs, the dynamic cell shutdown function is enabled. As a result, the BSC constantly checks the cell load. If the cell load is less than Same Coverage Cell Load Threshold (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 function is disabled, the problem is resolved.

14.6 Troubleshooting No Traffic Due to Poor Um Interface Quality 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 CMD message 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.


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.

Issue 01 (2011–8–17)


271


14 No Traffic

Location Procedure Figure 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


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 check whether 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.

Issue 01 (2011–8–17)


272


4.

14 No Traffic


5.

Perform operations provided in 14.8 Resetting. Then, go to Step 6.

6.


Typical Case Symptom There is no traffic on an onsite TRX and the alarm system reports the ALM-28008 Radio Link Failure alarm with Specific Problem of No Traffic on TRX. The system occasionally clears the alarm, but the traffic volume is low. Cause Analysis There is severe uplink interference on the frequency used by the problem TRX. Troubleshooting Procedure 1.

Analyze the traffic statistics when the problem occurred. Although few assignment commands 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 cell and there is traffic in the cell. However, MSs fail to access the assigned TCHs on the problem 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 uplink interference bands of the TRX are interference band 5 and the TRX is configured in nonfrequency hopping (non-FH) mode.

5.

Change the frequency used by the TRX. The problem is resolved. This indicates that the problem is caused by single-frequency interference.

14.7 Troubleshooting No Traffic Due to Antenna System Faults 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 equipment faults, incorrect data configuration, or poor Um interface quality are excluded, the problem may be 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.

Issue 01 (2011–8–17)


273


14 No Traffic


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 sent to or decoded by the BTS.

l

If the antenna connections are incorrect, the coverage area of the BCCH TRX in the cell may be different from the coverage areas of non-BCCH TRXs. As a result, MSs fail to access the assigned TCHs on non-BCCH TRXs after they initially access the TCHs on the BCCH TRX. This results in no traffic on non-BCCH TRXs.

Location Procedure Figure 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

Issue 01 (2011–8–17)


274


14 No Traffic

Troubleshooting Procedure Use 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 tests on 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.

2.


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.

4.


5.

Check whether the antenna tilt is correct and whether the tilt direction is consistent with the coverage area. l If no, adjust the antenna tilt. Then, go to Step 6. l If yes, go to Step 7.

6.


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 the fault. Then, go to Step 8. l If no, go to Step 9.

8.


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 to connect the TRX of cell B to the antenna of cell A. If the problem is resolved, the problem is 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.

Issue 01 (2011–8–17)


275


14 No Traffic

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 Case Symptom The onsite traffic volume suddenly decreases to zero and the ALM-28008 Radio Link Failure alarm with Specific Problem of No Traffic on TRX is reported on the system and is not cleared for several days. Cause Analysis The distributed indoor antenna system is powered off, and therefore no downlink signals are available. As a result, MSs fail to access the network. Troubleshooting Procedure 1.

View the traffic statistics when the problem occurs in the cell. No channel requests are reported in the cell, but the interference band messages are reported. The downlink transmit power 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 the distributed indoor antenna system is powered off.

14.8 Resetting This section describes how to perform resetting.

CAUTION Exercise 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

Issue 01 (2011–8–17)

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 parameter settings, see the MML Command Reference. Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

276


14 No Traffic

l

To reset the board software, run the RST BTSBRD command with Reset Type set to SOFTWARE(Software Reset). For details about the parameter settings, see the MML Command Reference.

l

To reset the board hardware, run the RST BTSBRD command with Reset Type set to HARDWARE(Hardware Reset). For details about the parameter settings, see the MML Command Reference.

If the no traffic problem is caused by software errors, resolve the problem by resetting the software or hardware. After the problem is resolved, Contact Huawei Customer Service Center to determine the root cause of the problem.

Issue 01 (2011–8–17)


277

GBSS9.0 Troubleshooting Guide

Recommend Documents