Professional Documents
Culture Documents
V900R008
Issue 01
Date 2008-06-10
INTERNAL
Website: http://www.huawei.com
Email: support@huawei.com
and other Huawei trademarks are the property of Huawei Technologies Co., Ltd.
All other trademarks and trade names mentioned in this document are the property of their respective holders.
Notice
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 the statements, information, and
recommendations in this document do not constitute a warranty of any kind, express or implied.
Contents
3 Common Faults...........................................................................................................................3-1
3.1 Troubleshooting One-Way Audio or No Audio..............................................................................................3-2
3.2 Troubleshooting Noises...................................................................................................................................3-3
3.3 Troubleshooting Cross Connection Faults......................................................................................................3-5
4 Link Faults...................................................................................................................................4-1
4.1 Link Fault Symptoms......................................................................................................................................4-2
4.1.1 Impacts of Link Faults on Services........................................................................................................4-2
4.1.2 Alarms Related to Link Faults...............................................................................................................4-3
4.1.3 Counters Related to Link Faults.............................................................................................................4-9
4.2 Link Troubleshooting Methods.....................................................................................................................4-11
4.2.1 Troubleshooting OML Faults...............................................................................................................4-13
4.2.2 Troubleshooting EML Faults...............................................................................................................4-14
4.2.3 Troubleshooting RSL Faults................................................................................................................4-16
4.2.4 Troubleshooting ESL Faults.................................................................................................................4-17
4.2.5 Troubleshooting PBSL Faults..............................................................................................................4-18
4.2.6 Troubleshooting SS7 Signaling Link Faults........................................................................................4-23
4.2.7 Troubleshooting Ater Signaling Link Faults........................................................................................4-26
4.2.8 Troubleshooting Ater OML Faults.......................................................................................................4-27
4.2.9 Troubleshooting E1/T1 Transmission Faults.......................................................................................4-27
4.2.10 Troubleshooting Optical Transmission Faults...................................................................................4-28
4.2.11 Troubleshooting M3UA Link Faults..................................................................................................4-29
4.2.12 Troubleshooting M3UA Route Unavailability Faults........................................................................4-32
4.2.13 Troubleshooting M3UA Destination Entity Inaccessibility Faults....................................................4-33
4.2.14 Troubleshooting Abis Interface IP Link Faults..................................................................................4-36
4.3 Typical Cases of Troubleshooting Link Faults.............................................................................................4-37
4.3.1 Case: BTS TRX Faults.........................................................................................................................4-38
4.3.2 Case: BTS Faults..................................................................................................................................4-38
4.3.3 Case: BTS Loading Failure..................................................................................................................4-39
4.3.4 Case: Abis Transmission Faults...........................................................................................................4-39
4.3.5 Case: M3UA Link Faults.....................................................................................................................4-40
5 Clock Faults.................................................................................................................................5-1
5.1 Clock Fault Symptoms....................................................................................................................................5-2
5.1.1 Impacts of Clock Faults on Services......................................................................................................5-2
5.1.2 Alarms Related to Clock Faults.............................................................................................................5-2
5.1.3 Counters Related to Clock Faults...........................................................................................................5-5
5.2 Clock Troubleshooting Methods.....................................................................................................................5-5
5.2.1 Troubleshooting Clock Source Faults....................................................................................................5-5
5.2.2 Troubleshooting Board Clock Faults.....................................................................................................5-7
5.3 Typical Cases of Troubleshooting Clock Faults.............................................................................................5-7
5.3.1 Case: All BTS Clock Reference Sources Unavailable...........................................................................5-8
6 Handover Faults.........................................................................................................................6-1
6.1 Handover Fault Symptoms..............................................................................................................................6-2
6.1.1 Impacts of Handover Faults on Services................................................................................................6-2
6.1.2 Alarms Related to Handover Faults.......................................................................................................6-2
6.1.3 Counters Related to Handover Faults.....................................................................................................6-2
6.2 Handover Troubleshooting Methods...............................................................................................................6-5
6.2.1 Troubleshooting No or Too Many Handovers Originated by the MS...................................................6-5
6.2.2 Troubleshooting Destination Cell Congestion Faults............................................................................6-6
6.2.3 Troubleshooting Hardware Faults..........................................................................................................6-6
6.2.4 Troubleshooting Inter-BSC or Inter-MSC Handover Failures...............................................................6-7
6.2.5 Troubleshooting Other Handover Faults................................................................................................6-8
7 Congestion Faults.......................................................................................................................7-1
7.1 Congestion Fault Symptoms...........................................................................................................................7-2
7.1.1 Impacts of Congestion Faults on Services.............................................................................................7-2
7.1.2 Alarms Related to Congestion Faults.....................................................................................................7-2
7.1.3 Counters Related to Congestion Faults..................................................................................................7-3
7.2 Congestion Troubleshooting Methods............................................................................................................7-4
7.2.1 Troubleshooting High Traffic................................................................................................................7-5
7.2.2 Troubleshooting Burst Traffic................................................................................................................7-6
7.2.3 Troubleshooting TRX Faults..................................................................................................................7-6
7.2.4 Troubleshooting Interference Problems.................................................................................................7-8
7.2.5 Troubleshooting Insufficient Terrestrial Resources...............................................................................7-9
7.2.6 Troubleshooting Insufficient Abis Resources........................................................................................7-9
7.3 Typical Cases of Troubleshooting Congestion Faults...................................................................................7-11
7.3.1 Case: TCH Congestion Due to TRX Faults.........................................................................................7-11
7.3.2 Case: SDCCH Congestion Due to LAC Configuration Faults............................................................7-11
8 Access Faults...............................................................................................................................8-1
8.1 Access Fault Symptoms..................................................................................................................................8-2
8.1.1 Impacts of Access Faults on Services....................................................................................................8-2
8.1.2 Alarms Related to Access Faults............................................................................................................8-2
8.1.3 Counters Related to Access Faults.........................................................................................................8-3
8.2 Access Troubleshooting Methods...................................................................................................................8-4
8.2.1 Troubleshooting Um Interface Quality Problems..................................................................................8-4
8.2.2 Troubleshooting Data Configuration Faults...........................................................................................8-7
8.3 Typical Cases of Troubleshooting Access Faults.........................................................................................8-11
8.3.1 Case: MS Access Failure Due to Weak Signals...................................................................................8-11
8.3.2 Case: MS Cell Reselection Failure Due to Weak Signals of Neighboring Cells.................................8-12
8.3.3 Case: MS Network Disconnection Due to Location Update Period Set Too Small............................8-12
9 PS Service Faults........................................................................................................................9-1
9.1 PS Service Fault Symptoms............................................................................................................................9-2
9.1.1 Impacts of PS Service Faults on Services..............................................................................................9-2
9.1.2 Alarms Related to PS Service Faults......................................................................................................9-2
9.1.3 Counters Related to PS Service Faults...................................................................................................9-4
9.2 PS Service Troubleshooting Methods...........................................................................................................9-12
9.2.1 Troubleshooting a Cell Not Supporting GPRS....................................................................................9-13
9.2.2 Troubleshooting Cell Faults (External PCU).......................................................................................9-14
9.2.3 Troubleshooting Cell Kickoff Failures (External PCU)......................................................................9-17
9.2.4 Troubleshooting PDCH Faults (External PCU)...................................................................................9-20
9.2.5 Troubleshooting LAPD Link Faults (External PCU)...........................................................................9-21
9.2.6 Troubleshooting Cell Activity State Faults (Built-in PCU).................................................................9-23
9.2.7 Troubleshooting Cell Service Disruption Faults (Built-in PCU).........................................................9-27
9.2.8 Troubleshooting Global Service Disruption Faults (Built-in PCU).....................................................9-28
9.2.9 Commands Executed on the PCU Maintenance Terminal...................................................................9-30
9.3 Typical Cases of Troubleshooting PS Service Faults...................................................................................9-31
9.3.1 Case: Intermittent LAPD Links............................................................................................................9-32
9.3.2 Case: Broken Links on the Gb Interface..............................................................................................9-32
9.3.3 Case: MS GPRS Failure.......................................................................................................................9-33
9.3.4 Case: Unstable GPRS Download Rate.................................................................................................9-33
Figures
Tables
Purpose
This document describes the methods of troubleshooting faults when the GBSS equipment is in
service. With this document, the maintenance personnel can solve the following problems:
l Complaints from subscribers
l Faults detected in regular maintenance
l Burst equipment faults
Product Version
The following table lists the product versions related to this document.
BTS3012AE V300R005&V300R006
BTS3006C V300R005&V300R006
BTS3002E V300R005
BTS3036/BTS3900 V300R008
GSM
BTS3036A/BTS3900A V300R008
GSM
DBS3036/DBS3900 V300R008
GSM
Intended Audience
This document is intended for:
l System engineers
l Technical support engineers
l Maintenance engineers
Change History
For changes in the document, refer to Changes in BSS Troubleshooting Guide.
Organization
1 Introduction to BSS Troubleshooting
This introduces the troubleshooting process and common means of fault location. If a fault cannot
be rectified, you can contact Huawei for technical support.
2 Collecting Information for Locating BSS Faults
When a fault occurs to the BSS, you need to collect the fault information as a reference for
troubleshooting. In addition, when you contact Huawei Customer Service Center, provide the
fault information for more efficient troubleshooting.
3 Common Faults
This describes the methods of troubleshooting common faults. Through these methods, you can
determine the class, subclass, or specific location of a fault.
4 Link Faults
This describes link faults in terms of the symptoms, troubleshooting methods, and typical cases.
5 Clock Faults
This describes clock faults in terms of the symptoms, troubleshooting methods, and typical cases.
6 Handover Faults
This describes handover faults in terms of the symptoms, troubleshooting methods, and typical
cases.
7 Congestion Faults
This describes congestion faults in terms of the symptoms, troubleshooting methods, and typical
cases.
8 Access Faults
This describes access faults in terms of the symptoms, troubleshooting methods, and typical
cases.
9 PS Service Faults
This describes PS service faults in terms of the symptoms, troubleshooting methods, and typical
cases.
10 Cell Broadcast Faults
This describes cell broadcast faults in terms of the symptoms, troubleshooting methods, and
typical cases.
Conventions
1. Symbol Conventions
The following symbols may be found in this document. They are defined as follows
Symbol Description
TIP Indicates a tip that may help you solve a problem or save your
time.
2. General Conventions
Convention Description
3. Command Conventions
Convention Description
Convention Description
4. GUI Conventions
Convention Description
> Multi-level menus are in boldface and separated by the ">" signs.
For example,choose File > Create > Folder .
5. Keyboard Operation
Convention Description
Key1,Key2 Press the keys in turn.For example,pressing Alt,A means the two
keys should be pressed in turn.
6. Mouse Operation
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.
This introduces the troubleshooting process and common means of fault location. If a fault cannot
be rectified, you can contact Huawei for technical support.
Start
Collect fault
information
Equipment
No Obtain Huawei
and services are Technical Support
restored?
Yes
End
l Fault symptoms
l Fault occurrence time, site, and frequency
l Fault scope and impact
l Operational status of the equipment before the fault occurs
l Operations performed on the equipment before the fault occurs, and the consequence
l Alarms and associated alarms when the fault occurs
l Fault symptoms mentioned in this document are categorized into several classes. For each class, this
document provides a series of fault location methods, through which subclasses may be determined.
For each subclass, this document provides a series of operations, through which the specific fault causes
can be found.
l In addition, this document describes how to analyze and locate common faults, such as one-way audio,
no audio, and noise.
NOTE
For service-related faults, you can refer to 1.2 Common Troubleshooting Methods to locate the
fault.
l Location of faults related to the subsystems
There are many types of clock faults and link faults. The fault scope, however, is relatively
narrow. Such faults have simple causes. Fault-related information is presented through
board LEDs, alarms, and error prompts. Based on such information, you can rectify the
fault in most cases.
Alarm information includes the description of the fault or exception, fault causes, and handling
suggestions. Alarm information relates to many parts of the BSS, including hardware, link, trunk,
and CPU load. It is an important key to fault analysis and location.
Alarm information is used to locate the fault and finding out the causes. The BSS alarm system
provides a huge amount of alarm information, which can be used to locate faults directly or
together with other means.
The LED status is used to quickly locate the fault and the causes of the fault. Because of limited
information, the LED status is often used together with alarm information.
Dialing Test
A dialing test is used to check the call processing function of the BSS and the relevant equipment.
It is a simple and quick way of troubleshooting.
Voice services take up a great part of all the services provided by the BSS. As a result, most
faults related to the BSS have great impacts on calls.
Dialing tests are often used in daily maintenance to determine whether the MS, BTS, BSC, and
trunk system work properly. Dialing tests are also used together with continuous and dynamic
tracing to test the BSS functions, such as call processing and calling number display.
Measurement
Measurement is a common technical means of BSS troubleshooting. It is widely used in power
supply testing, signaling analysis, waveform analysis, and bit error rate (BER) check. Through
instruments and meters, you can directly obtain fault-related data.
Performance Statistics
Performance statistics are a means of analyzing the call drop rate.
The call drop rate is an important counter of the BSS. It is affected by many factors and therefore
difficult to predict. Performance statistics can help to find call drop causes in time and prevent
call drops effectively
Interface Tracing
Interface tracing is used to analyze the causes of a failure in calling connection or signaling
cooperation between offices. Based on tracing results, you can directly locate the causes in most
cases.
A loopback test refers to such a test in which a transmitted signal is returned to the sending
device. Loopback is used to observe the functioning of a device or channel, the provisioning of
services, and the status of signaling flows. With the information, you can determine whether
hardware and software parameters are properly set. Loopback is commonly used to locate
transmission faults and trunk parameter errors. During the process of setting up a new site and
expanding the capacity of trunks, loopback of a BSS trunk can help to determine whether the
trunk and signaling link parameters are properly set.
Common tests and loopback tests are usually used together to locate transmission faults.
You can replace the faulty part with a good one to compare the running status of the two parts
to determine the scope or location of the fault. Interchange is applicable when the fault occurs
in a wide scope.
Reset refers to manually resetting some or all of the devices. Reset is mainly used to rectify
software running faults.
Switchover and reset should be used only in emergency. The reasons are as follows:
l Compared with other methods, switchover and reset are auxiliary methods.
l After switchover or reset, the fault symptom seldom appears again within a short period.
As a result, the faults cannot be found, which brings potential security and stability risks
to the equipment.
l Usually, the reset operation disrupts the ongoing services and even brings the system down.
To avoid data loss, you need to back up the system data before switchover of main control boards.
For details, refer to BSS Backup and Recovery Guide.
2. Provide the feedback information to Huawei technical services center according to 1.3.3
Fault Location Record Form. For details, refer to 1.3.1 Obtaining Technical Support.
NOTE
If encountered a critical fault, you can first contact Huawei technical services center prior to collecting and
providing the information necessary for troubleshooting.
Procedure
l Dial the customer service number of Huawei: 4008302118 or (+86-755) 2856 0000.
l Fax a properly written feedback form to Huawei (0755-28560111) or the local office.
– For an emergent fault, fill in the BSS Emergency Maintenance Notice to provide
the feedback information.
– For a non-emergent fault, fill in the 1.3.3 Fault Location Record Form to provide
the feedback information.
l Send an E-mail to support@huawei.com.
l Visit the website http://support.huawei.com for help.
NOTE
For details on how to contact the local office, visit the support website.
----End
For details on the collection of fault location information, refer to 2 Collecting Information for
Locating BSS Faults.
The following contents should be completed by the personnel from Huawei technical
services center.
Operator: Date:
Outstanding issue:
When a fault occurs to the BSS, you need to collect the fault information as a reference for
troubleshooting. In addition, when you contact Huawei Customer Service Center, provide the
fault information for more efficient troubleshooting.
This describes how to collect the TRACE files of the M2000 server and M2000 client for
troubleshooting.
2.10 Collecting Channel Status Information
This describes how to collect the channel status information for troubleshooting.
2.11 Collecting Board Bar Code Information
This describes how to collect bar code information of a BSC board for troubleshooting.
2.12 Collecting Voice Tuning Information
This describes how to collect voice tuning information based on the voice symptoms. The voice
problems involve noise, one-way audio (including no audio and voice discontinuity), and echo.
2.13 Collecting External PCU Information
When a fault occurs to the external PCU, you need to collect the fault information as a reference
for troubleshooting. In addition, when you contact Huawei Customer Service Center, provide
the fault information for more efficient troubleshooting.
Prerequisite
l The LMT runs normally.
l The communication between the LMT and the BSC is normal.
Context
If the local information is successfully collected, the local information is automatically saved to
the path: LMT installation path\BSC6000\BSC6000V900R008C01\BscObj\BSC Name
\LocaleInfo.
The local information is categorized into the following four types:
l Core Dump: mirror file of the realtime running of the server
l Pfm: performance statistics file
l Log: oprlog (operation log), dbglog (debugging log), runlog (running log), lstlog (lastword
log), chrlog (CHR log), btslog (BTS log), and frqlog (frequency scan log).
l Alarm: alarm log file
Procedure
Step 1 Choose BSC Maintenance > Maintain User Resource > Collect BSC Local Information.
Step 2 Click the Collect BSC Information tab. On the tab page, select Collect BSC local
information and set the BSC local information.
NOTE
You must select the Collect BSC local information so that you can collect and save the BSC local
information.
l Click the Collect BTS information tab. On the tab page, select the BTSs of which the
information needs to be collected.
l Click the Collect File tab. On the tab page, select the files of which the information needs
to be collected.
Step 3 Click Execute. The BSC local information is collected, as shown in Figure 2-1.
----End
Prerequisite
l The LMT runs properly.
l The BSC is functional.
l The communication between the LMT and the BSC is normal.
Procedure
Step 1 On the BSC6000 Local Maintenance Terminal, choose Configuration > Back Up > Back
Up Server Data on the menu. A dialog box is displayed, as shown in Figure 2-2.
Step 2 Click Back up to local. Then, click the button in the File Path on Local area to specify the path
for saving the data.
Step 3 Click Execute. After the operation is complete, the message Uploading succeeded is displayed.
You can obtain the BSC configuration data file specified in Step 2.
----End
Prerequisite
l The M2000 runs properly.
l The communication between the M2000 and the BSC is proper.
Procedure
Step 1 On the M2000 Client, choose Performance > Query Result on the menu. A dialog box is
displayed, as shown in Figure 2-3.
Step 2 Click New Query. A dialog box is displayed, as shown in Figure 2-4.
Step 3 In the left pane of the interface, click Object Type or Function Subset in the Organization
Style area, in the right pane of the interface, specify the object to be queried, the counters, and
period on the Object Settings, Counter Settings, and Other Settings tab pages separately.
Then, click Query.
Step 4 Click Save Template. The performance measurement result is saved in the form of .XLS.
----End
Prerequisite
l The communication between the LMT and the GBAM or the GOMU is proper.
l The communication between the Telnet client and the GBAM or the GOMU is proper.
Procedure
Step 1 Start the Telnet client, such as PuTTY Software, on the PC. Then, enter the IP address of the
GBAM and GOMU, and log in to the GBAM or GOMU as user root.
Step 2 Double-click the Internet Explorer icon and run the IP address (in the format of \
\XXX.XXX.XXX.XXX) of the GBAM to connect the GBAM server or the GOMU.
NOTE
If the Samba service is not started, run the rcsmb start command to start the service.
Step 3 Double-click the BSC6000 folder. Type User Name and Password, and then click Yes.
Step 4 Copy all the files under the BSC6000\data\mtndata\pfm directory to the local hard disk.
NOTE
If you are prompted to obtain specific rights in coping the files, run the chmod 777 /BSC6000 -R command
to change the read-and-write authority. After the files are copied, run the chmod 755 /BSC6000 -R
command to recover the read-and-write authority.
----End
Prerequisite
l The LMT runs properly.
l The communication between the LMT and the BSC is normal.
l The communication between the LMT and the alarm box is normal.
Procedure
Step 1 On the BSC6000 Local Maintenance Terminal, choose Alarm Maintenance > Manage
Alarm Log File on the menu. A window is displayed, as shown in Figure 2-5.
Step 2 Click Create. A dialog box is displayed, as shown in Figure 2-6. Specify the period during
which the fault occurs, and then generate the log file.
Step 3 After the log file generation succeeds, if you click Query in Figure 2-5, all the alarm log files
that are generated and saved in the server are displayed, as shown in Figure 2-7.
Step 4 Select the alarm log file that you want to upload it to the LMT PC, and then click Upload. The
alarm log file is uploaded to the path BscObj\Office Name\Alm in the LMT installation
directory.
----End
Prerequisite
l The communication between the LMT and the GBAM or the GOMU is proper.
l The communication between the Telnet client and the GBAM or the GOMU is proper.
Procedure
Step 1 Start the Telnet client, such as PuTTY Software, on the PC. Then, enter the IP address of the
GBAM and GOMU, and log in to the GBAM or GOMU as user root.
Step 2 Double-click the Internet Explorer icon and run the IP address (in the format of \
\XXX.XXX.XXX.XXX) of the GBAM to connect the GBAM server or the GOMU.
NOTE
If the Samba service is not started, run the rcsmb start command to start the service.
Step 3 Double-click the BSC6000 folder. Type User Name and Password, and then click Yes.
Step 4 Copy all the files under the BSC6000\data\datafile directory to the local hard disk.
NOTE
If you are prompted to obtain specific rights in coping the files, run the chmod 777 /BSC6000 -R command
to change the read-and-write authority. After the files are copied, run the chmod 755 /BSC6000 -R
command to recover the read-and-write authority.
----End
Prerequisite
l The LMT runs properly.
l The communication between the LMT and the BSC is normal.
Procedure
Step 1 On the BSC6000 Local Maintenance Terminal, choose BSC Maintenance > Maintain
Logs > Upload BSC Log Files on the menu. A window is displayed, as shown in Figure 2-8.
Step 2 Specify the Log Type and then click Query. The query result is shown in Figure 2-9.
Step 3 In the query result, select the log file to be uploaded and specify its upload path. Then, click
Upload to upload the log file to the path BscObj\Office Name\BscLog in the LMT installation
directory.
----End
Prerequisite
l The LMT runs properly.
l The communication between the LMT and the BSC is normal.
l The communication between the BSC and the BTS is normal.
NOTE
The following steps are taken as examples for logging in to the server.
Procedure
Step 1 On the BSC6000 Local Maintenance Terminal, choose BTS Maintenance > Maintain Site
> BTS Work Log. A dialog box is displayed, as shown in Figure 2-10.
CAUTION
The BSC extracts BTS logs and saves them on the server. You can obtain these logs on the
server, and then these logs saved in the BTS are deleted. When other two methods are used to
obtain logs, the logs saved in the BTS still exist.
Step 2 Click Get BTS Compressed Log, and then click OK. A dialog box is displayed, as shown in
Figure 2-11.
Step 3 In Figure 2-11, specify the parameters such as Site Name, Start Time, and End Time. Then,
click Start. If the progress bars in the Progress area show that the operation is complete, a
message is displayed, prompting you that the log extraction succeeds. The default directory on
the LMT for saving the compressed BTS log, BscObj\Office Name\CompressLog, is
displayed.
NOTE
You can use a log interpretation tool to view the log file.
----End
Prerequisite
l The LMT runs properly.
l The communication between the LMT and the BSC is normal.
Procedure
You can get the LMT log files from the LMT installation directory \BscObj\Office Name
\LmtLog.
----End
Procedure
Search for the white label attached to the GBAM shell. The literature following HUAWEI, such
as C5201 SERVER, is the GBAM model.
----End
Context
CAUTION
If the operations described below are performed, the local processes of the GBAM/GOMU will
be restarted. Thus, you are not advised to perform these operations except that the local processes
of the GBAM/GOMU are faulty and need to be restarted.
Procedure
Step 1 Start the Telnet client, such as PuTTY Software, on the PC. Enter the IP address of the GBAM/
GOMU, and then log in to the GBAM/GOMU as the root user.
Step 2 Run the cd /BSC6000/coredump command to visit the directory that saves the error information
associated with the GBAM/GOMU.
Step 3 Run the pkill -8 pomu_local.bin command to generate the omulocal.0000.core.1.gz file.
Here, 0000 indicates the subrack number and slot number of the GOMU, and 1 indicates the
count of the recorded abnormal information. This file is large is size (it may be 2 GB); thus, its
generation might take several minutes. You can run the ll command to query the file size. If the
file size becomes stable, you can infer that the file is successfully generated. Perform the
operations in Step 4 to compress the file.
Step 4 Run the gzip omulocal.0000.core.1.gz command to generate the compressed file, say, omulocal.
0000.local.1.gz.
This file is generally several decades of MB in size. You can copy the file from the path IP
address of the GBAM/GOMU\bsc6000\coredump.
----End
Context
CAUTION
If the operations described below are performed, the core processes of the GBAM/GOMU will
be restarted. Thus, you are not advised to perform these operations except that the core processes
of the GBAM/GOMU are faulty and need to be restarted.
Procedure
Step 1 Start the Telnet client, such as PuTTY Software, on the PC. Enter the IP address of the GBAM/
GOMU, and then log in to the GBAM/GOMU as the root user.
Step 2 Run the cd /BSC6000/coredump command to visit the directory that saves the error information
associated with the GBAM/GOMU.
Step 3 Run the pkill -8 pomu_core.bin command to generate the omucore.0000.core.1.gz file.
Here, 0000 indicates the subrack number and slot number of the GOMU, and 1 indicates the
count of the recorded abnormal information. This file is large is size (it may be 2 GB); thus, its
generation might take several minutes. You can run the ll command to query the file size. If the
file size becomes stable, you can infer that the file is successfully generated. Perform the
operations in Step 4 to compress the file.
Step 4 Run the gzip omucore.0000.core.1.gz command to generate the compressed file, say, omucore.
0000.core.1.gz.
This file is generally several decades of MB in size. You can copy the file from the path IP
address of the GBAM/GOMU\bsc6000\coredump.
----End
Context
NOTE
You can get other information about the GBAM/GOMU from the shared directory of the GBAM/GOMU.
Procedure
l To get the history operation information about the user, do as follows:
1. Start the Telnet client, such as PuTTY Software, on the PC. Enter the IP address of
the GBAM/GOMU, and then log in to the GBAM/GOMU as the root user.
2. Run the cp .bash_history /BSC6000/install command to copy the .bash_history file
to the shared directory of the GBAM/GOMU.
3. Visit the .bash_history file in the directory IP address of the GBAM/GOMU/users/
bsc6000/install to get the history operation information about the user.
l To get the information about the abnormal restart of the GBAM/GOMU, do as follows:
1. Start the Telnet client, such as PuTTY Software, on the PC. Enter the IP address of
the GBAM/GOMU, and then log in to the GBAM/GOMU as the root user.
2. Visit the core.********* file in the directory IP address of the GBAM/GOMU/
bsc6000/bscswm/omuroot to get the information about the abnormal restart of the
GBAM/GOMU.
NOTE
This file is generated automatically by the system when the OMU process is restarted
abnormally.
l To get the login information about the shared directory of the GBAM/GOMU, do as
follows:
1. Start the Telnet client, such as PuTTY Software, on the PC. Enter the IP address of
the GBAM/GOMU, and then log in to the GBAM/GOMU as the root user.
2. Run the cd /var/log/samba command to enter the /var/log/samba directory.
3. Run the cp log.smbd /BSC6000 command to copy the log.smbd file to the shared
directory of the GBAM/GOMU.
4. Visit the log.smbd file in the directory IP address of the GBAM/GOMU/users/
bsc6000 to get the login information about the shared directory of the GBAM/GOMU.
l To get the information about the Ethernet cards of the GBAM/GOMU, do as follows:
1. Start the Telnet client, such as PuTTY Software, on the PC. Enter the IP address of
the GBAM/GOMU, and then log in to the GBAM/GOMU as the root user.
2. Run the lspci | grep Ethernet command. After the result is displayed, capture it using
a relevant application, and save it for future use.
----End
Prerequisite
l The LMT runs properly.
l The communication between the BSC and the BTS is normal.
l The communication between the BSC and the MSC is normal.
Context
Two types of messages are available for tracing: signaling messages and user messages.
l Signaling messages
– The interface-related signaling messages involve those traced on the A interface, Abis
interface, Um interface, BSC_CBC interface, Pb interface for the external PCU, and Gb
interface for the built-in PCU.
– The link-related messages involve those traced on the BSSAP, SCCP, MTP2, MTP3,
SCTP, M3UA, RSL, OML, ESL, EML, and LAPD.
l User messages
The user messages are concerned with the continuity procedures and status of the user.
Procedure
For the detailed operations, refer to Configuring Message Tracing.
----End
Procedure
l Collect the TRACE file of the M2000 server.
1. Visit the directory IP address of the M2000 server/export/home/omc/var/logs
through FTP.
2. Find the TRACE file of the M2000, iMAP.XXXX.trace, in the previous directory.
The history TRACE files are saved in the tracebak folder of the same directory. Here,
XXXX indicates the name of an M2000 process.
NOTE
CAUTION
To obtain an interpretable TRACE file through FTP, set the FTP download mode to
binary.
You can get the TRACE file of the M2000 client from the installation directory of the
M2000 client, \client\tracefile.
NOTE
----End
Prerequisite
l The LMT runs properly.
l The communication between the LMT and the BSC is normal.
l The communication between the BSC and the BTS is normal.
Procedure
Step 1 On the BSC6000 Local Maintenance Terminal, choose BTS Maintenance > Monitor
Channel Status on the menu.
Step 2 In the displayed window, specify the Site, Cell, and TRX in the Operation Object. Then, click
Start. The channel status information is displayed, as shown in Figure 2-12.
Step 3 Use a relevant application to capture the result, and save it for future use.
----End
Prerequisite
l The LMT runs properly.
l The communication between the LMT and the BSC is normal.
Procedure
Step 1 On the BSC6000 Local Maintenance Terminal, choose BSC Maintenance > Maintain
Device > Query BSC Board Information on the menu. A dialog box is displayed, as shown
in Figure 2-13.
Step 2 In the Board Location area, specify the Subrack No., Board Type, and Slot No. of a board.
Then, on the Board Information tab page, click Query to get the bar code information about
the board.
Step 3 Use a relevant application to capture the result, and save it for future use.
----End
Procedure
l During the tuning phase, collect the information associated with noise and one-way audio
(including no audio and voice continuity) problems as follows:
– Check the number of noise occurrences during a call and the characteristics of the noise,
such as the clicking sound and the metal sound.
– Check whether the noise occurs regularly, say, every x seconds or every x minutes. If
the noise does not occur regularly, check whether the noise persists during the call.
– Check whether the amplitude of the noise is even, such as the volume fluctuation.
– Approximate the ratio of the noise amplitude to the normal voice strength.
– Check whether the noise is sharp than the voice.
– Check whether the symptom such as one-way audio, no audio, or voice discontinuity
occurs during the conversation. One-way audio means that only one party can hear the
voice from the other end of the line. No audio means both parties fail to hear the voice
from the peer. Voice discontinuity means that the voice is interrupted irregularly during
the conversation.
– The occurrences of the one-way audio are of the following types:
The one-way audio symptom occurs after the call is put through and persists during the
conversation (excluding the long call put-through failure). The one-way audio symptom
occurs after a period of normal conversation, and persists until the call is hanged up.
The one-way audio symptom also occurs after a period of normal conversation, and
then disappears.
l During the tuning phase, collect the information associated with the echo problem as
follows:
– Test place and BTS type
– Models and MSISDNs of the MSs that hear the echoes from the peer end
– Local echo volume (compared with the peer voice volume)
– Space condition of the peer MS (whether the MS is in a spacious place, near a wall, or
in a narrow room)
– Ambient environment of the peer MS (noisy or quiet)
– Peer volume fluctuation and the fluctuation of the echo heard by the local party
– Fluctuation of the echo heard by the local party once the speaker at the peer is blocked
– Fluctuation of the echo heard by the local party once the peer party is under an inter-
BTS handover
– Fluctuation of the echo heard by the local party once the peer party is under an inter-
BSC handover
– Whether the echo persists even through the peer party walks out of the room or its
ambient voice volume changes
----End
Prerequisite
l The PCUInfo application is running.
l The Telnet terminal is started.
l The FTP terminal is started.
Procedure
Step 1 Double-click PCUInfo.exe.
Step 2 On the PCUInfo, choose Capture > Capture on the menu. Figure 2-14 shows the PCUINFO
window.
Figure 2-15 Information items that can be connected through the PCUInfo
3. In the Alarm and DbgAlm text boxes, set the start date and end date, as shown in Figure
2-15.
NOTE
l The information in the PCU System Info and PCU Res Info areas is obtained through Telnet.
l The information in the FTP Files Setting area is obtained from the PCU hard disk through FTP.
Step 5 After obtaining the PCU information, click OK to save the PCU information to the sub-folder
in the PCU Info folder. The PCU information is named in the Info+the current date format, as
shown in Figure 2-17.
----End
Prerequisite
l The PCU LocalWS is started.
l The communication between the PCU LocalWS and the PCU is proper.
l The communication between the Telnet terminal and the PCU is proper.
Context
The signaling tracing of the PCU is performed on the PCU LocalWS. The interfaces consist of
the Um interface, Pb interface, and Gb interface.
Procedure
l Trace messages on the Um interface.
1. Start the PCU LocalWS. In the Maintenance window, choose Tracing > Um
Interface Tracing on the menu. A dialog box is displayed, as shown in Figure
2-18.
CAUTION
When tracing messages on the Um interface, you must clear the option Filter data
block.
2. Set the parameters. Create a task to trace the Um interface messages of the test cell.
NOTE
You can query the Cell No. and TRX No. by running the command mt pdch show attr
LCNo all in the Telnet terminal.
l Trace messages on the Pb interface.
1. Start the PCU LocalWS. In the Maintenance window, choose Tracing > Pb
Interface Tracing on the menu. A dialog box is displayed, as shown in Figure
2-19.
CAUTION
When tracing the messages on the Pb interface, click all the check boxes.
2. Set the parameters. Create a task to trace the Pb interface messages of the test cell.
NOTE
The Cell No. must be the same as that specified in the Um interface tracing.
l Trace the Gb interface (BSSGP CELL) signaling messages.
1. Start the PCU LocalWS. In the Maintenance window, choose Tracing > BSSGP
Cell Message Tracing on the menu. A dialog box is displayed, as shown in Figure
2-20.
2. Specify the Cell ID. Create a task to trace on the Gb interface the BSSGP cell
information messages of the test cell.
NOTE
You can query the Cell ID by running the command pcu show lcc LCNo in the Telnet terminal.
l Trace the Gb interface (BSSGP SIG) messages.
1. Start the PCU LocalWS. In the Maintenance window, choose Tracing > BSSGP
Signaling Message Tracing on the menu. A dialog box is displayed, as shown in
Figure 2-21.
2. Specify the NSEI. Create a task to trace on the Gb interface the BSSGP messages of
the test cell.
NOTE
You can query the NSEI by running the command Cell show CellID in the Telnet terminal.
l Save signaling messages.
1. After creating the tracing tasks on the Um, Pb, and Gb interfaces, save the messages
traced on the interfaces.
2. You should trace the signaling on the three interfaces simultaneously. After the test,
save the signaling tracing messages as a .gmt file. If the .gmt file is too large, you
should compress it into a .rar file.
----End
3 Common Faults
This describes the methods of troubleshooting common faults. Through these methods, you can
determine the class, subclass, or specific location of a fault.
Possible Causes
The possible causes of one-way audio or no audio are as follows:
Procedure
Step 1 On the BSC6000 Local Maintenance Terminal, perform a remote loopback on the speech
channel during a call. Here, set MSISDN to the called number and Loop Location to GE(O)
IUA. For detailed operations, refer to Looping Back Remote Speech Channel.
l If the Loop Direction is To BTS, you can infer that the speech channel on the BSC side is
operational if you (the calling party) can hear your own voice through the MS.
l If the Loop Direction is To MSC, you can infer that the speech channel on the MSC side
is operational if you (the calling party) can hear your own voice through the MS.
l If the fault occurs on the BSC side, go to Step 2; otherwise, go to Step 3 and Step 4.
Step 2 During a call, test the internal speech channel on the BSC6000 Local Maintenance
Terminal to check whether the TDM switching on the GTNU is normal. For detailed operations,
refer to Testing the Internal Speech Channel.
l If normal, go to Step 3.
l If abnormal, contact the Huawei Customer Service Center by referring to 1.3.1 Obtaining
Technical Support.
Step 3 During a call, check the speech channel resources on the BSC6000 Local Maintenance
Terminal by referring to Querying the Resources of An MS. The resources include the boards,
ports, and timeslots that carry the Abis, Ater, TC, and ACIC resources.
Step 4 Based on the ACIC information obtained in Step 3, check whether the configuration of the ACIC
port on the BSC side is consistent with that on the MSC side and whether the physical connection
is consistent with the configuration.
Step 5 Based on the Ater resource information obtained in Step 3, check whether there are cross
connections on the Ater interface and whether the physical connection is consistent with the
configuration.
Step 6 Based on the Ater resource information obtained in Step 3, check whether the Ater timeslots for
the speech channel are used for other purposes.
Step 7 Check whether an alarm about the speech channel is reported. If such an alarm is reported,
perform the corresponding processing by referring to Table 3-1.
Step 8 If the fault persists, contact the Huawei Customer Service Center by referring to 1.3.1 Obtaining
Technical Support.
----End
Possible Causes
The possible causes of bit errors that lead to noises are as follows:
l Grounding fault
l Radio link interference
l Clock fault
l Mismatching between the settings of DIP switch on the DTMU of the BTS and the actual
type (75 ohms or 120 ohms) of the transmission cable
Procedure
Step 1 If an alarm is reported, perform the corresponding analysis and processing by referring to Table
3-2.
Only within the coverage of a Make test calls by using the l For a frequency problem,
BTS MS to determine the specific check the status of the
location, such as a timeslot, a TRX.
frequency, or the entire l For a BTS problem,
coverage of the BTS. check the transmission
lines within the BTS.
Step 3 If the alarm persists, perform the corresponding analysis and locate the fault by referring to
Table 3-4.
Noises and voices are Error bits on the Error bits exist on the MSC
transmitted at the same time transmission lines affect the side.
in superimposition-like sample values of PCM.
format. Between them, noises
are not fluctuated greatly.
Some words cannot be heard Compressed voice signals Error bits exist within the
clearly. There are some must be decompressed BSC. Rectify the fault based
abnormal sounds such as the before being sent to the on the specific symptom and
bubble sound, clicking sound, receiver. The the corresponding rectification
and metal sound. decompression leads to method.
greatly fluctuated noises.
Step 4 Check whether the settings of the DIP switch on the DTMU of the BTS are consistent with the
type (75 ohms or 120 ohms) of the transmission cable.
Step 5 If the fault persists, contact the Huawei Customer Service Center by referring to 1.3.1 Obtaining
Technical Support.
----End
Fault Symptoms
In cross connection, the E1/T1 port can receive signals from the physical layer and no alarm is
generated, but the signals are sent by a wrong E1/T1 port at the peer end. Therefore, the upper-
level links are broken. Figure 3-1 shows the cross connection.
Correct connection
Cross connection
Detection Methods
There are two methods to detect cross connection faults, namely, loopback detection and alarm-
based detection.
l Loopback detection
Perform loopback on the remote E1/T1 port, and then check the data consistency between
the TX port and the RX port that are connected by the E1/T1 cables.
– If the data is consistent between the TX port and the RX port, the E1/T1 cables are
connected correctly.
– If the data is inconsistent between the TX port and the RX port, the E1/T1 cables are
cross-connected.
The loopback detection is of two types, remote loopback and physical loopback.
– Remote loopback applies when the GMPS/GEPS is directly connected to the GTCS
through the E1/T1 cables. In this scenario, you can run MML commands to perform
remote loopback on the remote E1/T1 ports.
– Physical loopback applies when the devices are connected through the DDF. In this
scenario, you can short-circuit the RX/TX ports on the DDF for the E1/T1 cables by
using conversion connectors to form a self-loop.
CAUTION
Physical loopback detection is applied to only the ports that carry the Ater OM links.
The loopback detection is performed during site deployment or upgrade. The advantage of
loopback detection is that ports can be detected in batches and faults in cross connections
can be located effectively. The disadvantage of loopback detection is that physical or remote
loopback must be performed on the DDF or remote E1/T1 port.
l Alarm-based detection
Disable the transmit function of the local E1/T1 port to enable the remote port to generate
the alarm 20081 Loss of E1/T1 Signals (LOS), and then add the Remote Alarm Indication
(RAI) to the alarm.
– If the E1/T1 cables are connected correctly, the local E1/T1 port can receive the RAI.
– If the E1/T1 cables are connected incorrectly, the local E1/T1 port does not generate
any alarm.
The alarm-based detection is used to locate the fault when one-way audio occurs during
site maintenance, or when loopback cannot be performed during site deployment. The
advantage of alarm-based detection is that loopback is not performed on the remote E1/T1
ports. The disadvantage of alarm-based detection is that you can only check whether the
E1/T1 cables are connected correctly but cannot acquire port information or detect the ports
in batches.
Restrictions
The restrictions of cross connection are as follows:
l Only the E1/T1 ports on the EIUa can be detected, but the optical ports on the OIUa cannot
be detected.
l Only whether cross connection exists can be detected, but the fact that both TX and RX
ports are cross-connected, as shown in Figure 3-2, cannot be detected.
RX Port TX Port
E1/T1 B E1/T1 B
TX Port RX Port
l If the E1/T1 cables are wrongly connected and the RX and TX ports on the DDF form a
self-loop, the loopback detection cannot find out whether cross connection exists.
l If the boards are in active/standby mode, the cross connection detection can be performed
only on the active board instead of the standby board.
l When the E1/T1 interface board works in active/standby mode, the alarm-based detection
requires the Y-shaped E1/T1 cables.
l The local E1/T1 ports to be detected have no alarms generated.
l No loopback is performed on the local E1/T1 ports to be detected.
l If the loopback detection is used, it must be performed on the remote E1/T1 port.
l If the alarm-based detection is used, you must ensure that no loopback is performed on the
remote E1/T1 port.
l The loopback detection supports the single-port test and board test, whereas the alarm-
based detection supports only the single-port test. Neither detection can be used to
simultaneously test multiple ports on a board or simultaneously test multiple boards.
Procedure
For details of how to perform loopback detection and alarm-based detection, refer to Check E1/
T1 Cross Connection(CHK E1T1CRS). Figure 3-3 shows the interface.
CAUTION
l Cross connection detection may disrupt the service temporarily. It is recommended that you
test cross connection during site deployment or upgrade.
l You cannot run the commands for testing cross connection repeatedly. Instead, you must run
another command after the previous test is completed.
----End
4 Link Faults
This describes link faults in terms of the symptoms, troubleshooting methods, and typical cases.
OML/EML Faults
When the operation and maintenance link (OML) or extended maintenance link (EML) is faulty,
neither voice services nor data services can be provided for the MSs in the coverage of the BTS.
RSL/ESL Faults
When the radio signaling link (RSL) or extended signaling link (ESL) is faulty, the impacts are
as follows:
l If the BCCH TRX is faulty and the TRX aid function is not configured, neither voice
services nor data services can be provided for the MSs in the cell.
l If a non-BCCH TRX is faulty, neither voice services nor data services can be provided for
the MSs occupying the TRX channel.
PBSL Faults
When the PCU is configured outside the BSC, the impacts of PCU-BSC signaling links (PBSLs)
are as follows:
l When all the PBSLs are faulty, data services cannot be provided for the MSs controlled by
the BSC.
l When some PBSLs are faulty, the capacity of data services of the BSC decreases.
l When all the SS7 signaling links break down, all the MSs drop calls.
l When some SS7 signaling links break down, the loads on other SS7 signaling links increase
but not all the MSs drop calls.
l When all the Ater signaling links break down, all the MSs drop calls.
l When some Ater signaling links break down, the loads on other links increase but not all
the MSs drop calls.
l When all the SIGTRAN links break down, all the MSs drop calls.
l When some SIGTRAN links break down, the loads on other SIGTRAN links increase but
not all the MSs drop calls.
Table 4-3 Alarms related to the external PCU interface link faults
Fault Type Alarm Name
E1/T1 fault or optical port fault 20081 Loss of E1/T1 Signals (LOS)
Counter Description
Counter Description
Procedure
Step 1 Deal with the reported alarm according to the alarm help.
Step 2 If the alarm persists, determine the subclass of the fault and take the corresponding measure, as
listed in Table 4-5.
Step 3 If the fault persists, contact the Huawei Customer Service Center by referring to 1.3.1 Obtaining
Technical Support.
----End
Fault Symptoms
The State of an OML is Failure, which you can check on the BSC6000 Local Maintenance
Terminal by referring to Maintaining LAPD Links. An alarm 1000 LAPD OML Fault is
reported. Multiple cells are out of service. Neither voice services nor data services can be
provided for the MSs in the coverage of the BTS.
Possible Causes
The possible causes of OML faults are as follows:
Procedure
Step 1 On the BSC6000 Local Maintenance Terminal, view the alarm information.
l Check whether a power-off alarm exists. If existent, rectify the fault by referring to 4.1.2
Alarms Related to Link Faults.
l Check whether an E1/T1 transmission alarm exists. If existent, rectify the fault by referring
to 4.2.9 Troubleshooting E1/T1 Transmission Faults.
l If no such an alarm exists, go to Step 2.
Step 2 By referring to Querying BTS Board Information, check whether the BTS main control board
is faulty.
l If faulty, rectify the fault by referring to 4.1.2 Alarms Related to Link Faults.
l If not faulty, go to Step 3.
Step 3 By referring to Querying the Status of an Interface Board Port, check whether the E1/T1 port
in connection with the BTS is faulty.
l If faulty, rectify the fault by referring to 4.1.2 Alarms Related to Link Faults.
l If not faulty, go to Step 4.
Step 4 By referring to Querying BSC Board Information, check whether the GEIUB/GOIUB,
GXPUT, and GXPUM are faulty.
l If faulty, rectify the fault by referring to 4.1.2 Alarms Related to Link Faults.
l If not faulty, go to Step 5.
Step 5 Check the configured BTS type.
1. On the BSC6000 Local Maintenance Terminal, click the corresponding TRX on the
Management Tree tab page.
2. In the Site Description area on the Site Device Panel tab page, check whether the
configured Site Type is consistent with the actual one.
l If inconsistent, remove this BTS and then reconfigure it by referring to Configuring
the BTS.
l If consistent, go to Step 6.
Step 6 Check the number of the E1/T1 port in connection with the BTS.
1. On the BSC6000 Local Maintenance Terminal, click the corresponding TRX on the
Management Tree tab page.
2. In the Site Description area on the Site Device Panel tab page, check whether the GEIUB
Subrack No., GEIUB Slot No., and GEIUB Port No. are consistent with the actual ones.
l If the settings are incorrect, move the BTS by referring to . Alternatively, connect the
corresponding port on the DDF and the configured port.
l If the settings are correct but the fault persists, contact the Huawei Customer Service
Center by referring to 1.3.1 Obtaining Technical Support.
----End
Fault Symptoms
On the BSC6000 Local Maintenance Terminal, the query result shows that the State of an
EML is Failure. For details, refer to Maintaining LAPD Links. The alarms 1000 LAPD OML
Fault and 11270 LAPD Alarm are reported. Multiple cells are out of service. Neither voice
services nor data services can be provided for the MSs in the coverage of the BTS.
Possible Causes
The possible causes of the EML fault are as follows:
l The GEHUB board is faulty.
l The GXPUT is faulty.
l The GXPUM is faulty.
l The configured BTS type is inconsistent with the actual BTS type.
l The port configured for the BTS is inconsistent with the actual one.
l The BTS main control board is faulty.
l The BTS is not powered.
l The BTS has a transmission failure.
Procedure
Step 1 On the BSC6000 Local Maintenance Terminal, view the alarm information.
l Check whether a power-off alarm exists. If existent, rectify the fault by referring to 4.1.2
Alarms Related to Link Faults.
l Check whether an E1/T1 transmission alarm exists. If existent, rectify the fault by referring
to 4.2.9 Troubleshooting E1/T1 Transmission Faults.
l If not existent, go to Step 2.
Step 2 Check whether the BTS board is faulty by referring to Querying BTS Board Information.
l If faulty, rectify the fault by referring to 4.1.2 Alarms Related to Link Faults.
l If not faulty, go to Step 3.
Step 3 By referring to Querying the Status of an Interface Board Port, check whether the E1/T1 port
in connection with the BTS is faulty.
l If faulty, rectify the fault by referring to 4.1.2 Alarms Related to Link Faults.
l If not faulty, go to Step 4.
Step 4 Check whether the GEHUB, GXPUT, and GXPUM are faulty by referring to Querying BSC
Board Information.
l If faulty, rectify the fault by referring to 4.1.2 Alarms Related to Link Faults.
l If not faulty, go to Step 5.
Step 5 Check the configured BTS type.
1. On the BSC6000 Local Maintenance Terminal, click the corresponding TRX on the
Management Tree tab page.
2. In the Site Description area on the Site Device Panel tab page, check whether the
configured Site Type is consistent with the actual one.
l If inconsistent, remove this BTS and then reconfigure it by referring to Configuring
the BTS.
l If consistent, go to Step 6.
Step 6 Check the number of the E1/T1 port in connection with the BTS.
1. On the BSC6000 Local Maintenance Terminal, click the corresponding TRX on the
Management Tree tab page.
2. In the Site Description area on the Site Device Panel tab page, check whether the GEHUB
Subrack No., GEHUB Slot No., and GEHUB Port No. are consistent with the actual
ones.
l If inconsistent, move the BTS by referring to . Alternatively, connect the DDF cable to
the data configuration port.
l If consistent, go to Step 7.
Step 7 On the BSC6000 Local Maintenance Terminal, browse the HDLC path data in the BTS data,
and check whether 31 timeslots are configured for the HDLC path. For details, refer to Browsing
Configuration Data.
l If the number of configured timeslots is not 31, reconfigure this BTS. For details of
configuring timeslots, refer to Timeslots on the Abis Interface.
l If the number of configured timeslots is 31 but the fault persists, contact the Huawei
Customer Service Center by referring to 1.3.1 Obtaining Technical Support.
----End
Fault Symptoms
The RSL fault symptoms are as follows:
l The State of an RSL is Failure, which you can check on the BSC6000 Local Maintenance
Terminal by referring to Maintaining LAPD Links.
l On the BSC6000 Local Maintenance Terminal, the Cabinet area of the Site Device
Panel shows that the TRX board is faulty.
l On the BSC6000 Local Maintenance Terminal, an alarm 2204 TRX Communication
Alarm or 405 Cell Out of Service is reported. Neither voice services nor data services can
be provided for the MSs in the cell.
NOTE
When the BCCH TRX is faulty, the TRX aid function works. TRX aid can take effect only when it is
configured for the cell. For detailed operations, refer to Configuring TRX Cooperation.
Possible Causes
The possible causes of RSL faults are as follows:
Procedure
Step 1 On the BSC6000 Local Maintenance Terminal, view the alarm information.
l If a TRX fault alarm such as 2204 TRX Communication Alarm is reported, rectify the
fault by referring to 4.1.2 Alarms Related to Link Faults.
l If no such an alarm is reported, go to Step 2.
Step 2 Check the status of the involved links by referring to Maintaining LAPD Links.
l If the OML is faulty, rectify the fault by referring to 4.2.1 Troubleshooting OML
Faults.
l If the RSL is faulty, go to Step 3.
Select the TRX from the Assigned TRXs area, and then check whether the corresponding
frequency in the Frequencies area is consistent with that supported by the TRX.
l If the setting is incorrect, replace the TRX board or modify the frequency. For details
about how to modify frequencies, refer to Configuring the Multiband Network.
l If the setting is correct but the fault persists, contact the Huawei Customer Service
Center by referring to 1.3.1 Obtaining Technical Support.
----End
Fault Symptoms
On the BSC6000 Local Maintenance Terminal, query the status of the LAPD link. The result
shows that the State of the ESL is Failure. For details, refer to Maintaining LAPD Links. An
alarm 2114 LAPD Alarm is reported. Multiple cells are out of service and neither voice services
nor data services can be provided for all the MSs in the coverage of the BTS.
Possible Causes
The possible causes of the ESL faults are as follows:
Procedure
Step 1 On the BSC6000 Local Maintenance Terminal, view the alarm information.
l Check whether the TRX fault-related alarms such as 2204 TRX Communication Alarm
exist. If existent, rectify the fault by referring to 4.1.2 Alarms Related to Link Faults.
l If not existent, go to Step 2.
Step 2 Check whether the GEHUB/GFGUB board is faulty by referring to Querying BSC Board
Information.
l If faulty, rectify the fault by referring to 4.1.2 Alarms Related to Link Faults.
l If not faulty, go to Step 3.
Step 3 Check whether the cable is correctly connected to the E1 port on the DPTU board. The correct
way is to connect the E1 cable at the top of the cabinet to the E1 port on the DPTU board.
l If the cable is connected incorrectly, reconnect the cable in the correct way as mentioned
previously.
l If the cable is connected correctly, go to Step 4.
Step 4 Check whether the DPTU board is inserted in a correct slot. The correct location is slot 3 or 4
of subrack 0.
l If the board is inserted in a wrong slot, reinsert the board in the correct location as mentioned
previously.
l If the board is inserted correctly but the fault persists, contact the Huawei Customer Service
Center by referring to 1.3.1 Obtaining Technical Support.
----End
Fault Symptoms
The State of a PBSL is Failure, which you can check on the BSC6000 Local Maintenance
Terminal by referring to Maintaining LAPD Links.
Possible Causes
The possible causes of PBSL faults are as follows:
l The GEIUB/GOIUB is faulty.
l The GXPUM is faulty.
l A transmission fault occurs.
l The E1 frame format on the external PCU side is inconsistent with that on the BSC side.
l The timeslot configured on the BSC side is inconsistent with that configured on the external
PCU side.
Procedure
Step 1 By referring to Querying BSC Board Information, check whether the GEIUB/GOIUB and
GXPUM in connections with the BTS are faulty.
l If faulty, rectify the fault by referring to 4.1.2 Alarms Related to Link Faults.
l If not faulty, go to Step 2.
Step 2 By referring to Querying the Status of an Interface Board Port, check whether E1/T1 port of
the PBSL is faulty.
l If faulty, rectify the fault by referring to 4.1.2 Alarms Related to Link Faults.
l If not faulty, go to Step 3.
Step 3 Check the Port Attributes in the Configure Board Attributes dialog box of the GEIUP/
GOIUP. Set the Frame Format to DOUBLE_FRAME.
NOTE
On the PCU LocalWS, check the Signaling Link Timeslot No. on the PCU side by running
the pcu show e1slot command.
l Check the Timeslot No. of the PBSL on the BSC side.
1. On the Management Tree tab page of the BSC6000 Local Maintenance Terminal,
right-click the root node BSC6000, and then click the BSC Attributes tab. The tab page
is displayed, as shown in Figure 4-4.
2. Click PCU in the Other Data area. In the displayed dialog box, click the Pb Signaling
Link tab, as shown in Figure 4-5.
l If the configured timeslot number is inconsistent with the actual one, change the Timeslot
No. of the PBSL on the BSC6000 Local Maintenance Terminal or PCU LocalWS.
l If consistent, go to Step 5.
Step 5 On the PCU LocalWS, check the status of the PBSL link and perform the corresponding
operations.
1. Run the command mt lapd show state {<BoardNo> all}|<LapdNo>|<LapdName> to
check the status of the PBSL.
l If the administrative status of the PBSL is Blocked, run the command mt lapd unblock
{<BoardNo> all}|<LapdNo>|<LapdName> to unblock the PBSL. The PBSL should
be restored to the Enabled state. If not restored, go to Step 5.2.
l If the administrative status of the PBSL is Unblocked, end the troubleshooting.
2. Run the command Mt lapd port show state <BoardNo> <HLPU/L2PUNo> to check the
status of the port on the L2PU/HLPU that carries the PBSL.
l If the LoopMode of the port carrying the PBSL is local loopback or remote loopback,
run the command mt lapd port loop set <BoardNo> <PortNo> <LoopMode> to set
LoopMode to NoLoop. The status of the PBSL should be restored to ENABLED. If
not restored, go to Step 5.3.
l If the LoopMode of the port carrying the PBSL is NoLoop, end the troubleshooting.
3. Rectify the PBSL fault by referring to 9.2.5 Troubleshooting LAPD Link Faults
(External PCU).
----End
Fault Symptoms
The fault symptoms of SS7 signaling links are as follows:
l The Destination signaling point state of an SCCP link is Prohibit, which you can check
on the BSC6000 Local Maintenance Terminal by referring to Maintaining the SCCP.
l The Service Transmit of an MTP3 link is Not using, which you can check on the BSC6000
Local Maintenance Terminal by referring to Maintaining MTP3 Links.
l The Link State of an MTP2 link is Start Locating, which you can check on the BSC6000
Local Maintenance Terminal by referring to Querying Status of MTP2 Links.
l An alarm 21525 SCCP DSP Unreachable or 21501 MTP3 DSP Unreachable is reported,
which you can check on the BSC6000 Local Maintenance Terminal. The ongoing
services are disrupted.
l The alarm 21514 MTP2 Link Service Disrupted is cleared immediately after it is
generated. Intermittence may lead to call drops.
Possible Causes
The possible causes of SS7 signaling link faults are as follows:
Procedure
l If the SS7 signaling link is not operational, do as follows:
1. By referring to Querying BSC Board Information, check whether the GXPUM,
GEIUT/GOIUT, and GEIUA/GOIUA that carry the SS7 signaling link are faulty.
– If faulty, rectify the fault by referring to 4.1.2 Alarms Related to Link Faults.
– If not faulty, go to Step 2.
2. On the BSC6000 Local Maintenance Terminal, click the BSC Attributes tab. In
the Other Data area, click SS7 Signaling Point. A dialog box is displayed, as shown
in Figure 4-6.
3. Check whether the settings of OPC, Encoding Scheme, Network Indicator, and
DPC are consistent with those on the MSC side.
– If inconsistent, delete the settings and then reconfigure the parameters by referring
to Configuring the SS7 Signaling Points.
– If consistent, go to Step 4.
4. On the BSC6000 Local Maintenance Terminal, click the BSC Attributes tab. In
the Other Data area, click SS7 Signaling Link. A dialog box is displayed, as shown
in Figure 4-7.
5. Check whether the settings of A Timeslot Mask, SLC, and SLC Send are consistent
with those on the MSC side.
– If inconsistent, delete the settings and then reconfigure the parameters by referring
to Adding an SS7 Signaling Link.
– If consistent, go to Step 6.
6. By referring to Querying the Status of an Interface Board Port, check whether the
E1/T1 port that resides on the A interface and carries the SS7 signaling link is faulty.
– If faulty, rectify the fault by referring to 4.1.2 Alarms Related to Link Faults.
– If not faulty, go to Step 7.
7. By referring to Querying the Status of an Interface Board Port, check whether the
E1/T1 port that resides on the Ater interface and carries the SS7 signaling link is faulty.
If faulty, rectify the fault by referring to 4.1.2 Alarms Related to Link Faults.
l If the SS7 signaling link breaks down, do as follows:
1. By referring to Querying BSC Board Information, check whether the GXPUM,
GEIUT(GOIUT), and GEIUA(GOIUA) that carry the SS7 signaling link are faulty.
– If faulty, rectify the fault by referring to 4.1.2 Alarms Related to Link Faults.
– If not faulty, go to Step 2.
2. By referring to Querying the Status of an Interface Board Port, check whether the
E1/T1 port that resides on the A interface and carries the SS7 signaling link is faulty.
– If faulty, rectify the fault by referring to 4.1.2 Alarms Related to Link Faults.
– If not faulty, go to Step 3.
3. By referring to Querying the Status of an Interface Board Port, check whether the
E1/T1 port that resides on the Ater interface and carries the SS7 signaling link is faulty.
If faulty, rectify the fault by referring to 4.1.2 Alarms Related to Link Faults.
l If the SS7 signaling link is disconnected intermittently, do as follows:
1. On the BSC6000 Local Maintenance Terminal, check whether there is an alarm
21514 MTP2 Link Service Disrupted that is cleared immediately after it is generated.
– If there is, rectify the fault by referring to 4.1.2 Alarms Related to Link Faults.
– If the fault persists, go to Step 2.
2. If the fault persists, contact the Huawei Customer Service Center by referring to 1.3.1
Obtaining Technical Support.
----End
Fault Symptoms
Check the status of the Ater signaling links on the Local Maintenance Terminal. For details,
refer to List LAPD Link(LST LAPDLNK) and List Ater Signaling Link(LST ATERSL).
On the BSC6000 Local Maintenance Terminal, by querying the alarm information you can
find that the 21002 Broken LAPD Link alarm is reported.
Possible Causes
The possible causes of the faults in Ater signaling links are as follows:
l In BM/TC separated mode, the GEIUT/GOIUT in the GMPS or remote GTCS is faulty.
l A transmission fault occurs on the Ater interface.
Procedure
Step 1 Check whether the GEIUT/GOIUT that carries the Ater signaling links is faulty. For details,
refer to Querying BSC Board Information.
l If faulty, rectify the fault by referring to 4.1.2 Alarms Related to Link Faults.
l If not faulty, go to Step 2.
Step 2 Check whether the E1/T1 port that carries the Ater OM links is faulty. For details, refer to
Querying the Status of an Interface Board Port. If faulty, rectify the fault by referring to
4.1.2 Alarms Related to Link Faults.
----End
Fault Symptoms
The Available Status of some or all HDLC links is Not available, which you can check on the
BSC6000 Local Maintenance Terminal by referring to Querying the Status of the Ater
OML. In addition, an alarm 21551 Ater OML Broken Alarm is reported. If all the Ater OMLs
break down, no operation or maintenance for the remote subracks can be performed.
Possible Causes
The possible causes of Ater OML link faults are as follows:
l In BM/TC separated mode, the GEIUT/GOIUT in the GMPS or remote GTCS is faulty.
l A transmission fault occurs on the Ater interface.
Procedure
Step 1 By referring to Querying BSC Board Information, check whether the GEIUT/GOIUT carrying
the Ater OML is faulty.
l If faulty, rectify the fault by referring to 4.1.2 Alarms Related to Link Faults.
l If not faulty, go to Step 2.
Step 2 By referring to Querying the Status of an Interface Board Port, check whether the E1/T1 port
of the Ater OML is faulty. If faulty, rectify the fault by referring to 4.1.2 Alarms Related to
Link Faults.
----End
Fault Symptoms
On the BSC6000 Local Maintenance Terminal, the query result shows that Port Status of the
E1/T1 port is Fault. For details of how to browse the alarm information, refer to Querying the
Status of an Interface Board Port. The following alarms are reported:
l 20081 Loss of E1/T1 Signals (LOS)
l 20082 Loss of E1/T1 Frames (LOF)
l 20083 Remote E1/T1 Alarm (RAI)
l 20084 E1/T1 Alarm Indication Signal (AIS)
l 20085 Loss of E1/T1 Multiframes (LOM)
l 20086 E1/T1 Link Loopback
l 20087 High BER over the E1/T1 Link
l 20089 Excessive Loss of E1/T1 Signals in an Hour
Possible Causes
The possible causes of the E1/T1 transmission faults are as follows:
l The DB44 connector of the E1/T1 cable is not securely connected to the panel of the
interface board.
l The transmission cable is wrongly connected.
l The E1/T1 port on the local device cannot receive signals normally.
l The E1/T1 port on the peer device cannot transmit signals normally.
l The line codes are inconsistent between lines.
l The subrack is not properly grounded.
l The shielding layer of the cable between the BSC and the transmission equipment is
damaged.
l The transmission line is faulty.
Procedure
Rectify the faults according to the alarm-handling suggestions. If the faults persist, contact the
Huawei Customer Service Center by referring to 1.3.1 Obtaining Technical Support.
----End
Fault Symptoms
On the BSC6000 Local Maintenance Terminal, the query result shows that Port Status of the
E1/T1 port is Fault. For details, refer to Querying the Status of an Interface Board Port. The
following alarms are reported:
l 20222 Loss of Signals on the Optical Port (RLOS)
l 20223 Loss of Received Signal Frames on the Optical Port (RLOF)
l 20224 Out-of-Synchronization of Received Signal Frames on the Optical Port (ROOF)
l 20225 Mismatch of Trace Byte of the Regenerator Section on the Optical Port (RTIM)
l 20228 Multiplex Section Alarm Indication Signal (MAIS)
l 20227 Regenerator Section Signal Deteriorated (RSD)
l 20228 Multiplex Section Alarm Indication Signal (MAIS)
l 20229 Multiplex Section Remote Defect Indication (MRDI)
Possible Causes
The possible causes of optical transmission faults are as follows:
Procedure
Rectify the faults according to the alarm-handling suggestions. If the faults persist, contact the
Huawei Customer Service Center by referring to 1.3.1 Obtaining Technical Support.
----End
Fault Symptoms
The M3UA link fault symptoms are as follows:
l On the BSC6000 Local Maintenance Terminal, check the status of SCCP connections.
The result shows that the Destination signaling point state of an SCCP connection is
Prohibited. For details, refer to Maintaining the SCCP.
l On the Local Maintenance Terminal, check the status of M3UA links. The result shows
that the Link State of an M3UA link is the non-activated or invalid state. For details, refer
to Display M3UA Link Status(DSP M3LNK).
l On the BSC6000 Local Maintenance Terminal, an alarm 701 M3UA Link Fault or
possibly 21525 SCCP DSP Unreachable and 704 M3UA Destination Entity
Unvailably are reported. The ongoing services are disrupted.
Possible Causes
The possible causes of M3UA link faults are as follows:
l The links are manually disconnected or deactivated.
l The SCTP link configuration is inconsistent between the BSC and the MSC.
l The router to the BSC is wrongly configured.
Procedure
Step 1 Check whether the GXPUM, GXPUT, and GFGUA that carry the M3UA links are faulty by
referring to Querying BSC Board Information.
l If faulty, check whether the board type is consistent with the data configuration and whether
the board is securely connected.
l If not faulty, go to Step 2.
Step 2 Check whether the parameter configuration related to M3UA links is consistent between the
BSC and the MSC.
1. On the BSC6000 Local Maintenance Terminal, right-click the GFGUA board on the
BSC Device Panel tab page, and then choose Configure M3UA Link > Modify M3UA
Link.
2. A dialog box is displayed. Click Modify.
3. Select the M3UA tab, as shown in Figure 4-8.
Check whether the parameters such as Local Port No., Local Address 1, Local Address 2,
Peer Port No., Peer Address 1, and Peer Address 2 on the BSC side are consistent with those
on the MSC side.
l If inconsistent, delete the original parameter settings and reconfigure the parameters.
l If consistent, go to Step 3.
Step 3 Verify whether the SCTP check and algorithm on the BSC side are consistent with those on the
MSC side.
Refer to Step 2. On the interface shown in Figure 4-8, select the SCTP tab page, as shown in
Figure 4-9.
Check whether the parameters such as Receive Check Sum Validation Flag, Send Check Sum
Validation Flag, and Check Sum Type on the BSC side are consistent with those on the MSC
side.
l If inconsistent, reconfigure the parameters to keep them consistent with those on the MSC
side.
l If consistent, go to Step 4.
Step 4 On the Local Maintenance Terminal, run the PING IP command to ping the IP address of the
remote MSC. Check whether the IP address can be pinged by referring to Ping Peer IP Address
(PING IP).
l If the IP address cannot be pinged, check whether the route from the BSC to the MSC is
normal. If the route is faulty, contact the Huawei Customer Service Center by referring to
1.3.1 Obtaining Technical Support.
l If the IP address can be pinged, on the peer MSC side ping the device IP address of the local
BSC. If the device IP address cannot be pinged, go to Step 5.
Step 5 Check the route configuration on the router connected to the BSC. Verify whether there is a
route to the GFGUA and ensure no redundant route configuration exists.
l If there is no route to the GFGUA, add a valid route by referring to step 5 described in
Configuring the GFGUA/GOGUA.
l If there is a route to the GFGUA and no redundant route configuration but the fault persists,
contact the Huawei Customer Service Center by referring to 1.3.1 Obtaining Technical
Support.
----End
are unavailable, or only the load on the available routes increases and the MSs incur no call
drops if some of the M3UA routes are unavailable.
Fault Symptoms
The fault symptoms of M3UA route unavailability are as follows:
l On the BSC6000 Local Maintenance Terminal, check the status of SCCP connections.
The result shows that the Destination signaling point state of an SCCP connection is
Prohibited. For details, refer to Maintaining the SCCP.
l On the Local Maintenance Terminal, check the status of M3UA routes. The result shows
that the Access Flag of an M3UA route is Unaccessible. For details, refer to Display M3UA
Route Status(DSP M3RT).
l On the BSC6000 Local Maintenance Terminal, an alarm 703 M3UA Route
Unvailable or possibly 21525 SCCP DSP Unreachable and 704 M3UA Destination
Entity Unvailably are reported. The ongoing services are disrupted.
Possible Causes
The possible causes of M3UA route unavailability are as follows:
Procedure
Step 1 Check whether the M3UA link is faulty.
l If faulty, rectify the fault by referring to 4.2.11 Troubleshooting M3UA Link Faults.
l If not faulty, go to Step 2.
Step 2 Check whether the BSC is connected to the MSC through an STP entity.
l If the BSC is connected to the MSC through an STP entity, check whether the link and the
route between STP and MSC is available.
l If the BSC is directly connected to the MSC with the link activated but the fault persists,
contact the Huawei Customer Service Center by referring to 1.3.1 Obtaining Technical
Support.
----End
Fault Symptoms
The fault symptoms of M3UA destination entity inaccessibility are as follows:
l On the BSC6000 Local Maintenance Terminal, check the status of SCCP connections.
The result shows that the Destination signaling point state of an SCCP connection is
Prohibited. For details, refer to Maintaining the SCCP.
l On the Local Maintenance Terminal, check the status of M3UA destination entities. The
result shows that the Access Flag of an M3UA destination entity is Unaccessible. For
details, refer to Display M3UA Destination Entity Status(DSP M3DE).
l On the BSC6000 Local Maintenance Terminal, view the alarm information. The alarms
704 M3UA Destination Entity Unvailably, 21525 SCCP DSP Unreachable, and 701
M3UA Link Fault are reported.
Possible Causes
The possible causes of M3UA destination entity inaccessibility are as follows:
l The M3UA link is faulty.
l The M3UA destination entity does not exist.
Procedure
Step 1 Check whether the M3UA link is faulty.
l If faulty, rectify the fault by referring to 4.2.11 Troubleshooting M3UA Link Faults.
l If not faulty, go to Step 2.
Step 2 Check whether the configuration data of the M3UA destination entity is correct.
1. On the Management Tree tab page of the BSC6000 Local Maintenance Terminal, right-
click BSC6000 and choose Configure M3UA Data > Configure M3UA Entity.
2. Select the M3UA DE tab, as shown in Figure 4-10.
Check whether the DPC(Hex) on the BSC side is consistent with the DCP on the MSC side.
l If the DPC is inconsistent, delete the M3UA destination entity on the BSC side and then
reconfigure the parameter.
l If the DPC(Hex) is consistent, go to Step 3.
Check whether the Adjacent DE Name on the BSC side is consistent with that on the MSC
side.
l If the corresponding MSC does not exists, add a linkset to the destination entity that is
adjacent to the MSC.
l If the corresponding MSC exists, go to Step 4.
Check whether the DE Name on the BSC side correspond to the destination entity on the MSC
side.
l If not existent, add a destination entity that corresponds to that on the MSC side.
l If existent, check whether the M3UA link is faulty. For details, see 4.2.11 Troubleshooting
M3UA Link Faults.
----End
Fault Symptoms
On the BSC6000 Local Maintenance Terminal, query the status of the LAPD link. The query
result shows that the State of the OML/EML/RSL/ESL is Failure. For details, refer to
Maintaining LAPD Links. An alarm 2114 LAPD Alarm is reported. Multiple cells are out of
service and neither voice services nor data services can be provided for the MSs in the coverage
of the BTS.
NOTE
After the Abis interface uses the IP link, the BTS communicates with the BSC through the IP network.
Therefore, if the IP link is functional, the IP bearer layer works normally.
Possible Causes
The possible causes of Abis interface IP link faults are as follows:
Procedure
Step 1 On the Local Maintenance Terminal, ping the IP address of the BTS port. For details, refer to
Pinging the Peer-End IP Address.
l If you ping the IP address successfully, you can infer that the BTS has obtained the IP
address; but if the OML is inaccessible, you can infer that the BTS fails to set up the link
correctly. Then, go to Step 2.
l If you cannot ping the IP address, the BTS may have not obtained the IP address through
the DHCP. Check whether the ports interconnecting the BTS and the BSC are configured
consistently with the data configuration and whether the electronic labels of the BTS are
consistent with the data configuration. If inconsistent, reconfigure the ports or the electronic
labels. For details, refer to Configuring Abis over IP. If consistent, go to Step 3.
Step 2 Check whether the TRAN wiring terminal is plugged out from the interface board.
l If the TRAN wiring terminal is still connected to the interface board, plug it out to reduce
its interference to the IP communication.
l If the TRAN wiring terminal is plugged out, go to Step 3.
Step 3 Check whether the DPTU board is inserted in a correct slot. The correct location is slot 3 or 4
of subrack 0.
l If the board is inserted in a wrong slot, reinsert the board in the correct location as mentioned
previously.
l If the board is inserted in a correct slot, go to Step 4.
Step 4 Check whether the route from the BSC to the BTS is configured incorrectly.
l If the route configuration is incorrect, reconfigure the route as follows:
– For layer 2 networking, the destination IP address is the logical IP address of the BTS,
and the gateway IP address is the port IP address of the BTS.
– For layer 3 networking, configure the following two routes:
– One destination IP address is the logical IP address of the BTS, and the gateway IP
address is the IP address of the port connecting the router and the GFGUB.
– One destination IP address is the DHCP Relay IP address of the BSC, and the
gateway IP address is the IP address of the port connecting the router and the
GFGUB.
For details, refer to Configuring Abis over IP.
l If the route configuration is correct but the fault persists, contact the Huawei Customer
Service Center by referring to 1.3.1 Obtaining Technical Support.
----End
Fault Symptoms
The inconsistency between configured TRX and actually used TRX results in the failure of the
TRX board to upload data. Thus, a fault occurs in the RSL.
Fault Symptoms
The inconsistency between configured BTS type and actual BTS type results in the failure of
the BTS boards to upload data. Thus, a fault occurs in the OML.
Fault Symptoms
If the DIP switches of the BSC6000 interface board and the BTS DTMU are not correctly set
when the 120-ohm trunk cable is used for transmission, both ends of the cable may be grounded
and thus form a loop. This follows a burst of bit errors, which disables the communication
between the BTS and the BSC. As a result, the BTS cannot be initialized.
Fault Symptoms
The 120-ohm twisted pair cable is used for the Abis transmission of a BTS and the signals are
transmitted through the DDF. After a loopback is performed on the DDF, the LIUx LEDs of the
BTS are off. The analysis shows that the Abis transmission is normal but bit errors may occur
on the Abis interface. The causes of bit errors are as follows:
l The connectors of the 120-ohm twisted pair cable are in poor contact.
l The connectors of the 120-ohm twisted pair cable are polluted.
l The 120-ohm twisted pair cable has wires exposed, which leads to strong signal
interference.
l Both ends of the shielding layer of the E1 cable between the BTS DTMU, DDF, and
BSC6000 GEIUB are grounded.
The previous analysis shows that both ends of the shielding layer of the E1 cable between the
BTS DTMU and the DDF are grounded and a loop is formed, which leads to bit errors. The
causes of bit errors are as follows:
l The signals are transmitted between the GEIUB, GEIUP, and GEIUT of the BSC through
the 120-ohm twisted pair cable in balanced mode. If the DIP switch for the transmitting
end is set to OFF, the cable is not grounded automatically. If the DDF is grounded only,
then no loop is formed, and thus the signal quality at the BSC transmitting end is good.
l The DIP switch on the BTS3012 DTMU is used to control the grounding of the E1 cable
jacket at the transmitting end, and the DIP switch on the DCSU is used for controlling
different transmission cables instead of grounding only the E1 cable jacket at the
transmitting end. The DIP switches S4, S5, S6, and S7 on the DTMU are set to ON before
delivery. Such settings form a loop between DTMU and DDF and lead to bit errors.
Fault Symptoms
The reset of the BSC GFGUA causes the SCTP link to break down. After the Ethernet cable is
reconnected, the SCTP link works normally.
3. According to the previous analysis, you can decide that the fault is related to the router
configuration. Perform the following operations for further analysis:
(1) Trace the SCTP of the A interface on the BSC side. You can find that only the uplink
message to the MSC instead of the MSC downlink message to the BSC is traced. For
details, refer to Tracing SCTP Messages on the A Interface.
(2) Trace the SCTP of the A interface on the MSC side. The MSC can receive the SCTP
message from the BSC and the MSC responds to the message.
(3) The port of the MSC connected to the router catches IP packets. The port can catch
the messages sent from or received by the MSC.
Based on the analysis, you can determine that the messages are discarded in the router and
you need to check the router configuration.
4. Check the router configuration. Figure 4-13 shows the routes between the BSC and the
MSC.
G 1
F
BSC G Router MSC
U
A 5
Two routes are configured from the MSC to the BSC: one is to port 1 of the GFGUA, and
the other is to port 5 of the GFGUA. When port 1 is enabled and port 5 is disabled, the
physical connection between the routers still exists. That is, two MSC-to-BSC routes exist
on the router. One is available and the other is unavailable.
Because the router determines the availability of a route according to physical connections,
the router identifies the route to port 5 as available. When the IP packets from the MSC to
the BSC are transferred at the router, the router may forward the IP packets to an unavailable
port 5.
To sum up, the messages sent by the BSC can reach the MSC, but the messages returned
by the MSC cannot reach the BSC.
5. Delete the redundant routes in the router, that is, physically disconnect the router from port
5.
5 Clock Faults
This describes clock faults in terms of the symptoms, troubleshooting methods, and typical cases.
Procedure
Step 1 Deal with the reported alarm according to the alarm help.
Step 2 If the alarm persists, determine the subclass of the fault and take the corresponding measure, as
listed in Table 5-3.
Step 3 If the fault persists, contact the Huawei Customer Service Center by referring to 1.3.1 Obtaining
Technical Support.
----End
Fault Symptoms
The PLL state is not Locked, which you can check on the BSC6000 Local Maintenance
Terminal by referring to Maintaining the BSC Clock Reference Status. An alarm 20010
Faulty 8 kHz Clock Source from the Standby GGCU to the Backplane of the GSCU or
20009 Faulty 8 kHz Clock Source from the Active GGCU to the Backplane of the GSCU
is reported.
Possible Causes
The possible causes of clock source faults are as follows:
l The active GGCU fails to lock the upper-layer clock source and provide the timing signals
to the GSCU.
l The active GGCU is faulty.
l The standby GSCU is faulty.
l The backplane is faulty.
Procedure
Step 1 By referring to Maintaining the BSC Clock Reference Status, check whether the standby
GGCU locks the upper-layer clock source.
l If the standby GGCU locks the upper-layer clock source, go to Step 2.
l If the standby GGCU fails to lock the upper-layer clock source, go to Step 3.
Step 3 Check whether both the active and the standby GSCUs report this alarm.
l If both the active and the standby GSCUs report this alarm, go to Step 4.
l If only one GSCU reports this alarm, go to Step 6.
Step 4 Secure the standby GGCU and then check whether the alarm is cleared.
l If the alarm is cleared, end the troubleshooting.
l If the alarm is not cleared, go to Step 5.
Step 5 Replace the standby GGCU and then check whether the alarm is cleared after the board is
successfully restarted.
l If the alarm is cleared, end the troubleshooting.
l If the alarm is not cleared, go to Step 6.
Step 6 Secure the GSCU and then check whether the alarm is cleared.
l If the alarm is cleared, end the troubleshooting.
l If the alarm is not cleared, go to Step 7.
Step 8 Switch over the active and standby boards, and then check whether the alarm is cleared after the
originally standby board is successfully restarted.
l If the alarm is cleared, end the troubleshooting.
l If the alarm is not cleared, go to Step 9.
Step 9 Replace the standby GSCU and then check whether the alarm is cleared after the board is
successfully restarted.
l If the alarm is cleared, end the troubleshooting.
l If the alarm is not cleared, contact the Huawei Customer Service Center by referring to
1.3.1 Obtaining Technical Support.
----End
Fault Symptoms
A clock source provided by a board is in an abnormal state, which you can check on the BSC6000
Local Maintenance Terminal by referring to Maintaining the BSC Clock Reference
Status. An alarm 20003 Board Fault - Faulty Inner Clock is reported.
Possible Causes
The possible cause of a board clock fault is that the board hardware is faulty.
Procedure
Replace the faulty board and then check whether the alarm is cleared after the board is
successfully restarted.
l If the alarm is cleared, end the troubleshooting.
l If the alarm is not cleared, contact the Huawei Customer Service Center by referring to
1.3.1 Obtaining Technical Support.
----End
This describes a typical case of troubleshooting the faults in the phrase-lock loop that is in non-
locked state. when the faults occur, you can infer that the clock reference source of the GGCU
is faulty.
5.3.4 Case: Handover Call Drop Due to Large Frequency Offset of BTS Clock
This describes how to troubleshoot the handover call drop fault caused by the unstable BTS
clock. You need to keep the BTS clock stable.
Fault Symptoms
When the networking mode is BTS - BSC (BM) - trunk transmission - BSC (TC) - MSC, all
BTSs of the BSC report the alarm warning that the clock reference source is faulty. Other network
performances are listed as follows:
l The BSC traces the line clock, and the BSC reports no related alarms.
l The transmission on the Ater interface is normal.
l Other BSCs under the same MSC report no related alarms.
The MSC and BSC report no clock reference source alarms, and you can infer that the clock
frequency offset is within a normal range.
The BTS clock frequency offset ranges from -0.15 ppm to +0.15 ppm (a millionth), and the BSC
clock frequency offset ranges from -4.6 ppm to +4.6 ppm. If the MSC clock frequency offset is
larger than ±0.15 ppm and smaller than ±4.6 ppm (in theory), the BTS reports the clock reference
source abnormal alarm and the BSC reports no related alarms.
Fault Symptoms
Currently, the BSC slip frame alarm is of two types:
If the BSC clock is asynchronous with the MSC clock and the difference between them reaches
a frame, one frame signal is discarded or repeated. Therefore, when the slip frame alarm is
reported, you must check the configuration and state of the clock on both BSC and MSC sides.
Fault Symptoms
On the BSC6000 Local Maintenance Terminal, query the status of the BSC clock reference
source. The PLL state is Free running, and the Work mode is Automatic. For details, refer to
Maintaining the BSC Clock Reference Status. Figure 5-1 shows the dialog box.
l When the phrase-locked loop of the GGCU is in Fast tracking state, this state is temporary
but will not last long.
l When the phrase-locked loop of the GGCU is in Hold over state, you can infer that the
current clock reference source is unavailable. On the BSC6000 Local Maintenance
Terminal, view the alarm information and check whether the alarms related to the clock
reference source are reported. If alarms are reported, handle the alarms by referring to BSS
Alarm Reference.
Fault Symptoms
Call drops occasionally occur when the handover is performed at the DCS1800M frequency
band. However, the signal level is normal without interference.
6 Handover Faults
This describes handover faults in terms of the symptoms, troubleshooting methods, and typical
cases.
l Edge handover
l Bad quality handover
l Rapid level drop handover
l Power budget (PBGT) handover
l Interference handover
If the handover fails, the voice quality is deteriorated or the call is dropped. Moreover, the
handover success rate decreases obviously.
The BSC clock alarm, BTS clock alarm, TRX fault alarm, CDU fault alarm, and antenna fault
alarm are related to handover.
When the clock alarm is generated, the BTS service still provides services but greatly affects
the handover. For clock alarms, refer to 5.1.2 Alarms Related to Clock Faults.
Counter Description
Procedure
Step 1 Deal with the reported alarm according to the alarm help.
Step 2 If the alarm persists, determine the subclass of the fault and take the corresponding measure, as
listed in Table 6-2.
A handover fails because the target cell is 6.2.2 Troubleshooting Destination Cell
congested. Congestion Faults
Step 3 If the fault persists, contact the Huawei Customer Service Center by referring to 1.3.1 Obtaining
Technical Support.
----End
Possible Causes
The possible causes of no handover originated or too many handovers originated are as follows:
l If the handover threshold is too high, few handovers can be originated. If it is too low, too
many handovers are originated frequently.
l If a neighboring cell is not configured, the MS cannot originate a handover to this cell.
l If the handover hysteresis is too large, few handovers can be originated. If it is too small,
too many handovers are originated frequently.
l If the N or P value is too large, few handovers can be originated. If it is too small, the
handover target cell may not be the best one.
Procedure
Step 1 If the handover threshold is improper, adjust it.
----End
Possible Causes
The possible causes of destination cell congestion are as follows:
Procedure
Step 1 If a TRX or channel fault occurs, rectify such a fault first.
Step 2 If the cell does not allow the conversion from full-rate channels to half-rate channels, set TCH
Rate Adjust Allow of each TRX of this cell to Yes on the BSC6000 Local Maintenance
Terminal by referring to Modifying Channel Attributes (Full Rate and Half Rate).
Alternatively, expand the capacity of the cell.
----End
Possible Causes
The possible causes of hardware faults are as follows:
Procedure
Step 1 If the configuration data of the failed cell and its neighboring cells is not modified recently, you
can infer that the BTS hardware is faulty.
l If the handover problem occurs in only one cell under this BTS, you can infer that a TRX
of the cell is faulty, which leads to a failure in handover to this TRX.
l If the handover problem occurs also in the neighboring cells on the same site, you can infer
that the hardware, such as the TMU, shared by the cells is faulty.
For the above problems, you can check them by blocking some TRXs. If the handover success
rate is within the allowed range after blocking a TRX, check whether this TRX is faulty or
whether the related CDU or feeder is faulty.
NOTE
If UL signals and DL signals on a TRX are very unbalanced, then handover problems, such as frequent
handovers or decreases in the handover success rate, may often occur.
Step 2 Trace the Abis interface to check whether the signaling related to this cell is normal, including
whether the UL and DL RX qualities are good. For detailed operations, refer to Tracing the
Messages on the Abis Interface.
If the measurement report shows that the TCHH Receive Level Measurement or TCHF
Receive Level Measurement is poor, you can infer that the hardware of this cell is faulty or
there is severe interference to this cell. Thus, signaling messages cannot be exchanged properly
and the handover cannot be performed successfully. For detailed operations, refer to 7.2.4
Troubleshooting Interference Problems.
----End
Possible Causes
The possible causes of inter-BSC and inter-MSC handover failures are as follows:
l The data configuration of the cells involved in inter-MSC handover is incorrect.
l The configuration data of the target cell for inter-BSC handover is incorrect.
l The MSC and the BSC process signaling messages on the A interface in different ways,
and therefore they fail to cooperate with each other.
l Clocks of the two BSCs are out of synchronization.
Procedure
Step 1 On the MSC side, check whether the configuration data, such as the CGI and owner, of the
involved cells is correct.
----End
Possible Causes
The possible causes of other handover faults are cell congestion, poor quality of transmission
on the Um interface, and signaling problem on the A interface.
NOTE
The following procedure helps analyze configuration data in depth for troubleshooting.
Procedure
Step 1 Determine the type of handovers with high failure rates by referring to 6.1.3 Counters Related
to Handover Faults. The handover may be intra-cell handover, handover from a cell in the same
BSC, handover to a cell in the same BSC, handover from a cell in another BSC, handover to a
cell in another BSC, handover from a cell in another system, or handover to a cell in another
system.
Step 2 Based on the specific counter and signaling tracing result, find the cause of the handover fault.
Step 3 If the cause of the handover fault is still unclear, contact the Huawei Customer Service Center
by referring to 1.3.1 Obtaining Technical Support.
----End
7 Congestion Faults
This describes congestion faults in terms of the symptoms, troubleshooting methods, and typical
cases.
When a congestion fault occurs, pages of the calling parties and the called parties cannot be
processed, SMSs cannot be sent or received, or the BTS cannot be maintained. Congestion
mainly occurs on the radio channels, Abis interface, and A interface.
The TRX incurs faults, which leads to the 2116 TRX Configuration Alarm
congestion of Um interface resources in peak
hours. 2148 TRX Hardware Alarm
The E1 transmission on the A interface is faulty, 20082 Loss of E1/T1 Frames (LOF)
or the bit error rate is high (higher than 10-6), or
the number of configured signaling links is too 20089 Excessive Loss of E1/T1 Signals
small, which leads to the congestion or in an Hour
unavailability of MTP2 and MTP3 links. 20090 Excessive E1/T1
Synchronization Failures in an Hour
Counter Description
Counter Description
Procedure
Step 1 Deal with the reported alarm according to the alarm help.
Step 2 If the alarm persists, determine the subclass of the fault and take the corresponding measure, as
listed in Table 7-4.
On the M2000 Client, check the traffic on 7.2.1 Troubleshooting High Traffic
the SDCCH and TCH. The result shows
that the traffic exceeds the designed.
On the M2000 Client, check the traffic on 7.2.2 Troubleshooting Burst Traffic
the TCH. The result shows that the traffic
increases suddenly during a short period.
Step 3 If the fault persists, contact the Huawei Customer Service Center by referring to 1.3.1 Obtaining
Technical Support.
----End
Fault Symptoms
The symptoms of high traffic are as follows:
l The traffic in each of recent days is higher than the designed. On the M2000 Client, you
can obtain the Traffic Volume on TCH.
l More than 90% of the channel resource and circuit resource are occupied at traffic hours.
On the BSC6000 Local Maintenance Terminal, you can obtain the TCH status at peak
hours by referring to Monitoring Channel Status and the circuit resource usage on the A
interface by referring to Maintaining the Circuits on the A Interface.
Possible Causes
High traffic is possibly caused by too many subscribers.
Procedure
Expand the system capacity by referring to BSS Capacity Expansion Guide. Alternatively,
take traffic-sharing measures to relieve congestion.
----End
Fault Symptoms
The symptoms of burst traffic are as follows:
l More than 90% of the channel resource and circuit resource are occupied at traffic hours.
On the BSC6000 Local Maintenance Terminal, you can obtain the TCH status at peak
hours by referring to Monitoring Channel Status and the circuit resource usage on the A
interface by referring to Maintaining the Circuits on the A Interface.
l The circuit resource usage at peak hours is obviously higher than the average in the same
time segment on other days. You can obtain the Mean Number of Busy Circuits on the
A Interface at peak hours on the M2000 Client.
l Traffic in a time segment is obviously higher than that in other time segments of the day.
You can obtain the Traffic Volume on TCH on the M2000 Client.
Possible Cause
Burst traffic is possibly caused by a big event such as a football game or concert in an area within
a period.
Procedure
To relieve congestion in the case of burst traffic, do as follows:
l Enable some half-rate channels in this period to make more channels available. For detailed
operations, refer to Modifying Channel Attributes (Full Rate and Half Rate).
l Add SDCCHs in this period and enable dynamic conversion between SDCCH and TCH.
For detailed operations, refer to Modifying Channel Attributes (TCH and SDCCH).
----End
Possible Causes
The possible causes of TRX faults are as follows:
Procedure
Step 1 Rectify the fault according to the alarm help. The alarm reported may be 2116 TRX
Configuration Alarm, 2148 TRX Hardware Alarm, 2180 TRX Band Mismatch ARFCN,
2196 TRX Clock Critical Alarm, or 2204 TRX Communication Alarm.
l If the fault is rectified, end the troubleshooting.
l If the fault persists, go to Step 2.
2. Determine the TRX status based on the description of the color on the right of Figure
7-1.
l If the TRX status is Error/Locked (Auto), you can infer that the BTS is not powered. Reset
and reload the TRX board.
l If the TRX status is not Error/Locked (Auto), go to Step 3.
Step 3 If the TRX fault cannot be confirmed, check the cable connections and VSWR of the antenna
system. For detailed operations, refer to Testing the Antenna System and Measuring the
VSWR at the Antenna Port. If all pass the check, replace the TRX board and then check the
services.
l If the services are restored, end the troubleshooting.
l If the services are not restored, contact the Huawei Customer Service Center by referring
to 1.3.1 Obtaining Technical Support.
----End
Fault Symptoms
The interference symptoms are as follows:
l The MS sends channel request messages to two cells each time the MS originates a call.
You can detect this symptom by making test calls and tracing signaling messages on the
Um interface on the BSC6000 Local Maintenance Terminal. For detailed operations,
refer to Tracing CS Domain Messages on the Um Interface.
This symptom indicates that the BCCHs in the two cells are configured with the same
frequency. Thus, in the cell that is selected by mistake, there are many invalid SDCCH
request messages, which leads to congestion. This symptom always occurs at peak hours.
l The level of interference including adjacent-channel interference is higher than the
expected. You can monitor the channel interference band on the BSC6000 Local
Maintenance Terminal. For detailed operations, refer to Monitoring Channel
Interference Band.
When this symptom occurs, the MS cannot receive the commands sent by the BSC and
therefore applies for channels repeatedly, which leads to congestion in the SDCCH or TCH,
especially at peak hours.
Possible Causes
The possible causes of interference are as follows:
l Intra-network interference
l Interference from repeaters
l Interference from other high-power communication equipment
l Hardware fault
Procedure
l For the first fault symptom, configure the BCCHs in the two cells with different frequencies
by referring to Modifying TRX Frequencies.
l For the second fault symptom, rectify the fault by referring to Analysis of Interference
Problems. Alternatively, adjust the frequency hopping mode by referring to Changing the
FH Mode.
----End
Fault Symptoms
Many circuits are occupied or congested for a long time. You can check the status of the circuits
on the A interface on the BSC6000 Local Maintenance Terminal. For detailed operations,
refer to Maintaining the Circuits on the A Interface.
Possible Causes
The possible causes of insufficient terrestrial resources on the A interface that is not based on
IP are as follows:
l If many circuits are occupied for a long time, you can infer that the configured circuits are
insufficient.
l If the circuits are congested, you can infer that some circuits are blocked or faulty.
Procedure
To rectify the fault, do as follows:
l If many circuits are occupied for a long time, add E1s/T1s on the A interface.
– When the BM and the TC are configured in different subracks, operate according to
Adding an A Interface E1/T1.
– When the BM and the TC are configured in the same subrack, operate according to
Adding an A Interface E1/T1.
l If some circuits are blocked or faulty, do as follows:
– If some circuits are blocked, unblock them by referring to Unblock A Interface CIC
(UBL ACIC).
– If some circuits are faulty, you can infer that a fault occurs in transmission or the interface
board. In this case, operate according to 4.2.9 Troubleshooting E1/T1 Transmission
Faults.
----End
Fault Symptoms
Many Abis timeslots are occupied for a long time, which you can check on the BSC6000 Local
Maintenance Terminal by referring to Querying the Status of the Abis Interface Timeslot.
Possible Causes
The possible cause of insufficient Abis resources is that the configuration is improper.
Procedure
To rectify the fault, do as follows:
l Adjust Abis timeslot assignment by referring to and Manually Assigning the Abis
Timeslots.
l Select the Abis Resource Adjustment TCHH Function Switch.
1. On the Management Tree tab page of the BSC6000 Local Maintenance
Terminal, right-click the cell and then select Configure Cell Attributes from the
shortcut menu.
2. Double-click the cell in the Cell view box to add it to the Selected cells box, and then
click Next.
3. Click Set Cell Properties. The Set Cell Attributes dialog box is displayed.
4. Click Call Control. A dialog box is displayed, as shown in Figure 7-2.
Set Abis Resource Adjustment TCHH Function Switch to Yes.
----End
Fault Symptoms
Query the alarm information and the result shows that the communication of some TRX boards
is abnormal. The traffic statistics information shows that the congestion rate on the TCH
increases.
Fault Symptoms
All the MSs in the cell fail to update locations. A large number of Location Updating Reject
messages are traced, which leads to the congestion on the SDCCH.
2. Modify the LAC configuration on the BSC side to keep it consistent with that on the MSC
side. For details, refer to Step 1 described in 8.2.2 Troubleshooting Data Configuration
Faults.
8 Access Faults
This describes access faults in terms of the symptoms, troubleshooting methods, and typical
cases.
Procedure
Step 1 Deal with the reported alarm according to the alarm help.
Step 2 If the alarm persists, determine the subclass of the fault and take the corresponding measure, as
listed in Table 8-3.
l The MSC rejects the service request 8.2.2 Troubleshooting Data Configuration
from the MS. Faults
l The number of expirations of the setup
indication timer is larger than a preset
value.
l The immediate assignment success rate
is lower than a preset value.
l The congestion rate of the SDCCH is
higher than a preset value.
l The paging success rate is lower than a
preset value.
Step 3 If the fault persists, contact the Huawei Customer Service Center by referring to 1.3.1 Obtaining
Technical Support.
----End
Possible Causes
The possible causes of Um interface quality problems are as follows:
l The equipment is faulty or the network planning is improper. In this case, the coverage of
the network is unsatisfied.
l UL and DL signals are unbalanced on the Um interface, or UL signals are greatly affected
by interference.
Procedure
Step 1 Check whether the equipment is faulty.
On the BSC6000 Local Maintenance Terminal, check the kickoff status of the cell and the
status of each board of the BTS in the Figure 8-1 dialog box. For detailed operations, refer to
Querying BTS Attributes.
If the Operation status is Enabled, check whether each board of the BTS is faulty.
3. In the displayed dialog box, select the Device Attributes tab page, as shown in Figure
8-2.
Set the Power Level to adjust the TRX power, thus solving the problem of unbalancing between
UL and DL signals.
CAUTION
A higher power level indicates a lower power value. Power level 0 indicates the maximum power
value.
2. After you click Start in the dialog box as shown in Figure 8-3, the BTS starts to scan
frequencies 512 to 517 at the specified time.
On the BSC6000 Local Maintenance Terminal, the frequency scanning result shows the
interference to each frequency in the uplink. The smaller the value, the lower the
interference. For detailed operations, refer to Querying Frequency Scan Results.
Select an idle frequency with the lowest interference as the BCCH frequency of the cell.
CAUTION
After the frequency scanning task is complete, click Stop in the Configure Frequency
Scan dialog box. Otherwise, the BTS scans these frequencies once every day.
Possible Causes
The possible causes are as follows:
l The data configuration is inconsistent between the BSC and the MSC.
l The cell-related parameters are not properly set.
Procedure
Step 1 Check whether the data configuration is inconsistent between the BSC and the MSC.
Determine the fault coverage, that is, whether the fault occurs in all the cells or only a few cells
in the coverage of the BSC.
l If the fault occurs in all the cells in the coverage of the BSC, check the global configuration
data as follows:
– When the BM and the TC are configured in different subracks, see Configuring the
BSC Attributes for details.
– When the BM and the TC are configured in the same subrack, see Configuring the
BSC Attributes for details.
– When the A interface uses the IP transmission mode, see Configuring the BSC
Attributes for details.
l If the fault occurs in a few cells in the coverage of the BSC, check the configuration data
of specified cells as follows:
1. On the BSC6000 Local Maintenance Terminal, right-click a cell on the
Management Tree tab page. Then, choose Configure Cell Attributes.
2. On the Configure Cell Attributes dialog box, select the cell, and click Next.
3. Click Configure Cell Attributes. In the displayed Set Cell Attributes dialog box,
check the following parameters: MCC, MNC, LAC, and CI, as shown in Figure
8-4.
CAUTION
The parameter configuration mentioned above must be kept consistent between the BSC and the
MSC.
Step 2 Check whether the cell access parameters are set properly.
If the access fault occurs in a few cells but not because the MSC rejects services, check whether
the cell access parameters are set properly, and verify the parameters related to the cells in idle
mode and the cell timer, as shown in Figure 8-5 and Figure 8-6.
l If the fault persists after the parameters are set correctly, contact the Huawei Customer
Service Center by referring to 1.3.1 Obtaining Technical Support.
l If the parameters are set incorrectly, reconfigure the parameters. If the fault persists after
reconfiguration, contact the Huawei Customer Service Center by referring to 1.3.1
Obtaining Technical Support.
----End
Fault Symptoms
The MS is located in the poor coverage of signals and thus fails to access the network due to
weak signals.
Fault Symptoms
The MS in idle mode fails to perform cell reselection. It incurs a call drop first and then registers
in the network.
Fault Symptoms
An office has four BTSs, and the network runs normally. One day, however, the MSs are
suddenly disconnected from the network.
roaming MSs is more than 5000. The problem may be caused by the sharp increase of MSs,
which burdens the network in the following aspects:
l High TCH congestion rate
If all the TCHs in some areas are occupied, then other MSs cannot make calls.
l High SDCCH congestion rate
If all the SDCCHs in some areas are occupied, then the MSs cannot perform signaling
interaction. In addition, the MSs can neither make or receive calls nor perform location
update, and the location update failure directly leads to MS disconnection from the
network.
3. Check the BSC idle parameters.
The time of periodic location update is set to 12 minutes for the BSC and 30 minutes for
the MSC. The setting means that all the activated MSs initiate a periodic location update
to the SDCCH every 12 minutes. When the number of MSs reaches a certain level, all the
SDCCHs are occupied. At this time, if the MSs initiate the periodic location update again,
the MSs may fail the location update because there are no idle SDCCHs and thus the MSs
will be disconnected from the network.
4. Modify the configuration data.
On the BSC6000 Local Maintenance Terminal, set Period of Periodic Location Update
(6 minutes) to 10, that is, 60 minutes. For details, refer to Step 2 described in 8.2.2
Troubleshooting Data Configuration Faults. In addition, set the period for the MSC to
180 minutes.
Fault Symptoms
The MS can receive the signals from the BTS but cannot access the network.
Fault Symptoms
The fault symptoms of the MS access failure are as follows:
l The MS displays that it fails to search the network, or the MS displays no information.
l The MS displays that the network list contains no originating network.
Fault Symptoms
The fault symptoms are as follows:
l The MS displays that it fails to search the network, or the MS displays no information.
l The MS searches one or more networks.
l Most of the MSs cannot access the cell.
l No request message is available on the Abis interface.
3. The MS can access the network normally after the parameter is modified.
9 PS Service Faults
This describes PS service faults in terms of the symptoms, troubleshooting methods, and typical
cases.
Table 9-1 lists the alarms related to the PS service faults in the case of using the external PCU.
The congestion start threshold and the 21001 LAPD Link Congestion
congestion end threshold of the LAPD links
on the Pb interface are improperly set, or the
LAPD signaling load exceeds the congestion
start threshold of the LAPD links.
The LAPD link on the Pb interface cannot 21002 Broken LAPD Link
receive any messages from the peer end
(PCU).
All the PBSLs between the BSC and the PCU 104 All PBSLs in the PCU Are Faulty
are faulty.
The one-way audio occurs in a PBSL between 105 ONE PBSL Link SINGLE PASS
the BSC and the PCU.
The circuit with an alarm flag is not 127 No Pb Interface Circuit Configured on
configured on the BSC side but on the PCU the BSC side
side.
The circuit with an alarm flag is not 128 No Circuit Configured in the PCU
configured on the PCU side but on the BSC
side.
The BSC sends the PCU the message 134 BSC Unable to Block a Packet Circuit
indicating that the BSC blocks the circuit with
maximum retransmissions, but the PCU does
not respond to the messages.
The BSC sends the PCU the message that the 135 BSC Unable to Unblock a Packet
BSC unblocks the circuit PCU with Circuit
maximum retransmissions, but the PCU does
not respond to the messages.
The BSC sends the PCU the message 136 BSC Unable to Reset a Packet Circuit
indicating that the BSC resets the circuit with
maximum retransmissions, but the PCU does
not respond to the messages.
Table 9-2 lists the alarms related to the PS service faults in the case of using the built-in PCU.
The delay of the transmission between BTS and BSC in 291 Cell Transmission Delay
the cell is below the lower limit or above the upper limit. Abnormal
The BSC supports GPRS/EGPRS but the actual BTS 294 TRX Config Error
TRXs do not support GPRS/EGPRS.
The GEPUG is faulty, or the NSVC is blocked, or the 331 NSVC Faulty
bearer channel is inaccessible, or the data configuration
is inconsistent between BSC and SGSN.
The GFGUG is faulty, or the network between BSC and 332 NSVL Faulty
SGSN is disconnected, or the data configuration is
inconsistent between BSC and SGSN.
The cell distribution fails or is prohibited by the license, 340 Cell PS Service Faulty
or the Um or Gb interface is blocked.
The cell distribution on the DSP exceeds the upper limit. 341 DSP Resource Overload
The PTP BVC signaling flow is abnormal, or the PTP 342 PTP BVC Faulty
BVC is blocked.
The communication link between BSC and SGSN is 343 NSVL Dynamic
faulty, or the data configuration of the SERVER IP/UDP Configuration Process Failure
port is inconsistent between BSC and SGSN.
Among the 22 DSPs of the GDPUP, the redundant 16 344 FAULTY DSP OVER
DSPs are faulty. LIMIT
Counter Description
Counter Description
Table 9-4 lists the counters related to PS service faults in the case of using the built-in PCU.
Counter Description
Counter Description
Counter Description
Counter Description
Counter Description
Counter Description
Procedure
Step 1 Deal with the reported alarm according to the alarm help.
Step 2 If the alarm persists, determine the subclass of the fault and take the corresponding measure, as
listed in Table 9-5.
On the external PCU LocalWS, check the 9.2.2 Troubleshooting Cell Faults (External
cell status. The result shows that a cell PCU)
malfunctions.
On the external PCU LocalWS, trace the 9.2.3 Troubleshooting Cell Kickoff Failures
messages on the Pb interface and run a cell (External PCU)
reset command. The result shows that a cell
fails to start work.
NOTE
Resetting a cell causes the cell out of service.
Perform this operation only when the cell cannot
offer services properly.
On the external PCU LocalWS, check the 9.2.4 Troubleshooting PDCH Faults
PDCH status. The result shows that a (External PCU)
PDCH malfunctions.
Check the status of LAPD links on the Pb 9.2.5 Troubleshooting LAPD Link Faults
interface. The result shows that an LAPD (External PCU)
link malfunctions.
On the M2000 Client or BSC6000 Local 9.2.6 Troubleshooting Cell Activity State
Maintenance Terminal, check the cell Faults (Built-in PCU)
configurations, physical connections, and
port parameter settings.
NOTE
Resetting a cell causes the cell out of service.
Perform this operation only when the cell cannot
offer services properly.
Find that the PCU is running properly but 9.2.8 Troubleshooting Global Service
all the ongoing services are disrupted Disruption Faults (Built-in PCU)
suddenly.
NOTE
For details on the PCU commands, refer to 9.2.9 Commands Executed on the PCU Maintenance
Terminal.
Step 3 If the fault persists, contact the Huawei Customer Service Center by referring to 1.3.1 Obtaining
Technical Support.
----End
Possible Causes
The possible cause of a cell not supporting GPRS is that the cell is configured not to support
GPRS. In this case, the system information issued by the BTS does not carry any PS-related
information, and therefore the MS cannot perform PS services in the cell.
Procedure
Step 1 On the Management Tree tab page of the BSC6000 Local Maintenance Terminal, click the
cell and check the cell attributes, as shown in Figure 9-1.
Step 2 On the Cell Attributes tab page, check whether the GPRS Support check box is selected. If it
is not selected, the cell cannot support GPRS.
To enable the cell to support GPRS, select the GPRS Support check box and ensure that the
cell is configured with PDCHs.
----End
Fault Symptoms
The cell fault symptoms on the external PCU side are as follows:
l The cell has an internal fault, the cell resources are not ready, the equipment is not
initialized, the cell does not support GPRS, the cell does not exist, or the data configuration
of the cell is incorrect.
l If the BSC administrative status of the cell is BLOCKED.
Procedure
On the PCU LocalWS, check the cell status.
NOTE
For details on the PCU commands, refer to 9.2.9 Commands Executed on the PCU Maintenance
Terminal.
l If the cell status is Internal fault, do as follows:
1. On the PCU LocalWS, check the CGI of the cell.
2. On the BSC6000 Local Maintenance Terminal, check the MCC, MNC, LAC, and
CI. For detailed operations, refer to Step 1 of 8.2.2 Troubleshooting Data
Configuration Faults.
NOTE
The CI can be displayed in decimal or hexadecimal mode. Set the Cell LAC&CI&RA display
mode to Decimal or Hexadecimal. For detailed operations, refer to Setting Attributes of the
BSC6000 Local Maintenance Terminal. The LAC and CI in the CGI are displayed in
hexadecimal mode.
3. Check whether the CGI on the PCU side is consistent with that on the BSC side.
– In consistent, end the troubleshooting.
– If inconsistent, modify the CGI on the PCU LocalWS or BSC6000 Local
Maintenance Terminal.
l If the cell status is Dependency, do as follows:
Select PBSL from the LAPD Link No. Scope area to check the status of the PBSL on the
BSC side. For detailed operations, refer to Maintaining LAPD Links.
If the State of the PBSL is Failure, rectify the fault by referring to 9.2.5 Troubleshooting
LAPD Link Faults (External PCU).
l If the cell status is Device has not been initialized, do as follows:
1. On the BSC side, check the status of the TRXs configured for the cell.
a. On the Management Tree tab page of the BSC6000 Local Maintenance
Terminal, select a TRX. Then, check the related information on the Site Device
Panel, as shown in Figure 9-2.
c. On the Channel Attributes tab page, click Channel No. 0 to 7 in turn to check
all the channel types of the current TRX in Channel Type drop-down list, as
shown in Figure 9-3.
3. Check whether the PBCCH is configured on the BSC side but not configured on the
PCU side. If the configurations are inconsistent on the two sides, modify the
parameters to keep them consistent.
l If the BSC administrative status of the cell is BLOCKED, do as follows:
1. On the BSC6000 Local Maintenance Terminal, check the status of the site and cell
to ensure that the cell is operational. For detailed operations, refer to Querying BTS
Running Status.
2. If the cell is operational, block the cell and then unblock the cell to check the cell status
on the PCU side.
3. On the PCU LocalWS, run the cell reset command, trace the messages on the Pb
interface, and then operate according to 9.2.3 Troubleshooting Cell Kickoff Failures
(External PCU).
----End
Context
Figure 9-4 shows the GPRS cell kickoff procedure.
BSC PCU
PCU_BSC_CELL_RESET
BSC_PCU_CELL_RESET_ACK
PCU_BSC_CELL_CONFIG_REQ
BSC_PCU_CELL_INFO
PCU_BSC_CELL_INFO_CNF
BSC_PCU_CHAN_INFO
PCU_BSC_CHAN_INFO_CNF
.
.
.
BSC_PCU_CHAN_INFO
PCU_BSC_CHAN_INFO_CNF
BSC_PCU_CELL_CONFIG_ACK
.
.
.
PCU_BSC_PDCH_REQ
BSC_PCU_PDCH_ACK
.
.
.
PCU_BSC_PDCH_REQ
BSC_PCU_PDCH_ACK
1. The PCU initializes the cell and sends a PCU_BSC_CELL_RESET message to the BSC
on the Pb interface.
2. After the PCU receives a BSC_PCU_CELL_RESET_ACK message from the BSC, the
PCU sends a PCU_BSC_CELL_CONFIG_REQ message to the BSC, requesting the
configuration information of the cell.
3. The BSC sends a BSC_PCU_CELL_INFO message and multiple
BSC_PCU_CHAN_INFO messages to the PCU. The PCU responds with a
PCU_BSC_CELL_INFO_CNF message and PCU_BSC_CHAN_INFO_CNF messages
respectively. After the BSC sends such a message to the PCU, it waits for the response
from the PCU. The BSC sends another message to the PCU only after it receives the
confirmation message from the PCU.
4. After the BSC receives all the confirmation messages from the PCU, the BSC sends a
BSC_PCU_CELL_CONFIG_ACK message to the PCU, indicating that it has received all
the configuration information of the cell.
5. The PCU sends PCU_BSC_PDCH_REQ messages to the BSC on the Pb interface. The
BSC responds with BSC_PCU_PDCH_ACK messages. These channel request and
acknowledgment messages are processed concurrently.
During the cell kickoff procedure, if the response to a message is timeout, this message is sent
out again. If still timeout after multiple retransmissions, the system takes different measures in
different cases:
l BSC_PCU_CELL_RESET_ACK timeout
In this case, the PCU fails to initialize the cell. It then initializes other cells if necessary
and after that initializes this cell again.
l BSC_PCU_CELL_CONFIG_ACK timeout
In this case, the PCU fails to initialize the cell. It then initializes other cells if necessary
and after that initializes this cell again.
l Other responses timeout
Go to Step 1 to implement cell initialization.
During the cell kickoff procedure, if an NACK message is received, the system take different
measures in different cases:
l After sending a PCU_BSC_CELL_CONFIG_REQ message to the BSC, the PCU may
receive a BSC_PCU_CELL_CONFIG_NACK message from the BSC. The cause may be
that the cell does not exist, the cell does not support GPRS, the BSC is resetting the cell,
or others.
– If the cell does not exist or the cell does not support GPRS, the PCU does not initialize
the cell any longer.
– If the BSC is resetting the cell or the initialization is caused by other reasons, the PCU
initializes other cells and then this cell again.
l After sending a PCU_BSC_PDCH_REQ message from to the BSC, the PCU may receive
a BSC_PCU_PDCH_REQ_NACK message from the BSC. Go to Step 1 to implement cell
initialization.
Procedure
Step 1 On the PCU LocalWS, start Pb interface tracing and run a cell reset command.
Step 2 After sending a PCU_BSC_CELL_CONFIG_REQ message to the BSC, the PCU may receive
a BSC_PCU_CELL_CONFIG_NACK message from the BSC. For different causes, use
different troubleshooting methods, as shown in Table 9-6.
The cell does not support GPRS. Refer to 9.2.1 Troubleshooting a Cell Not
Supporting GPRS.
The BSC is resetting the cell. After the BSC resets the cell, run the cell reset
command again on the PCU LocalWS.
----End
Fault Symptoms
l The PDCH status is Device has not been initialized or Blocked.
l The BSC administrative status of the PDCH is Blocked.
Procedure
On the PCU LocalWS, check the cell status on the PCU side.
NOTE
For the PCU commands, refer to 9.2.9 Commands Executed on the PCU Maintenance Terminal.
l If the PDCH status is Device has not been initialized, do as follows:
1. On the BSC6000 Local Maintenance Terminal, check the status of the BTS and cell
where the PDCH is located. For detailed operations, refer to Querying BTS Running
Status.
2. On the PCU LocalWS, check the circuit status of the Pb interface by referring to 9.2.9
Commands Executed on the PCU Maintenance Terminal.
– If the circuit status is Uninstalled, check whether the circuit configuration of the
Pb interface on the BSC side is consistent with that on the PCU side. If inconsistent,
Fault Symptoms
An LAPD link is in a faulty state, which you can check on the BSC6000 Local Maintenance
Terminal. The LAPD link is in the DISABLED state, which you can check on the PCU
LocalWS.
Possible Causes
The possible cause of LAPD link malfunctions is circuit insufficiency on the Pb interface. Circuit
insufficiency is further caused by the following reasons:
For details on the PCU commands, refer to 9.2.9 Commands Executed on the PCU Maintenance
Terminal.
Procedure
Step 1 On the BSC6000 Local Maintenance Terminal, check the status of the E1/T1 port.
1. Loop back the E1/T1 port of the LAPD link and then check the loopback status. For detailed
operations, refer to Looping Back the Interface Board Port. If the E1/T1 port is in
loopback mode, click stop to stop the loopback.
2. Loop back the E1/T1 timeslot of the LAPD link and then check the loopback status. For
detailed operations, refer to Looping Back the Interface Board Port Timeslot. If the
timeslot is in loopback mode, click stop to stop the loopback.
3. Check the status of the LAPD link by referring to Maintaining LAPD Links. Check the
status of the LAPD link. If it is not restored, check whether the data configuration of the
LAPD link is consistent with the E1/T1 physical connection.
l If inconsistent, modify the data configuration.
l If consistent, go to Step 2.
Step 2 On the PCU LocalWS, check the status of the LAPD link.
If the administrative status of the LAPD link is BLOCKED, unblock the LAPD link.
l If the administrative status of the LAPD link is ENABLED, end the troubleshooting.
l If the administrative status of the LAPD link is still abnormal, go to Step 3.
Step 3 On the PCU LocalWS, check the status of the port of the LAPD link.
If the port of the LAPD link is in local or remote loopback, stop the loopback.
l If the administrative status of the LAPD link is ENABLED, end the troubleshooting.
l If the administrative status of the LAPD link is still abnormal, go to Step 4.
Step 4 Perform a loopback test on the E1/T1 lines that carry the LAPD link. This test does not affect
the data services on other E1/T1 lines connected to the L2PU/HLPU or the signaling on the
LAPD link. The specific operations are as follows:
1. On the BSC side, connect the RX end and the TX end of the E1/T1 lines that carry the
LAPD link.
2. On the PCU LocalWS, run the E1/T1 loopback command.
3. Check the loopback status of the E1/T1 lines and the status of the LAPD link.
l If the E1/T1 loopback test succeeds, the status of the LAPD link is ENABLED, which can
be checked on the PCU LocalWS. On the BSC6000 Local Maintenance Terminal, check
whether the configuration of the LAPD link on the BSC side is consistent with that on the
PCU side. For detailed operations, refer to Maintaining LAPD Links. If inconsistent,
modify the data. If the fault persists, go to Step 5.
l If the status of the LAPD link is still DISABLED on the PCU LocalWS, then, on the PCU
side, connect the RX end and the TX end of the E1/T1 lines that carry the LAPD link. If
the E1/T1 loopback test succeeds, you can infer that the E1/T1 lines that carry the LAPD
link are faulty. Replace the E1/T1 cable. If the E1/T1 loopback test fails, go to Step 5.
Step 5 On the PCU LocalWS, perform a loopback test on the board that carries the LAPD link.
CAUTION
This test is performed on all the LAPD links carried on the two L2PUs of the RPPU. Therefore,
the test disrupts the transmission of all traffic and signaling.
NOTE
Based on the result of LAPD link loopback, take one of the following measures:
l If the loopback test succeeds in LoopMode 1, 2, 4, or 5, the status of the LAPD link is
ENABLED, which you can check on the PCU LocalWS. Check whether the configuration
of the LAPD link on the BSC side is consistent with that on the PCU side.
l If the loopback test succeeds in LoopMode 1, 2, or 4 but fails in LoopMode 5, you can infer
that the external port for the E1/T1 cable that carries the LAPD link may be faulty and you
need to replace the board.
l If the loopback test fails in LoopMode 1, you can infer that the LAPD module software may
be incorrect and you need to contact Huawei for technical support. If the loopback test
succeeds in LoopMode 1, you can infer that the hardware of the L2PU that carries the LAPD
link may be faulty and you need to replace the board.
Step 6 On the PCU LocalWS, check whether the timeslot configured for the LAPD link is consistent
with that on the BSC side.
Step 7 On the BSC side and the PCU side, separately check whether the E1/T1 physical connection of
the LAPD link is consistent with the data configuration.
----End
Possible Causes
The possible causes of the cell activity state faults are as follows:
l The cell cannot kick off normally or the cell distribution fails.
l The Um interface or the Gb interface is blocked.
Procedure
Step 1 On the Local Maintenance Terminal, run the DSP PSCELL command to verify the state of
a specified cell.
If the cell is inactivated, modify the cell state as follows:
1. On the Management Tree tab page of the BSC6000 Local Maintenance Terminal, right-
click the cell and then select Configure Cell Attributes from the shortcut menu.
2. In the displayed dialog box, double-click the target cell in the Cell view list box to add it
to the Selected cells list box. Then, click Next.
3. In the Cells to be set list box, select the target cell, and then click Set Cell Properties. A
dialog box is displayed, as shown in Figure 9-5.
Change the Activity State from Activated to Inactivated.
Step 4 On the Local Maintenance Terminal, run the DSP PSRES command to verify the cell Gb
administration state.
According to different transmission modes between the BSC and the SGSN, perform different
operations:
l Gb over FR
1. On the BSC6000 Local Maintenance Terminal, view the alarm information and
check whether the alarm 331 NSVC Faulty exists.
– If existent, troubleshoot the fault according to the alarm help.
– If not existent, go to 4.2.
2. On the Local Maintenance Terminal, run the DSP NSVC command to verify the
NSVC state.
– If the NSVC is blocked, unblock it by referring to Unblock NSVC(UBL
NSVC).
– If the NSVC is unblocked, go to 4.3.
3. On the Local Maintenance Terminal, run the DSP BC command to verify the BC
service state.
– If the BC service is unavailable, reconfigure it by referring to Maintaining the
BC.
– If the BC service is available, go to 4.4.
4. On the Local Maintenance Terminal, run the DSP NSVC command to verify
whether the NSVC configuration is consistent between the BSC side and the SGSN
side.
– If the configuration is inconsistent, reconfigure the NSE and NSVC on the BSC
side to keep them consistent with those on the SGSN side. For details, refer to
Configuring the NSE and Configuring the NSVC.
– If the configuration is consistent, go to Step 5.
l Gb over IP
1. On the BSC6000 Local Maintenance Terminal, view the alarm information and
check whether the alarm 332 NSVL Faulty exists.
– If existent, troubleshoot the fault according to the alarm help.
– If not existent, go to the next step.
2. Check whether the IP network from the BSC to the SGSN runs normally.
– If the IP network runs abnormally, check and modify the network by referring to
4.2 Link Troubleshooting Methods.
– If the IP network runs normally, go to the next step.
3. On the Local Maintenance Terminal, run the DSP NSVL command to verify
whether the NSVL configuration is consistent between the BSC side and the SGSN
side.
– If the configuration is inconsistent, reconfigure the NSE and NSVL on the BSC
side to keep them consistent with those on the SGSN side. For details, refer to
Configuring the NSE, Configuring the Local NSVL, and Configuring the
Remote NSVL.
– If the configuration is consistent, go to Step 5.
Step 5 On the Local Maintenance Terminal, run the DSP PTPBVC command to verify the PTP BVC
state.
l If the PTP BVC administration state is blocked, unblock the PTP BVC by referring to
Unblock PTPBVC(UBL PTPBVC).
l If the PTP BVC administration state is unblocked but the fault persists, contact the Huawei
Customer Service Center by referring to 1.3.1 Obtaining Technical Support.
----End
Possible Causes
The possible causes of cell service disruption faults are as follows:
l The MS is faulty.
l The data configuration is improper.
l The cell does not work normally.
Procedure
Step 1 Check whether the MS or its SIM card is faulty.
l If faulty, modify or replace the MS or SIM card.
l If normal, go to Step 2.
Step 2 On the BSC6000 Local Maintenance Terminal, check whether GPRS Support in the basic
attribute parameters is selected.
l If it is not selected, set the parameter to enable the MS to run the PS services in the cell.
l If it is selected, go to Step 3.
Step 3 On the Local Maintenance Terminal, run the DSP PSCELL command to verify whether the
cell is in normal state.
l If abnormal, rectify the fault by referring to 9.2.6 Troubleshooting Cell Activity State
Faults (Built-in PCU).
l If normal, go to Step 4.
Step 4 On the BSC6000 Local Maintenance Terminal, check the MCC, MNC, LAC, and CI.
l If the parameters are configured incorrectly, refer to 8.2.2 Troubleshooting Data
Configuration Faults to rectify the fault.
l If the parameters are configured correctly, go to Step 5.
Step 5 On the Local Maintenance Terminal, run the DSP PSRES command to verify the channel
status.
l If the channel is unavailable, check the status of the LAPD link on the BSC6000 Local
Maintenance Terminal; if the OML or RSL is faulty, refer to 4.2 Link Troubleshooting
Methods to rectify the fault.
l If the channel is available, go to Step 6.
Step 6 On the BSC6000 Local Maintenance Terminal, trace the Gb interface SIG and PTP messages.
For details, refer to Tracing SIG Messages on the Gb Interface and Tracing PTP Messages
on the Gb Interface.
After the MS is switched on, check whether the MS ATTACH and PDP Activation messages
are traced. According the reported information, determine the fault type and rectify the fault.
l If the fault is rectified, end the troubleshooting.
l If the fault persists, go to Step 7.
Step 7 On BSC6000 Local Maintenance Terminal, trace the Um interface message. For details, refer
to Tracing PS Domain Messages on the Um Interface.
Check the uplink and downlink messages on the Um interface, and analyze data transmission,
packet assignment, MS access, and immediate assignment to decide whether they are in normal
state. According to the reported information, determine the fault type and rectify the fault.
l If the fault is rectified, end the troubleshooting.
l If the fault persists, contact the Huawei Customer Service Center by referring to 1.3.1
Obtaining Technical Support.
----End
Possible Causes
The possible causes of global service disruption are as follows:
l The equipment is faulty.
l A transmission fault occurs.
l The data configuration is incorrect.
l The software program works abnormally.
Procedure
Step 1 Check whether the equipment is faulty.
1. Check and rectify the fault in power supply.
a. Check whether the power supply LED of the BSC power distribution box is in the
normal status.
l If the LED is abnormal, check whether the -48 V DC power cabinet works properly
and whether the power cables are securely connected to the -48V1 and -48V2
wiring terminals on the power distribution box.
WARNING
Be careful when checking the power cabinet and power cables. Misoperations are
dangerous.
l If normal, go to 1.1.b.
b. Check whether all subracks and LAN switches are powered normally.
l If abnormal, check whether the power switches of the subracks or LAN switches
are set to off, and whether the power input connectors on the subracks and LAN
switches and the -48 V power output connectors on the power distribution box are
in good contact.
l If normal, go to Step 2.
On the BSC6000 Local Maintenance Terminal, view the alarm information to check whether
there are hareware-related alarms. On the Device Panel, check whether the hardware is faulty.
To troubleshoot the fault, refer to 9.1.2 Alarms Related to PS Service Faults.
Check the ports that connect the BSC and the SGSN or BTS, and check whether the trunk cable
is securely connected to the port on the board.
Step 5 Check whether the software program works normally on both BSC and SGSN sides.
On the BSC6000 Local Maintenance Terminal, trace the Um and Gb interface messages and
decide whether the software program is abnormal. For details, see Step 6 and Step 7 described
in 9.2.7 Troubleshooting Cell Service Disruption Faults (Built-in PCU).
----End
Table 9-7 lists the commands frequently used on the PCU maintenance terminal.
NOTE
Each PCU MML command consists of keywords and optional parameters. The format of parameters is
defined as follows:
l < >: indicates mandatory items. The items in the angle brackets cannot be omitted when you enter a
command.
l [ ] : indicates optional items. The items in the brackets can be omitted when you enter a command.
Function Command
Function Command
Setting the loopback status of the LAPD mt lapd port loop set{<LapdNo>|
links <LapdName>}<LoopMode>
LoopMode is of two types:
l NoLoop: no loopback and normal working
mode
l FromE1Line: loopback of the E1 cable. You
need to connect the transmitting end and the
receiving end of the E1 cable.
This describes a typical case of troubleshooting the faults in data configuration or GPRS network
equipment. The faults may cause the MS to fail the network access.
9.3.4 Case: Unstable GPRS Download Rate
This describes a typical case of troubleshooting the unstable GPRS download rate. The fault is
caused by the factors such as channel resources, coding schemes, and Gb interface flow control.
Fault Symptoms
The intermittent LAPD link fault occurs when the E1 cable on the Pb interface is faulty with its
RX end normal but TX end abnormal.
According to the LAPD protocol, the link setup is regarded as successful when the SAMB frame
is received. Therefore, the LAPD link setup is successful if the RX end is normal. If the TX is
abnormal, the interconnection with the peer end fails and the link is broken when the timer
expires. Therefore, if the RX end is normal but the TX end is abnormal, the LAPD links are
intermittent. In addition, the alarm 20083 Remote E1/T1 Alarm (RAI) is reported.
Fault Symptoms
The Gb interface is blocked and the PS service is disrupted because the Gb links are broken.
Fault Symptoms
After switch-on, the MS cannot access the network normally, the MS PDP fails to be activated,
and the MS cannot perform data transmission.
Fault Symptoms
When the MS performs GPRS data transmission, especially through the FTP, the download rate
is unstable.
On the Management Tree tab page of the BSC6000 Local Maintenance Terminal, right-
click BSC6000 and select Configure BSC Attributes. On the displayed dialog box, select
the NS and BSSGP tab page, as shown in Figure 9-6.
This describes cell broadcast faults in terms of the symptoms, troubleshooting methods, and
typical cases.
l The cell broadcast function is enabled, but the MS cannot receive cell broadcast messages.
l The CBT fails to broadcast messages. In this case, a Failed to submit message is displayed.
l The simple cell broadcast function is enabled, but the MS cannot receive cell broadcast
messages.
Table 10-1 lists the alarms related to cell broadcast service faults.
The network connection is faulty. For 102 Disrupted Connection with the CBC
example, the Ethernet cable is loosely
connected.
Table 10-2 lists the counters related to cell broadcast service faults.
Counter Description
Procedure
Step 1 Deal with the reported alarm according to the alarm help.
Step 2 If the alarm persists, determine the subclass of the fault and take the corresponding measure, as
listed in Table 10-3.
The BSC fails to provide the cell broadcast 10.2.1 Troubleshooting Disconnection
service. Between the BSC and the CBC
The CBS.exe file is not running or the SQL Server 10.2.2 Troubleshooting CBS Startup
is not running properly. Failures
The MS cannot make calls or display the network 10.2.5 Troubleshooting Message
properly. The possible cause is that the cell Reception Failures Caused by the MS
broadcast function is disabled or the number of
the channel for cell broadcast is incorrect.
The BSC cannot provide the simple cell broadcast 10.2.6 Troubleshooting Incorrect
service, and the MS cannot receive cell broadcast Parameter Setting of the Simple Cell
messages. Broadcast
Step 3 If the fault persists, contact the Huawei Customer Service Center by referring to 1.3.1 Obtaining
Technical Support.
----End
Possible Causes
The possible causes of the disconnection between the BSC and the CBC are as follows:
Procedure
Step 1 Check whether the GXPUM board is faulty by referring to Querying BSC Board
Information.
l If faulty, rectify the fault by referring to 10.1.2 Alarms Related to Cell Broadcast Service
Faults.
l If not faulty, go to Step 2.
Step 2 Check whether the GOMU/GBAM routing is consistent with the configuration of the CBC.
l If inconsistent, reconfigure the data to keep it consistent. For details, refer to Configuring
Cell Broadcast.
l If consistent, go to Step 3.
NOTE
Check the GOMU/GBAM routing as follows: on the BSC6000 Local Maintenance Terminal, query the
following Basic Data in the Configure BSC Attributes window: CBC IP, CBC Port, CB Interface
IP, CB Port, and CB Interface Handshake.
Step 3 Check whether the transmission cable is faulty. If faulty, rectify the fault by referring to 4.2.9
Troubleshooting E1/T1 Transmission Faults and 4.2.10 Troubleshooting Optical
Transmission Faults.
Step 4 If the fault persists, contact the Huawei Customer Service Center by referring to 1.3.1 Obtaining
Technical Support.
----End
Possible Causes
The possible cause of a CBS startup failure is that the CBS software is closed by mistake or the
SQL Server is malfunctioning.
Procedure
Step 1 Check the running status of the CBS.
Step 2 If neither CBS.exe nor Huawei.exe runs properly, check the cbs.log file in \iMobile\cbs\.
You can infer that an error occurs when the SQL Server is started.
l Check the system tray. If the icon is displayed, you can infer that the SQL Server is
running.
l Check the system tray. If the icon is not displayed, you can infer that the SQL Server
is not started.
Choose Start > Programs > Microsoft SQL Server > Service Manager to start the SQL
Server.
l Check the system tray. If the icon or is displayed, you can infer that the SQL Server
stops running or the running is suspended.
Double-click the icon. In the displayed dialog box, choose Start > Continue (S) to start
or continue to run the SQL Server. If the SQL Server fails to be started, refer to the SQL
Server installation guide to reinstall it.
NOTE
If the iMobile database still fails to be opened, restart the SQL server and then run the CBS.exe file.
----End
Possible Causes
The possible causes of such submit failures are as follows:
l The GXPUM on the BSC side is not running properly.
l The CBC is not configured properly on the BSC side.
l The number of cells that support short message broadcast is 0 in the license file on the BSC
side, or no channel for broadcasting short messages is set up in the cells on the BSC side.
Procedure
Step 1 On the BSC Device Panel tab page of the BSC6000 Local Maintenance Terminal, check
whether the GMPS is configured with the GXPUM and whether the GXPUM is running properly.
l If the GXPUT is not configured, configure it by referring to Configuring the GXPUM
and ensure that it can run properly.
l If the GXPUT is not running properly, rectify the fault by referring to Analysis of
Hardware Faults.
l If the GXPUM is configured and it is running properly, go to Step 2.
Step 2 Check the global data configuration of the BSC.
1. On the Management Tree tab page of the BSC6000 Local Maintenance Terminal, right-
click BSC6000 and select Configure BSC Attributes. A dialog box is displayed, as shown
in Figure 10-1.
2. On the Basic Data tab page, check whether the settings of the following parameters are
consistent with the actual configuration:
l Support Cell Broadcast
l CBC IP
l CBC Port
l CB Interface IP
l CB Interface Port
l CB Interface Handshake
l If inconsistent, modify the parameter settings to keep them consistent.
l If consistent, go to Step 3.
Step 3 On the Local Maintenance Terminal, check the license information and check whether the
parameter settings are consistent with the actual configuration. For detailed operations, refer to
Display License Usage Information(DSP LICUSAGE).
l If the number of TRXs that support short message broadcast is 0, you can infer that the cell
broadcasting function is not enabled. In this case, a new license needs to be requested.
l If the number of TRXs that support short message broadcast is 0, you can infer that the cell
broadcasting function is enabled. Go to Step 4.
Step 4 Check whether the CBCH is configured for the TRX.
l If the CBCH is not configured, configure it on the BSC6000 Local Maintenance
Terminal by referring to Configuring Cell Broadcast.
l If the CBCH is configured, go to Step 5.
Step 5 If the fault persists, contact the Huawei Customer Service Center by referring to 1.3.1 Obtaining
Technical Support.
----End
Possible Causes
The possible causes of parameter setting errors are as follows:
l The number of broadcast support cells exceeds that specified in the BSC license file.
l The cell on which the MS camps is not within the broadcast scope, or the broadcast time
is set incorrectly.
Procedure
Step 1 On the Local Maintenance Terminal, check the AUTHORIZED CBS CELL specified in the
BSC license file. For detailed operations, refer to Display License Usage Information(DSP
LICUSAGE).
Step 2 Check the CBT data configuration to obtain the number of broadcast support cells.
1. Select a message to be broadcast through the CBT software, as shown in Figure 10-2.
2. Right-click the message, and then select Edit from the shortcut menu. A dialog box is
displayed, as shown in Figure 10-3.
3. On the Broadcast Scope tab page, calculate the number of selected cells.
Step 3 Compare the number of broadcast support cells specified in the BSC license file with that
specified in the BSC data configuration.
l If the number of selected cells exceeds the number of broadcast support cells specified in
the BSC license file, consult with the customer about whether to apply for a new license.
l If no new license file is required, remove some cells to cause the number of cells within
the limit specified in the BSC license file.
Step 4 Check whether the cell on which the MS camps is within the broadcast scope, as shown in
Figure 10-3. If the cell is not within the broadcast scope, select the cell in which the message
is to be broadcast.
Step 5 Select the broadcast tab page, as shown in Figure 10-4. Check whether the configured broadcast
time is consistent with the required one. If inconsistent, modify the start time and then submit
the message.
----End
Possible Causes
The possible cause of a message reception failure caused by the MS is that the MS fails to access
the network or the MS disables the function of receiving cell broadcast messages.
Procedure
Step 1 Check whether the MS can make calls and display the MNC.
l If the MS can implement such functions, end the troubleshooting.
l If the MS cannot implement such functions, go to Step 2.
Step 2 Check whether the function of receiving cell broadcast messages is enabled or whether the
number of the channel for cell broadcast is correct.
l If the function of receiving cell broadcast messages is disabled, enable it.
l If the number of the channel for cell broadcast is wrong, correct it.
l If the fault persists, contact the Huawei Customer Service Center by referring to 1.3.1
Obtaining Technical Support.
----End
Possible Causes
The possible causes are as follows:
l The simple cell broadcast function is not enabled on the BSC6000 Local Maintenance
Terminal or the related parameters are set incorrectly.
l The cell broadcast message is not configured on the Local Maintenance Terminal.
Procedure
On the BSC6000 Local Maintenance Terminal, enable the simple cell broadcast function and
configure related parameters. For details, refer to Configuring Simplified Cell Broadcast.
----End
Fault Symptoms
If the user name on the CBT/OMT/MMT is different from that on the CBS, or if the DCOM
configuration is incorrect, the CBT/OMT/MMT fails to connect to the server.
NOTE