ZXUN CS TROUBLESHOOTING

COURSE OBJECTIVES
• Overview
• Hardware Faults
• Interface Faults
• Service Faults
OVERVIEW
• Basic Requirements for the Maintenance Personnel
– Technical Knowledge
• Get familiar with the communication knowledge, such as the mobile
communication principle, the ATM principle and the soft-switching principle.
• Get familiar with signaling protocols related with the broad-band/narrow-
band No.7 signaling, BICC signaling and H.248 signaling.
• Get familiar with the related international technical regulations.
• Understand billing principles and flows.
• Understand the basic knowledge about the computer networks, including
Ethernet, TCP/IP, Client/Server architecture and Oracle database.
• Get familiar with the product knowledge of the ZXUN MSCS system,
concerning the functional structure, call flow, and service flow.
OVERVIEW
– Networking and Running Environment
• Know the hardware architecture and performance of the ZXUN system very
well.
• Know the inter-module routing and routing between modules and offices in
the ZXUN system very well.
• Know signaling and protocols of the ZXUN system and the networking
equipments very well.
• Get familiar with the network architecture and channel allocation of the
relevant transmission equipment.
OVERVIEW
– Operations
• Master basic computer operations.
• Master daily operations of the ZXUN 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.
• 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.
OVERVIEW
– Instruments and Meters
The maintenance personnel of ZXUN Server should proficiently locate faults by
using various instruments and meters. The common instruments and meters
include multi-meter and the SS7 analyzer.
TROUBLESHOOTING FLOW
OVERVIEW
• Troubleshooting Principles
– Check
– Ask
– Think
– Act
OVERVIEW
• Troubleshooting Methods
– Analyzing Fault Information
– Analyzing Alarm Information
– Indicator Status
– Signaling Tracing
– Log Querying
– Test and Self-Loop
– Unplugging/Plugging
OVERVIEW
– Comparison and Interchange
– Analyzing through Dialing Test
– Configuration Modification
– Performance Statistics
– Configuring Data
– Experience Processing
COURSE OBJECTIVES
• Overview
• Hardware Faults
• Interface Faults
• Service Faults
FAULTS IN BOARD RUNNING PROCESS
• Fault Phenomena
– 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.
FAULTS IN BOARD RUNNING PROCESS
• Fault Causes
– 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.
FAULTS IN BOARD RUNNING PROCESS

• Fault Handling Flow

HARDWARE FAULTS
• Handling Hardware Faults of GPBB0 Board
– Fault Phenomenon
• The GPBB0 board cannot be started. In normal cases, both the OK and
HOST indicators flash at 1 Hz, and the ACT indicator stays on.
• When the active GPBB0 board is abnormal, the network alarm system
displays that the communication with the foreground is abnormal, and the
data could not be sent to the foreground.
• The maintenance tools, such as the statistics alarm, the performance
statistics, the signaling tracing, and the failure observation, could not be
used normally.
HARDWARE FAULTS
– Solution
1. Use a board of the same type to replace the faulty board.
2. Format the hard disk on the new GPBB0 board through a serial port, and
then restart this board.
3. The new GPBB0 board automatically synchronizes with the active GPBB0
board to make the configuration take effect.
4. Transmit all the tables to the new GPBB0 module in the foreground
subsystem, and then restart this module.
HARDWARE FAULTS
• Handling Hardware Faults of the FSWA1 Board
– Fault Phenomenon
• The fault management system reports an alarm that the internal media plane
of several MPBA0 boards and MPBA1 boards in abnormal.
• The fault management system reports an alarm that the OK indicator of the
FSWA1 board gives an alarm.
• The fault management system reports an alarm for loss of 8K clock or other
clock inputs.
• The fault management system reports an alarm for the HW circuit error of
some boards such as the MPBA0 board and the MPBA1 board.
HARDWARE FAULTS
– Solution
1. Change over the active and standby FSWA1 boards on the Local
Maintenance Terminal (LMT). Check whether the fault is eliminated. If the
changeover failed, directly press the EXCH key on the board for a
while to implement hardware
changeover.
2. If the hardware changeover failed, perform the RST operation on the faulty
board on the LMT terminal. Check whether the fault is eliminated.
3. If the fault still remains after restart, insert and extract the faulty board.
Check whether the fault is eliminated.
4. Directly replace the faulty FSWA1 board with the FSWA1 board of the same
type.
HARDWARE FAULTS
• Handling Hardware Faults of the Interface Processing Board Fault
– Fault Phenomenon
• The fault management system reports an alarm that an external port of an
interface processing board is abnormal.
• The OOS indicator of the BSWA0 board is alarming.
HARDWARE FAULTS
– Solution
1. When the fault occurs on an interface processing board, observing the board
indicators is a direct way. Sometimes, it is the only method.
2. Change over the active/standby interface processing boards on the LMT
terminal.Check whether the fault is eliminated. If changeover failed, directly
press the EXCH key on the board for a while to implement hardware
changeover.
3. If the hardware changeover failed, perform the RST operation on the faulty
board on the LMT terminal. Check whether the fault is eliminated.
4. If the fault still remains after restart, insert and extract the faulty board.
Check whether the fault is eliminated.
5. Directly replace the faulty interface processing board with the board of the
same type.
HARDWARE FAULTS
• Handling Hardware Faults of the MPBA0/MPBA1 Board
– Fault Phenomenon
• The fault management system reports an alarm for communication
interruption of the MPBA0/MPBA1 board.
• The fault management system reports an automatic detection alarm for a
DSP being abnormal and an alarm for the HW fault on the MPBA0/MPBA1
board.
• There is noise or no voice in a call session.
• When a subscriber is implementing a call service, the local office cannot
provide system tones or provide wrong tones.
• Implementation of the dialing service is abnormal.
• Three-party call and conference call service cannot be implemented.
HARDWARE FAULTS
– Solution
1. Reset the board where the DSP mentioned in the automatic detection alarm
is located.
2. Perform the dialing test for the specified resources to find the DSP with
abnormal services, and then reset it.
3. Reset the entire board to see whether the fault is eliminated.
4. Directly replace the faulty MPBA0/MPBA1 board with the MPBA0/MPBA1
board of the same type.
COURSE OBJECTIVES
• Overview
• Hardware Faults
• Interface Faults
• Service Faults
COURSE OBJECTIVES
• Overview
• Hardware Faults
• Interface Faults
• Service Faults
INTERFACE FAULTS
• Handling MSCS-RNC Interface Fault
– Fault Phenomenon
• The RNC office direction is unreachable;
• The calls related with the subscribers in the RNC all fail;
• The service of subscriber location updating fails.
INTERFACE FAULTS
– Solution
• Check whether the RNC office direction on the MGW is reachable.
• Check whether the coupling between ZXUN MSC Server and the MGW is
normal.
• Check the AS configuration of SIO location on the MGW and ZXUN MSC
Server.
INTERFACE FAULTS
• Handling MSCS-MGW Interface Fault
– Fault Phenomenon
• All the calls related with the subscribers in local office fail;
• The office direction between the ZXUN MSC Server and the MGW is
disconnected.
• The association is normal, but AS and ASP are abnormal, being non-
activated. There is an MGW registration failure message in the platform
signaling tracing.
• The AS is in normal status, but the gateway fails to register on the MGC.
INTERFACE FAULTS
– Solution
1.Check the physical connection to see whether the connection line change
causes Mc interface abnormality. If GPBB0 is configured with an
active/standby mode, specially check the connection line from GPBB0 to the
switch of the signaling plane.
2.Check the data configuration of the ZXUN MSC Server and the MGW, mainly
including the following data:
– The adjacent office configuration
– IP protocol stack configuration
– SIGTRAN data configuration
INTERFACE FAULTS
3.Check whether the status of SMP module managing association modules,
and SIPI module are normal, whether there is an alarm. If the onsite
conditions permits, restart GPBB0 to see whether the fault can be
eliminated.
4. Activate/deactivate associations through the Dynamic Management tab page
offered on the OMM Main Process client to see whether the fault is
eliminated.
5. If actual and virtual addresses of the opposite end can be successfully
pinged through with the platform tool, but the SCTP connection cannot
be established, possibly broadcast storm occurs on the switch connected
with SIPI modules of MSCS and MGW. It results in the communication
exception of Mc interface. To restore the service as soon as possible,
temporarily connect SIPI modules of MSCS and MGW with crossover cable.
INTERFACE FAULTS
6. Activate/deactivate associations again through the Dynamic Management
tab page offered on the OMM Main Process client to see whether the fault is
eliminated.
7. If the fault still exists, initialize GPBB0, transmit all the tables again, and
finally restart GPBB0.
INTERFACE FAULTS
• Handling MSCS-MSCS Interface Fault
– Fault Phenomenon
• Call connection fails. During the outgoing BICC calls, after an IAM message
is sent, the peer office immediately returns a REL message.
• Outgoing calls fail. The User Equipment (UE) dials the outgoing number and
obtains the correct roaming number, but there is no outgoing BICC
message, and the call is released immediately;
• The BICC signaling bearer is faulty, and the SCTP link message cannot be
successfully traced.
INTERFACE FAULTS
– Solution
1.Check whether the data configuration is correct. Frequent data configuration
errors are as follows:
– Check whether the SIO location AS bearing the BICC service is
configured;
– The CIC configuration ranges of both ends are inconsistent;
– The corresponding CIC is not configured to the correct office direction.
2.Check whether the BICC signaling bearer is normal. When lower-layer
signaling bearer (MTP3/MTP3B/SCTP/M3UA) is faulty, the maintenance
command of the CIC cannot reach the opposite end. Use the dynamic
management tool to check whether the corresponding signaling bearer is
normal.
INTERFACE FAULTS
• Handling MSCS-HLR Interface Fault
– Fault Phenomenon
• The HLR subscriber cannot register after restarting the mobile phone, and
the registered subscriber cannot be called.
• In the signaling tracing, it is found that the VLR sends the authentication
request to the HLR, but cannot receive the response message from the HLR.
The call loss reports that waiting timeout error.
• On the Dynamic Management tab page on the OMM Main Process client,
the office direction from the local office to the HLR is unreachable.
INTERFACE FAULTS
– Solution
1. Check whether the association between MSCS and HLR is normal.
2. Check the SIO-location-AS configuration on HLR and MSCS.
On HLR, the AS service indicator is SCCP user, and the opposite-end office
is MSCS.
On MSCS, the AS service indicator is SCCP user, and the opposite-end
office is HLR.
INTERFACE FAULTS
• Handling MGW-MGW Interface Fault
– 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.
INTERFACE FAULTS
– Solution
1.Check whether the configuration is correct. Common configuration errors
are as follows:
 The encoding and decoding mode is not configured correctly.
 The interface information is not configured correctly.
 The MPBA0 board is not configured correctly.
2. Open Failure Observation to trace the call and find out the fault cause.
COURSE OBJECTIVES
• Overview
• Hardware Faults
• Clock Faults
• Interface Faults
• Service Faults
SERVICE FAULTS
• Handling Location Update Service Fault
– Fault Phenomenon
• The subscriber cannot log in the network after powering on the MS;
• The subscriber cannot log in the network after updating the location;
• The subscriber cannot be found in the R_MS table by using the probe after
the MS is powered on;
• The location update failure causes the call fault.
SERVICE FAULTS
– Solution
• 1. Analyzing the subscriber with fault, confirm whether it is the single
subscriber fault or multi-subscriber fault, and then open the signaling tracing
tool to trace the faulty subscriber.
• 2. For the single subscriber fault, trace the subscriber signaling.
• 3. For the multi-subscriber fault, analyzing the information of faulty
subscribers is needed.
SERVICE FAULTS
• Handling Basic Call Service Fault
– Fault Phenomenon
• After successfully updating the location, the subscriber cannot originate a
call normally.
• After successfully updating the location, the subscriber cannot receive a call
normally.
• The failure observation system reports a great deal of call loss.
SERVICE FAULTS
– Solution
• Open the signaling tracing system, and specify the subscriber signaling to be
traced and then trace the signaling;
• Use the UE with call fault to perform the call service, and analyze the traced
signaling result;
• If no signaling can be successfully traced, check whether the UE is faulty,
and use another UE to make a call attempt.
SERVICE FAULTS
• If the fault is possibly caused by the local office by analyzing the signaling,
open the Failure Observation System to check the failure reason in the
system, and locate the internal fault.
• If it is the interconnection fault, contact the opposite-end office to handle it
corporately.
• If the call failure occurs to many subscribers, timely check whether the links
between the local office and important office directions are normal; check
whether all SMP module in local office are normal.
SERVICE FAULTS
• Handling MGW Service Fault---Case1
– Fault Phenomenon
• The circuit is in abnormal status. And the CIC is not in idle status.
• Query the local end status of the CIC circuit on the MSCS. The status is
“ERRORREQ”, indicating the request message is illegal.
SERVICE FAULTS
– Solution
• Check the office directions and links from the MSC to the MGW, AS, and
ASP. Find that all of them are in normal status.
• Check the “Batch create MSCS tone” ,Check the MGW static data in MSC
Server
• Synchronize the data. Check the status of the CIC circuit, and find that it is in
IDLE status normally
SERVICE FAULTS
• Handling MGW Service Fault---Case2
– Fault Phenomenon
• The calling party complains that there are noises during a call when the local
office subscriber serves as the called party.
• The signaling flow is normal.
SERVICE FAULTS
– Solution
• Perform trunk dial-up test to appear the fault again. The noise always
appears on the office direction irregularly. .
• Check the type of the transmission circuit ,find that it adopts the SDH
transmission. Check the SDH alarm to find that trunk alarm exists on the
trunk circuit of this office direction, indicating there is apparent bit error on
this transmission, which probably causes the noise
• Contact the maintenance personnel of the transmission system to eliminate
the fault with the method of loop-back link by link, and finally locate the fault
point.
SERVICE FAULTS
– Summary
• If noises appear in certain cells or location areas ,the location point of the
noise is related to the BSC/RNC.
• If noises occur on the inter-office, Check the outgoing trunk circuit. Perform
the dial-up test on all of the trunk circuits to find the board or transmission
system existing fault.
• If the noise appears irregularly and randomly both inside the MGW office and
between offices, check whether the fault is located in local office, for
example, in the TSWA0, FSWA0 and GPBB0 boards, and data configuration
of MSCS and MGW.
Thank You