ZXWN MGW
Media Gateway
Troubleshooting
Version 3.07
ZTE CORPORATION
ZTE Plaza, Keji Road South,
Hi-Tech Industrial Park,
Nanshan District, Shenzhen,
P. R. China
518057
Tel: (86) 755 26771900
Fax: (86) 755 26770801
URL: http://ensupport.zte.com.cn
E-mail: support@zte.com.cn
LEGAL INFORMATION
Copyright © 2006 ZTE CORPORATION.
The contents of this document are protected by copyright laws and international treaties. Any reproduction or distribution of
this document or any portion of this document, in any form by any means, without the prior written consent of ZTE CORPORATION is prohibited. Additionally, the contents of this document are protected by contractual confidentiality obligations.
All company, brand and product names are trade or service marks, or registered trade or service marks, of ZTE CORPORATION
or of their respective owners.
This document is provided “as is”, and all express, implied, or statutory warranties, representations or conditions are disclaimed, including without limitation any implied warranty of merchantability, fitness for a particular purpose, title or non-infringement. ZTE CORPORATION and its licensors shall not be liable for damages resulting from the use of or reliance on the
information contained herein.
ZTE CORPORATION or its licensors may have current or pending intellectual property rights or applications covering the subject
matter of this document. Except as expressly provided in any written license between ZTE CORPORATION and its licensee,
the user of this document shall not acquire any license to the subject matter herein.
ZTE CORPORATION reserves the right to upgrade or make technical change to this product without further notice.
Users may visit ZTE technical support website http://ensupport.zte.com.cn to inquire related information.
The ultimate right to interpret this product resides in ZTE CORPORATION.
Revision History
Product
Version
Revision
Revision Reason
V3.07.40
20090420–R1.0
First edition
Serial Number: sjzl20092207
Contents
About This Manual.............................................. i
Declaration of RoHS Compliance ........................ i
Troubleshooting ................................................1
Basic Requirements for the Maintenance Personnel ............. 1
Troubleshooting Flow ...................................................... 2
Troubleshooting Principles................................................ 4
Troubleshooting Methods ................................................. 4
Hardware Faults ................................................9
Faults in Board Configuration ........................................... 9
Handling Fault Occurring during Board Configuration ........ 9
An Instance for Handling Board Version Loading
Failure .............................................................12
Faults in Board Running Process ......................................12
Fault Handling Procedure ............................................13
Handling UIM Board Hardware Faults............................14
Handling OMP Board Hardware Faults ...........................17
Handling SMP Board Hardware Faults ...........................19
Handling SIPI Board Hardware Fault.............................20
Handling SPB Board Hardware Faults............................21
Handling CLKG Board Hardware Faults..........................23
Handling IPI Board Fault .............................................24
Handling DTB/DTEC Board Fault ..................................25
Handling APBE Board Fault..........................................26
Handling MRB Board Fault...........................................27
Handling VTCD Board Fault .........................................29
Handling Changeover Exceptions .....................................30
Handling CPU Overload...................................................31
Clock Faults..................................................... 33
Handling System Clock Exception ....................................33
Handling the Clock Lock Failure .......................................35
Handling the Clock Networking Fault ................................38
Handling the Inconsistent Lock Status of Active/Standby
CLKG Boards.........................................................39
Handling the Clock Reference Loss ...................................41
Handling the Output Clock Loss .......................................42
Handling the Slip Code ...................................................44
Interface Faults............................................... 47
Handling MGW-MSCS Interface Fault ................................47
Handling MGW-MGW Interface Fault .................................49
Handling MGW-RNC Interface Fault ..................................50
Handling MGW-PSTN Interface Fault.................................52
Handling MSCS-BSC Interface Fault .................................54
Handling Service Faults ..................................................56
OMM System Faults ......................................... 59
Handling OMM Abrupt Abnormality...................................59
Handling Virus/Security Events........................................62
Analyzing Instance 1......................................................64
Analyzing Instance 2......................................................64
Analyzing Instance 3......................................................65
Analyzing Instance 4......................................................66
Analyzing Instance 5......................................................67
Analyzing Instance 6......................................................68
Analyzing Instance 7......................................................70
Analyzing Instance 8......................................................71
Interconnection Faults in IP-Bearer
Network .......................................................... 73
Handling Continuous Call Loss Generated for Broken
Receiving Fiber of Soft-Switch .................................73
Handling Call Loss Generated by Soft-Switch after CE
Restarts ...............................................................74
Handling Soft-Switch Failing to Ping through CE.................75
Voice Faults..................................................... 77
Common Voice Faults .....................................................77
Troubleshooting Ideas and Common Methods ....................78
Troubleshooting Ideas ................................................78
Common Methods for Locating Faulty NE ......................79
Methods of Locating Internal Fault Points on CN.............81
Echo Fault Handling .......................................................82
Echo Principles ..........................................................82
Working Principles of Echo Canceller ............................83
Principle Overview.............................................83
Echo Directions.................................................84
Echo-Suppression Implementation ...............................85
Configuring Echo Cancellation .............................85
Configuring Echo Cancellation by Adopting
Resource Pool ........................................87
System Implementation .....................................88
Fault Processing ........................................................89
Monolog Fault Handling ..................................................89
Both-Way Silence Fault Handling......................................90
Noise Fault Handling ......................................................92
Cross-Talking Fault Handling ...........................................92
Instance Analysis ..........................................................93
Analyzing Instance 1..................................................93
Analyzing Instance 2..................................................94
Analyzing Instance 3..................................................95
Analyzing Instance 4..................................................96
Figure.............................................................. 99
Table ............................................................. 101
Index ............................................................ 103
About This Manual
Purpose
At first, thank you for choosing ZXWN wireless core network system of ZTE Corporation!
ZXWN system is the 3G mobile communication system developed
based on the UMTS technology. ZXWN system boasts powerful
service processing capability in both CS domain and PS domain,
providing more abundant service contents. Comparing with the
GSM, ZXWN provides telecommunication services in wider range,
capable of transmitting sound, data, graphics and other multi-media services. In addition, ZXWN has higher speed and resource utilization rate. ZXWN wireless core network system supports both
2G and 3G subscriber access, and provides various services related with the 3G core network.
ZXWN MGW Media Gateway boasts the functions of media control and media flow control, and provides transmission resources.
ZXWN MGW is totally compatible with 3GPP R4 of June 2003, and
is downward compatible with 3GPP R99 of June 2002. ZXWN
MGW not only supports the networking mode of bearer independent of control in 3GPP R4, but also can be bound to a MSC with
ZXWN MSCS, supporting the networking mode of 3GPP R99. Besides satisfying the requirements of constructing the common mobile switching network, ZXWN MSCS also can satisfy the requirements of construct the No.7 signaling network and mobile intelligent network, and can be adapted to various complicated networking modes of the mobile switching network. Thus the continuity
development capability of the network is improved.
The purpose of writing this manual is to provide procedures and
guidelines that support the maintenance of ZXWN MGW.
Intended
Audience
This document is intended for engineers and technicians who perform maintenance activities on ZXWN MGW.
Prerequisite Skill
and Knowledge
To use this document effectively, users should have a general understanding of wireless telecommunications technology. Familiarity with the following is helpful.
What Is in This
Manual
�
ZXWN MGW system and its various components
�
User interfaces on the ZXWN MGW
�
ZXWN MGW operating procedures.
This manual contains the following chapters:
Chapter
Summary
Chapter 1, Troubleshooting
Introduces troubleshooting
background, troubleshooting
sequence, troubleshooting
methods and types of faults.
Chapter 2, Hardware Faults
Introduces about the hardware
faults.
Chapter 3, Clock Faults
Introduces about the clock faults.
Confidential and Proprietary Information of ZTE CORPORATION
i
ZXWN MGW Troubleshooting
Conventions
Chapter
Summary
Chapter 4, Interface Faults
Introduces about the interface
and service faults.
Chapter 5, OMM System Faults
Introduces about the OMM system
faults.
Chapter 6, Interconnection Faults
in IP-Bearer Network
Introduces about the
interconnection faults in IP
bearer network.
Chapter 7, Voice Faults
Introduces the methods of
handling voice faults occurring in
the CN.
ZTE documents employ the following typographical conventions.
Typeface
Meaning
Italics
References to other Manuals and documents.
“Quotes”
Links on screens.
Bold
Menus, menu options, function names, input fields,
radio button names, check boxes, drop-down lists,
dialog box names, window names.
CAPS
Keys on the keyboard and buttons on screens and
company name.
Note: Provides additional information about a
certain topic.
Mouse operation conventions are listed as follows:
ii
Typeface
Meaning
Click
Refers to clicking the primary mouse button (usually the
left mouse button) once.
Doubleclick
Refers to quickly clicking the primary mouse button
(usually the left mouse button) twice.
Right-click
Refers to clicking the secondary mouse button (usually
the right mouse button) once.
Confidential and Proprietary Information of ZTE CORPORATION
Declaration of RoHS
Compliance
To minimize the environmental impact and take more responsibility to the earth we live, this document shall serve as formal
declaration that ZXWN MGW manufactured by ZTE CORPORATION
are in compliance with the Directive 2002/95/EC of the European
Parliament - RoHS (Restriction of Hazardous Substances) with respect to the following substances:
�
Lead (Pb)
�
Mercury (Hg)
�
Cadmium (Cd)
�
Hexavalent Chromium (Cr (VI))
�
PolyBrominated Biphenyls (PBB’s)
�
PolyBrominated Diphenyl Ethers (PBDE’s)
…
The ZXWN MGW manufactured by ZTE CORPORATION meet the
requirements of EU 2002/95/EC; however, some assemblies
are customized to client specifications. Addition of specialized,
customer-specified materials or processes which do not meet the
requirements of EU 2002/95/EC may negate RoHS compliance of the
assembly. To guarantee compliance of the assembly, the need for
compliant product must be communicated to ZTE CORPORATION in
written form. This declaration is issued based on our current level
of knowledge. Since conditions of use are outside our control, ZTE
CORPORATION makes no warranties, express or implied, and assumes
no liability in connection with the use of this information.
Confidential and Proprietary Information of ZTE CORPORATION
i
ZXWN MGW Troubleshooting
This page is intentionally blank.
ii
Confidential and Proprietary Information of ZTE CORPORATION
Chapter
1
Troubleshooting
Table of Contents
Basic Requirements for the Maintenance Personnel .................
Troubleshooting Flow ..........................................................
Troubleshooting Principles....................................................
Troubleshooting Methods .....................................................
1
2
4
4
Basic Requirements for the
Maintenance Personnel
Knowledge
Networking
and Running
Environment
Operations
�
Get familiar with the communication knowledge, such as mobile communication principles, ATM principles and soft-switching principle.
�
Get familiar with signaling protocols related with , BICC No.7
signaling and H.248 signaling.
�
Get familiar with related international technical regulations.
�
Understand billing principles and flows.
�
Understand basic knowledge about computer networks, including Ethernet, TCP/IP, Client/Server architecture and Oracle
database.
�
Get familiar with product knowledge of the ZXWN MGW system,
concerning functional structure, call flow, and service flow.
�
Know hardware architecture and performance of the ZXWN
MGW system very well.
�
Know the inter-module routing and routing between modules
and offices in the ZXWN MGW system very well.
�
Know signaling and protocols of the ZXWN MGW system and
the networking equipments very well.
�
Get familiar with the network architecture and channel allocation of the relevant transmission equipment.
�
Master daily operations of the ZXWN MGW system.
�
Know well which operations will cause the interruption of part
of or all services.
�
Know well which operations will cause damage to the equipment.
Confidential and Proprietary Information of ZTE CORPORATION
1
ZXWN MGW Troubleshooting
Instruments and
Meters
�
Know well which operations will cause vital effects on the
billing.
�
Know well which operations will cause the subscriber’s complaint.
�
Know well emergency or backup measures.
The maintenance personnel of the ZXWN MGW system must get
familiar with how to use instruments and meters to locate a fault.
The common instruments and meters include multi-meter and the
SS7 analyzer.
Troubleshooting Flow
The troubleshooting flow of the ZXWN MGW system is shown Figure 1.
2
Confidential and Proprietary Information of ZTE CORPORATION
Chapter 1 Troubleshooting
FIGURE 1 TROUBLESHOOTING FLOW
Confidential and Proprietary Information of ZTE CORPORATION
3
ZXWN MGW Troubleshooting
The above flow describes the location and processing flow of the
non-emergency fault. As for the emergency fault, inform local
ZTE office or call ZTE Global Customer Support Center as earliest
as possible, and operate the equipments under the instruction of
the ZTE technical support personnel.
Troubleshooting Principles
When performing the troubleshooting, follow the troubleshooting
flow and the basic principles: check, ask, think and act.
Check
Check the phenomena of the fault first, that is, check which part of
the equipment is faulty and which alarm is generated, and check
the severity degree and the harm caused.
For the phenomena checking, the system provides various tools,
such as the performance statistics, the signaling tracing, the alarm
query, the log query and failure observation.
Ask
After checking the phenomena, the maintenance personnel must
inquiry the onsite personnel of each phase about the fault causes,
such as that the data have been modified, that the file has been
deleted, that the circuit board has been replaced, and that power
cut, lightening or incorrect operation has occurred.
Think
Combining the on-site phenomena checked and the results acquired with the communication knowledge, think, analyze and
judge the possible reason that may cause such fault, and then
make the correct judgment.
Act
Find out the fault point based on the above three steps, solve and
eliminate the fault by modifying data, replacing the circuit board,
and so on.
When operating the equipment, the maintenance personnel must
consider whether it is the busy hour, and the potential consequence
of operating at the busy hour. As for uncertain problems, the personnel must consult ZTE technical support personnel.
Troubleshooting Methods
Analyzing Fault
Information
The fault information analysis is mainly used to judge the range
and category of the fault, providing the evidence for reducing the
fault range and initially locating the fault on the primary phase of
the fault processing. The personnel with rich maintenance experiences can even locate the fault directly.
The collection and analysis of the fault information plays a vital role in processing other kinds of faults, especially the trunk
fault, for the trunk needs to connect with the transmission system
and there are signaling coordination problems. The fault information includes whether the transmission system runs normally, and
whether the data or definitions of some signaling parameters have
been changed by the opposite-end office.
4
Confidential and Proprietary Information of ZTE CORPORATION
Chapter 1 Troubleshooting
Analyzing Alarm
Information
The alarm information refers to the information transferred from
the ZXWN MGW alarm system in the mode of sound, light or screen
output. The alarm information features briefness and large and
complete contents, involving the hardware, link, trunk, billing, CPU
load and other parts of the ZXWN MGW. It is one of the important
evidences for the fault analysis and location.
The alarm information analysis is mainly used to find out the specific location or cause of the fault. Because the alarm information
outputted by the Fault Management System of ZXWN MGW has
large and complete contents, it is usually used to directly locate
the fault cause, or coordinate with other methods to locate the
fault cause. It is one of main methods to analyze the fault.
With high location accuracy, the alarm generated by ZXWN MGW,
for example, can test and locate each circuit of the signaling system. When the alarm station generates several alarm messages,
firstly process the fault alarm with high level according to the alarm
level, and then process the event alarm.
Indicators Status
Every board of the ZXWN MGW is equipped with corresponding
running and status indicators, and some board is even equipped
with the function or feature indicator. Board indicators reflect the
working status of the board, and most of them can reflect the status of link, optical channel, node, channel, active/standby servers
and others serving as one of important bases for fault analysis and
location.
The indicator status analysis is used to quickly find the fault position or cause, preparing for further processing. Due to the relatively inadequate information provided by the indicator, it is usually
used together with the alarm analysis.
Signaling Tracing
The signaling tracing plays an important role in analyzing the failure cause of the subscriber call connection and inter-office signaling coordination. The cause for the call failure can be obtained
from results of the signaling tracing, which is helpful for the subsequent analysis. ZXWN MGW provides a lot of signaling tracing
methods.
Log Querying
Because the data configuration of ZXWN MGW is complex, incomplete configuration often causes faults. To quickly locate such
faults, it is required to query the data configuration performed by
the maintenance personnel. ZXWN MGW provides the log querying function, which can record the operator’s operation. Besides
querying the log information of the local office, inquire about the
data modification made by the opposite end office, when some
problems are related to the opposite-end office.
Test and Self-Loop
�
Test
With the aid of instruments or testing software, test the corresponding technical parameters of subscriber lines, transmission channels and trunk equipment that probably have faults,
and judge whether the equipment is faulty or going to be faulty
based on the test results.
In addition, ZXWN MGW supports testing a CPU on a board
instantly, and scheduling the task to test CPUs periodically or
in batches, too.
�
Self loop
Self-loop refers to testing the transmission equipment or
transmission channel by adopting the self-transmitting and
Confidential and Proprietary Information of ZTE CORPORATION
5
ZXWN MGW Troubleshooting
self-receiving method in hardware or software mode, to judge
whether such conditions as the transmission equipment, the
transmission channel, the service status and the signaling
coordination are normal. Through these conditions, confirm
whether the condition of the corresponding hardware and
the software parameter settings are normal. This method is
mostly used to locate the transmission problems and judge
the correctness of the trunk parameter settings.
When locating the fault related to the transmission, test is often
used together with self-loop. Self-loop can be divided into hardware self-loop and software self-loop. The latter one is featured
by simple operation and flexible usage, but its reliability is not as
good as the hardware self-loop. In addition, during the course of
the office commissioning and trunk expansion, the trunk self-loop
of ZXWN MGW is often used to judge the correctness of such aspects as the trunk parameter settings of the local office and the
outgoing routing data configuration.
Caution:
Cancel the software self-loop once the troubleshooting is completed. Therefore, it is recommended for the maintenance personnel to form a habit of making records to avoid such things.
Unplugging/Plugging
When the circuit board is faulty, eliminate such faults as poor
contact or processor exception by plugging/unplugging the circuit
board and external interface connector.
During the course of plugging/unplugging the board, the operation regulations of plugging/unplugging the board must be strictly
complied with; otherwise, the board and other components may
be damaged.
Comparison and
Interchange
�
Comparison
Comparison refers to comparing the faulty component or fault
phenomenon with the normal one and performing analysis to
find the differences and locate the fault. This method is applicable to the situation of single fault.
�
Interchange
Interchange refers to interchanging a faulty component with
the normal one (such as the board or the fiber) when the fault
range or the faulty component still cannot be confirmed after
replacing the components with spare parts. Then compare the
new running status with the previous status to judge the fault
range or location.
6
Confidential and Proprietary Information of ZTE CORPORATION
Chapter 1 Troubleshooting
Caution:
Take all precautionary measures while interchanging the board,
because board interchange has a high risk and is easy to bring
new problems. Interchange operation should only be applicable
to the components such as optical fiber and E1. Perform board
replacement or board interchange when the traffic is low, for example, 0:00 ~ 6:00.
Configuration
Modification
The modified configuration contents can include the timeslot, the
board position, the board parameters, the number selector, the
number properties, the trunk properties and the protocol type.
So this method is applicable to eliminate the fault caused by the
configuration error after locating the fault to the single site.
For example, given that the signaling link to an office direction is
abnormal, which affects the signaling transmitted through the link
and services related to the link. The following configuration data
can be modified:
1. Change the signaling route so as the new route does not use
the signaling link to this office direction. If the fault disappears,
it indicates that the fault lies in the original route.
2. Change the signaling link group so as the new signaling link
group does not use the signaling link to this office direction.
If the fault disappears, it indicates that the fault lies in the
original link group.
3. Change the SPB channel used by the signaling so as the new
signaling does not use the channel on the original SPB. If the
fault disappears, it indicates the fault is related to the original
SPB.
In the process of version upgrading or capacity expansion, the
original configuration can be deployed again to locate the fault
when doubting that there are errors in the new configuration.
When the fault cannot be exactly located to the board by modifying
the timeslot configuration, the replacement method is required to
further locate the fault. Therefore, under the condition of no spare
board available, this method is applicable to preliminarily locate
the fault type and temporarily recover the services by using the
other service channels or board positions.
Performance
Statistics
The performance statistics is mainly used to locate the system
resource fault.
The performance measurement analysis is to create the performance measurement task through the ZXWN MGW performance
statistic function, to analyze the possible cause and range of the
fault. Usually, its result is important for fault handling.
Coordinating with the signaling tracing tool, the performance statistical tool plays an important role in finding abnormal inter-office signaling coordination and the trunk parameter setting error.
Therefore, the maintenance personnel should master it.
Configuring Data
The configured data decides the working and coordinating mode
of the system. Generally, the data modification is not allowed.
Some special conditions, such as the abrupt change of the external
environment or the wrong operation, probably cause the damage
Confidential and Proprietary Information of ZTE CORPORATION
7
ZXWN MGW Troubleshooting
or modification of the configuration data of the equipment, and the
service interruption as well.
If the fault has been located to the local system, it is capable to
query and analyze the current configuration data, and identify the
wrong operation of the network management by checking the user
operating logs of the network management.
Only the maintenance personnel with rich experiences and knowing well the equipment can analyze the configuration data.
Experience
Processing
Such special condition as instantaneous abnormal power supply,
low voltage and the strong external electromagnetic interference
can cause the abnormal working status of the board. The service
may be interrupted, accompanied with corresponding alarm, or no
alarm. And the configuration data of each board may be normal.
Testified by the experiences, the fault can be effectively handled by
using such methods as resetting the board, restarting the equipment after power-off, synchronizing the data again or switching
the MP.
It is recommended not to use this method frequently, as this
method cannot completely find out the fault reason. Except for
the emergency, preferentially adopt previous methods or ask
for the technical support through the normal channel to locate
the fault to eliminate the external/internal hidden trouble of the
equipment.
8
Confidential and Proprietary Information of ZTE CORPORATION
Chapter
2
Hardware Faults
Table of Contents
Faults in Board Configuration ............................................... 9
Faults in Board Running Process ..........................................12
Handling Changeover Exceptions .........................................30
Handling CPU Overload.......................................................31
Faults in Board Configuration
This section describes how to handle the faults occurring during
board configuration.
Handling Fault Occurring during
Board Configuration
Background
ZXWN MGW adopts integrated hardware platform. According to
different board types, the loaded board falls into loading OMP
board and non-OMP board.
When OMP board starts, it requests profile from OMM server
through IP address that is allocated during serial port debugging.
If the profile can be obtained, OMP board compares it with the
local file. If they are consistent, OMP board invokes the version
from the local hard disk for starting. Otherwise, it obtains the
version file from OMM server for starting, and modifies the local
profile at the same time. If the profile is unavailable, OMP starts
according to the local profile.
Non-OMP board requests the version file from active OMP instead
of from OMM server for starting. If non-OMP board obtains the
version file from OMP successfully, it uses the obtained version file
for starting. Otherwise, it invokes the version file stored on its
own FLASH.
Common
Phenomena
Common Causes
�
Board indicators failed to be illuminated normally.
�
The OMM alarm system prompts that the board is offline or
unstable.
During board configuration, the common fault causes are as follows.
1. Board fault occurs in the BOOT phase.
Confidential and Proprietary Information of ZTE CORPORATION
9
ZXWN MGW Troubleshooting
Hardware problems result in a lot of boards failing to start, such
as FLASH, RAM, hard disk, and some sub-cards. Poor contact
between backplane and boards may also cause such problems.
In these cases, faulty device can be located through the serial
port printing. To locate the device fault, replace the related
devices with spare parts to exclude the devices one by one.
Generally, all devices complete self-test in the production
phase. However, faults may occur in transit. Some faults
can be handled manually, for example, installing hard disk or
memory bar again. But in most cases, the board needs to be
sent back for repairing.
2. Slot or backplane error occurs in the BOOT phase.
Some boards failed to start due to slot or backplane problem. To locate it, plug the normal board into the faulty slot.
If the board still fails to start, then there are some problems in
the slot or backplane. On site, check whether the configuration conforms to the platform specifications for the slots, and
whether the backplane of this slot is damaged physically.
If the fault results from the physical fault of the slot or backplane, do not use this slot to avoid the fault on site.
3. The error occurs while downloading a version.
Check whether the shelf control-plane connection-line corresponding to this slot is normal. Usually, all of the boards in the
shelf cannot start if there are some problems in the connection
line. Some faulty chips in the UIM board may also cause some
slots in the shelf failing to start.
4. BSP self-test error
Generally, if there are some problems in the equipment hardware, view the alarms on the background to find out specific
causes. In some exceptional cases, the LED indicator of the
board is physically faulty, but the board works normally.
To handle the fault occurring in this phase, send the board back
for repairing.
5. Errors occur in other subsequent phases.
Usually the hardware works normally in these phases. The
fault is due to the software configuration error. While handling
the fault, first check whether the software version and related
chip version are correct through the alarms corresponding to
the version management. Then check whether the slot restriction, HW distribution, and port configuration are reasonable. Finally check whether the active/standby configuration
or load-sharing configuration is correct.
Flow Diagram
10
Figure 2 shows the flow of handling the fault occurring during board
configuration.
Confidential and Proprietary Information of ZTE CORPORATION
Chapter 2 Hardware Faults
FIGURE 2 HANDLING THE FAULT OCCURRING DURING BOARD
CONFIGURATION
Fault Handling
Procedure
1. Check whether version loading is finished for all the boards
in the Version Management tab of the Professional Maintenance window of the NetNumen M30 window. Check
whether the OMPCFGx.INI profile (x is the office number) exists in the folder zxwomcs\ums-svr of the installation directory
on the OMM server. Check whether the loaded version file
exists in the zxwomcs\ums-svr\cnvmVerFile directory.
If there is no OMPCFGx.INI file in the specified directory, create
the OMP boot file in the Version Management window. If
there is no loaded version file in the specified directory, load
the version again.
2. On the File Management window of Local Maintenance Tool,
check whether the version file exists on the hard disk (named
as /DOC0) and memory (named as /IDE0) of OMP board.
If the version file does not exist in the specified directory
(/DOC0/VER and /IDE0/RELEVER) of hard disk on the OMP
board, load the version again.
3. On the File Management interface of Local Maintenance Tool,
check whether version files on other boards are correct. In
general, version files exist in the /FLASH0/VER directory.
If you failed to query the version file with the file management
function of Local Maintenance Tool, check the running status
of the board, implement the troubleshooting flow of board. If
the queried version file is wrong, load the correct version file
for this board in the Version Management tab.
Confidential and Proprietary Information of ZTE CORPORATION
11
ZXWN MGW Troubleshooting
4. Check the working status of UIM and CHUB boards. If they are
faulty, the communication between OMP and other boards will
be interrupted. As a result, other boards cannot load version
file from OMP.
If UIM and CHUB boards work abnormally, check their hardware configuration and version loading to make sure that they
run normally.
An Instance for Handling Board
Version Loading Failure
Topic
Handling board version loading failure
Symptom
ZXWN MGW may upload version files to server when loading version files in batch by default. But it cannot complete foreground
switching. No prompt is displayed during this process.
Solution
1. Check whether the communication between background server
and foreground OMP is normal. Find that the background can
ping through the foreground. Check CPU1 on OMP board, and
find that the OMP board runs normally, and the RUN2 indicator
on its panel is in normal status.
2. To make sure whether the OMP gets the version files to be
loaded, check whether there are three files (*.BIN, *.RBF and
*.ini) in the \ZXWN-OMCS\zxwomcs\ums-svr directory on OMM
server, and then restart the OMP. Check whether the OMP configuration is correct, whether the OMP gets the version from
server. The results meet the requirements. After restarting
the OMP, log in the OMP from hyper-terminal, and check the
working status of the board with the SCSSHowMcmInfo command. The board is normal. Therefore, the board hardware is
not faulty.
3. Check the OMP board again, and find that the RPU fails to start.
Check whether the background is configured with the capacity
of office data. Restart the OMP. The problem still remains.
4. Probably the problem lies in FTP settings. On the Professional
Maintenance > Version Management tab of the NetNumen M30 window, click the Get OMP’s OMC FTP Address
button on the sub-tool. Find that the server IP address for
version downloading is 127.0.0.1. Modify it to the server’s intranet IP address. After that, version loading is normal.
Summery
The FTP address of OMM server must be configured correctly for
OMP board to get version files during the version-loading process.
Faults in Board Running
Process
This section describes how to handle the faults occurring during
the running process of boards.
12
Confidential and Proprietary Information of ZTE CORPORATION
Chapter 2 Hardware Faults
Fault Handling Procedure
Common Fault
Phenomena
Common Causes
of Faults
Flow
�
Indicators on board cannot be illuminated normally.
�
OMM fault management system prompts that a board is offline
or unstable.
�
All board-related services are interrupted.
�
Malfunctioning board’s own hardware fault
�
Upper-level board of the board that reports an alarm is faulty.
�
Poor contact between board and its slot
�
Backplane is faulty.
�
Port connection of the board is faulty.
�
UIM board fault
�
CHUB board fault
Figure 3 shows the flow of handling the common faults occurring
during the running process of boards.
FIGURE 3 HANDLING COMMON FAULTS
Precautions
OF
BOARDS
Board changeover, reset, and replacement will bring some influence on the system. These operations must be implemented under the guide of ZTE technical supporters. Furthermore, board replacement procedure must strictly conform to the operating specifications. Refer to ZXWN MGW Board Replace for details.
Confidential and Proprietary Information of ZTE CORPORATION
13
ZXWN MGW Troubleshooting
Handling UIM Board Hardware Faults
Background
UIM board implements functions of managing resource shelf, the
Ethernet Level-2 switching, and the circuit domain timeslot multiplexing/exchanging in the resource shelf. Meanwhile, the UIM
board provides external interfaces of the resource shelf, including
the packet data interfaces (GE optical interfaces) connecting with
the core switching unit, the circuit domain interfaces (optical interfaces) connecting with the circuit switching units and the control
plane data Ethernet interfaces (4 FEs) of the distributed processing platform. The UIM board provides the control plane, the media
plane and the HW resources for this resource shelf. The UIM board
can be divided into several types, as described in Table 1.
TABLE 1 UIM TYPES
Board
Name
Function
UIMC
Universal Interface
Module of Control
Having the GCX sub-card, without the T network and the media
plane, and only providing the control plane resources
UIMP
Universal Interface
Module of Packet
Having the GXS sub-card, without
the T network resources, and providing the control plane resources
and the media plane resources
UIMT
Universal Interface
Module of TSNB
Having the TDM optical interface,
introducing the TSNB 8K timeslot
resources to this recourse shelf,
and providing the big T network
resources and the control plane
resources
UIMC
Universal Interface
Module of BUSN
Having the small T network and
the GXS sub-card, and providing the control plane, media
plane and inner-shelf 4K timeslot
switching resources
The UIM cable has the following types:
14
�
Clock connection line: adopts the ZTE dedicated clock cable,
connecting the RCLKG to the UIM. It sends the CLKG clock
signal to the UIM, and then the UIM provides the clock signal
to each board in the shelf.
�
Control plane connection line: adopts the ZTE dedicated cable
in the case of an office with multiple shelves, connecting the
RUIM (UIM rear board) to the RCHB (CHUB rear board); adopts
the straight Ethernet cable in the case of an office with two
shelves, connecting from the RUIM of the main control shelf to
that of non-main control shelf.
�
TDM connection line: used in the case of an office with the big
T network, and adopts the fiber, connecting from the TFI of
the core switching shelf in the circuit domain to the UIMT of
the resource shelf.
Confidential and Proprietary Information of ZTE CORPORATION
Chapter 2 Hardware Faults
Fault Phenomenon
Flow
�
Media plane connection line: used in the case of an office with
Level-1 switching shelf, and adopts the fiber, connecting from
the GLIQV board of the Level-1 switching shelf to the UIM.
�
The network management alarm system reports that the OSS
interruption occurs to several or all boards, and the network
interface of the control plane is blocked.
�
The ALM indicator on the UIM board gives alarms. And the
network management system reports the 8K and 16M clock
input loss.
�
Plugging/unplugging the board except the UIM causes alarms
that other online boards are abnormal.
�
There are whole-shelf HW loopback detection alarms in resource shelf.
The troubleshooting flow of the UIM fault is shown in Figure 4.
FIGURE 4 TROUBLESHOOTING FLOW
Solution
OF
UIM FAULT
1. When the fault occurs on the UIM board, checking the fault
from the indicators on the board is a relatively direct method.
Sometimes, it is the only method. Table 2 lists the meanings
of the indicators on the UIM board.
The normal running status is that the RUN indicator flashes at
1 Hz, and both the ALM indicator and the ENUM indicator are
constantly off.
�
If the RUN, ALM, and ENUM indicators are on, usually the
board breaks down.
Confidential and Proprietary Information of ZTE CORPORATION
15
ZXWN MGW Troubleshooting
�
�
�
�
If the ENUM indicator is on, the board is not plugged well.
Check whether the board is plugged well, and whether the
extractor is closed.
If the RUN indicator stays off, there is hardware fault occurs
on the board. Replace the board.
If the RUN indicator and ALM indicator are on constantly,
there is a hardware logic problem in the board. It probably
needs to update the chips on the board, which can be solved
by replacing the board on site.
If the RUN indicator flashes quickly, the board is loading
the version information. If the board cannot work normally,
check whether the hardware configuration and loaded version are correct.
TABLE 2 INDICATORS
ON
UIM
Indicator
Description
RUN
Run indicator
The board runs normally - flashing at 1 Hz.
ALM
Alarm indicator
ACT
Active/standby indicator
On – Active, off - Standby
ENUM
Board plugging/unplugging indicator
On: the board is not well plugged
ACT-P
Active indicator of the board packet domain
On: the board packet domain is active
ACT-T
Active indicator of the board circuit domain
On: the board circuit domain is active
16
ACT1
Optical interface 1 is active when plugging
the GXS sub-card.
ACT2
Optical interface 2 is active when plugging
the GXS sub-card.
LINK1
On: the FE-C1 port on the rear board is link
up
LINK2
On: the FE-C2 port on the rear board is link
up
LINK3
On: the FE-C3 port on the rear board is link
up
LINK4
On: the FE-C4 port on the rear board is link
up
SD1
There is signal in the optical interface 1
when plugging the GXS sub-card.
SD2
There is signal in the optical interface 2
when plugging the GXS sub-card.
Confidential and Proprietary Information of ZTE CORPORATION
Chapter 2 Hardware Faults
Indicator
Description
SD3
There is signal in the first TDM optical
interface when using the TDM optical
interface.
SD4
There is signal in the second TDM optical
interface when using the TDM optical
interface.
2. Switch the active/standby UIM, to check whether the fault disappears. But it is recommended not to plug/unplug the possible faulty board, because the fault possibly will not appear
again. The faulty board can be plugged and unplugged if the
changeover fails. If the fault still exists, replace the faulty UIM
board.
3. Whole-shelf HW loopback detection alarms of the resource
shelf: the T network related part is abnormal, check such
items as the small T network configuration of the UIMU board,
whether the physical connection between the UIMT and the
TFI is consistent with the UIM-COMM-TFI configuration port,
the physical connection, and the connection indicator.
Handling OMP Board Hardware
Faults
Background
The OMP board is responsible for the operation, maintenance and
management of the whole NEs on the foreground. It receives the
instructions from the OMM, reports various alarm information, traffic statistical information and tracing message specified by the subscribers to the OMM. It is the operation and maintenance center
of the system. The OMP is also responsible for managing and distributing the software version of all of boards on the foreground.
Each board needs to load the required version file from the OMP
for starting.
The OMP connects to the IP network externally through the OMC2
interface on the RMPB rear board, implementing the communication with the OMM server.
Fault Phenomenon
Flow
�
The Run indicator on the panel of the OMP board cannot flash
at 1 Hz normally, continuously alternating between flashing
quickly and turning off.
�
The OMM alarm system reports that the communication between the OMP board and the foreground fails, unable to transmit any data to the foreground.
�
The NE maintenance tools of the foreground, such as the signaling tracing and failure observation, cannot work normally.
�
The OMP board is in a deadlock.
The troubleshooting flow of the OMP fault is shown in Figure 5.
Confidential and Proprietary Information of ZTE CORPORATION
17
ZXWN MGW Troubleshooting
FIGURE 5 TROUBLESHOOTING FLOW
Solution
OMP FAULT
1. Observing the status of the RUN2 indicator on the OMP board,
first judge whether the board works normally. There are two
CPUs on the OMP board. The CPU1 belongs to the RPU module, while the CPU2 belongs to the OMP board. In the normal
working status, the RUN2 indicator of the OMP module flashes
at 1 Hz. Otherwise, there is fault in the OMP module.
�
�
�
�
18
OF
If the ENUM2 indicator is on, the board is not plugged well.
Check whether the board is plugged well, and whether the
extractor is closed.
If the RUN2 indicator stays off, there is hardware fault occurs in the board. Replace the board.
If both the RUN2 indicator and ALM2 indicator stay on,
there is a hardware logic problem in the board. It probably needs to update the onboard chips. It can be solved
by replacing the board on site.
If the RUN2 indicator flashes quickly, it indicates that the
board is loading the version information. If the board cannot work properly, check whether the hardware configuration and loaded version are correct.
Confidential and Proprietary Information of ZTE CORPORATION
Chapter 2 Hardware Faults
�
If the HD2 indicator stays on, it indicates that the board is
reading the hard disk all the time. Probably, there is a fault
in the hard disk of the board. Replace the board.
2. On the OMM client, perform the active/standby changeover for
the OMP board. If the changeover is failed, directly press the
EXCH key on the board for a while to implement hardware
changeover.
3. If the fault still remains after changeover, reset the OMP board.
Reset the board on the OMM client. If the resetting is unsuccessful, press the Reset key on the board with a tool to reset
the board forcefully. If the fault still remains after resetting,
replace the OMP board to make sure whether it is the hardware
fault.
4. If the fault still remains, check the pins on the backplane
to eliminate the contact problem. Check whether the DIP
switches on the backplane are correct. The DIP switches in
the shelf where the OMP is located are fixedly in the No.2 shelf
in the No. 1 rack.
Handling SMP Board Hardware
Faults
Background
The SMP board processes the MTP3 and its upper-layer protocols,
including the CC, MM, SCCP, BSSAP, BSSAP+, RANAP and H.248
protocol. It is the center of all services of the control system.
According to different functions, the SMP board is divided into the
signaling SMP and service SMP.
�
The signaling SMP is responsible for processing signaling, such
as the SIGTRAN protocol.
�
The service SMP is responsible for various upper-level services,
such as the call control and the mobility management.
In addition, the SMP generates the original CDR that is forwarded
by the USI to the billing server through the internal bus.
Without external interfaces, the SMP does not need the rear board
and the connection lines.
Fault Phenomenon
Solution
�
There are OSS communication interruption alarms in the network management.
�
The RUN indicator of the SMP board cannot flash at 1Hz, continuously alternating between flashing quickly and turning off.
�
Some signaling links are unavailable.
�
The services of some subscribers are interrupted.
Both the SMP and the OMP adopt the MPx86 physical board. For
the fault handling procedures, refer to “Solution” in Handling OMP
Board Hardware Faults.
Confidential and Proprietary Information of ZTE CORPORATION
19
ZXWN MGW Troubleshooting
Handling SIPI Board Hardware Fault
Background
The SIPI board is responsible for providing the bottom-layer IP
interface for SIGTRAN, and the external IP interface as well.
The RMNIC rear board provides the external interface of the SIPI,
connecting to the IP network with the network cable, and interconnecting with the adjacent office interface.
Fault Phenomenon
Flow
�
The fault management system on the OMM client prompts that
the association is interrupted.
�
The RUN indicator on the SIPI board flashes abnormally.
�
The office direction of some associations is unreachable.
�
Subscriber services are interrupted.
Figure 6 shows the flow of troubleshooting the SIPI board fault.
FIGURE 6 HANDLING
Solution
THE
SIPI BOARD FAULT
1. The MNIC does not need the FE port when serving as the SIPI
board. At this time, set the number of FE ports as zero.
2. The SIPI board connects the external network with the FE1
network interface, and the internal control plane with the FE3
network interface. Check the network cable to make sure that
the connection of network interfaces is normal.
3. Locate and replace the SIPI board with the replacement
method. Make sure whether the fault results from itself or
other boards.
Example: When the OMP is faulty, the SIPI cannot load the
version file while starting, resulting in the activation failure of
the SIPI board. When the UIM is faulty, the SIPI cannot communicate normally.
20
Confidential and Proprietary Information of ZTE CORPORATION
Chapter 2 Hardware Faults
Handling SPB Board Hardware
Faults
Background
The SPB is responsible for processing the narrowband Signaling
System No.7 (SS7) MTP-2 protocol and its lower-layer protocols.
Each board provides 16 E1s externally for accessing, and extracts
the 8K line clock reference to the CLKG. In addition, the SPB can
be set with the 75 Ω or 120 Ω transmission mode according to
different impedance characteristics of the transmission line.
The SPB connects with other offices through the interfaces on the
RSPB rear board, adopting the ZTE dedicated transmission cable
as the connection line.
Fault Phenomenon
Flow
�
The board cannot be started, or in a deadlock while running.
The alarm indicator on the board flashes.
�
The fault management system prompts that the bit errors exist
in the link layer, or that the CRC check fails.
�
Some or all links on the SPB board are interrupted.
The troubleshooting flow of the SPB fault is shown in Figure 7.
FIGURE 7 TROUBLESHOOTING FLOW
OF
SPB BOARD
Confidential and Proprietary Information of ZTE CORPORATION
21
ZXWN MGW Troubleshooting
Solution
1. Check whether the CPU1 is normal.
There are up to four CPUs on the SPB board. The CPU1, as the
primary CPU, manages the board resources, including turning
on each indicator. The rest three CPUs are the secondary CPUs.
Therefore, check the status of CPU1 first when the board cannot be start or in a deadlock during the running.
Check the CPUs of the SPB board in the Rackchart Management tab of the Daily Maintenance window of the NetNumen M30 window. The system will display the status of four
CPUs. Check whether the CPU1 is normal.
2. The normal running status is indicated as:
�
The RUN indicator flashes at 1 Hz.
�
The ACT indicator is on constantly.
�
The ALM and the ENUM indicators are off constantly.
When all these indicators are on, the CPU1 possibly cannot be
started. The reasons are as follows:
�
�
If this problem appears when the board is powered on for
the first time, generally, the reason is that the boot is
burned incorrectly. Burn the software of the BOOT chip
again.
The mother board of SPB is faulty. Replace the board to
eliminate the fault.
3. The board runs normally, but there are bit errors in the E1 link,
especially with large traffic.
�
�
�
Check whether the clocks of two interconnected environments are synchronous;
Check whether the configuration of the jumpers and board
impedance DIPs are consistent with the cable adopted;
Check whether the impedance against ground of each environment conforms to the requirements.
For the SPB, the specific method of checking the impedance matching is as follows.
1. Findd four DIP switches (S3-S6) on the board, with each one
corresponding to four channels of E1s (No.1~16 channels of
E1s from the upper to the lower). The "ON" position represents
75 Ω, while the “OFF” position represents 120 Ω.
2. Find four DIP switches S2 that indicate the E1 status. From
the upper to the lower, one switch corresponds to one group of
E1s (having 4 E1s), that is, 16 E1s totally. The "ON" position
represents 75 Ω, while the “OFF” position represents 120 Ω.
3. Set the jumper on the rear board. There are five groups of
jumpers (X11-X15) from the upper to the lower. Where, the
X11 and X15 correspond to 2-channel E1s respectively, while
other jumpers correspond to 4-channel E1s respectively. Each
channel of E1 is configured with jumpers on the sending and
receiving directions. The sending jumper is above the receiving
one. When the impedance matching is set as 75 Ω, just place
the jumper on the sending end, and no jumper on the receiving
end. When the impedance matching is set to be 120 Ω, place
no jumper on both the receiving and the sending end.
22
Confidential and Proprietary Information of ZTE CORPORATION
Chapter 2 Hardware Faults
Handling CLKG Board Hardware
Faults
Background
As the clock generation board, the CLKG is responsible for providing the clock for the system, tracing the external reference line
clock, and keeping the NE clock synchronous with the network
clock. In the ZXWN MGW, the clock is used to help establish stable link with the traditional SS7 network. Both the SPB board and
UIM board use the clock.
The CLKG board need not download the version from the OMP during the activation. It activates through the program in the onboard
chip directly. Therefore, the version loading problem can be omitted while troubleshooting the CLGK board.
The CLKG board provides the internal clock interfaces and external
clock tracing interfaces through the RCLKG rear board. The internal clock interface connects to the UIM on the expansion frame
with the ZTE dedicated clock cable, and then UIM sends the clock
to each board that needs the clock. The external clock tracing
interface connects to the clock tracing signal output interfaces of
the external interface boards such as SPB, APBE and SDTB with
the ZTE dedicated clock tracing cable.
Fault Phenomenon
Flow
�
The RUN indicator on the CLKG board flashes abnormally.
�
The red ALM indicators on the UIM, APBE and SPB boards are
on.
�
The fault management system on the OMM client prompts that
the clock signal is lost.
�
Faults occur in the SS7 link, such as intermittent disconnection,
bit error and interruption.
Figure 8 shows the flow of troubleshooting the CLKG board fault.
Confidential and Proprietary Information of ZTE CORPORATION
23
ZXWN MGW Troubleshooting
FIGURE 8 TROUBLESHOOTING FLOW
Solution
OF THE
CLKG BOARD
1. Check the indicators on the CLKG board to confirm the running
status of the CLKG.
2. Check whether the external line of the rear board RCLKG of the
CLKG is connected correctly.
3. Perform active/standby changeover to check the working status of the CLKG board.
4. Check whether the fault lies in the CLKG board by using the
replacement method. If the CLKG board is faulty, replace it.
Handling IPI Board Fault
Background
Fault Phenomenon
Flow
24
The SIPI board is responsible for providing the IP interface of the
media plane externally. The RMNIC rear board provides the IP
interface, connecting to the IP network with the network cable,
and interconnecting with the adjacent office interface.
�
The fault management system of the OMCS client prompts that
there is a RTP trunk alarm.
�
The RUN indicator on the IPI board flashes abnormally.
�
Subscriber services are interrupted.
Figure 9 shows the flow of troubleshooting the SIPI board fault.
Confidential and Proprietary Information of ZTE CORPORATION
Chapter 2 Hardware Faults
FIGURE 9 HANDLING
Solution
THE
IPI BOARD FAULT
1. The IPI board adopts the MNIC board. When the FE port number is set as one or two, the MNIC board actually occupies two
media plane network interfaces. It will occupy the media plane
network interfaces on the adjacent slots.
2. Four network interfaces of the IPI board can all be used to
connect the external. Check the network cable to confirm the
connection of the network interface is normal.
3. Locate and replace the IPI board with the replacement method.
Make sure whether the fault results from itself or other boards.
Example: When the OMP is faulty, the IPI cannot load the version file while starting, resulting in the activation failure of the
IPI board. When the UIM is faulty, the IPI cannot communicate
normally.
Handling DTB/DTEC Board Fault
Background
Fault Phenomenon
As the digital trunk interface board, the DTB/DTEC board is used
to access the E1/T1 link. It provides 32-channel E1/T1 interfaces
externally through the RDTB rear board, and extracts 8k line clock
reference to the CLKG. In addition, it can respectively set the 75
Ω and 120 Ω transmission mode based on the impedance characteristics of the transmission line.
�
The fault management system of the OMCS client prompts that
there is an E1 trunk alarm.
�
The RUN indicator on the DTB/DTEC panel flashes abnormally,
and the ALM indicator shows that there is an alarm.
�
Subscriber services are interrupted.
Confidential and Proprietary Information of ZTE CORPORATION
25
ZXWN MGW Troubleshooting
Flow
Figure 10 shows the flow of handling the DTB/DTEC board fault.
FIGURE 10 HANDLING
Solution
THE
DTB/DTEC BOARD FAULT
1. There are totally 12 4-position DIP switches on the DTB/DTEC
board. Eight 4-position DIP switches (S1-S6, S9, and S12) are
for setting the matching impedance of each E1 channel as 75 Ω
or 120 Ω. S7 and S8 4-position DIP switches are for indicating
the receiving matching impedance of corresponding E1 chip to
the CPU. S10 and S11 position DIP switches are for indicating
the long/short wire status of each E1 chip to the CPU.
2. The DTB/DTEC board provides 32 E1s to the outside world. If
there is a problem in a certain E1, locate the fault by creating
the E1 self loop to make sure whether the problem occurs on
local end or opposite end. If it is at local end, check the status
of related sub-unit and trunk data.
3. If all of the E1s of the board are faulty, first try to reset the
board, and check data. If the fault still exists, replace the
board with a new one to eliminate the fault.
Handling APBE Board Fault
Background
26
As the Iu-CS interface board, the APBE board provides two optical
interfaces to connect the interface at the RNC side. It is responsible for processing the ATM adaptation, the broadband No.7 bottom-layer signaling such as the ALL5-SAR, SSCOP, and SSCF, and
Confidential and Proprietary Information of ZTE CORPORATION
Chapter 2 Hardware Faults
forwarding the MTP3B signaling packet to the SMP through the FE
interface for processing.
Fault Phenomenon
Flow
�
Serious alarm appears in the fault management system, and
the communication interruption occurs on the APBE unit.
�
All of the RNC services connected by the APBE are interrupted.
�
The fault management system prompts that the office direction
to the RNC is unreachable.
Figure 11 shows the flow of troubleshooting the APBE fault.
FIGURE 11 HANDLING
Solution
THE
APBE BOARD FAULT
1. There are two pairs of optical interfaces on the APBE board
panel. Each pair of optical interfaces is configured with sending
and receiving directions. If the sending/receiving directions
are reversed, the board cannot receive the optical signal.
2. The APBE board must be configured with correct ATM address;
otherwise, the RNC office direction is unreachable.
3. Check whether the PVC signaling, voice channel PVC, VCI, and
VPI, and PATH ID settings are correct.
Handling MRB Board Fault
Background
The MRB is a media resource board in the MGW. It is responsible for providing various media resources for the system, including various signal tones, voice tones, DTMF, MFC, and multi-party
Confidential and Proprietary Information of ZTE CORPORATION
27
ZXWN MGW Troubleshooting
talking resources. The MRB board is configured in the BUSN shelf,
without backup. The MRB implements different functions by configuring different attributes for the sub-units in the OMM system.
For example, the sub-unit represents the tone sub-unit when being configured as TONE, the dual tone multiple-frequency sub-unit
when being configured as the DTMF, and the multi-frequency compelled sub-unit when being configured as the MFC.
Fault Phenomenon
Flow
�
For the call service, the local office cannot provide system tones
or provide wrong tones.
�
For the second call service, subscriber cannot dial a second
call, or an error occurs on the number identification after the
second call.
�
Three-party call and conference call service cannot be implemented.
�
Serious alarm appears in the fault management system, and
the communication interruption occurs on the MRB unit.
�
The RUN indicator on the panel of the MRB board is abnormal.
Figure 12 shows the flow of troubleshooting the MRB fault.
FIGURE 12 HANDLING
Solution
28
THE
MRB BOARD FAULT
1. There are total four DSPs on each MRB board. A DSP can be
configured with different media resources. According to the
fault phenomena, find out the corresponding DSP for resetting.
2. The MRB must be configured under the corresponding SMP according to the planning. If the configuration is wrong, the sub-
Confidential and Proprietary Information of ZTE CORPORATION
Chapter 2 Hardware Faults
scribers under the corresponding SMP cannot use the resources
in the MRB.
3. Reset the whole board. If the fault still remains, replace the
faulty board with a new one to eliminate the fault.
Handling VTCD Board Fault
Background
Fault Phenomenon
Flow
The VTCD board is the voice codec board in the MGW. It is responsible for coding/decoding voice Iu-UP and AMR, and processing the
Nb-UP. The VTCD board is configured in the BUSN shelf, without
backup.
�
Serious alarm appears in the fault management system, and
the communication interruption occurs on the VTCD unit.
�
Such faults as the noise or no voice occur during the call.
�
The indicator on the VTCD is abnormal.
Figure 13 shows the flow of troubleshooting the VTCD fault.
FIGURE 13 HANDLING VTCD BOARD FAULT
Solution
1. There are total four DSPs on each MRB board. A DSP can be
configured with different media resources. According to the
fault phenomena, find out the corresponding DSP for resetting.
2. The MRB must be configured under the corresponding SMP according to the planning. If the configuration is wrong, the subscribers under the corresponding SMP cannot use the resources
in the MRB.
3. Reset the whole board. If the fault still remains, replace the
faulty board with a new one to eliminate the fault.
Confidential and Proprietary Information of ZTE CORPORATION
29
ZXWN MGW Troubleshooting
Handling Changeover
Exceptions
Background
Common Causes
Handling
Board changeover is a kind of maintenance means frequently used
for board replacement, version update, and other routine maintenance activities. After changeover, service personnel should observe the working status of the system. If it works normally, board
changeover is successful. If the system cannot work normally, immediately power down the board on which changeover was performed, and bring the standby board into active status.
The common causes for changeover exceptions are as follows.
�
Operations do not conform to standardizations.
�
It is prohibited by system running status.
�
Standby board is in abnormal status.
1. Check whether standby board is normal.
When standby board is unavailable for no insertion, faults or
abnormal running status, the system will deny to implementing
active/standby changeover.
On the Daily Maintenance window of the NetNumen M30
window, find the NE to be maintained. Open the Rackchart
Management tab, select the corresponding module and rack,
and find the board on which active/standby changeover is to be
implemented. Check the board’s information. If the board is in
hybrid, unknown or other statuses, active/standby changeover
cannot be performed for it.
2. Check whether board version is loaded normally.
On the Professional Maintenance > File Management tab
of the NetNumen M30 window, check whether the board version files on the board are correct.
If you failed to query version files with this method, check the
running status of the board, and implement the troubleshooting flow for the board.
If you can query version files, but they are wrong, load the
correct ones for this board in Version Management.
3. Other prohibited conditions
To ensure the safe operation of switches, the system will also
deny the changeover operation when large traffic, high CPU
occupancy, scheduled tasks, data backup, and other special
conditions occur. If you forcefully to implement changeover,
serious consequences may arise, such as CDR missing, call
disconnection, and all active/standby boards being reset.
30
Confidential and Proprietary Information of ZTE CORPORATION
Chapter 2 Hardware Faults
Caution:
�
Changeover is an operation with relatively high risks. System
data backup must be done in advance.
�
It is recommended to perform changeover on OMP and other
important boards at 0:00 - 6:00 am, and to keep a certain
interval between two changeover activities.
Handling CPU Overload
Background
Common Causes
Common Fault
Phenomena
Flow
CPU overload is a major fault in ZXWN MGW. Too-high CPU usage
will increase call loss and decrease the call completion ratio. More
serious condition will cause ZXWN MGW breakdown.
�
Over excessive traffic
�
Interface congestion
�
Too-short cycle of performance statistics task
�
Irrational location area settings
�
Informal maintenance activities
�
Incorrect data settings.
�
The “Load of the CMP board is excessive” alarm appears in
Fault Management system
�
View the CPU occupancies of CMP (service processing module)
and SMP (signaling processing module) in the Performance
Statistics and Load Statistics windows of the NetNumen
M30 window.
1. Check traffic.
On ZXWN MSCS, query recently performance statistics reports
to know the traffic within a period of time. Generally, observe
the conditions of CPU overload caused by large traffic. To control traffic, refer to the Emergency Handling for Large Traffic
section in ZXWN MSCS MSC Server Emergency Fault Handling
and System Recovery.
2. Check maintenance operations.
A lot of maintenance tasks will consume too many CPU resources. Therefore, some operations should be avoided when
traffic is large, such as performing bulk modification with commands, displaying excessive command-executed results, performing dynamitic tracing on excessive links, tracking excessive signaling, and other operations.
3. Check performance statistical cycle.
During routine maintenance, majority traffic statistical tasks
are closely associated with calls. Therefore, too-short statistical task cycle will aggravate the CPU load of system. Currently,
a 1-hour cycle is relatively adequate.
Confidential and Proprietary Information of ZTE CORPORATION
31
ZXWN MGW Troubleshooting
4. Check whether data configuration is correct.
For MSCS, data configuration errors will cause CPU overload in
the following three aspects.
�
�
�
Unbalanced load-sharing configuration on signaling links
and trunks results in some signaling links carrying too large
load. It causes the board that is responsible for processing
this part of services is overloaded. In this case, data-link
configuration should be adjusted.
Unbalanced trunk distribution results in some modules carrying relatively heavy load. In this case, circuits should be
distributed to each module.
Incorrect MAP configuration will also cause excessive CPU
load.
5. Check whether location area settings are rational.
Slit the location areas with irrational settings, or adjust them
through BSC/RNC.
32
Confidential and Proprietary Information of ZTE CORPORATION
Chapter
3
Clock Faults
Table of Contents
Handling System Clock Exception ........................................33
Handling the Clock Lock Failure ...........................................35
Handling the Clock Networking Fault ....................................38
Handling the Inconsistent Lock Status of Active/Standby
CLKG Boards.....................................................................39
Handling the Clock Reference Loss .......................................41
Handling the Output Clock Loss ...........................................42
Handling the Slip Code .......................................................44
Handling System Clock
Exception
Background
The clock plays a vital role in the CS domain. Without clock, the
CS domain cannot work normally. Therefore, it is necessary to
ensure the normally working of clock system.
In ZXWN MGW, the CLKG is plugged into the main control shelf
where the OMP is located, providing the clock signal to the UIM
boards in all shelves.
The CLKG traces the upper-level office clock signal from the DTB,
SDTB, APBE and SPB boards with the clock tracing cable to keep
the local clock synchronous with the upper-level office clock.
Common Causes
Flow Diagram
�
On the Fault Management window, there are Clock Loss
alarms reported by the resource board, such as DTEC, VTCD,
MRB and SPB.
�
The ALM indicator of the board is on.
�
The narrowband link is interrupted or there are alarms in the
narrowband link.
Figure 14 shows the flow of troubleshooting the clock abnormality.
Confidential and Proprietary Information of ZTE CORPORATION
33
ZXWN MGW Troubleshooting
FIGURE 14 HANDLING
Solution
THE
CLOCK ABNORMALITY
1. Check whether the CLKG board runs normally. For the method,
see Handling CLKG Board Hardware Faults.
2. If there is a fault in the CLKG board, handle it first, and then
check whether the system clock exception disappears. If the
CLKG works normally, check whether the connection between
the UIM board in the BUSN shelf and the CLKG is correct.
Note:
The CLKG board is connected to the UIM through the RCLKG
rear board.
3. If there is a fault in the connection line, replace the connector of
the clock cable to the UIM board, or the clock cable to eliminate
the fault.
4. If the clock is still lost in the case of both the CLKG board and
the connection between the CLKG board and UIM board are
correct, check whether the UIM board works normally. For the
method of troubleshooting the UIM fault, see .
34
Confidential and Proprietary Information of ZTE CORPORATION
Chapter 3 Clock Faults
Handling the Clock Lock
Failure
Background
During the running process, the ZXWN MGW extracts the upperlevel office line clock, BITS clock or GPS clock according to the
configuration, to keep synchronous with the entire network clock.
When tracing the upper-level office line clock, it extracts the upper-level clock reference signal through the interface boards SPB,
DTB, APBE, and SDTB, and sends signal to the RCLKG rear board
of the CLKG through the dedicated clock tracing cable. The CLKG
traces this clock reference automatically.
When tracing the BITS clock or GPS clock, the dedicated clock
tracing cable transmits the external clock reference signal to the
RCLKG rear board of the CLKG. The CLKG automatically traces this
clock reference.
The clock lock failure means that the local office cannot synchronously trace the standard clock reference of upper-level office,
such as the BITS clock and line clock. When the clock lock is
failed, the working status of the CLKG board in the ZXWN MGW is
as follows.
�
The CATCH indicator is constantly on.
�
Both the CATCH indicator and the TRACE indicator have flashed
synchronously for more than 30 minutes.
Based on the above-mentioned conditions, judge that the CLKG
board is hard or unable to lock the upper-level clock.
Fault Phenomenon
Flow
�
The link-layer bit error occurs in the outgoing narrowband link
of the E1 (connecting with the HLR) or DT (connecting with the
PSTN) of the SPB board.
�
The outgoing E1 indicator of the SPB/DTEC board flashes abnormally, and the alarm indicator is on.
�
The signaling link is disconnected or intermittent.
�
The CLKG board cannot remain stable tracing status.
�
The indicator on the CLKG board is abnormal.
�
The signaling link is unstable, appearing intermittent disconnection and even interruption.
�
The fault management system reports the slip alarm.
�
Such faults as the noise and one-way transfer may possibly
occur when subscribers are talking.
The troubleshooting flow of the clock locking failure is shown in
Figure 15.
Confidential and Proprietary Information of ZTE CORPORATION
35
ZXWN MGW Troubleshooting
FIGURE 15 TROUBLESHOOTING FLOW
Solution
OF
CLOCK LOCKING FAILURE
1. The CLKG board is preheated insufficiently.
The CLKG board adopts the high-stability and high-precision
crystal oscillator to generate the local clock. Due to the working
characteristics of the crystal oscillator, the CLKG board cannot
enter the normal tracking status until it has been preheated
for a period of time. If the system failed to trace the clock
signal when the CLKG board has not run for enough time or just
been replaced, wait for at least three hours for the CLKG board
is preheated sufficiently, and then observe the clock tracing
status again.
2. Check the setting of the interface board (SPB).
�
�
If the clock fault occurs on the backplane of the SPB, troubleshoot the fault by replacing the CLKG board, UIM board,
and clock output cable.
Check whether the setting of 75/120 Ω matching
impedance is correct. The impedance of the E1 cable must
match that of the board.
The method to set the E1 cable impedance is: set the DIP
switches S3~S6 on the SPB board. The ON position in-
36
Confidential and Proprietary Information of ZTE CORPORATION
Chapter 3 Clock Faults
dicates that the matching impedance is 120 Ω, while the
OFF position indicates that the matching impedance is 75
Ω. Table 3 lists the corresponding relationship between the
DIP switches and E1 lines.
TABLE 3 IMPEDANCE DIP SWITCHES
�
�
OF
E1
ON THE
SPB BOARD
DIP Switch
Corresponding E1
1st bit ~ 4th bit of S3
Channel 1~4 E1 of the SPB
board
1st bit ~ 4th bit of S4
Channel 5~8 E1 of the SPB
board
1st bit ~ 4th bit of S5
Channel 9~12 E1 of the SPB
board
1st bit ~ 4th bit of S6
Channel 13~16 E1 of the SPB
board
Check the reliability of the cable connecting to the E1, which
can be solved by replacing the E1 cable.
When the E1 line length is more than 300 meters, adopt
the long-line mode.
For the DTEC board, find the E1 status indicating DIP S10
and S11, with eight switches in total. From the upper to
the lower, a switch corresponds to a group of E1s (4 E1s),
that is, eight groups of E1s in total. The short-line mode is
set by placing the switch to ON, and the long-line mode is
set by placing it to OFF.
For the SPB board, find the E1 mode setting DIP S1, with
four switches in total. From the upper to the lower, a switch
corresponds to a group of E1s (4 E1s), that is, four groups
of E1s in total. The short-line mode is set by placing the
switch to ON, and the long-line mode is set by placing it to
OFF.
3. Handle the clock networking fault.
The clock networking fault results from the self-loop relationship exists between the local exchange and upper-level clock
office, which causes the clocks to track mutually. In this case,
the clock lock failure often occurs.
For the handling method, see Handling the Clock Networking
Fault.
4. Handle the upper-level clock source fault.
The CLKG board works normally and the clock networking relationship is correct, but the clock still cannot lock the upper-level
office. In this case, contact the office homed by the upper-level
clock source to make sure whether there is clock fault in the
upper-level office. If the clock-source accuracy of the equipment to be traced does not reach the level-2 clock, negotiate
with the office to ask for the clock source with high accuracy.
5. Handle the inconsistent lock status of the active/standby CLKG
board.
Confidential and Proprietary Information of ZTE CORPORATION
37
ZXWN MGW Troubleshooting
If one of active/standby CLKG boards of local office can trace
and lock the upper-level clock, there is no problem with the
upper-level clock source and clock networking. The fault must
exist in this office. For how to handle this kind of faults, see
Handling the Inconsistent Lock Status of Active/Standby CLKG
Boards.
Handling the Clock
Networking Fault
Background
In the communication network, all node clocks must keep synchronous so that the link document and data receiving/transmitting can be identified normally. In the clock networking, the clock
synchronous relation between each node is divided into following
three types:
�
Quasi-synchronization
This synchronization mode is generally applicable to the international communication, for the PRC used by different countries has high accuracy that reaches 1×1011 so that the slip
occurs only one time within 70 days.
�
Mutual synchronization
This synchronous relation is relatively complex and requires
the clocks with higher level.
�
Master-slave synchronization
With a reference clock in the network, distribute the clock
based on the hierarchy. The master-slave synchronization
adopting 3-level architecture is adopted in China.
The level-1 clock, PRC serves as the master clock and complies
with ITU-T recommendation G.811. Composed by the cesium
clocks, the PRC mainly works in the free-running status. There
is another local master clock mainly composed by the atomic
clock and the GPS can be synchronized by the PRC.
The level-2/level-3 slave clock is mainly used on the level2/level-3 node of the network. The node clock stability complies with the G.812/YD-T1012. Here, the level-2/level-3 corresponds to original enhanced level-2/level-3.
Overview
The clock networking fault refers to the clock synchronization fault
caused by the error configuration of synchronous relation with
other office. Clock self-loop is the most typical one.
Two offices with the master-slave relation track and synchronize
the clock mutually when they are synchronizing the clock reference. Therefore, the close-loop of clock is formed. That is the
clock self-loop.
For example, when the ZXWN MSCS is interconnected with the
PSTN, the MSCS tracks the E1 line clock on the PSTN line and
compares with the 8K line clock on the PSTN. And the PSTN does
the same thing to the MSCS. This is the clock self-loop, as shown
in Figure 16.
38
Confidential and Proprietary Information of ZTE CORPORATION
Chapter 3 Clock Faults
FIGURE 16 EXAMPLE
FOR
CLOCK SELF-LOOP
In the practical networking, connecting the 8K link clock reference
often causes the clock self-loop fault. Such a fault is relatively
reduced when the BITS clock reference is adopted.
Fault Phenomenon
Solution
When the clock self-loop fault occurs, the common fault phenomena are shown as follows:
�
The system is hard to track the clock again when the clock lock
loss happens frequently.
�
The system clock cannot be locked.
The handling method of clock networking fault is shown below:
1. Check the actual result of the clock networking to make sure
whether the clock self-loop fault occurs.
2. If it is, change the reference clock source of the local office or
interconnected office based on the actual condition to eliminate
this fault.
Adopt the PSTN clock reference to eliminate the clock self-loop
fault as shown in the Figure 16.
Handling the Inconsistent
Lock Status of
Active/Standby CLKG
Boards
Overview
When the clock tracing status of two CLKG boards configured with
active/standby mode are inconsistent, the hidden trouble exists,
although the system may work normally. At this time, it is necessary to check the system, and handle the hidden trouble to make
the active and standby CLKG boards work normally.
In this case, the clock networking fault and the clock source fault
generally can be excluded basically.
Fault Phenomenon
When the CLKG boards is configured with the active/standby
mode, one CLKG board cannot be locked (the CATCH indicator is
Confidential and Proprietary Information of ZTE CORPORATION
39
ZXWN MGW Troubleshooting
constantly on, or both the CATCH indicator and TRACE indicator
flash synchronously), but another CLKG board can be locked.
Solution
The method of handling inconsistent lock status of the active/standby CLKG boards is as follows.
TABLE 4 HANDLING METHOD OF INCONSISTENT LOCKING STATUS
ACTIVE/STANDBY CLKG BOARDS
Phenomenon
Method
The BITS clock serves as the clock reference
Step 1
The 8K line clock servers as the clock
reference
Step 2
OF
1. The BITS clock serves as the clock reference
In the case of the BITS clock serving as the clock reference,
basically restrict the fault location on the slots and the CLKG
board itself while handling this inconsistent lock status fault.
i. Switch the CLKG board incapable of locking the clock to the
standby status. And then plug/unplug this board again to
exclude the contact problem.
ii. After unplugging this board, check whether the pin 24/25
of the J5 connector of the corresponding slot are bent. The
pin distortion may also result in this fault.
iii. If it is permitted, replace the clock reference of the uncertain CLKG board to see whether this board can be locked.
In this way, exclude or locate whether the CLKG board is
faulty.
2. The 8K line clock serves as the clock reference
The 8K reference clocks of the active/standby CLKG board are
transferred independently. Therefore, there is no inevitable
association between the 8K reference clock of the active CLKG
board and that of the standby CLKG board. As a result, it cannot directly draw a conclusion that the CLKG board is faulty
when the lock status of the active/standby CLKG board is inconsistent, in the case of the 8K clock source serving as the
CLKG current reference clock. Troubleshooting the fault carefully is necessary.
Although the 8k clock cables are separated on the backplane,
they have the same source, therefore, the fault generally does
not relate to the clock networking or the clock hierarchy.
i. Touch the RJ45 connector that feeds in the clock reference
on the RCKG1 rear board to eliminate the contact problem.
If the fault still exists, handle it by performing the following
steps.
ii. If there exists another 8K reference clock, switch the
current tracking reference of the CLKG through the background or manual mode to the standby reference. And
then observe the lock status of the CLKG. If the CLKG is
locked, restrict the fault location on the slot or the rear
board; otherwise, the CLGK board is basically faulty.
40
Confidential and Proprietary Information of ZTE CORPORATION
Chapter 3 Clock Faults
iii. If there is only one 8K reference clock, pull out the clock reference cable from the RCKG1 rear board, replace the normal clock reference cable, and extract the clock from other
interface board. If this phenomenon disappears, the fault
is located on the clock cable, the interface board that extracts the clock, and the rear board of this interface board.
If the phenomenon still exists, restrict the fault location on
the CLKG, the slot plugged the CLKG, and the RCKG1. And
then handle the fault by using the replacement method,
find out the faulty component and replace it.
Handling the Clock
Reference Loss
Overview
The clock reference loss refers to the upper-level clock reference
signal used by the system is lost, which makes the system asynchronous with the whole network. When the CLKG board gives the
clock loss alarm, it is necessary to check and handle the fault.
Fault Phenomenon
When the BITS clock reference is lost, probably appear following
two conditions:
Solution
�
Both active CLKG board and standby CLKG board lose the clock
reference.
�
The clock reference loss status of the active/standby CLKG
board is different.
The handling method of clock reference loss is shown in Table 5.
TABLE 5 HANDLING METHOD OF INCONSISTENT CLOCK REFERENCE STATUS
OF ACTIVE/STANDBY CLKG BOARDS
Phenomenon
Method
The BITS clock serves as the clock
reference
Step 1
The 8K line clock servers as the clock
reference
Step 2
1. The BITS clock serves as the clock reference.
i. Both active CLKG board and standby CLKG board lose the
clock reference
Check the indicators on the active/standby CLKG board,
finding that the KEEP indicator (working mode indicator)
and the corresponding BITS clock reference indicator (such
as the 2MBPS1 indicator) are constantly on. This means
that the CLKG was in tracking status before losing the current clock reference. In this case, the CLKG board itself is
normal. Check whether the 9-pin connector on the RCKG1
rear board is dropped or loose.
Troubleshoot the corresponding output or transmission
equipment of the BITS.
Confidential and Proprietary Information of ZTE CORPORATION
41
ZXWN MGW Troubleshooting
ii. The clock reference loss status of the active/standby CLKG
board is different.
If this fault occurs during the system running, check
whether the CLKG board is well plugged, for which will
make the board loose. Otherwise, the CLKG board is
probably faulty. The board should be replaced in time.
If this fault appears during the course of office commissioning, check whether the slot is normal. And check whether
the pin 24/25 of the J5 connector are normal, which is located at the corresponding backplane slot.
2. The 8K line clock serves as the clock reference.
i. Both active and standby CLKG boards lose the clock reference.
Check whether the RCKG1 rear board is loose, whether
RJ45 connector of the reference inputting interface is loose
and whether the interface board works normally.
If the reference is lost during the course of office commissioning, check the connecting line. For example, if the 8K
clock reference is extracted through the DTB, check such
components as the 8K clock cable, the RCKG1 rear board.
ii. The clock reference loss status of the active/standby CLKG
board is different.
One CLKG board can detect the clock reference signal, but
another CLKG board cannot. Therefore, concentrate on the
CLKG board and its corresponding slot, the RCKG, the 8K
clock reference cable, the clock extracting interface board,
and the rear board of the interface board. For how to handle such kind of faults, refer to Handling the Inconsistent
Lock Status of Active/Standby CLKG Boards.
Handling the Output Clock
Loss
Overview
The output clock loss refers to that the output clock signal is abnormal or lost, which is transmitted from the CLKG board to the
UIM or other board in the system. At this time, the board in the
system will report the clock loss alarm.
Fault Phenomenon
When the BITS clock reference is lost, probably appear following
two conditions:
Solution
42
�
The board in the system reports the clock loss alarm.
�
The signaling link appears intermittent disconnection and even
interruption.
�
The ALM indicator on the board is on.
The handling method of output clock loss is listed in Table 6.
Confidential and Proprietary Information of ZTE CORPORATION
Chapter 3 Clock Faults
TABLE 6 HANDLING METHOD
OF
OUTPUT CLOCK LOSS
Phenomenon
Method
All the output clocks have been lost for a
moment
Step 1
All the clocks have been lost for a long time
Step 2
Several clocks are lost
Step 3
1. All the output clocks have been lost for a moment.
During the system running, the clock signal is lost suddenly,
and then recovers automatically about 10 seconds later. Query
the history notification and history alarm information to see the
working mode conversion of the CLKG. If the CLKG lock loss
happens suddenly and the lock loss status lasts for about 120
minutes, the fault reason can be basically judged as the clock
deterioration due to the network fluctuation. The CLKG board
tracks the clock signal again so that the clock is temporarily
lost during this process. It is necessary to check the network
fluctuation reason to prevent this fault from appearing again.
2. All the clocks have been lost for a long time.
The clock signal has been lost for more than 10 seconds during
the system running. If either the 44-pin connector on the CLKG
rear board or the 9-pin connector on the RUIM is not loose,
the fault reason is that both the active and standby CLKGs are
running in the standby mode due to the abnormality. In this
case, check whether the ACT indicator on the CLKG board turns
off. If it is, plug/unplug the CLKG board to handle this fault.
3. Several clocks are lost.
Generally, the loss of one or several clocks results from the
hardware faults. Check the clock cable, the socket connector
and the backplane first, and then check the board. The following example describes the handling procedure.
i. The CLKG board is connected to the three shelves, labeled
as the shelf 1, shelf 2, and shelf 3 respectively. The UIM
of the shelf 1 reports the clock loss alarm, but either the
shelf 2 or shelf 3 does not. Switch the 9-pin clock cable
connector of the shelf without reporting this alarm (such
as the shelf 2) with the UIM of the shelf 1 reporting this
alarm.
ii. If the shelf 1 still reports the clock loss alarm, but either
the shelf 2 or shelf 3 does not, restrict the fault location on
the RUIM, UIM and slot plugged with the UIM. Then replace
the RUIM to eliminate its problem.
If the clock loss phenomenon disappears after the RUIM is
replaced, the RUIM rear board is faulty. Otherwise, replace
the UIM board. If this phenomenon disappears after the
UIM is replaced, basically the UIM is faulty. Otherwise, the
backplane is faulty.
iii. After the UIM board is replaced, the UIM in the shelf 1 does
not report the clock loss any longer, but the shelf 2 starts
to report this alarm. In this case, troubleshoot the fault on
Confidential and Proprietary Information of ZTE CORPORATION
43
ZXWN MGW Troubleshooting
the system clock cable, RCKG1, RCKG2, CLKG, and the slot
plugged with the CLKG.
Replace the system clock cable. If the alarm from the shelf
1 disappears, the system clock cable is faulty. If the shelf 1
still reports alarm after the clock cable is replaced, replace
the RCKG1 and RCGK2 rear boards. If the alarm disappears, there is a problem in the rear boards. Otherwise,
replace the CLKG board. If the alarm disappears, there is
a problem in the CLKG board. Otherwise, the slot plugged
with the CLKG board is faulty.
Handling the Slip Code
Overview
The slip code is the error judgment to the data among different
offices after running for a period of time due to the minor difference
of clock frequency. The slip code is usually related to the clock
system, but it does not always result from the CLKG board. The
engineering problems or transmission problems often cause this
fault.
The national standard (GB-12048) defines the slip code alarm as
follows: report the common alarm when the slip occurs four times
within 24 hours, and the important alarm when it occurs 255 times.
When the CLKG board is locked, its frequency difference is above
-1×1010, fully complying with the related specifications.
Fault Phenomenon
Solution
�
The fault management system reports the slip code alarm.
�
Some signaling links report the link intermittent disconnection
alarm.
The handling method of slip code fault is listed in Table 7.
TABLE 7 HANDLING METHOD
OF
SLIP CODE
Phenomenon
Method
The CLKG board works abnormally
Step 1
E1 configuration is error
Step 2
The inter-office clock synchronous relation
is error
Step 3
Transmission fault
Step 4
Opposite-end office fault
Step 5
1. The slip code is caused by the CLKG.
When the slip code occurs, check the CLKG working status first.
If it is in the trace status, the slip interval is not less than 40
minutes. That is to say, if the CLKG is in the trace status at
the same time, the CLKG board can be excluded basically.
If the CATCH indicator on the CLKG is constantly on, or the
CATCH indicator and TRACE indicator flash synchronously, and
44
Confidential and Proprietary Information of ZTE CORPORATION
Chapter 3 Clock Faults
the slip interval is about several minutes, the CLKG board is
probably faulty. The CLKG board should be checked by using
such methods as the active/standby changeover, resetting and
replacement.
2. The slip code is caused by the unused E1.
If there are some unused E1s that have been connected and
configured, these E1s certainly will cause the slip code, and the
serious one. Clear all used E1s and delete the configuration
data of the unused E1s in the system. In this way, the system
will not report the alarms from those unused E1s.
3. The offices interconnected through the E1 have neither direct
nor indirect clock synchronous relation.
In the whole network, all offices interconnected through the E1
must have the direct or indirect clock synchronous relation. If
two offices interconnected through the E1 have no such relation, the slip code probably occurs in the E1 system between
these two offices.
At this time, it is necessary to check the clock networking relation among different corresponding offices and establish the
direct or indirect clock synchronous relation between those offices.
4. The slip code is caused by the transmission.
If the clock networking relation is correct and the CLKG works
normally, the slip code still occurs. It is necessary to check
whether the transmission is normal. Because the normal-working CLKG can only confirm the clock is sent at correct rate.
However, the slip code is caused by the deviation of the sending rate from the receiving rate, especially when the clock reference of the CLKG is not extracted from the line, or not transmitted from the opposite-end office where the slip code occurs.
5. The slip code occurs when the opposite-end office is faulty.
The slip code also occurs when the opposite-end office clock is
faulty. At this time, it is necessary to handle the fault of the
opposite-end office in time to eliminate to slip code.
Confidential and Proprietary Information of ZTE CORPORATION
45
ZXWN MGW Troubleshooting
This page is intentionally blank.
46
Confidential and Proprietary Information of ZTE CORPORATION
Chapter
4
Interface Faults
Table of Contents
Handling MGW-MSCS Interface Fault ....................................47
Handling MGW-MGW Interface Fault.....................................49
Handling MGW-RNC Interface Fault ......................................50
Handling MGW-PSTN Interface Fault.....................................52
Handling MSCS-BSC Interface Fault .....................................54
Handling Service Faults ......................................................56
Handling MGW-MSCS
Interface Fault
Background
Mc interface is the interface between MSCS and MGW. Figure 17
shows its protocol-stack structure.
FIGURE 17 MC INTERFACE PROTOCOL STACK
The MGW equipment interacts with the MSCS through the Mc interface, which adopts the standard H.248 protocol and supports
the binary and text protocol CODEC formats.
During the service connecting process, the MGW is applicable to
invoke and manage various service resources under the control
of the MSC Server. The Mc interface fault will cause the MGW
equipment incapable of providing the service.
Generally, the Mc interface adopts the IP bearer. Because current
network is not all-IP network, the Mc interface protocol stack usually adopts the H.248/M3UA/SCTP/IP mode. The IP physical interconnection between the ZXWN MSC Server and the MGW is implemented by connecting the FE1 interfaces on the rear board of the
SIPI board of two NEs. The corresponding SIPI unit is configured
Confidential and Proprietary Information of ZTE CORPORATION
47
ZXWN MGW Troubleshooting
with the IP address and the SCTP association. The upper-layer is
configured with the AS data, and the AS data of SIO location.
The signal trail of the Mc interface is shown below:
SMP → UIM → SIPI → IP Network → MSCS
Fault Phenomenon
Solution
�
All the calls related to the subscribers in local office fail.
�
The office direction between the MSC Server and MGW is disconnected.
�
The association cannot be deactivated/activated normally in
the Dynamic Management.
�
The association status is normal, but the statuses of the AS
and ASP are abnormal, being non-activated. There is an MGW
registration failure message in the platform signaling tracing.
�
The AS status is normal, but the gateway failed to register on
the MGC.
1. Check the physical connection to see whether the change of
the connection line causes Mc interface abnormality. If the
SIPI and UIM are both active/standby, specially check the line
between the SIPI and the UIM.
2. Check the data configuration of the MGW, including the following data.
�
The adjacent office configuration
�
IP protocol stack configuration
�
SIGTRAN data configuration.
3. Check whether the status of the SMP managing the association
module and SIPI is normal, whether there is an alarm. If the
onsite conditions permitting, restart the OMP, SMP and SIPI to
see whether the fault can be eliminated.
4. Use the dynamic management tool provided by the OMM to
activate/deactivate the association to see whether the fault can
be eliminated.
5. Check the port address and service status of each board, and
the routing information on the RPU through the OMM system.
6. In the Dynamic Management interface, check the association
status and whether the M3UA route is reachable.
7. If the actual/virtual address of opposite end can be successfully pinged by using the platform tool, but the SCTP connection
cannot be established, possibly the broadcast storm occurs to
the switch connected with the SIPI boards of the MSCS and the
MGW, which causes the Mc interface communication abnormal.
To restore the service as soon as possible, use the cross cable to temporarily connect the SIPI boards of the ZXWN MSC
Server and the MGW.
8. If the fault still cannot be eliminated by using all available
methods, reset the RPU and SMP, transmit all tables again,
and finally restart the MP.
Instance Analysis
Topic: the Mc interface fault results from the disconnection of the
signaling link to the MSC Server.
1. Symptom
All of the call service cannot be processed.
2. Source
48
Confidential and Proprietary Information of ZTE CORPORATION
Chapter 4 Interface Faults
The subscriber or carrier tells that the call service cannot be
processed. The background reports the link interruption alarm.
3. Related Components
Broadband signaling processing board or the MNIC board
4. Fault Analysis and Location
The link to the MSC Server is interrupted.
5. Solution
Determine whether the fault is caused by the local office or
by opposite-end office. If it is caused by the opposite office,
ask the opposite-end office to handle the fault. If it is caused
by the local office, determine whether it is caused by software
or hardware. If it is caused by hardware problem, check the
board or optical fiber. If it is caused by software, record the
symptom, and analyze the reason. If it is necessary, reset the
board.
6. Summery
i. In the fault location procedure, determine whether the
fault is from the local office or the opposite-end office,
and then determine whether it is hardware problem or
software problem.
ii. When resetting the board, save the relevant fault information for the future fault location.
Handling MGW-MGW
Interface Fault
Background
Nb interface is the interface between two MGWs. It is responsible
for transferring the media plane information. The bearing mode
of the Nb interface is the ATM, TDM, and IP, as specified by the
protocol. In the current practical networking, Nb interface mainly
adopts TDM bear and IP bearer.
�
With the bottom-layer adopting the IP bearer, the signaling
processing flow of the Nb interface is shown as follows.
VTCD (MRB) → UIM → IPI → IP Network → Opposite-end MGW
interface board
�
With the bottom-layer adopting the TDM bearer, the signaling
processing flow of the Nb interface is shown as follows:
VTCD (MRB) → UIM → DTB (SDTB) → TDM Network → Opposite-end MGW interface board
Fault Phenomenon
�
The call signaling flow is correct, but the call does not have
two-way speech.
�
The fault such as the noise and call interrupted during the call
process.
�
The call failed to be established because the MGW resources
failed to be obtained.
Confidential and Proprietary Information of ZTE CORPORATION
49
ZXWN MGW Troubleshooting
Solution
1. Check whether the data configuration is correct. Frequent data
configuration errors are as follows.
�
The CODEC mode setting error
�
Interface information configuration error
�
The VTCD configuration error.
2. Open the Failure Observation to trace the call and find out the
fault reason.
Instance Analysis
1. Symptom
One MSCS is configured with two MGWs. The inter-office communication between two MGWs is unsuccessful after the Nb
interface configuration is over. Without playing tones, trace
the signaling and find that the call is disconnected directly after it is confirmed, therefore, the call failed. The inter-office
call cannot be established.
2. Fault analysis and location
i. The inter-office signaling tracing shows that the call is disconnected directly after it is confirmed. The call fails.
ii. Implement the test, and find that the communication between two MGWs is normal, which means that the connection from the MGW to the BSC is normal and configured
correctly.
iii. Analyze that the VTCD configuration processing the CODEC
is error, which causes the unsuccessful communication between two MGWs. Check the configuration and find that
the VTCD unit is configured not under the SMP module that
processes the call but under the OMP module. As a result,
the inter-office call is failed.
3. Solution
Delete the VTCD unit from the OMP module and configure it
under the SMP module, and then restart the VTCD. The Nb
interface signaling is clear, and the fault is eliminated.
Handling MGW-RNC
Interface Fault
Background
Iu-CS interface is the interface between CN and RNC in CS domain. In the R4 phase, the MSCS processes the control plane of
the ATM-borne Iu-CS interface. The signaling is adapted based
on the AAL5, and transmitted through the SCCP. The MGW processes the user plane and the bearer control plane of the Iu-CS
interface. The ALCAP controls the establishment and release of
the user plane connection. The user data is adapted based on the
AAL2, and transmitted through the AAL2 connection.
In practical networking at present, the signaling interaction between the MSCS and the RNC is switched by the SG built in the
MGW. The networking mode and interface protocol stack structure
are shown in Figure 18.
50
Confidential and Proprietary Information of ZTE CORPORATION
Chapter 4 Interface Faults
FIGURE 18 NETWORKING MODE & INTERFACE PROTOCOL STACK STRUCTURE
The connection relationship between the MGW and the RNC is the
direct-connection through the fiber physically, with bottom-layer
bearer ATM.
The signaling trail between MGW and RNC is as follows.
SMP → UIM → APBE → ATM Network → RNC
Fault Phenomenon
Solution
Instance Analysis
�
The RNC office is unreachable.
�
The subscriber calls under RNC all fail.
�
Subscriber location update service fails.
1. First check whether the APBE board works normally. Check
whether the RUN indicator on the APBE is normal and whether
the ALARM indicator gives alarms.
2. Check whether the indicator of the fiber-connected optical interface is on. If it is off, check whether the sending/receiving
fiber is connected reversely, and whether the connection is correct.
3. After correctly connecting the fiber, check whether the ATM-interface data configurations of local office and RNC are correct.
Focus on the PVC configuration.
4. If the office is still unreachable when fiber connection and PVC
configuration are both correct, locate the fault with the selfloop method. If the link cannot be activated after looping back
the local office, check the configuration data of the signaling
link to the RNC, including signaling link, signaling link group,
signaling office and signaling route. The links can be activated
normally after self looping back RNC and MGW, but the links
become abnormal after interconnection. Check whether the
data of interconnected ends are consistent, including PVC, SLC,
DPC, and OPC.
5. If the office is reachable, and the circuit is normal, but all the
subscriber calls under RNC still fail, further check the RNCrelated data configuration.
1. Topic
The signaling link of the Iu interface cannot enter into the service status.
2. Symptom
Confidential and Proprietary Information of ZTE CORPORATION
51
ZXWN MGW Troubleshooting
Being in the Initial Position Status, the signaling link from the
MGW to the RNC cannot enter into the Service Status.
3. Fault analysis and location
Generally, such fault is caused by two cases: the hardware
fault and the ATM configuration problem.
i. It is found that the board running indicator is normal, and
the board does not give alarms. Printing the information
from the foreground is normal. If there are problems on
the hardware, following information will be printed.
TIMER TCC OUT, SSCOP Send AA_RELEASE_Ind/Conf… or
TIMER NORESPONSE OUT, SSCOP Send AA_RELEASE_Ind
In….
It indicates that the bottom layer is disconnected or connected in single direction. Then replace the board with the
same normal one, but the fault does not be eliminated. So,
the hardware fault can be excluded.
ii. Check the ATM configuration on the MGW, finding that the
data satisfies the requirement. Check the interconnected
ATM configuration with the RNC side, finding that the VPI
configured at the RNC side is inconsistent with the one configured at the CN side.
4. Solution
Modify the VPI configuration data to make the VPI at the CN
side consistent with that at the RNC side. The link enters into
the service status after modification.
Handling MGW-PSTN
Interface Fault
Background
In the R4 networking application, all service interactions between
the MGW and PSTN switch are based on TDM bearer connection
mode. Since the call part is separated from the control part, the
configuration of MGW as a bearer device for interconnection with
other devices mainly refers to configuration of bearer resources.
Therefore, it only needs to ensure the consistent TDM interconnection of two ends while debugging.
In actual networking, there is no physical connection between MSC
Server and PSTN switch. Signaling interaction between them is
implemented by MGW-built-in SG to forward the signaling message. The ZXWN MGW supports the built-in SG function. Figure
19 shows the networking structure between the ZXWN MSCS and
PSTN switch for ISUP message forwarding.
52
Confidential and Proprietary Information of ZTE CORPORATION
Chapter 4 Interface Faults
FIGURE 19 NETWORKING
SUPPORTED)
AND
PROTOCOL ARCHITECTURE (BUILT-IN SG
The MGW and PSTN are connected directly and physically through
the E1. The TDM serves as their bottom-layer bearer. The signaling route between the MGW and PSTN is shown as follows.
SMP → DTEC → TDM network → PSTN
Fault Phenomenon
Solution
Instance Analysis
�
The PSTN office direction is unreachable.
�
Part or all of the circuits are abnormal.
�
Calls from fixed network are crossed.
1. Check whether the DTEC board works normally. Check whether
the RUN indicator on the DTEC board is normal, and whether
there is an alarm shown by the ALARM indicator.
2. The crosstalk is usually due to that E1 lines are crossed. Adjust
the connection of E1 line to eliminate the fault.
3. In the Dynamic Management interface, check the status of the
PCM and CIC, and check the status of the corresponding circuit
in the R_CIC table with a probe. Locate the fault according to
the status.
4. If the fault is not due to the hardware problems, check the
circuit configuration and trunk management configuration on
the MSCS to further locate the fault.
1. Topic
A CIC circuit to the PSTN is unavailable.
2. Symptom
�
The call using this link fails.
�
The status value of the R_CIC is not 0.
�
�
The reset/block operation on the circuit through the dynamic management fails.
The platform cannot receive the message from the opposite
end after tracing the link signaling.
3. Fault analysis and location
i. Gather the service MP printing information about the activating/deactivating association for the management association module of the MGW and MSCS office.
ii. Check whether the trunk status is normal, and whether the
sub-unit is unblocked.
iii. Check the status value of the CICID in the R_CIC foreground table.
Confidential and Proprietary Information of ZTE CORPORATION
53
ZXWN MGW Troubleshooting
iv. If the status value of CICID is 512, it indicates that the local
end is blocked. Make sure that the PCM system number
and signaling timeslot are correct, and the trunk board is
in normal status. Use the light-emitting diode on the DDF
to ensure there are circuits on the receiving and sending
channels.
v. Unplug the trunk line from the trunk board, and plug the
line again after 30 seconds later. The fault is eliminated.
Handling MSCS-BSC
Interface Fault
Background
The MGW provides the bearer for the A interface traffic with the
TDM connection mode.
In the R4 phase, ZXWN MSCS integrates with ZXWN MGW to serve
as MSC in R99 (this mode is called MGW built-in mode). There is
only one MSC (one NE) at the BSC side. The A interface is the interface between MSC Server and BSC. Figure 20 shows the adopted
protocol stack. MSC Server processes all of the control messages
of the A interface. This interface implements the functions unrelated to the bearer part, including subscriber mobility management, BSS access, control plane processing of the call service and
SMS service.
FIGURE 20 A-INTERFACE PROTOCOL STACK STRUCTURE
When MGW built-in networking mode is adopted, ZXWN MGW and
ZXWN MSCS use the same SP. In this case, there is no physical
connection between ZXWN MSCS and BSC, the BSSAP protocol between them is transferred through ZXWN MGW. Figure 21 shows
the networking mode. In this networking mode, if the MTP3 upper-layer user is configured in the MGW, the SCCP cannot be configured, because the MSCS and MGW use the same SP. The MGW
needs to forward all of the messaged to the MSCS, but the BSSAP
is above the SCCP. If the SCCP part is configured to the MGW, the
BSSAP message cannot be forwarded to MSCS correctly. Therefore, the ZXWN MSCS and ZXWN MGW are combined to form a
MSC NE.
54
Confidential and Proprietary Information of ZTE CORPORATION
Chapter 4 Interface Faults
FIGURE 21 MGW BUILT-IN NETWORKING MODE
STRUCTURE
AND
ITS PROTOCOL
For ZXWN MGW, the boards processing the narrow-band No.7 signaling protocol are shown in Figure 22.
FIGURE 22 BOARDS RELATED
PROTOCOL
Fault Phenomenon
Solution
Instance Analysis
TO
NARROW-BAND NO.7 SIGNALING
�
The BSC office direction is unreachable.
�
Part or all of the circuits are abnormal.
�
Talks are crossed.
1. Check whether the DTB board works normally. Check whether
the RUN indicator on the DTB board is normal, and whether
there is an alarm shown by the ALARM indicator.
2. The crosstalk is usually due to that E1 lines are crossed. Adjust
the connection of E1 line to eliminate the fault.
3. On the Dynamic Management window, check the status of
the PCM and CIC, and check the status of the corresponding
circuit in the R_CIC table with a probe. Locate the fault according to the status.
4. If the fault is not due to the hardware problems, check the
circuit configuration and trunk management configuration on
the MSCS to further locate the fault.
1. Topic
The call completion ration to a certain BSC is low.
Confidential and Proprietary Information of ZTE CORPORATION
55
ZXWN MGW Troubleshooting
2. Symptom
i. Calls are hard to connect, only few of which can be put
through.
ii. Gather the fault information
iii. Gather the networking condition to check whether the A
interface of the BSC can be forwarded to the MSC Server
by the MGW.
iv. Gather the performance statistic data of the OMM before
and after the fault occurs, such as m3ua, mtp3, and signaling link statistics.
v. Save the stored alarm information before and after the fault
occurs.
vi. Gather the call loss of the service and signaling, including
MM, VLRMAP, MSCMAP, and BSSAP.
vii.If there is printing information, save the information
printed before and after the fault occurs.
viii.If there are a lot of signaling tracing records before and
after the fault occurs, save them to the utmost.
ix. Gather and save the traffic statistics before and after the
fault occurs.
x. Gather the records of the operation to the foreground before and after the fault occurs.
3. Analysis
i. By tracing the signaling, it is found that for the calling party,
the network returns the call proceeding message after receiving the setup message. A moment later, the network
sends the disconnect message. But the called party is hard
to trace the page rsp message.
ii. Perform statistics on the sending and receiving messages of
the A interface signaling link through the OMM system. The
sending and receiving messages of each signaling link are
not balanced. The sending and receiving ratio is seriously
imbalanced.
iii. Observe the call loss records. Most of them are due to the
paging has no response or calling party releases the call
abnormally.
iv. It can be inferred that the problem lies in the message
forwarded from the M3UA to the MTP3 at the MGW side.
A lot of messages are lost. Reset the standby board of the
SMP
Handling Service Faults
Background
56
The MGW provides the call-independent service bearing function
and implements the service bearing conversion and service flow
format processing under the control of the MSC Server.
Confidential and Proprietary Information of ZTE CORPORATION
Chapter 4 Interface Faults
The basic service fault of the MGW refers to that the equipment
cannot either provide corresponding bearing function or implement
the bearing service conversion and service flow processing.
This section describes the handling of service faults by using a
specific example.
Instance 1
1. Topic
The circuit is in abnormal status. And the CIC is not in idle
status.
2. Symptom
Query the local end status of the CIC circuit on the MSCS.
The status is “ERRORREQ”, indicating the request message is
illegal.
3. Fault Analysis and Location
The CIC circuit is related to the voice channel. For the R4
networking, the signaling is separated from the voice channel,
that is, the MSC controls the signaling part, while the MGW
carries the voice channel. Therefore, focus on checking the
MSCS data configuration related to the MGW.
4. Solution
i. Check the office directions and links from the MSC to the
MGW, AS, and ASP. Find that all of them are in normal status.
ii. When querying the static data of the MGW, find that they
are not configured. Configure these data again. But the
command fails, prompting that “Language description template number does not exist. Configure the language description first.” Therefore, check the configuration related
to the tone. A tone type of the language description exists
in “Batch create MSCS tone”, but it is not configured in the
data configuration.
iii. Select ALL for the tone types in the “Batch create MSCS
tone”. Add MGW static data again. The command is executed successfully.
iv. Synchronize the data. Check the status of the CIC circuit,
and find that it is in IDLE status normally.
5. Summary
i. When creating MSCS tone in batch in the MSCS, the default
type of tone is TONEID, other types such as LANGSTR are
not default. For practical configuration, it is not enough to
configure these data with only the TONEID type. Therefore,
it needs to select other tone types according to the actual
condition. In this way, the command can be executed successfully.
ii. In addition, the OMM system provides the batch command
to speed up the data configuration. But it needs to carefully
check whether every command can be executed successfully after implementing each batch processing. If the command is executed unsuccessfully, carefully check where the
problem is located, and then execute this command separately.
Instance 2
�
Topic
Confidential and Proprietary Information of ZTE CORPORATION
57
ZXWN MGW Troubleshooting
CIC timeslot configuration error causes low call completion ratio of wireless system.
�
Symptom
This fault occurs in a soft switch project. On the OMM system,
the performance index “call completion ratio of wireless system” under the soft switch is lower than that under other MSC
about 4%~6%. It does not meet the specified standards.
The onsite networking mode is MSCS-MGW-BSC.
�
Fault Analysis and Location
Analyze the formula used by the operator for calculating the
call completion ratio of wireless system, and find that the “success rate of service channel allocation (changeover excluded)”
parameter is lower than normal standard.
The calculation formula of this parameter is: “Times of successful service channel allocation”/“Times of requests for service channel allocation”×100%.
The operator takes the times of BSC receiving an “AssigReq”
assignment request message from MSC as that of requests for
service channel allocation, and the times of BSC sending an
“AssignCmp” assignment completion message to MSC as that
of successful service channel allocation. Obviously, the lower
success rate of service channel allocation results from more
assignment failure.
Analyze the BSC-provided CICs failed to be allocated, and find
that these CICs are all corresponded by 16-timeslot in E1 of
A-interface. After querying, find that the BSC engineer deleted
all CICs corresponded by 16-timeslot of E1 when unblocking
the A-interface circuit.
�
Solution
At the MSC side, delete the BSC-provided CICs corresponded
by this part of 16-timeslot. The performance index is recovered.
�
Summary
Negotiate interconnecting data with adjacent office during
signaling and circuit commissioning, including signaling point
code, SLC, signaling-located timeslot, PCM start number, and
other data.
58
Confidential and Proprietary Information of ZTE CORPORATION
Chapter
5
OMM System Faults
Table of Contents
Handling OMM Abrupt Abnormality.......................................59
Handling Virus/Security Events............................................62
Analyzing Instance 1..........................................................64
Analyzing Instance 2..........................................................64
Analyzing Instance 3..........................................................65
Analyzing Instance 4..........................................................66
Analyzing Instance 5..........................................................67
Analyzing Instance 6..........................................................68
Analyzing Instance 7..........................................................70
Analyzing Instance 8..........................................................71
Handling OMM Abrupt
Abnormality
Fault Phenomenon
Flow Diagram
�
No clients can log in the system.
�
The OMM cannot connect to the primary NEs.
�
The OMM cannot execute various man-machine commands.
Figure 23 shows the flow of handling the abrupt abnormality of the
OMM system.
Confidential and Proprietary Information of ZTE CORPORATION
59
ZXWN MGW Troubleshooting
FIGURE 23 HANDLING
Solution
THE
ABRUPT ABNORMALITY
OF THE
OMM
SYSTEM
1. Update fault of the OMM system
The OMM system fails to be started after being upgraded.
�
�
�
Check whether the software packet is correct, such as the
software name, version ID and packet bytes.
Check whether the abnormal start of the OMM system is
due to the abnormal modification to ums-svr\deploy\deploy*.xml or ums-clnt\deploy\deploy*.xml. The solution is to replace deploy*.xml with the correct one.
In the OMM software running version, check whether the
key file or directory has been deleted. Start the OMM software, and carefully view the output information of the command, to find out the lost file according to the prompt. Copy
the corresponding file in the version backup position to current running position, and then restart the OMM system.
2. Network fault
�
60
There are errors in the configurations of the OMM IP address, subnet mask or network gateway, which cause the
Confidential and Proprietary Information of ZTE CORPORATION
Chapter 5 OMM System Faults
network fault and make NEs unable to establish communication.
�
�
�
�
Check the above-mentioned configurations carefully, correct the error configuration. And then check whether the
network fault has been eliminated through the Ping command.
Enter the netstat -an command to check following ports
of the OMM server: 21, 23, 1521, 5000~5006, 5057 and
21099~21114. Check whether these ports are blocked by
the firewall.
Search for “port” in the file ums-svr\deploy\deploy-default.properties, and find the list of all ports needed by
the current version. And then check whether some listed
ports are blocked in the firewall configuration table. Unblock these ports if they are blocked.
The network port, network card, network cable or network
equipment of the carrier is faulty, and the Ping command
cannot be used to successfully ping the extra-network from
the OMM server.
By using such methods as the Ping packet, Trace command,
network cable or equipment replacement, check the fault
reason and replace the faulty equipment.
3. Database fault
�
�
�
Check the listening configuration of the ORALCE server.
Run the lsnrctl command status in the DOS window of the
server, and then check whether the listening service configuration is correct and the database instance runs normally.
If the listening service is abnormal, modify the configuration by using the NET MANAGER tool of ORACLE, and
restart the listening service.
Test whether the RACLE instance used by the OMM software
works normally through the sqlplus tool of ORALCE. If the
instance is abnormal, use the ORACLE Enterprise Manager
to restart the database instance, modify the operation, and
recover the database instance.
Check whether the IP address of each database server is
correctly configured in the ums-svr\deploy\deploy-default.properties file. Modify the IP address when it is
inconsistent with the one in the ORALCE database.
4. Other faults
It is found that the free space of disk partition where the OMM
system software is installed is less than 300 MB. Clear this
disk partition to keep its free space above 500 MB. The way
is mainly backing up and clearing the system log and the statistical information. Back up the old system log and statistical
information to other hard disk, or store them to the external
medium, and then delete them. Of course, the trash file in the
operating system also should be cleared.
Confidential and Proprietary Information of ZTE CORPORATION
61
ZXWN MGW Troubleshooting
Handling Virus/Security
Events
Fault Phenomenon
Flow Diagram
�
The OMM system finds that an anonymous IP user logs in the
system and modifies the data, or that the host where the OMM
system is located suffers from the login, intrusion or attack
from illegal user.
�
The virus occurs in the OMM system or the network where the
OMM system is located.
Figure 24 shows the flow of handling the virus/security events.
FIGURE 24 HANDLING VIRUS/SECURITY EVENTS
Solution
1. Check whether a virus or bug exists in the OMM system.
�
�
62
Scan the OMM system and kill the virus. One or several
antivirus software is available, such as Norton, Symantec,
MacAfee, KV3000 or Rising.
Perform analysis and check whether the security bug exists
in the premises network through various network security
analyzing tools, such as Network Analyzer, Sniffer and Ag-
Confidential and Proprietary Information of ZTE CORPORATION
Chapter 5 OMM System Faults
ilent. Eliminate such hidden security trouble based on the
actual network condition.
2. Check whether there are security problems in the OMM system.
�
�
�
After checking the login logs of the OMM system, it is found
that the user with illegal IP address once logged in the system. Delete the illegal user name and password of the OMM
system.
It is found that the system configuration information has
been modified illegally. For example, the configuration
about NE access has been changed, which was not performed by the inner personnel. Check and recover the
modified data configuration in the system.
After checking the user name and password logging in the
NE system, it is found that there is a new user with administrator authority, or that a user announces that original login
user name and password cannot be used for unknown reason. Modify the user password of the root authority or the
Admin authority. It should be noted that the password must
have certain security intensity, such as not less than eight
digits, containing letters, numbers and being case sensitive.
3. Check whether the security problems exist in the database.
Open Enterprise Manager Console to check whether any illegal user exists in the administrator group. If any illegal user
exists, delete it in the Enterprise Manager Console.
4. Check whether the security problems exist in the OMM server
computer.
�
�
On the User tab of the Task Manager (For Windows
2003), anonymous user simultaneously logs in the system.
If this user is logging in the system, right-click and select
Break. When necessary, pull out the network cable to
temporarily disconnect the network, and then perform the
following operations:
Click My Computers > Manage > System Tools > Local
User and Group > User to check whether there is any new
administrator user. If there is, delete it. Select Administrator, right-click and select Set Password to modify the
user password. It should be noted that the password must
have certain security intensity, such as not less than eight
digits, containing letters, numbers and being case sensitive.
5. Check whether the security problems exist in the OMM network
firewall.
�
Log in the firewall with administrator authority, to check
whether there are illegal IP login records. If the records
exist, delete the corresponding illegal user’s login information. And then modify the current administrator’s login
password. It should be noted that the password must have
certain security intensity, such as not less than eight digits,
containing letters, numbers and being case sensitive. If the
administrator cannot log in the firewall, log in the firewall
again after restarting and resetting the firewall.
Confidential and Proprietary Information of ZTE CORPORATION
63
ZXWN MGW Troubleshooting
�
Check the firewall, including the access control list, static
route configuration and port settings. Recover the original
configuration items of the firewall.
Analyzing Instance 1
Topic
The client cannot access the server because of the system log full.
Symptom
Sometimes the client cannot connect to the server after being
restarted. After logging in the client, the topology tree cannot be
displayed on the client, and the left directory tree is empty. But
the connection between the client and the server is normal.
Fault Analysis and
Location
Fault Handling
�
After checking the server, it is found that the process is not
started. While restarting the server, all processes cannot be
started.
�
After the check, it is found that the free space of partition C
is 0, and there are 4G log files. The disk-full error causes the
OMM fault.
After deleting old logs, the server restarts normally. It is recommended to set reasonable log-clearing mechanism for the OMM
server and clients, automatically clearing the old logs.
Analyzing Instance 2
Topic
Symptom
Fault Analysis and
Location
The client fails to connect to the server.
After installing the OMM server and client (both can be installed on
the same computer), the system prompts that Failed to connect
the server after inputting the IP address of the server on the
client.
There are several reasons.
�
The server IP address inputted is incorrect.
Handling: check the IP address of the server carefully.
�
The physical connection between the client and the server is
not clear.
Handling: Check whether the channel between the client and
server is clear with the Ping command. Check the physical
connection between the server and client, to assure the normal
physical connection.
�
The port of the ftp service at the server side conflicts with that
of the IIS service.
Handling: Stop the IIS service in the Services, and set the
IIS service type as Disable. The OMM system of ZXWN MGW
does not need the IIS service. The activation of the IIS service
often results in the port conflict and affects the normal login of
the client.
�
64
Other reasons
Confidential and Proprietary Information of ZTE CORPORATION
Chapter 5 OMM System Faults
Handling: The OMM system requires a server with relatively
high performance. The poor performance of the server will
possibly cause the login failure of the client.
Summary
1. Manually deleting the version file in the File Management possibly causes the foreground version database table inconsistent
with the file. It is recommended to directly delete the version
file through the Version Management instead of File Management. Otherwise, the foreground system possibly cannot obtain the version during the restarting.
2. The parameters are incorrect when performing the physical
configuration for the board, which causes version load failure.
For example, it must be clear whether the T network, CPU and
the GXS sub-card exist when configuring the UIM board parameters.
3. It is required to re-allocate the address of the OMM ftp server
after upgrading the OMM server.
Analyzing Instance 3
Topic
The OMM fault results from the incorrect settings of the timing
task.
Symptom
When an MSC Server is creating the data of the MGW managed
by this MSC Server, the response of the OMM client is too slow to
modify and add data, which will last for about 10 minutes.
Fault Analysis and
Location
1. This problem occurs frequently since a certain time (April 4).
Therefore, it is doubted that the data were modified at that
time. Search the operation logs of April 4, but there are too
many operations in the logs. So search the fault with other
method.
2. Observe the CPU load when the fault occurs. The CPU occupancy is very high. It is confirmed that the fault results from
the periodic or aperiodic running of a process.
3. Check the occupancy of the disk space by the OMM server.
There are five files with the extensions of DMP. Four of them
are larger than 1500 Mb, which are created by an unknown
process in the morning. The fault occurs again at about 14:20
p.m., and the size of the fifth file increases constantly and dramatically, close to 500 Mb. From this phenomenon, it is inferred that this fault occurs periodically.
4. Check the system management in the OMM system, only the
performance statistics data are set with the functions of data
backup, export and automatic deletion. And the Data Backup
policy is enabled for all of the policies in the Policy Management. This policy was modified on April 4 with a cycle of 27
hours. Check the entries of the policy management in the log
files, finding that an operator set the policy on that day. It is
confirmed that this policy results in the problem.
5. Suspend the data backup policy, and observe the running of
the system for two days. This fault does not occur again.
Summary
As a useful data backup tool, the data backup policy in the policy
management is used to perform data backup for the database of
data configuration in the OMM system. But the data backup operation occupies high CPU of the OMM server. Therefore, execute
Confidential and Proprietary Information of ZTE CORPORATION
65
ZXWN MGW Troubleshooting
such kind of task in the early morning or a period of time without
frequent operations.
Analyzing Instance 4
Topic
Symptom
Fault Analysis and
Location
The EMS fails to get the performance measurement file for OMM
FTP parameter setting errors.
The EMS fails to get the performance file reported by the CS.
The soft-switch reports a notification to the EMS, informing that the
performance files are ready. However, the IP address contained in
the performance files is wrong, which is set as 127.0.0.1. It results in that the EMS fails to get the performance files of the CS.
To configure the IP address through the tool in the tools\config\
directory on the OMM server, perform the following steps.
1. Run the run.bat in the tools\config\ directory, to pop up the
Config the Environment of Software dialog box, as shown
in Figure 25.
FIGURE 25 SETTING CORBA FTP
66
Confidential and Proprietary Information of ZTE CORPORATION
Chapter 5 OMM System Faults
2. On the CORBA FTP tab, input the big network address (that
is, the IP address for the OMM communicating with the EMS).
3. Delete TEMP files.
3. Delete TEMP files.
Result: The fault is solved after the OMM system is restarted.
Summary
If selecting to install the CORBA during the installation of OMM
system, it needs to set the FTP address of the CORBA at a later
stage of the installation. The default address is 127.0.0.1. To
avoid this error, modify it to the address used for communicating
with the EMS.
Analyzing Instance 5
Topic
Symptom
The OMM server fails to start.
The OMM server fails to start. Check the log file server-start.log
on the OMM server in the X:\ZXWN-OMCS\zxwomcs\ums-svr\log
directory.
The following information is shown in the file.
Starting failed
RuntimeErrorException: Error in MBean operation ’start()’
Cause: java.lang.Error: test 3 times ftp server fail
Fault Analysis
The FTP server fails to start during the startup of the OMM server
because the port 21 was occupied. There are following two cases.
1. Other FTP server was started, probably the IIS carried by the
operating system.
2. During the startup of the server, the FTP process was not
stopped normally. The engineer checks whether there is a
JAVA process in the Task Manager, and closes the Oracle HTTP
server in the Services.
Solution
1.
2.
3.
4.
5.
Summary
Click Start > Run, and type the CMDcommand. The Command Promptwindow appears.
Type the netstat -an|findstr 21 command to view whether
the port 21 is occupied.
Select Control Panel > Administrative Tools > Services to
pop up the Services dialog box.
Stop the IIS service carried by the Windows operating system.
Restart the OMM server.
�
Directly execute the run.bat (\ZXWN-OMCS\zxwomcs\umssvr\bin\run.bat) to start the OMM server for viewing more
startup information.
�
Close the FTP server before startup. Execute the netstat
-an|findstr 21 command to check whether the port 21 is
occupied.
Confidential and Proprietary Information of ZTE CORPORATION
67
ZXWN MGW Troubleshooting
Analyzing Instance 6
Topic
Symptom
Fault analysis and
location
The OMM client fails to connect the OMM server, and fails to log in
the database with the sqlplus uep/uepuep@omc command, of
which the omc is a database instance.
The OMM client fails to connect the OMM server.
1. Collect files.
{ORACLE_HOME}\admin\{ORACLE_SID}\bdump\*.trc
{ORACLE_HOME}\admin\{ORACLE_SID}\udump\*.trc
{ORACLE_HOME}\admin\{ORACLE_SID}\cdump\*.trc
{ORACLE_HOME}\admin\{ORACLE_SID}\pfile\*.*
admin\{ORACLE_SID}\bdump\alert_{ORACLE_SID}.log
Note:
ORACLE_HOME refers the installation path of the ORCLE, which
is usually installed in the D:/ORACLE directory on the OMM
server.
Through gathering files, it is found that the records in the
alert_{ORACLE_SID}.log are as follows.
Wed Sep 12 00:39:07 2007
KCF: write/open error block=0x1055 online=1
file=2 D:\ORACLE\ORADATA\OMC\UNDOTBS01.DBF
error=27072 txt: ’OSD-04008: WriteFile() Failed, unable to
write files to it
O/S-Error: (OS 1453) Quota insufficient, unable to complete
the required service’
Wed Sep 12 00:39:07 2007
Errors
in
d:\oracle\admin\omc\bdump\omc_ckpt_2120.trc:
ORA-00202:
TROL03.CTL’
controlfile:
file
’D:\ORACLE\ORADATA\OMC\CON-
ORA-27091: skgfqio: unable to queue I/O
ORA-27070: skgfdisp: async read/write failed
OSD-04006: ReadFile() Failed, unable to write files to it
O/S-Error: (OS 1453) Insufficient quota exists to complete the
required service
Wed Sep 12 00:39:07 2007
Errors
in
d:\oracle\admin\omc\bdump\omc_dbw0_1612.trc:
file
ORA-01242: data file suffered media failure: database in
NOARCHIVELOG mode
ORA-01114: IO error writing block to file 2 (block # 4181)
68
Confidential and Proprietary Information of ZTE CORPORATION
Chapter 5 OMM System Faults
ORA-01110: data file 2:
DOTBS01.DBF’
’D:\ORACLE\ORADATA\OMC\UN-
ORA-27072: skgfdisp: I/O error
OSD-04008: WriteFile() Failed, unable to write files to it
O/S-Error: (OS 1453) Insufficient quota exists to complete the
required service
DBW0: terminating instance due to error 1242
Wed Sep 12 00:39:09 2007
Errors
in
d:\oracle\admin\omc\bdump\omc_lgwr_2084.trc:
file
ORA-00345: redo log write error block 45901 count 2
ORA-00312: online log 1 thread 1:
DATA\OMC\REDO01.LOG’
’D:\ORACLE\ORA-
ORA-27072: skgfdisp: I/O error
OSD-04008: WriteFile() Failed, unable to write files to it
O/S-Error: (OS 1453) Insufficient quota exists to complete the
required service
Wed Sep 12 00:39:31 2007
Errors
in
d:\oracle\admin\omc\bdump\omc_ckpt_2120.trc:
file
ORA-00204: error in reading (block 1, # blocks 1) of controlfile
ORA-00202:
TROL03.CTL’
controlfile:
’D:\ORACLE\ORADATA\OMC\CON-
ORA-27091: skgfqio: unable to queue I/O
ORA-27070: skgfdisp: async read/write failed
OSD-04006: ReadFile() Failed, unable to write files to it
O/S-Error: (OS 1453) Insufficient quota exists to complete the
required service
Wed Sep 12 00:39:31 2007
Errors
in
d:\oracle\admin\omc\bdump\omc_lgwr_2084.trc:
file
ORA-00340: IO error processing online log 1 of thread 1
ORA-00345: redo log write error block 45901 count 2
ORA-00312: online log 1 thread 1:
DATA\OMC\REDO01.LOG’
’D:\ORACLE\ORA-
ORA-27072: skgfdisp: I/O error
OSD-04008: WriteFile() Failed, unable to write files to it
O/S-Error: (OS 1453) Insufficient quota exists to complete the
required service
Preliminarily, judge the fault results from insufficient table
space.
2. In DOS, type the sqlplus “sys/omc@omc as sysdba” command, and find that the 9205-patch is not installed. The oracle
version is still 9201.
Confidential and Proprietary Information of ZTE CORPORATION
69
ZXWN MGW Troubleshooting
Note:
Adjusting database parameters and installing 9205-patch are
recommended.
3. The adjusted database parameters are as follows.
sqlplus "sys/omc@omc as sysdba"
alter system set processes=300 scope=spfile;
alter system set timed_statistics=FALSE scope=spfile;
alter system set aq_tm_processes=0 scope=spfile;
alter system set shared_pool_size=167772160 scope=spfile;
alter system set java_pool_size=167772160 scope=spfile;
alter system set large_pool_size=67108864 scope=spfile;
alter system set db_cache_size=209715200 scope=spfile;
alter
system
scope=spfile;
set
pga_aggregate_target=167772160
alter system set undo_retention=1800 scope=spfile;
alter system set log_buffer=1048576 scope=spfile;
show parameters pfile;
4. Close the database instance.
shutdown immediate
5. Restart the database instance again.
startup
Summary
The oracle is not update to version 9205, which may cause some
uncertain factors. Therefore, it needs to confirm that the patches
are already installed for OMM database and user database, and
the OMM database is upsized successfully.
Analyzing Instance 7
Topic
OMP fails to communicate with the OMM server.
Symptom
OMP cannot communicate with the background server during MSC
Server debugging.
Fault analysis and
location
1. The engineer cannot ping the IP address of the foreground OMP
from the background server. However, the OMP is started and
runs the version normally.
2. The engineer checks the IP configuration of the OMP, which is
in the same network section with the background server. And
both of them has same mask. In normal circumstances, the IP
address of the OMP should be pinged through.
3. The engineer checks the FE interface of the switch, and finds
both status indicators and network cables are normal.
70
Confidential and Proprietary Information of ZTE CORPORATION
Chapter 5 OMM System Faults
4. The engineer checks the switch settings, and finds that it has
been separated into several VLANs, but that the network interface of the background server is not in the same VLAN with
that of the OMP.
Solution
The engineer adjusts the network cable of the OMP to make it use
the same VLAN with that of the OMM server. The communication
is normal.
Summary
IP communication network requires appropriately planning the IP
address, and separating the VLAN for the switch.
Analyzing Instance 8
Topic
Opening two OMM clients causes the failure of querying performance statistics results.
Symptom
After starting two clients, an engineer fails to query the performance statistic results for unknown error.
Fault analysis and
location
1. The engineer deletes the temporary files in the temp folder.
After that, the performance query is successful. But the fault
appears again very soon.
2. The problem always occurs when two OMM clients are started.
In this project, MSCS and MGW are located at different places.
Each has its own server side.
Fault Cause
When one OMM client is started, some temporary files will be automatically written in the TEMP folder. Meanwhile, these files will
also be resident in the memory. When another client is started for
performing performance query, the system will also write some
temporary files in the TEMP folder. Since some temporary files
with the same name are used by the OMM client that is started
previously, the system implements write-protect for these files.
This results in write failure, which causes the query to be terminated abnormally.
Solution
Close one of OMM clients. The performance query may be performed normally.
Confidential and Proprietary Information of ZTE CORPORATION
71
ZXWN MGW Troubleshooting
This page is intentionally blank.
72
Confidential and Proprietary Information of ZTE CORPORATION
Chapter
6
Interconnection Faults
in IP-Bearer Network
Table of Contents
Handling Continuous Call Loss Generated for Broken Receiving Fiber of Soft-Switch ......................................................73
Handling Call Loss Generated by Soft-Switch after CE
Restarts ...........................................................................74
Handling Soft-Switch Failing to Ping through CE.....................75
Handling Continuous
Call Loss Generated for
Broken Receiving Fiber of
Soft-Switch
Fault Description
When the receiving fiber at the soft-switch side is broken, high call
loss appears. At the same time, there are about 300 online calls in
stable status. However, there normally should be about 600 online
calls.
The networking structure is shown in Figure 26. The media plane
interfaces adopt the load-sharing mode, and enable the BFD fast
detection with the CE. The BFD is used to bind the static route.
When the receiving fiber is interrupted at the MGW side, it can
disable corresponding outgoing routes through this optical interface by using the BFD function. When the receiving fiber is interrupted at the MGW side, the ZTE soft-switch system can make the
external port down through the board on which no optical signal
is input, to quickly delete the outgoing route through this optical
interface.
Confidential and Proprietary Information of ZTE CORPORATION
73
ZXWN MGW Troubleshooting
FIGURE 26 INTERCONNECTION BETWEEN MEDIA PLANE
NETWORK
AND
BEARER
Analyzing and
Processing
1. After a fault occurs in the media plane interface of the MGW,
immediately disable the route through the faulty interface. The
method is: input the SHOW IP ROUTE ALL command on the
OMM client to check all the IP V4 route entries. The static route
through the MGW’s faulty interface is already down, indicating
that the MGW processing is correct.
2. Check whether the CE side correctly handles the static route
after the BFD is down. The CE engineer logs in the router,
and checks the route table. He/she finds that the static route
through the faulty port is still in Active status. He/she confirms
that the BFD is not bound with the static route.
Fault Cause
When the interface link is faulty, both the soft-switch equipment
and the CE must disable the route through the faulty interface
through related detective mechanism. Otherwise, it will cause the
data traffic, and affect the services.
Solution
The fault is handled after the CE engineer modifies the data configuration.
Handling Call Loss
Generated by Soft-Switch
after CE Restarts
Fault Description
74
The soft-switch equipment interconnects to another vendor’s CE
in the load-sharing mode, as shown in Figure 27. After the CE1 is
powered off, all the outgoing traffic of the soft-switch equipment
Confidential and Proprietary Information of ZTE CORPORATION
Chapter 6 Interconnection Faults in IP-Bearer Network
passes through the CE2. There are about 800 call loss records
during the power-on of the CE1.
FIGURE 27 INTERCONNECTION BETWEEN SOFT-SWITCH
AND
CE
Analyzing and
Processing
1. When the call loss is generated during the power-on of the CE,
ping the CE gateway from the ZTE soft-switch network management platform. The CE gateway can be pinged through,
but fails to ping the opposite soft-switch through the bearer
network.
2. Detect the opposite soft-switch equipment of the IP bearer network through the Trace tool, and find that the first hop can be
transmitted to the CE, but the subsequent routes fail to reach
the CE.
Fault Cause
When the CE is powered on, probably the port between the CE
and the soft-switch is restored at first, and then the BFD, but the
dynamic route of the IP bearer network is not restored. In this way,
the data traffic of the soft-switch will be sent to the CE, resulting
in the packet loss and bringing serious influence on the services.
Solution
The CE engineer adjusts the power-on sequence of the CE port to
make sure that the internal routes of the IP bearer network restore
first after the CE is powered on.
Handling Soft-Switch Failing
to Ping through CE
Fault Description
The ZTE soft-switch equipment is interconnected to another vendor’s CE. During the call, the soft-switch fails to ping through the
CE address after the electric interface between the MSCS and CE
is restored after physical disconnection.
Confidential and Proprietary Information of ZTE CORPORATION
75
ZXWN MGW Troubleshooting
Analyzing and
Processing
1. After the laptop is directly connected with the signaling interface board of the soft-switch equipment, the laptop can ping
through the SIPI interface address.
2. After the laptop is directly connected with the CE, the laptop
cannot ping through the interface address of the CE. By capturing the package with the WireShark, the engineer only finds
the ARP request sent out, but does not receive the response
from the CE.
The above-mentioned analysis shows that the fault is not located
at the soft-switch side. The CE engineer checks the data, and finds
that the CE’s electric interface cannot be configured as Enforced.
However, the CE engineer said the electric interface of the CE is in
enforced mode when he/she negotiated the data with us.
76
Fault Cause
Inconsistent electric interface configuration will cause the softswitch failing to ping through the CE.
Solution
On the soft-switch network management platform, the engineer
modifies the soft-switch’s electric interface to auto-negotiation
mode, and the fault is solved.
Confidential and Proprietary Information of ZTE CORPORATION
Chapter
7
Voice Faults
Table of Contents
Common Voice Faults .........................................................77
Troubleshooting Ideas and Common Methods ........................78
Echo Fault Handling ...........................................................82
Monolog Fault Handling ......................................................89
Both-Way Silence Fault Handling..........................................90
Noise Fault Handling ..........................................................92
Cross-Talking Fault Handling ...............................................92
Instance Analysis ..............................................................93
Common Voice Faults
Overview
Voice Fault Types
In general case, voice faults result from bearer problems. In
special case, other problems, such as signaling compatibility
and abnormal parameter processing made by control plane, will
also cause voice faults. Or, handover or other services happens
after the subscriber enters the stable status, which will also
result in voice faults. For these cases, analyze signaling to find
corresponding cause.
There are the following common voice phenomena.
�
Echo
Speaker hears his/her own and the opposite’s voice at the same
time in telephone.
�
Monolog
The local party can hear the opposite voice for a period of time,
but the opposite party cannot hear the local party’s voice during a call.
Monolog divides into long-time monolog and instantaneous
monolog. Long-term monolog refers to the monolog lasts for
a long time, and cannot restore. Instantaneous monolog lasts
for a short time. Usually, a call becomes normal after two to
five seconds. Monolog is different from voice intermittence.
Voice intermittence usually results from poor quality at wireless side. Because of this, the listening sound is discontinuous,
but with very short interval.
�
Both-way silence
Calling and called parties cannot hear the opposite’s voice, but
can hear his/her own echo sometimes.
Confidential and Proprietary Information of ZTE CORPORATION
77
ZXWN MGW Troubleshooting
�
Noise (gabbling call)
The voice quality is poor during a call, sometimes along with
metallic sound, iron forged sound, jangle, other noises. These
abnormal sounds are discontinuous, abrupt, and short.
�
Cross-talking
Calling or called party may hear voices, ring-back tone, and
other sounds from other person during a call.
Voice Fault
Analysis
Generally, voice faults are probably caused by CN NE, or wireless
network (BSC/BTS). Sometimes, they are associated with mobile
phones.
In CN, the common fault points are as follows.
�
Abnormal signaling processing for incompatible signaling
�
A/IU interface trunk or inter-office trunk
�
UIMT/TFI/TSNB board fault
�
Fiber or fiber module between UIMT and TFI
�
VTCD board or some DSP is faulty during IP calls.
In addition, EDRT board of BSC, BTS, mobile phone, and wireless
environment may also cause tone faults.
Troubleshooting Ideas and
Common Methods
This section describes troubleshooting ideas and common methods.
Troubleshooting Ideas
The most crucial point for troubleshooting voice faults is to make
sure which NE in the network causes the fault firstly. If it is difficult
to locate the fault quickly, analyze and process it by referring to
the following ideas.
If not sure which NE causes the fault, you should coordinate with
engineers at wireless side and service personnel from other exchanges to troubleshoot the fault together.
�
Know subscriber’s complaints.
Before troubleshooting the fault, you must clearly know detailed information about complaints. Focus on the following
information.
�
Calling and called numbers
�
Calling and called locations (located exchange and BSC)
�
78
Occurrence probability of the fault (whether it occurs during
every call or occasionally)
Confidential and Proprietary Information of ZTE CORPORATION
Chapter 7 Voice Faults
�
�
Time of the fault occurs (whether it occurs in ring-back
phase, when the call is just completed connected, or during
a call).
Know the operations before and after the fault occurs.
Know the operational conditions of local NE, wireless equipment, and other NEs in the whole network before and after the
fault, such as:
�
�
�
�
Capacity expansion is implemented for A-interface or interoffice trunk.
Engineering personnel changed trunk jumpers in the equipment room.
The EFR function is enabled at wireless side.
Fault reproduction
Fault reproduction is used to make a fault occur again through
many times of call quality tests when service personnel cannot
locate the fault immediately after knowing complaints. This is
to find the common points so as to find the fault source.
The following aspects require attention when reproducing a
fault.
�
�
�
�
Respectively record the signaling when the voice-quality
problem occurs and when the voice is normal.
Record the probability of this problem occurring.
Record the call model and information of involved NEs when
this problem occurs.
Fault Analysis
Synthesize the collected information from the three aspects
mentioned above, and analyze the fault.
Common Methods for Locating Faulty
NE
The following methods are frequently used for locating the NE(s)
that results in the fault. You may troubleshoot the fault with one
or several methods.
Exclusion Method
The voice quality problem is complex. In most cases, it results
from the combined influence of several NEs. To reduce the
troubleshooting range, you may preliminarily locate the faulty NE
through dialing test or loopback test.
There are two methods of excluding NEs.
Perform dialing test for specified services, offices, and resources
(CIC or TC) to locate the faulty NE. The general principles are as
follows.
�
Calls are normal in the local BSC, which proves that BSC processing, transmission from MGW to BSC, and some functions
of MGW are normal.
Confidential and Proprietary Information of ZTE CORPORATION
79
ZXWN MGW Troubleshooting
Loopback between
NEs
�
Calls cannot be connected on some BSCs in a same MGW. It is
doubted that these BSCs process calls abnormally, or A-interface trunk works abnormally.
�
Local office call is normal, but inter-office call is abnormal.
Probably, the fault results from the processing problem of inter-office trunk or opposite-end office.
�
Local office plays ring-back tone abnormally, which becomes
normally after calls. Probably, MRB board of local office or
T-network-related board is abnormal.
Perform loopback on the bearer between NEs, and then implement
CQT to locate faulty NE.
For example, in a V3 end office, monolog occurs when a mobile
subscriber calls a PSTN subscriber. Implement loopback test on
one E1 of the A-interface trunk. After loopback, specify the call
from mobile subscriber to PSTN subscriber to adopt the loopback
trunk circuit. If the mobile subscriber can hear his/her own voice
after the call is completed connected, but the PSTN subscriber cannot, BSC can be excluded.
Implement loopback test on one E1 of inter-office trunk. After
loopback, specify the call from mobile subscriber to PSTN subscriber to adopt the loopback trunk circuit. If the mobile subscriber
can hear his/her own voice after the call is completely connected,
but the PSTN subscriber cannot, BSC and CN can be excluded.
Caution:
Loopback test has effect on the current network services. Release
loopback as earliest as possible after the test is completed. In
addition, this method has some limitations for BSC and CN NEs
with different implementation modes.
Locating Faults
with Tools
Use 2M signaling analyzer and other similar meters to locate the
system-related problems. Intercept signaling section by section
to determine the problem range, as shown in Figure 28.
FIGURE 28 INTERCEPTING CALLS SECTION
BY
SECTION
During segmentation interception, focus on endpoint of each section (that is the access point of interception equipment). Probably,
the problem just lies in this connection points.
80
Confidential and Proprietary Information of ZTE CORPORATION
Chapter 7 Voice Faults
This method and the call quality test on specified trunk may be
used in a combined manner. For example, specify the third timeslot of the first E1 of the A-interface trunk to accept the CQT test.
After the call is connected, connect the receiving line of 2M signaling analyzer to the independent output interface of E1-corresponded tee connector on the DDF rack.
Methods of Locating Internal Fault
Points on CN
Overview
These methods are usually used for troubleshooting, when voice
faults are certainly caused by the node on CN or leading-in trunkcircuit import. They can also be used for implementing self-test
for CN when the faulty NE is different to be located.
The following scenarios are only used for providing reference for
locating faults onsite. The onsite engineers may also select suitable methods according to practical conditions.
Signaling
Comparison
�
Information collection
Collect signaling messages when voice problems occur and
when voice is normal.
�
Applicable Scenarios
This method is applicable for a certain call model or office
where the voice problem occurs.
Example: a CN is interconnected with several PSTN offices.
The voice quality is normal when mobile subscriber calls PSTN
office A. However, when mobile subscriber calls subscriber in
PSTN office B, voice quality is poor in every call.
Method
Compare the faulty signaling with the normal signaling to see
whether their signaling code streams are different. If they have
different lengths of code streams, or the settings of important
parameters in signaling messages are different, feed back this
signaling to headquarter for making sure whether the signaling
is normal.
Trunk Continuity
Test
�
Prerequisites
Opposite equipment supports continuity.
�
Applicable Scenarios
Inter-office trunk test
�
Method
Perform the continuity test on the trunks on Dynamic Management of OMM client. This method cannot distinguish a
self-looped trunk.
Dialing Test on
Specified Trunk
(TDM Bearer)
�
Prerequisites
SIM cards and mobile phones of calling and called parties are
ready.
�
Applicable Scenarios
Confidential and Proprietary Information of ZTE CORPORATION
81
ZXWN MGW Troubleshooting
Voice problems always focus on one or several A-interface
trunk or inter-office trunk (TDM-type trunk circuit).
�
Method
The current CN system provides the function of doing dialing
test on specified trunks.
Dialing Test on
Specified RTP/TC
Resources (IP
Bearer
�
Prerequisites
SIM cards and mobile phones of calling and called parties are
ready.
�
Applicable Scenarios
Voice problems always focus on one or several A-interface
trunk or inter-office trunk (IP-type trunk circuit).
�
Method
The current CN system provides the function of doing dialing
test on specified trunks.
Board
Changeover/Resetting
If you doubt that the voice fault probably locates on some
functional board, and this board/interface is configured with
active/standby mode, you may change over or reset it manually
or with software. If this board/interface shares load with others,
you may change over or reset spare board/interface to examine
whether some board/interface is faulty.
Caution:
�
Changeover is an operation with relatively high risks. System
data backup must be done in advance.
�
It is recommended to perform changeover on OMP and other
important boards at 0:00 - 6:00 am, and to keep a certain
interval between two changeover activities.
Echo Fault Handling
This section describes the procedure for handling echo fault.
Echo Principles
Electrical Echo
The transmission system on the relay network uses four-wire for
transmission, while subscriber transmission line uses two-wire for
full-duplex transmission. This conversion is implemented through
two/four-wire hybrid in local switch.
However, the transmitter and receiver cannot be isolated completely, since the impedance of actual hybrid coil is mismatched.
Therefore, the two/four-wire converter can only separate the
transmitter from the receiver to a certain extent. The signals
received by four-wire are not converted completely to two-wire.
82
Confidential and Proprietary Information of ZTE CORPORATION
Chapter 7 Voice Faults
Some signals leak out to the transmission part of four-wire. As a
result, echo wave is generated, as shown in Figure 29. Electrical
echo is the main source of echo. Common echo canceller is used
to eliminate it.
FIGURE 29 ELECTRICAL ECHO
Acoustic Echo
Speaker and microphone are not well isolated in some telephones.
Acoustic echo is generated when the sound given out is transmitted
back to the microphone through several times of space-reflection.
This case happens when a hands-free telephone is used in a room
or car.
Working Principles of Echo Canceller
Principle Overview
An echo canceller subtracts the assessed value of echo signals
from the four-wire transmitting path to eliminate the interference.
The echo signal value is assessed based on the voice signals on
four-wire receiving path. Briefly, an echo canceller supervises the
voices from the far-end on the receiving path, and then assesses
the echo value. Finally, subtract this value from the transmitting path. In this way, the echo is eliminated, only the voices
of near-end are transmitted to the far-end.
An echo canceller has four ports. Two ports are located at the
drop-side, and the other two ports are located at the line-side, as
shown in Figure 30.
Confidential and Proprietary Information of ZTE CORPORATION
83
ZXWN MGW Troubleshooting
FIGURE 30 WORKING PRINCIPLES
OF
ECHO CANCELLER
Because the echo to be eliminated is generated at end path, the
delay on the long haul line does not affect the echo canceller. But,
the total circuit delay (end-path plus long-haul-line) determines
whether to use an echo canceller. When it is more than 30 ms, an
echo canceller should be adopted.
Note:
When an echo canceller is installed at near-end, remote subscribers are benefited. When it is installed at far-end, near
subscribers are benefited.
Echo Directions
Incoming EC and outgoing EC are two concepts concerning gateway exchange.
Figure 31 shows the essential meaning of incoming EC and outgoing EC. The marks of incoming and outgoing calls are reflected by
signaling, which may be IAM/IAI signaling or ACM signaling.
FIGURE 31 INCOMING/OUTING EC
�
84
Incoming EC
Confidential and Proprietary Information of ZTE CORPORATION
Chapter 7 Voice Faults
It is the direction that receives an IAM or ACM/CPG/ANM message. This is the direction of an echo. The direction of audio
frequency has the opposite direction with that of this echo.
�
Outgoing EC
It is the direction that sends an IAM or ACM/CPG/ANM message. This is the direction of an echo. Audio frequency has the
opposite direction with that of this echo.
Generally, an echo has directional character. Because of it, the
echo suppressor also has this character. We mainly focus on the
parameters setting for EC direction.
EC direction includes the GMSC-PSTN direction (or E1 direction)
and the GMSC-MSC direction (or HW direction). Suppose the networking structure is PSTN-GMSC-MSC, PTSN generates echoes,
and GMSC provides an echo canceller. EC direction may understand as this: The echo canceller on the E1 direction may suppress
the echo generated when PSTN dials an MS.
Echo-Suppression Implementation
Whether to enable echo suppression in ZXWN MSCS requires integrating the echo suppression information carried by signaling
and the hardware configuration of MGW (whether DTEC board is
equipped)
Currently, ZXWN MGW supports embedded echo suppression function. Independent echo suppression function (EC Pool) is under
research.
Configuring Echo Cancellation
Prerequisites
Before the operation, it is required to confirm:
�
The OMM system runs normally.
�
The OMM client has logged in the OMM server normally.
Context
Perform this procedure to configure the function of echo cancellation.
Steps
1. On the MML Terminal interface of OMM client, select MSCS in
the root tree.
2. In the MML Commands tree, double-click Trunk Configuration > Trunk Group > Modify Information Flag of Trunk
Group.
3. Type Trunk Group Number, and click the box following Enable Flag to pop up the Enable Flag dialog box, as shown in
Figure 32.
Confidential and Proprietary Information of ZTE CORPORATION
85
ZXWN MGW Troubleshooting
FIGURE 32 ENABLE FLAG
4. Select the Echo (Include Echo Killer) check box.
5. Click OK to return to the MML Terminal interface.
6. Click Execute to run the command.
7. On the OMM client, select Views > Professional Maintenance > MSCS > Variables Control > IGW Service Control
Parameter to enter the IGW Service Control Parameter
tab.
8. Select the ISUP Spare row, as shown in Figure 33.
FIGURE 33 ISUP SPARE
9. Click the Modify icon on the sub-tool to enter the editing status. Type 1.
The default is 0.
10. Click Save on the sub-toolbar.
END OF STEPS
86
Confidential and Proprietary Information of ZTE CORPORATION
Chapter 7 Voice Faults
Configuring Echo Cancellation by Adopting
Resource Pool
Prerequisites
Before the operation, it is required to confirm:
�
The OMM system runs normally.
�
The OMM client has logged in the OMM server normally.
Context
In the condition of ECPOOL is configured, it is not allowed to configure the EC sub-card to the DTB and SDTB units where only E1
lines are led out. The SDTB unit does not support ECPOOL.
Steps
1. Perform one of the following steps to specify the MGW exchange to be configured on the MML Terminal interface of
the OMM client.
Execute the SET command in the command input area.
Select the required NE in the root tree.
For example, to select the MGW exchange with the office ID as
31 in the root tree, the command is:
SET:NEID=31;
2. Add an EC POOL resource board. The command is ADD UNIT.
For the parameters in the ADD UNIT command, refer to Table
8.
TABLE 8 PARAMETERS
IN THE
ADD UNIT COMMAND
Parameters
Explanation
Instruction
LOC
Unit location
Format: RACK - SHELF - SLOT
MODULE
Module No.
Specifies No. of the module that
the unit belongs to. Usually 1 is
selected for the OMP module that
the unit belongs to.
UNIT
Unit No.
The No. of the unit corresponded
by the board, ranging from 1 to
2000. Type an unused unit No..
TYPE
Unit type
Selects it according to the actual
conditions.
BKMODE
Backup mode
Select NO.
For example, add an EC POOL resource board in a mode of
DTEC sub-card plus EC. The specific command is as follows.
ADD UNIT:LOC="1"-"2"-"3",MODULE=1,UNIT=3,TYPE=D
TB2_ECPOOL_Z2EC1,BKMODE=NO,BKUNIT=65535,CLK=2
55;
3. Configure the management mode of EC resources. The command is SET ECRSC.
For the parameters in the SET ECRSC command, refer to Table
9.
Confidential and Proprietary Information of ZTE CORPORATION
87
ZXWN MGW Troubleshooting
TABLE 9 PARAMETERS
IN THE
SET ECRSC COMMAND
Parameters
Explanation
Instruction
EC
The management modes of
EC resources are as follows.
Type POOL.
�
CONNECTED: Direct
connected mode
�
POOL: Pool mode
For example, to set the management mode of EC resources to
the POOL mode, the command is as follows.
SET ECRSC:EC=POOL;
END OF STEPS
Postrequisite
Transfer the data tables.
System Implementation
�
Incoming processing for tandem/end office
Whether to enable outgoing EC for incoming calls is determined
by trunk flag and the echoInd field carried by IAM message.
�
�
�
If the echoInd field carried by incoming IAM message is 1,
it indicates that the preceding office enables the EC function. By default, local office will disable this function. If
the trunk flag is “ECHO” and the ISUP Spare variable is
configured with 1, local office will forcibly enable the EC
function.
If the echoInd field carried by incoming IAM message is 0,
it indicates that the preceding office disables the EC function. By default, local office will determine whether to enable this function. If the trunk flag is ECHO, local office will
enable the EC function.
Processing at outgoing side of tandem office
Currently, the incoming EC function can be enabled forcibly for
outgoing calls, which is determined by the trunk flag and the
echoInd field carried by incoming ACM message.
�
�
88
If the echoInd field carried by incoming ACM message is
1, it indicates that the preceding office enables the EC function. By default, local office will not enable this function.
If the trunk flag is ECHO and the ISUP Spare variable is
configured with 1, local office will forcibly enable the EC
function, and the echoInd field carried by outgoing ACM
message is 1.
If the echoInd field carried by incoming ACM message
is 0, it indicates that the preceding office disables the EC
function. Local office will determine whether to enable this
function according to the configurations. If the trunk flag
is ECHO, local office will enable the EC function, and the
echoInd field carried by outgoing ACM message is 1.
Confidential and Proprietary Information of ZTE CORPORATION
Chapter 7 Voice Faults
�
Processing an originating call of end office
An end office originates a call. When it requests an A-interface
circuit, EC is enabled by default. CC sends an message to interoffice signaling during voice service. The EC flag contained by
this message is forcibly configured as 1, indicating that EC is
enabled.
But, mobile terminal has its own EC function so that the end
office does not need to enable it. In subsequent version, EC is
not required when an A-interface circuit is requested. The EC
flag carried by the message sent to inter-office signaling is still
forcibly configured as 1.
�
Special Notes
If the ECHO (Include Echo Killer) flag is not selected for outgoing trunk group (for example, SET TGFLG:TG=1,DISABL
E="Echo";), and the ISUP Spare variable is valued as 1, the
echoInd field carried by outgoing IAM message is 1.
During an originating call of local office, the echoInd field carried by outgoing IAM messages is 1 under default conditions.
If local office serves as a transit exchange, the echoInd field
is carried by incoming IAM message transmitted transparently.
Fault Processing
Generally, an echo is generated when a mobile subscriber belonging to a gateway exchange calls a fixed subscriber. In this case,
you need to check whether DTEC board is installed in the trunk
group between mobile exchange and fixed exchange, and whether
the EC function is enabled during the corresponding data configuration.
In addition, mobile phone’s own problem will also cause an echo.
To locate this fault, just replace it with another test terminal.
Monolog Fault Handling
Overview
The monolog fault often occurs, which involves many NEs. Because many reasons may cause this fault, onsite engineer should
find the common points according to fault information so as to locate and handle it.
Fault Analysis
The monolog fault is relatively complicated, which is probably
caused by the following reasons.
�
BSC/RNC or other NE problem
EDRT of BSC, carrier frequency interference of radio signals,
uplink/downlink imbalance, and other conditions may cause
monolog.
�
Mismatched wires of trunk
Receiving or transmitting line of some E1 on the trunk circuit
is connected to a wrong E1, or cables are badly welded. No-
Confidential and Proprietary Information of ZTE CORPORATION
89
ZXWN MGW Troubleshooting
tice that the trunk problem only occurs on either receiving or
transmitting direction; otherwise, it is a both-way silence fault.
�
Signaling compatibility
Signaling incompatibility results from the interconnection between equipment produced by different manufacturers in the
CN. As a result, the monolog fault occurs.
�
TSNB/TFI/UIMT/VTCD board is faulty.
The monolog fault may be caused by the circuit-connection
error in switching network board, the optical module fault of
TFI board, and other conditions.
�
Fault Handling
If ring-back tone or color ring back tone can be heard normally,
but the monolog phenomenon suddenly appears during a call,
check whether handover or radio signal interference occurs,
and whether the radio signal strength is normally.
Service personnel must regard Troubleshooting Ideas as overall
guiding principle. Handle monolog fault with the locating methods
mentioned above according to onsite conditions.
Since currently voice stream cannot be saved, service personnel
can only hear voice manually for judgment when voice fault (bothway silence, monolog, and other faults) occurs. Analyze the CDR
files to judge the circuit seized by this call so as to reduce the range
of hearing voice. Loop is the best method used to judge where the
fault occurs. With this method, reduce the troubleshooting range
till the fault is located.
Both-Way Silence Fault
Handling
Overview
As monolog fault, both-way silence fault often occurs. In addition,
these two faults are confusable. Actually, there is an essential
distinction between them. When a fault occurs, service personnel
should distinguish them by respectively knowing the subjective
feelings of calling and called parties.
Both-way silence fault is mostly caused by interconnection of trunk
circuits.
Fault Analysis
�
Analyzing fault for TDM bearer
Corresponding to a TDM bearer, both-way silence fault is generally caused by the following conditions.
�
BSC or other NE problem
�
Trunk wires are mismatched or self-looped.
Mismatched-wire condition in both-way silence fault is
somewhat different from that in monolog fault. The following conditions possibly result in both-way silence fault.
Both receiving and transmitting lines of some E1 on the
trunk circuit are connected to a wrong E1. Receiving and
transmitting lines are connected inversely during interconnection. Cables are badly welded. In addition, trunk
90
Confidential and Proprietary Information of ZTE CORPORATION
Chapter 7 Voice Faults
self-loop will also cause this fault. In this case, calling and
called parties can hear his/her own voice, which is easy to
reveals the problem.
�
PCM system IDs at both sides of a trunk for interconnection
are inconsistent.
The inter-office trunk between MSC A and MSC B are totally interconnected N E1s. The PCM system ID of MSC A
is “0~N-1”, while that of MSC B is “1~N”. When MSC A
allocates the second timeslot in the E1 of the trunk circuit
whose PCM system ID is 1, the corresponded physical circuit is the second timeslot of the second E1. However, the
physical circuit actually used by MSC B is the second timeslot of the first E1.
�
TSNB/TFI/UIMT board fault
Both-way silence fault may be caused by the circuit-connection error in switching network board, the optical module fault of TFI board, and other conditions.
�
Analyzing fault for IP bearer
Corresponding to an IP bearer, both-way silence fault is generally caused by the following conditions.
�
RNC or other NE is faulty.
�
GLI board in MGW is faulty.
For example, the faulty memory on the GLI board causes
this board’s forwarding table error, which results in bothway silence.
�
UIM board in MGW is faulty.
For example, the forwarding chip on the UIM board is faulty.
The current version is added the auto-sensing and autochangeover functions to evade this fault. Generally, this
kind of problem will not appear in the outfield.
�
VTCD board in MGW is faulty.
For example, VTCD chip has a hardware fault or other problems.
Fault Handling
To handle both-way silence, perform the CQT test first to make
sure the fault range, whether both ring-back tone and voice cannot
be heard, or just voice call is abnormal during the whole call.
�
If both-way silence occurs in all types of calls (intra-office and
outgoing calls), it is usually related with core switching board,
such as TSNB and PSN.
�
If this fault occurs in the calls to some office, it is usually related
with the trunk circuit or opposite device(s) of this office.
�
Perform board changeover to handle the both-way silence fault
that is possibly caused by malfunctioning TSNB/PSN/UIMT/TFI
board.
�
To troubleshoot the fault caused by trunk circuits, perform CQT
test on designated trunk for TDM circuits; or on designated
RTP/TC resources for IP circuits.
�
To troubleshoot the fault related with IP bearer network,
you can only capture packets on each rank, for CS version
3.06/3.07.11/3.07.20 does not yet provide the loopback
Confidential and Proprietary Information of ZTE CORPORATION
91
ZXWN MGW Troubleshooting
function. Generally, capture the IP messages between NEs
first to make sure that which NE causes this fault, and then
capture the messages inside this NE to make sure of the faulty
module.
Noise Fault Handling
Overview
Fault Analysis
Fault Handling
Noise fault occasionally appears in a call, which is usually concurrent with monolog or both-way silence.
This fault is possibly due to one or more of the following causes.
�
The DDF frame where the trunk circuit is located is not well
grounded, or error codes occur on the transmission equipment.
�
Poor radio link signals, radio frequency interference, or the system problem of radio antenna and feeder.
�
Clock fault in the CN, or BSC and other NEs
�
TSNB/TFI/UIMT board fault in the CN
�
TDM/IP terminal deadlock due to MGW version error.
To troubleshoot a noise fault, perform CQT test to make sure the
fault range. If a noise fault occurs in all types of calls (intra-office and outgoing calls), it is usually related with core switching
board, such as TSNB and PSN. If this fault occurs to the calls to
some office, it is usually related with the trunk circuit or opposite
equipment of this office.
Perform board changeover to handle the noise fault that is possibly caused by malfunctioning TSNB/PSN/UIMT/TFI board working
in active/standby mode. For a noise fault caused by TDM trunk
circuit, specify a trunk to perform the CQT test to locate it. For
a noise fault caused by IP trunk circuit, capture IP messages to
locate it.
Cross-Talking Fault
Handling
A noise fault occasionally appears in a call, which is usually concurrent with monolog, both-way silence, or noises.
Fault Analysis
92
Generally, cross-talking fault is seldom caused by the CN problem.
The common causes are as follows.
�
BSC fault, radio frequency interference, or other radio problems
�
Connection error occurs on TSNB, PSN and other switching
boards in the CN
Confidential and Proprietary Information of ZTE CORPORATION
Chapter 7 Voice Faults
Instance Analysis
This section describes some voice-fault instances.
Analyzing Instance 1
Topic
Networking
Diagram
Calls of some end office occurs monolog, both-way silence and
cross-talking faults.
Figure 34 shows the networking diagram of this instance.
FIGURE 34 NETWORKING DIAGRAM
Symptom
Analyzing and
Processing
When an end office is in maintenance period, monolog, both-way
silence, cross-talking and other faults appear in some call.
1. Reproduce the fault through call quality test.
�
�
�
The subscriber dials intra-office calls under MGW 1 for 50
times. Monolog, cross-talking and other faults do not appear.
The subscriber dials intra-office calls under MGW 2 for 50
times. Monolog, cross-talking and other faults do not appear.
The subscriber under MGW1 dials a NOKIA subscriber for
50 times. The route is MGW1-T1-NOKIA. One time of
Confidential and Proprietary Information of ZTE CORPORATION
93
ZXWN MGW Troubleshooting
monolog, two times of cross-talking and both-way silence
faults appear.
�
�
�
The subscriber under MGW1 dials a NOKIA subscriber for
50 times. The route is MGW1-MGW2-T2-NOKIA. One time
of monolog and two times of cross-talking faults appear.
The subscriber under MGW2 dials a NOKIA subscriber for
50 times. The route is MGW2-T2-NOKIA. Monolog, crosstalking and other faults do not appear.
The subscriber under MGW2 dials a NOKIA subscriber for
50 times. The route is MGW2-MGW1-T1-NOKIA. Two times
of monolog and one time of both-way silence faults appear.
2. Analyze call quality results
By analyzing the call quality test results of local office, find
that voice faults are not caused by BSC, A-interface trunk circuit, and local-office boards. By analyzing the results of tests
through different calling routes, find that the MGW1-T1-NOKIA
inter-office trunk and some E1 lines on the circuits between
MGW 1 and MGW 2 have problems, which cause voice faults.
3. Perform designated trunk call quality test
Perform designated trunk call quality test results on the MGW1T1-NOKIA trunks, and find that voice faults always occur in the
calls through some E1 lines. Check the jumpers on this E1 line,
and find that some lines are connected inversely or crosswise.
4. Check physical circuit
Since NetNumen M30 (V3.06) installed in the current network
does not support performing call quality test on inter-MGW circuits, onsite service personnel directly check the physical connection of this part of circuits. He/she finds that some E1 line
is connected inversely or crosswise.
Solution
Rectify the trunk circuits having connection errors. The fault is
eliminated.
Analyzing Instance 2
Topic
Echo and monolog faults happen in some end office.
Symptom
The calling subscriber belongs to ZTE end office, while the called
subscriber belongs to S-manufacturer end office. The calling subscriber can hear the called subscriber’s voice, without any exceptions. But the called subscriber cannot hear the opposite’s voice,
but only an echo of his/hers. There is a direct-connected trunk
circuit between these two end offices.
Analyzing and
Processing
1. Inquire into the operating conditions before and after the fault
happened.
Before the fault occurs, seven A-interface circuits (PCM 16~22)
are added, of which four circuits are abnormal.
2. Perform interception test.
Connect a 2M online BER tester with the A-interface of ZTE end
office for intercepting timeslots. The called subscriber sound
is heard on uplink and downlink.
94
Confidential and Proprietary Information of ZTE CORPORATION
Chapter 7 Voice Faults
3. Analyze the fault.
Since the called subscriber’s voice is audible on the uplink and
downlink of the A interface, its uplink is abnormal. Possibly,
the faulty point is located at BSC, A-interface trunk, and Abis
circuit.
4. Handle the fault.
i. At the CS side, replace the abnormal PCM 19 port with the
normal PCM 20 port, and swap data between PCM 19 and
PCM 20. The BSC side remains unchanged. PCM 19 port is
abnormal, while PCM 20 port is normal, indicating that the
MGW ports are normal.
ii. At the CS side, the trunk group corresponded by PCM
16~19 is changed, but these four circuits are still faulty.
iii. Perform changeover on the EDRT board at the BSC side,
but the fault still remains.
iv. On the TIC of the BSC side, exchange the transmission
ports of PCM 19 and PCM 20, and the ports corresponded
by data, too. The MGW side remains unchanged. However,
PCM 19 port is still abnormal, while PCM 20 port is normal,
indicating that the ports at the BSC side are normal.
v. Perform soft-loop on transmission, and the same fault phenomena are simulated. So, the fault is caused by transmission problems.
Solution
The transmission personnel of A-interface are responsible for handling this fault. The fault is eliminated after the abnormal circuit
is replaced.
Analyzing Instance 3
Topic
Background noises are audible in the calls of an end office.
Symptom
Background noise similar like firecracker sound appears in some
calls of this end office. Either or both of the parties can hear it
simultaneously.
Analyzing and
Processing
Background noise appears after several times of intra-office call
quality tests. Since intra-office call does not involve other MSC,
the call is connected only through MSC of local office and BSC. And
inter-office trunk or opposite device will not affect it. But, you still
need to check whether the noise comes from the radio side or the
CN side.
Contact with headquarters, perform voice-channel self-loop on the
trunk board of MSC or BSC to locate the fault. Log in the SDTB/DTB
board occupied by the foreground, and operate self-loop voice
channel with related commands.
When background noise appears during the call test, perform selfloop from the timeslot of the CN A-interface occupied by calling
and called parties to the BSC side. Noise does not exist. Perform
self-loop to the UIMT side. Both parties can hear noises. It is
basically sure that the fault is located at the CN side. After dialing
for several times, find that either of the calling and called parties
Confidential and Proprietary Information of ZTE CORPORATION
95
ZXWN MGW Troubleshooting
will seize the two SDTB trunks in shelf 2 in rack 2 of MSC when
noise appears.
The voice code stream of intra-office call involves ETSN, TFI, UIM
and SDTB boards in MSC.
�
SDTB board is a trunk board.
�
UIM board completes Ethernet level-2 switching inside shelf,
and connects the TFI board (timeslot switching interface board)
through fiber.
�
ETSN board is a timeslot switching board.
An uplink originated call from A-interface trunk is transmitted
through SDTB board, and then through UIMT and TFI board, and
finally reaches ESTN. After the timeslot switching processing of
ESTN, this call is sent to SDTB through TFI and UIMT boards.
Finally, it reaches the called party through BSC, an A-interface
trunk. The uplink route of a terminated call is the same as that
of the originated call.
The intra-MSC connection flow of intra-office call is shown in Figure
35.
FIGURE 35 CALL QUALITY TEST FLOW
Check TFI and UIMT boards, and find that the corresponding optical interface of TFI implements active/standby changeover automatically and continuously. This TFI board is connected with the
UIM board of this shelf. And other TFI optical interfaces and UIMT
board are normal.
The changeover notification is also shown in the Fault Management window of the NetNumen M30 window.
Since board fault or incorrect connection between UIMT and TFI
boards may possibly cause noises, change over the ESTN board
of MSC, and find that an exception of optical interface changeover
exists, and noises are not eliminated.
Solution
After the optical module of the TFI board is replaced, the exception of optical-interface auto-changeover is eliminated. Specify
the trunk of the two SDTB boards that occur exceptions to perform the CQT test for several times. Noises do not appear again.
Analyzing Instance 4
Topic
96
Noises result from the transmission system fault.
Confidential and Proprietary Information of ZTE CORPORATION
Chapter 7 Voice Faults
Symptom
After an office is interconnected with its opposite office, the signaling flow is normal. However, some calling subscribers complain that they can hear noises when they dial an intra-office called
party.
Fault Analysis and
Location
1. Analyze the fault phenomena, and find that noises basically
result from inter-office fault, which probably lies in the trunk
circuit to an office.
2. Check the relation schema of traffic flow and the network topology structure diagram of local office. The incoming and outgoing calls of local office are mainly forwarded by two T-offices.
3. Perform trunk dial-up test to reproduce the fault. Find that the
noise always appears irregularly on one office of a T-office.
4. Check the transmission-circuit type between the MGW and the
T-office, and find that it adopts SDH transmission mode. Check
the alarms related to SDH on the OMM system, and find that a
“Trunk receiving-end alarms” alarm exists on the trunk circuit
to this office. It indicates that obvious error code exists on this
transmission, which probably causes the noise.
5. Contact the service personnel of transmission system for cooperation. Eliminate the fault together with the method of
loop-back segment by segment, and finally locate the fault
point.
Fault Handling
When the transmission service personnel handle the fault, the
alarm in the fault management system disappears. Perform the
dial-up test with the designated mobile phone, the noise disappears.
Summary
�
The noise fault occurs frequently in routine maintenance. To
eliminate it, first determine the noise location according to its
phenomena. It has following common features.
�
�
�
�
If noise always appear in some cells or location areas belonging to local office, its location is related to BSC/RNC.
Primarily check the trunk circuits between local office and
BSC/RNC, and radio side. Contact the service personnel at
the radio side to locate the fault together.
If noise occurs on the inter-office circuit, and intra-office
calls have no noises, the noise location is related to adjacent office. Check outgoing trunk circuits of local office.
Perform dial-up tests on all the trunk circuits, and trace the
inter-office signaling to find the board or transmission system existing fault.
If noise appears irregularly and randomly both inside MGW
office and between offices, check whether it is located in
the local office, for example, in TSNB, TFI, UIM, and SMP
boards, and data configuration of MSCS and MGW.
If the transmission system is faulty, contact its service personnel immediately. Cooperate to find the fault point with the
loop-back method segment by segment to provide necessary
information and help for eliminating the fault quickly.
Confidential and Proprietary Information of ZTE CORPORATION
97
ZXWN MGW Troubleshooting
This page is intentionally blank.
98
Confidential and Proprietary Information of ZTE CORPORATION
Figure
Figure 1 Troubleshooting Flow .............................................. 3
Figure 2 Handling The Fault Occurring During Board
Configuration ....................................................11
Figure 3 Handling Common Faults of Boards..........................13
Figure 4 Troubleshooting Flow of UIM Fault ...........................15
Figure 5 Troubleshooting Flow of OMP Fault...........................18
Figure 6 Handling the SIPI Board Fault .................................20
Figure 7 Troubleshooting Flow of SPB Board ..........................21
Figure 8 Troubleshooting Flow of the CLKG Board...................24
Figure 9 Handling the IPI Board Fault ...................................25
Figure 10 Handling the DTB/DTEC Board Fault .......................26
Figure 11 Handling the APBE Board Fault ..............................27
Figure 12 Handling the MRB Board Fault ...............................28
Figure 13 Handling VTCD Board Fault ...................................29
Figure 14 Handling the Clock Abnormality .............................34
Figure 15 Troubleshooting Flow of Clock Locking Failure ..........36
Figure 16 Example for Clock Self-Loop..................................39
Figure 17 Mc Interface Protocol Stack...................................47
Figure 18 Networking Mode & Interface Protocol Stack
Structure..........................................................51
Figure 19 Networking and Protocol Architecture (Built-In SG
Supported) .......................................................53
Figure 20 A-Interface Protocol Stack Structure ......................54
Figure 21 MGW Built-In Networking Mode and Its Protocol
Structure..........................................................55
Figure 22 Boards Related to Narrow-Band No.7 Signaling
Protocol............................................................55
Figure 23 Handling the Abrupt Abnormality of the OMM
system.............................................................60
Figure 24 Handling Virus/Security Events..............................62
Figure 25 Setting CORBA FTP ..............................................66
Figure 26 Interconnection Between Media Plane and Bearer
Network ...........................................................74
Figure 27 Interconnection Between Soft-Switch and CE ..........75
Confidential and Proprietary Information of ZTE CORPORATION
99
ZXWN MGW Troubleshooting
Figure 28 Intercepting Calls Section by Section......................80
Figure 29 Electrical Echo.....................................................83
Figure 30 Working Principles of Echo Canceller ......................84
Figure 31 Incoming/Outing EC.............................................84
Figure 32 Enable Flag.........................................................86
Figure 33 ISUP SPARE ........................................................86
Figure 34 Networking Diagram ............................................93
Figure 35 Call Quality Test Flow ...........................................96
100
Confidential and Proprietary Information of ZTE CORPORATION
Table
Table 1 UIM Types .............................................................14
Table 2 Indicators on UIM ...................................................16
Table 3 Impedance DIP Switches of E1 on the SPB Board ........37
Table 4 Handling Method of Inconsistent Locking Status of
Active/Standby CLKG Boards...............................40
Table 5 Handling Method of Inconsistent Clock Reference
Status of Active/Standby CLKG Boards .................41
Table 6 Handling Method of Output Clock Loss .......................43
Table 7 Handling Method of Slip Code ...................................44
Table 8 Parameters in the ADD UNIT Command .....................87
Table 9 Parameters in the SET ECRSC Command....................88
Confidential and Proprietary Information of ZTE CORPORATION
101
ZXWN MGW Troubleshooting
This page is intentionally blank.
102
Confidential and Proprietary Information of ZTE CORPORATION
Index
A
L
Active status..................... 30
Adjacent office .................. 48
Alarm analysis ....................5
Alarm level .........................5
Alarm query........................4
Link .................. 5, 7, 22,
25, 39, 49, 51, 74, 92
Local office ..............5–6,
28, 39, 48, 51, 97
M
B
Backplane ................ 10,
19, 36, 40, 42–43
C
Changeover ...................... 19
Client/server.......................1
Conference call ................. 28
Control plane ......... 20, 50, 77
D
Data configuration ................. 5–6, 32,
48, 51, 57, 63, 65, 74
DIP switch ........................ 26
DIP switches ..................... 22
Man-machine command ..... 59
Mask ............................... 60
Matching
impedance ................ 26, 36
N
Network cable ................... 63
Networking mode ...... 50,
54, 58
No.7 signaling .....................1
O
OMM server ................ 9,
64–66, 68, 70–71
Outgoing route.................. 73
P
F
Failure observation ...... 4,
17, 50
File management............... 65
FTP.................................. 66
H
Handover ................... 77, 90
History alarm .................... 43
History notification ............ 43
performance statistic ......... 71
Performance statistics .......................4, 31, 65
Power on .......................... 75
Power-off ...........................8
Probe............................... 55
R
Registration ...................... 48
S
I
IP address .............9, 48,
60, 63–64, 66, 70–71
J
signaling link .................... 48
Signaling link .............. 7,
42, 44, 51–52, 56
Signaling links................... 32
signaling route .................. 51
Signaling route.............. 7, 53
Jumper ............................ 22
Confidential and Proprietary Information of ZTE CORPORATION
103
ZXWN MGW Troubleshooting
Signaling tracing ......4–5,
7, 17, 48, 50
T
Trunk management............ 55
V
Version management ................... 10, 30, 65
104
Confidential and Proprietary Information of ZTE CORPORATION
