SJ-20121227135800-008-ZXUR 9000 GSM (V6.50.102) Emergency Maintenance

ZXUR 9000 GSM
Base Station Controller

Emergency Maintenance
Version: V6.50.102
ZTE CORPORATION
No. 55, Hi-tech Road South, ShenZhen, P.R.China
Postcode: 518057
Tel: +86-755-26771900
Fax: +86-755-26770801
URL: http://ensupport.zte.com.cn
E-mail: support@zte.com.cn
LEGAL INFORMATION
Copyright © 2013 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
Revision No. Revision Date Revision Reason
R1.0 2013-01-30 First Edition
Serial Number: SJ-20121227135800-008
Publishing Date: 2013-01-30(R1.0)
SJ-20121227135800-008|2013-01-30(R1.0) ZTE Proprietary and Confidential

Content
About This Manual ......................................................................................... I
Chapter 1 Emergency Maintenance Overview......................................... 1-1
1.1 Emergency Maintenance Purpose ....................................................................... 1-1
1.2 Emergency Maintenance Scope ......................................................................... 1-1
1.3 Basic Principles for Emergency Maintenance ....................................................... 1-3
1.4 Emergency Maintenance Precautions ................................................................. 1-4
1.5 Emergency Maintenance Preparations ................................................................ 1-4
1.5.1 Daily Preparation of Emergency Maintenance ............................................ 1-4
1.5.2 Holiday Preparation of Emergency Maintenance ........................................ 1-5
1.6 Contact Information of Technical Support from ZTE .............................................. 1-6
Chapter 2 Emergency Maintenance Flow................................................. 2-1

2.1 Service Check.................................................................................................... 2-2
2.2 Fault Records .................................................................................................... 2-3
2.3 Initial Location and Analysis of Fault Causes........................................................ 2-4
2.4 Emergency Aid................................................................................................... 2-4
2.5 Service Recovery ............................................................................................... 2-5
2.6 Service Observation ........................................................................................... 2-5
2.7 Information Records ........................................................................................... 2-5
Chapter 3 Emergency Fault Handling....................................................... 3-1

3.1 Handling Flow .................................................................................................... 3-1
3.2 Analysis of BSC Service Fault Coverage ............................................................. 3-1
3.3 Power Supply Check .......................................................................................... 3-2
3.3.1 Check of the Power Supply System in the Equipment Room ....................... 3-3
3.3.2 Check of Power Supply on the Rack ......................................................... 3-4
3.3.3 Check of the Power Supply on a Shelf ...................................................... 3-4
3.3.4 Check of Powering-On.............................................................................. 3-5
3.4 Handling of Board Faults .................................................................................... 3-5
3.5 Operation Status Check of the System Clock ....................................................... 3-6
3.6 Handling of Transmission Failure......................................................................... 3-6
3.6.1 Principles for Handling Transmission Alarms .............................................. 3-7
3.6.2 Methods for Handling Transmission Alarms................................................ 3-8
3.6.3 Causes for Transmission Alarms ............................................................... 3-8
3.6.4 CSTM-1 Interconnection Fault................................................................... 3-9

3.6.5 E1 Array Mode Fault................................................................................3-11
3.7 Emergency Handling of BSC Service Abnormality and Interruption .......................3-11
3.7.1 Handling A Interface Faults ......................................................................3-11
3.7.2 Call Failures Handling............................................................................. 3-12
3.7.3 Handling of Unilateral or Voiceless Conversation Faults............................ 3-12
3.7.4 Handling of Webpage Access Failures..................................................... 3-13
3.8 Handling of BTS Service and Interruption........................................................... 3-14
3.8.1 Large-Scale Cell Outages Handling ........................................................ 3-14
3.8.2 Handling of Cell Abnormal Interruption..................................................... 3-14
3.8.3 Handling of Service Interruption Caused by Data Modification Error........... 3-15
3.9 Description on Board Resetting and Changeover ............................................... 3-15
3.9.1 Influence of Resetting and Changeover ................................................... 3-16
3.9.2 Changeover Modes ................................................................................ 3-16
3.10 Link/Cell Fault Confirmation Methods............................................................... 3-17
3.10.1 Check of Cell MTP3 Link ...................................................................... 3-17
3.10.2 Check of Cell Normality ........................................................................ 3-17
3.11 Overview of Data Backup and Recovery .......................................................... 3-17
3.12 Description on Board Panel Indicator ............................................................... 3-18
3.12.1 Types of Board Panel Indicators ............................................................ 3-18
3.12.2 Description on Board Panel indicator Status........................................... 3-18
3.12.3 Description on Common Indicators ........................................................ 3-19
Chapter 4 Fault Feedback Description ..................................................... 4-1

4.1 Fault Feedback Information................................................................................. 4-1
4.2 Data Recorded for Feedback ............................................................................. 4-2
4.3 Methods for Obtaining System Records ............................................................... 4-4
4.3.1 Obtaining Equipment Printing Files............................................................ 4-4
4.3.2 Obtaining ZDB Files ................................................................................. 4-5
4.3.3 Obtaining Data Backup ZIP Files of OMM .................................................. 4-6
4.3.4 Obtaining Software Settings...................................................................... 4-7
4.3.5 Obtaining Alarm Files ............................................................................... 4-7
4.3.6 Obtaining Notification Files ....................................................................... 4-7
4.3.7 Obtaining Performance Data one Hour Before and After Fault..................... 4-8
4.3.8 Obtaining Traced Signalling at Interface A.................................................. 4-8
4.3.9 Querying Dynamic Data at Interface A ....................................................... 4-8
4.3.10 Obtaining Traced Signalling at Interface Abis ........................................... 4-9
4.3.11 Querying dynamic data at Base Station.................................................... 4-9
4.3.12 Tracing PS Service Signalling ............................................................... 4-10
II

4.3.13 Querying the Status of BVC and NSVC.................................................. 4-10
4.3.14 Obtaining Operation Logs of OMM Server.............................................. 4-10
4.3.15 Checking Overstocked Data.................................................................. 4-10
4.3.16 Querying Disk Space .............................................................................4-11
4.3.17 Obtaining NM Printing Files....................................................................4-11
4.3.18 Obtaining Configuration Files at NM ...................................................... 4-12
4.3.19 Obtaining Operation Logs at the Client................................................... 4-12
4.3.20 Checking System Time Zone................................................................. 4-12
4.3.21 Checking NM Version ........................................................................... 4-13
Appendix A Maintenance Record Table .................................................. A-1

A.1 Fault Record Table............................................................................................. A-1
A.2 Troubleshooting Record Table ............................................................................ A-2
A.3 Equipment Emergency Maintenance Notice......................................................... A-2
Tables .............................................................................................................. I
Figures........................................................................................................... III
Glossary .........................................................................................................V
III

IV

About This Manual
Purpose
This manual describes how to perform emergency maintenance on ZXUR 9000 GSM base
station controller and take corresponding records.
Intended Audience
l System engineers
l Maintenance engineers
What is in This Manual

This manual contains the following chapters:
Chapter Summary
1, Overview Describes applicable scope, guideline, and preparations of

emergency maintenance.
2, Emergency Maintenance Describes the emergency maintenance flow.

Flow
3, Emergency Faults Describes how to handle emergency faults.

Handling
4, Fault Feedback Describes how to send fault feedbacks and obtain system logs of
Information emergency maintenance.
Appendix A, Emergency Describes the emergency maintenance table.

Maintenance Table
Related Documentation
The following documentation is related to this manual:
l ZXUR 9000 GSM Base Station Controller Hardware Description
l ZXUR 9000 GSM Base Station Controller Status Management Operation Guide
l ZXUR 9000 GSM Base Station Controller Calling Tracing Operation Guide
l ZXUR 9000 GSM Base Station Controller Software Version Management Operation
Guide
l NetNumen U31 R18 Unified Element Management System Fault Management
Operation Guide
l NetNumen U31 R18 Unified Element Management System Performance
Management Operation Guide
l NetNumen U31 R18 Unified Element Management System Security Management
Operation Guide

Conventions
This manual uses the following typographical conventions:
Typeface Meaning
Note: provides additional information about a certain topic.
II

Chapter 1
Overview
Table of Contents
Emergency Maintenance Purpose..............................................................................1-1
Emergency Maintenance Scope ................................................................................1-1
Basic Principles for Emergency Maintenance .............................................................1-3
Emergency Maintenance Precautions .......................................................................1-4
Emergency Maintenance Preparations .......................................................................1-4
Contact Information of Technical Support from ZTE....................................................1-6
1.1 Emergency Maintenance Purpose

Emergency maintenance is to take emergent measures to remove faults occurred to the
system or the equipment, to restore the system or the equipment , and to eliminate or
reduce losses.
In addition, it is to analyze and locate the fault, find the fault cause, and remove the fault
in accordance with the prompt message, signalling trace (that is calling trace), and error
logs when critical faults occur to some parts and functions of the system during the system
operation.
1.2 Emergency Maintenance Scope

During the system operation, users can determine whether to start the emergency
maintenance through reading user complaints, viewing alarm reports, and analyzing
performance reports.
1. User complaints
Table 1-1 shows user complaints about emergency maintenance.
Table 1-1 User Complaints
Complaint Content Description
l Lots of speech users cannot access;

l Lots of MSs cannot be acted as After receiving user complaints, users should
called/caller; further check the alarm information and KPI
l Lots of users cannot use packet data ser- measurement result, to determine whether
vices. emergent fault occurs.
1-1

ZXUR 9000 GSM Emergency Maintenance
2. Alarm reports
Table 1-2 shows the alarm report that shall be viewed on emergency maintenance.
Table 1-2 Alarm Report on Emergency Maintenance
Alarm Type Alarm Description
Alarms on standby boards, such as OMP and

CMP.
Active board alarm in active/standby mode
Board alarm Board alarm in non-active/standby mode
Abnormal access clock
Phase-locked loop out of lock
Clock alarms Level 1 alarm on lost clock reference source
Alarm on unreachable MTP3 office
Alarms related with interface A SCCP subsystem unavailable
NSVC failure alarm
SGSN is blocked
Alarms related with interface Gb NSE block alarm
MSC overload
Congestion at signalling point
Alarms on traffic control Too high CPU load
Loss of trunk frame
Loss of trunk signal
SDH/SONET: loss of signal
PPP Link Broken
Rack Abis control link broken
Broken Association
Relevant transmission alarms Association Channel Broken
3. Performance Reports
Normally, KPI index is not a direct condition to start emergency maintenance.Table

1-3 shows the important KPI index that shall be viewed and analyzed on emergency
maintenance.
1-2

Chapter 1 Emergency Maintenance Overview
Table 1-3 KPI Index
Index Type Index Name
SDCCH congestion rate
TCH congestion rate
TCH traffic
Congestion TCH availability
TCH assignment success rate
Channel occupation Call success rate
Handover Handover success rate
Call drop TCH call drop rate
l When KPI is changed exceptionally, users should confirm whether the emergency
maintenance, together with user complaint, test, and alarm analysis, should be
started.
l When the emergency maintenance process is started under critical alarm and
user complaints, KPI index should be used as a subsidiary analysis tool and
troubleshooting method.
1.3 Basic Principles for Emergency Maintenance

The following are the basic principles for ZXUR 9000 GSM emergency maintenance:
l Before the emergency maintenance, locate the fault and perform troubleshooting from
interior to exterior, or from entire to local.
l During daily maintenance, in accordance with the emergency maintenance data of
ZXUR 9000 GSM and related equipment, along with historical fault analysis and
experience, make handling schemes for emergency faults, and periodically organize
relevant managers and maintenance personnel for training and demonstration.
l Relevant maintenance personnel should learn more about the system in daily
maintenance, especially to be familiar with common exceptional information about
NM alarm, and indicator statuses on the BSC panel, to master common tools about
data backup/restoration.
l When emergency fault occurs to the system or equipment, the maintenance personnel
should keep calm, and then check BSC hardware and transmission to determine
whether the fault is caused by BSC. If yes, perform troubleshooting in accordance
with the emergency scheme or relevant process in this manual.
l Before, in the process of, or after emergency maintenance, maintenance personnel
should collect the alarm information about the fault, and send the troubleshooting
report, equipment alarm file, and log file to ZTE for analysis and locating and providing
better after-sale services.
l On-site critical faults should be removed as soon as possible. In addition, fault location
and analysis tools (such as the NM alarm and signalling trace) should be enabled to
1-3

reserve related information for fault location and analysis before such operations are
performed as the switchover, resetting, and restarting.
1.4 Emergency Maintenance Precautions

The following precautions should be taken during the emergency maintenance:
l Some restoration operations (for example, board reset) may greatly affect the system
operation, so these operations should be performed by or under the operators with
enough maintenance experience, to locate faults quickly.
l If the faults greatly affect the network operation, maintenance personnel should con-
tact ZTE Customer Support Center or local ZTE office at the earliest possible time for
technical support, no matter whether they can determine to remove faults.
1.5 Emergency Maintenance Preparations

1.5.1 Daily Preparation of Emergency Maintenance
Daily preparation of emergency maintenance contains:
l Data backup and system inspection
l Remote maintenance station establishment
l Preparation of important spare parts
1.5.1.1 Data Backup and System Inspection

Data backup during daily maintenance assists in the detection of critical faults and potential
risks, and the restoration of configuration data when a fault occurs to the system.
Data Backup
Maintenance personnel should back up daily data.
Configuration data can be manually or automatically backed up.
l Automatic Backup
By default, the system automatically performs backup for OMM configuration data
every day.
Path to save configuration data: OMM server \home\zte\mo_data\backup\mo_output.
l Manual Backup
1. Open the Configuration Management tab, and select Configuration
Management > Data Backup.
2. Select an NE, configure the save path and backup NE, and click OK.
3. On the Data Backup Result tab, click Close.
Configuration data backup is performed successfully.
1-4

Chapter 1 Emergency Maintenance Overview
Path to save configuration data: OMM server

\home\zte\mo_data\backup\mo_output.
System Inspection
System inspection contains:
If major alarm exists while checking historical alarms (within 1 week) and current alarms,
handle it immediately. If the alarm persists, contact local ZTE office or customer service
center.
1.5.1.2 Remote Maintenance Station Establishment

To quickly locate and remove the faults under the support of ZTE technicians, PCAny
Where or VPN remote access should be always kept proper on different sites. Users can
contact local ZTE office while commissioning remote access.
1.5.1.3 Preparation of Important Spare Parts

Users should prepare for sufficient spare parts for important boards on BSC, such as UMP,
USP, EGBS, EGFS, and ETCB.
1.5.2 Holiday Preparation of Emergency Maintenance

Preparation in holiday mainly aims at large traffic, not just the specific holiday period.
1.5.2.1 Load Monitoring

Load monitor includes the following items:
1. CPU load on the BSC at busy time each day in holiday. CMP load at BSC should not
exceed 70%.
2. CPU load on each board throughout the monitoring period. The referential threshold
is 70%.
3. Try best to reduce the operation of signaling trace during large traffic, to reduce the
influence on MP load.
4. During large traffic, stop or close probe software, to reduce CPU load.
5. The load value of No.7 signaling link at interface A on the BSC should be lower than
0.4. Otherwise, add more No.7 signaling links.
6. The load value of service timeslot at interface A on the BSC should be lower than 0.6
Erlang. Otherwise, add more circuits at interface A.
7. It is recommended to monitor the load at the CN side. If the load at the CN side is
improper, inform the maintenance personnel as soon as possible.
1.5.2.2 Load Reduction Measures

Users can use the following measures to reduce load.
l Check whether FUC flow control at the BSC side is enabled.
1-5

l Check whether the SIM card for mobile phones on site are classified according to
specified requirements. If it is classified, check whether the flow control at the BSC
side is enabled.
l For individual base station with large traffic, it is recommended to enable handover for
preprocessing.
l Pause or delete unnecessary observation tasks.
l Pause or delete unnecessary measurement tasks.
l Get the No.7 signaling link at interface A and the working load at service timeslot. The
one near or over the upper limit should be expanded timely.
l Get the working load about SCTP coupling at interface A. The one near or over the
upper limit should be expanded timely.
l Temporarily modify two or more pagings as one paging mode for CN.
1.6 Contact Information of Technical Support from ZTE

Contact information of technical support from ZTE is as follows:
1. Telephone at global ZTE customer service center
l Fixed phone: 8008301118
l Mobile phone: 4008301118.
2. Local ZTE office
1-6

Chapter 2
Flow
Emergency maintenance falls into the following steps and activities:
1. Check services.
2. Record faults, and produce a Fault Record Table.
3. Locate initially and analyze fault causes.
4. Ask for emergency aid, make records and release Equipment Emergency Maint
enance Notice.
5. Restore services.
6. Observe services.
7. Record information, and fill in Troubleshooting Record Table.
Figure 2-1 illustrates the emergency maintenance flow.
2-1

Figure 2-1 Emergency Maintenance Flow
Table of Contents
Service Check ............................................................................................................2-2
Fault Records.............................................................................................................2-3
Initial Location and Analysis of Fault Causes..............................................................2-4
Emergency Aid...........................................................................................................2-4
Service Recovery .......................................................................................................2-5
Service Observation ...................................................................................................2-5
Information Records ...................................................................................................2-5
2.1 Service Check

When emergency fault occurs, follow the following steps to check services:
1. Check the power supply of cabinet immediately. If large-scale power supply occurs,
soon notify the maintenance personnel to perform restoration, switch off the power
2-2

Chapter 2 Emergency Maintenance Flow
supply of all cabinets in sequence, and switch on again until the power supply is stable
and reliable. For the power-on/power-off methods of ZXUR 9000 GSM, refer to the
Power Supply Check section in this manual.
2. If the external power supply is improper, observe the call in each office direction at the
performance statistics station in accordance with user complaints, to decide whether
the fault occurs to the global office or individual office. If it occurs to the individual
office, contact relevant technician of this office to check interface status, link status,
locate and confirm the fault. Otherwise, check the peer office. If the fault occurs to the
local office, proceed to the next step.
3. Check whether the indicator status on each panel is proper, and check whether the
physical connection and links of other NEs are proper.
4. If no obvious fault occurs to hardware, check the software and data. Check whether
there are alarms on board and link failure in accordance with the alarm information at
the NM client end. Otherwise, check whether the status of each radio resource cell is
proper, and check whether the physical connection and links between the local NE and
other NE are proper. Restore data if the system failure is due to improper modification
and deletion of data through recalling and checking the operation log.
5. Immediately notify the maintenance personnel on other related NEs to perform
troubleshooting together, or perform troubleshooting in accordance with the
emergency maintenance manual on other related NE equipment.
Note:
After a fault occurs, users should timely locate the fault, and decide whether the fault occurs
to the local office or other office, to handle the fault timely and rapidly.
2.2 Fault Records

When starting the emergency scheme, before or in the process of troubleshooting in
accordance with this manual, users should record such information as the operation
version and faults, especially the information after performing the operations described in
the 2.1 Service Check section, in the Fault Record Table (see Appendix A.1).
Back up the OMC configuration data.
Note:
Fault records assist in handling emergency faults, analyzing and summarizing subsequent
problems, so users should take an exhaustive fault record.
2-3

2.3 Initial Location and Analysis of Fault Causes

Obtain relevant data about alarm, performance, and printing, and analyze obvious
phenomenon about network fault. Observe the information of equipment operation, and
board indicator status. Check the fault caused by the ZXUR 9000 GSM equipment or
other reasons, and determine its involved scope.
If the fault is located as being caused by the ZXUR 9000 GSM equipment, analyze on-site
alarms, performance, signalling, and printing logs, locate the fault point, and perform
troubleshooting.
Locate and analyze the fault based on the following three aspects:
1. Service faults
l Register the user number after receiving users’ complaints about service faults,
analyze and find out the CN, BSC, or BTS where the complaint user is located, to
locate and determine fault-related equipment.
l If the location of the user can be determined at the BSC side, search for help at
the CN side.
2. Locate faults by analyzing KPI index
l Query relevant indices in KPI to determine the affected base station scope about
the fault.
l Determine whether it is a global fault based on the faulty base station.
l Determine whether it is associated with the module and specific board based on
the faulty base station.
3. Test arrangement.
If possible, arrange test at specific area, to provide more accurate information on
emergency maintenance.
2.4 Emergency Aid

Emergency aid is applicable to a critical system fault, or services that are not restored
after starting the emergency recovery scheme or performing troubleshooting guided in this
manual.
ZTE CORPORATION provides the following emergency aid:
l Service hotline (7 x 24 hours)
Hotline of ZTE’s customer service center: 800-830-1118
International hotline: +86–755–26771900
Service fax: (0755)26770801
International service fax: +86–755–26770801
l Remote technical support
According to the information provided at the service hotline, ZTE technical support
experts solve common problems on the phone by remotely logging in to the
problematic site, and provide on-site technical support for complex problems.
2-4

Chapter 2 Emergency Maintenance Flow
l On-site technical support

Upon arriving at the site, the maintenance experts from ZTE take emergency
maintenance measures to recover the communication as soon as possible.
2.5 Service Recovery

If fault causes cannot be located quickly after following the troubleshooting methods
provided in this manual and asking for emergency aid, try to recover services by switching,
resetting, and replacing boards.
Caution!
Board switchover, reset, and replacement greatly influences system operation, so users
should properly perform these operations.
Make records of the current state before any board handover and physical location change.
Make records of each step and symptom occurring in the service recovery on the site.
2.6 Service Observation

After the service recovery, make a further check to see whether the system has already
recovered , to avoid any other problems.
In addition, arrange attendants in the service peak period, to monitor the network operation
and solve the problem in time (if any problem occurs).
2.7 Information Records

Collecting fault information is important for asking for technical support, analyzing and
locating the fault cause, and preventing such faults from occurrence.
Collecting fault information not only provides precious maintenance experience for
operators, but also provides good reference for manufactures to improve the equipment.
The information to collect includes the following:
1. Brief notice
The operator makes the brief notice, including the fault occurrence time, fault
properties, fault symptom, and detailed fault handling steps. If the fault is not
removed, provide the detailed handling steps for subsequent troubleshooting.
2. System debugging information

Copy all logs on the NM server and save to a new folder path.
Save the log files on the UMP board of BSC through the file manager.
2-5

3. Alarm information
Collect the history alarms from thirty minutes before to thirty minutes after the fault.
Maintenance personnel can query and save on the alarm browsing window.
4. Command log information
Collect the command log information about ZXUR 9000 GSM from thirty minutes
before to thirty minutes after the fault, to facilitate maintenance personnel to query
the operation logs, safety logs, and system logs in the log management subsystem
of the NM.
5. Signalling trace information
Collect the signalling trace information aboutZXUR 9000 GSM from thirty minutes
before to thirty minutes after the fault, to facilitate maintenance personnel to obtain
the signalling trace information through signalling trace tools.
For operation details, refer to the section Description on Fault Feedback in this manual.
2-6

Chapter 3
Emergency Fault Handling
Table of Contents
Handling Flow ............................................................................................................3-1
Analysis of BSC Service Fault Coverage ....................................................................3-1
Power Supply Check ..................................................................................................3-2
Handling of Board Faults ............................................................................................3-5
Operation Status Check of the System Clock .............................................................3-6
Handling of Transmission Failure ...............................................................................3-6
Emergency Handling of BSC Service Abnormality and Interruption ..........................3-11
Handling of BTS Service and Interruption .................................................................3-14
Description on Board Resetting and Changeover .....................................................3-15
Link/Cell Fault Confirmation Methods .......................................................................3-17
Overview of Data Backup and Recovery ..................................................................3-17
Description on Board Panel Indicator........................................................................3-18
3.1 Handling Flow

The following describes procedures to check ZXUR 9000 GSM emergency faults.
1. Analyze BSC Fault Coverage.

2. Check the power supply.
3. Handle the user service interruption caused by BSC board fault.
4. Check the system clock working status.
5. Handle the user service interruption caused by abnormal transmission.
6. Handle the user service interruption caused by abnormal radio cell.
7. Handle the user service interruption caused by the wrong modification of ZXUR 9000
GSM radio configuration data.
8. If the problem persists, ask for emergency aid.
3.2 Analysis of BSC Service Fault Coverage

How to analyze the BSC service fault coverage is described in Table 3-1.
Table 3-1 BSC Service Fault Coverage Analysis
Fault Coverage Possible Causes Recommended Solutions
All CS and PS services in the Power failure Check the power supply.
whole network are blocked. CN-side failure Check the CN side.
3-1

Fault Coverage Possible Causes Recommended Solutions
All CS services in the whole

CN-side failure Check the CN side.
network are blocked.
All PS services in the whole

CN-side failure Check the CN side.
network are blocked.
Check the board and replace it

A/Gb interface board fault
if necessary.
All CS and PS services in a
Incorrect configurations
single BSC are blocked. Modify office direction
corresponding to the office
configurations.
at the CN side.

All CS services in a single BSC A interface board fault
if necessary.
are blocked.
No.7 link fault Check No.7 link configurations.

All PS services in a single BSC Gb interface board fault
if necessary.
are blocked.
No.7 link fault Check No.7 link configurations.
Check the Abis link status, and

All services of a BTS are The corresponding link fault
analyze the symptoms.
blocked.
BTS fault Check the BTS fault.
Cell configuration error Check cell configurations.

All services of a cell are blocked.
Manual blocking Unblock the cell.
3.3 Power Supply Check

Description
The system power failure may result from the power supply fault in the equipment room.
When power failure occurs suddenly, determine the fault source first.
Check the power supply in the following sequence::

1. Check whether the power supply in the equipment room is normal.
2. Check whether the power supply of all racks is normal.
3. Check whether the power supply of all shelves is normal.
4. Power on the equipment again.
5. Validate the service.
Figure 3-1 illustrates the handling process for system power failure.
3-2

Chapter 3 Emergency Fault Handling
Figure 3-1 Handling Process During System Power Failure
3.3.1 Check of the Power Supply System in the Equipment Room

To remove the power failure caused by the power supply fault in the equipment room, the
maintenance personnel should follow the following steps and power on the system again.
1. Before the power supply in the equipment room recovers, to avoid failure,switch off all
the power-supply switches on the cabinet power-distribution subrack connected to the
external power supply system, and toggle the double-circuit feeding switch to off.
2. Check the power-supply system in the equipment room immediately.
3-3

Tip:
After the power supply in the equipment room recovers, you should power on the system
again. The power-on order is as the following:
1. Power on the power distribution subrack. Check whether the power supply voltage is
within the proper range: -57 V to -40 V. V。
2. Power on the dual-circuit on the racks. Check whether the power supply voltage is
within the proper range: -57 V to -40 V. V ～ -40 V。
3. Recover the power supply of the network cabinet and server cabinet. Start the NM
server, charging dual-machine server, and disk machine.
3.3.2 Check of Power Supply on the Rack

Check whether the power supply on the rack is proper.
l If the RUN/ALM indicator on the power distribution subrack panel of the rack is ON
(green) and flashes at 1 Hz, the power supply of the rack is properl. That is, the inlet
cable is proper and the internal circuit of the power distribution subrack is proper.
l If the RUN/ALM indicator on the power distribution subrack panel of the rack is always
off, the power supply of the cabinet is improper. That is, the two-path inlet power
supply of the power distribution subrack is under voltage. Check whether the cable
connecting the power distribution cabinet with the rack is loose or broken. If so,
replace the cable in time.
Recover the power supply on the rack
Check whether the dual-path power supply voltage of the power distribution subrack is
within the proper range (-40 V to -57 V). If so, set the power switch to the ON position to
resume the rack power supply.
3.3.3 Check of the Power Supply on a Shelf

Check whether the power supply on the shelf is proper.
1. If all indicators on the shelf are OFF, the power supply on the shelf is improper.
2. If the switch on the shelf of the power distribution subrack is off, the power supply on
the shelf is improper.
Recover the power supply on the shelf

Check whether the dual-path power supply voltage of the power distribution subrack is
within the proper range. If so, set the power switch on each shelf corresponding to the
power distribution subrack to the ON position to resume the shelf power supply.
3-4

3.3.4 Check of Powering-On

The procedure for powering on the system again and the precautions are described as
follows:
Power on ZXUR 9000 GSM rack, shelf, and board.
Power-on order: Power on the main control shelf, and then other shelves. Power on and
start ZXUR 9000 GSM. Observe the indicator status on the board to check whether the
system startup is proper (no alarm and the indicator flashes properly). After making sure
OMM is started properly, check the following items:
l Check whether there is communication fault through the fault management. For
example, if the communication between modules is proper, remove the fault.
l Check and remove the signalling link fault in the office direction through the fault man-
agement.
l Perform the basic service test. Make sure that the service is recovered through the
signalling trace and failure observation.
3.4 Handling of Board Faults

This section describes several types of boards which greatly influence the normal running
of services. These boards are to facilitate rapid location and troubleshooting of faults.
l Interface board: EDTT, ESDTT, ESDTG, EDTI, ESDTI, and EGPB, which mainly
provide the access of IP, CSTM-1, and E1/T1 of the A, Gb, and Abis interfaces.
l Switching board: EGBS and EGFS, which provide the inter-board service interchange
platform.
l System control board: UMP, which performs the operation and maintenance on NE,
processes the global office procedures, and achieves control related to the operation
and maintenance of the system.
l Processing unit: USP and ETCB, which process the protocol of the control plane and
user plane.
Generally, the alarm generated at the NM client and the flashing status of ZXUR 9000
GSM rack board can help to locate the faulty board and its causes.
1. Log in to the NM client, and click View > Alarm Management to check whether there
is any board alarm and the type of the alarm board.
2. Observe the status of the indicators on the board.
The following is the examples for the status of common indicators. For details, refer to
Description on Board Panel Indicator.
l If the board runs properly, the Host indicator is green and flashes at 1 Hz, and the OK
indicator is green and flashes at 1 Hz.
l If the active/standby indicator (ACT) is solid ON, it indicates the board is the active
board. If the indicator is solid OFF, it indicates the board is the standby board. When
fault occurs during the changeover of the active/standby board, the fault can be
located through observing the active/standby indicator status.
3-5

Proposals for handling such fault:

1. The alarm management information generally indicates the alarm causes and
recommended operations to eliminate this alarm. Perform related operations
according to such information.
2. Wait for the board to recover to its normal status, and observe whether the user service
restores to normal.
If indicators flash abnormally for long during the board running and the NM alarm persists,
try the following operations:
1. Reserve the alarm information.
2. Reset the alarm board or replace the board.
Note:
Resetting BSC boards may bring a great impact on services. Such as, if you reset CMP,
user services on this board will be interrupted. The transmission allocated on the interface
board of BSC will be interrupted if you reset it. Therefore, please proceed with caution.
3.5 Operation Status Check of the System Clock

The clock system fault may result in the global service interruption. Check the clock system
with the following methods:
1. Check whether the external connection of the EGFS board is proper.
2. Check whether the system clock of EFGS is proper and whether the NE and NM clock
data are consistent.
3. Perform active/standby changeover on EGFS.
4. Replace the EGFS board.
3.6 Handling of Transmission Failure

Check with the following methods to decide the user service interruption caused by
improper transmission:
1. On the NM client, check the status of the transmission links, such as MTP3 link,
signalling link, and association, to see whether there is any link fault.
2. On the NM client, check whether there is any real-time alarm for the cell transmission
channel, No.7 link, and association. Check whether the alarm exists constantly and
cannot be removed.
3. Check the indicator status on the interface board to see whether the transmission cable
is proper.
Proposals to handle the link resource fault:
3-6

1. Check whether the data to be negotiated by such external NEs as BTS, CN and BSC
are consistent (such as signalling point code, and IP address). If there is any abnormal
configuration data, ensure that the configuration data is modified at local or other NEs,
and modify it.
2. If the problem persists, perform the self-loop on the optical interface or E1/T1 at the
BSC side.If the fault disappears after the local self-loop, the cause may be the abnor-
mal running of the peer NE.
3. If the conditions allow (for example, the physical distance between NEs is very small),
perform the self-loop at the corresponding remote NE according to link fault location.
For example, for the Abis link, perform the self-loop on the optical interface of the
interface board at BTS. For the A/Gb interface, perform the self-loop on the optical
interface of the interface board at CN.If the peer NE becomes normal after the self-loop,
the cause is the transmission network configuration fault.
4. If the fault persists after the self-loop, check the transmission cable for connection and
good contact, and cables for damages and exposing.
5. For IP network, when all equipment is running normally, if the global services
disconnect, the maintenance personnel should examine whether the IP network runs
normally first.
a. Check the association status in NM configuration management. If the association
is not in service status, recreate the association. If the creation fails,Check the IP
network through pinging the peer interface IP address on OMMR.
b. In the performance management, check the QoS statistics of IP link types in one
office direction, and know the accessibility of the peer IP address according to the
packet loss rate.
c. With the dedicated instrument or software, test the transmission delay, error
bit rate, and jitter of the IP network, to confirm whether such faults as network
congestion, network thunderstorm, and virus attack, occur in the IP network.
6. If the problems fail to be solved with all the above methods, launch the emergency
aid, or reset the interface board with caution. For resetting details, refer to 3.9 Board
Resetting and Changeover Description.
3.6.1 Principles for Handling Transmission Alarms

l Handle the near-end alarms prior to handling the far-end alarms.
Near-end alarms are reported by the optical interface board when it detects the
abnormality in the signal received. Far-end alarms are reported to the optical
interface board when the opposite device detects the abnormality in the signal
received. The near-end alarms should be handled first because they are original
alarms that indicate the abnormality.
l Observe the commonness of the alarms
When several interface boards generate alarms of the same type, or when alarms of
the same type occur on several E1 links, observe whether the board or E1 links are
in the same office or whether the opposite switches are the same model.
3-7

l Contact the peer end to handle the far-end alarms.

Far-end alarms are reported by the peer-end equipment. When far-end alarms occur
on the interface board, go to the far-end equipment maintenance personnel to know
about what are original alarms and what original alarms are eliminated. Far-end
alarms of the interface board disappear.
l Ping transmission at each section of Ethernet.
Locate the transmission fault. That is, find out the faulty section (such as the section
cannot be pinged through or the section to which packet loss occurs), or locate the
faulty equipment.
l Detect inner media plane
Detect the media plane of BSC, inter-boards, and inter-shelves, to check whether
there is any packet loss resulting form hardware fault in BSC.
l Handle transmission alarms

Remove the alarms for packet loss at the bottom bearer layer caused by abnormal or
unstable transmission.
l Capture packets
Packet capture at the external switch is a method for judging packet loss and disorder
of NE. Packet capture at the site and BSC is used together for comparison. The PTN
equipment at the Abis interface can also support to capture packets.
The function of packet capture varies from different manufactures, so you can contact
the transmission manufacturer for support.
3.6.2 Methods for Handling Transmission Alarms

1. Determine the fault type through comparison.
When the alarm exists on some interface boards, if allowed, change the boards or
fibers to determine whether the alarm is related to the board or office.
2. Locate the fault through loopback.
NM test management interface provides different loopback settings for optical interface
and E1 interface boards, including line loopback of optical path, test loopback of optical
path, line loopback of optical path at the system side, line loopback of E1, and test
loopback of E1.
3.6.3 Causes for Transmission Alarms

1. LOS,LOF
The cause may be that the REG equipment directly connecting to the interface board
is faulty or the pigtail/flange between the local-end ODF and the equipment is faulty.
2. AU-AIS, AU-LOP, HP-UNEQ, HP-PLM
3-8

The cause is that the SDH transport network does not enable/ configure the higher
order path.
3. TU-AIS, TU-LOP, LP-UNEQ, LP-PLM
The cause is that the lower order path is not established in SDH transport network or
the DXC configuration does not meet the requirement of networking.
4. E1-AIS,E1-LOF
The cause is the connection fault between the opposite switch and the SDH transport
equipment, such as, E1 cable connection fault.
5. RS-TIM,HP-TIM,LP-TIM
The cause is that the values of local J0, J1, and J2 are inconsistent with the
configurations of SDH transport equipment. Alarms of these three types do not affect
the services.
To eliminate the alarms, obtain the values of J0, J1, and J2 related to the transport
equipment through the query opposite configuration and then modify the values in the
database.
6. RS-FERF,HP-FERF,LP-RDI,E1-RAI
Check and remove the near-end alarms on the corresponding layer.
In particular, for E1-RAI alarms, contact the maintenance personnel of the opposite
switch to confirm whether the E1 frame format is the same as the local end.
7. E1-SLIP
If E1SLIP occurs when the board is running normally, the cause is the clock fault.
3.6.4 CSTM-1 Interconnection Fault

ESDTI/ESDTG/ESDTT is the SDH/SONET network interface board of the platform. to
access the TDM/IP link through the CSTM-1 interface.
In the SDH transport network shown in Figure 3-2, REG is the regenerative repeater, ADM
is the add/drop multiplexer, DXC is the digital cross-connection equipment, and TM is the
terminal multiplexer.
3-9

Figure 3-2 Network Location and Alarm Structure of the optical interface boards
ESDTI/ESDTG/ESDTT terminates the regeneration section overhead between the REG

and the optical interface board. Alarms for maintaining the regenerator section include:
LOS (Loss Of Signal), LOF (Loss Of Frame), and RS-TIM (Regenerator Section - Trace
Identifier Mismatch).
ESDTI/ESDTG/ESDTT terminates the regeneration section overhead between the nearest
ADM and the optical interface board. Alarms for maintaining the regeneration section
include: MS-AIS (Multiplex Section - Alarm Indication Signal), MS-FERF (Multiplex Section
- Far End Receive Failure), SF (Signal Failure), and SD (Signal Degrade).
ESDTI/ESDTG/ESDTT terminates the higher order path overhead between the DXC and
the optical interface board. Alarms for maintaining the higher order path include: AU-AIS
(Administration Unit-Alarm Indication Signal, AU-LOP (Administration Unit - Loss Of
Pointer), HP-TIM (Higherorder Path Trace Identifier Mismatch), HP-UNEQ (Higher-order
Path UN-Equipped), HP-PLM (Higherorder Path - Payload Label Mismatch), HP-FERF
(High-order Path - Far End Receive Failure), and LOM (Loss Of Multiframe).
ESDTI/ESDTG/ESDTT terminates the lower order path overhead between the TM and
optical interface board. Alarms for maintaining the lower order path include: TU-AIS
(Tributary Unit - Alarm Indication Signal), TU-LOP (Tributary Unit - Loss Of Pointer),
LP-RDI (Lower-order Path - Remote Defect Indication), LP-RFI (Lower-order Path -
Remote Failure Indication), LP-TIM (Lower-order Path - Trace Identifier Mismatch),
LP-UNEQ (Lower-order Path UN-Equipped), and LP-PLM (Lowerorder Path - Payload
Label Mismatch).
ESDTI/ESDTG/ESDTT terminates the E1 circuit overhead between the opposite switch

and the optical interface board. Alarms for maintaining the E1 circuit include: E1 AIS (E1-
Alarm Indication Signal), E1 LOF (E1 Loss Of Frame), E1-LOM (E1 Loss Of Multiframe),
E1-RAI (E1 Remote Alarm Indicator), E1-FEBE (E1 Far End Block Error), and E1-SLIP.
3-10

3.6.5 E1 Array Mode Fault

Several E1 links of the interface board has two array modes on the optical path, G.707
and Tributary. The array modes of both interconnection ends must be the same. If not,
the probable symptom is: Services borne on E1 1, 4, 7, 10, 13, 16, 19, 23, 26, 29, 32, 35,
38, 41, 45, 48, 51, 54, 57, 60, 63 are normal and on others are disconnected.
To confirm whether the array modes are same or not, insert E1AIS alarm on the opposite
on E1 2. If the E1 22 detects the alarm, the array modes at the interconnection ends are
different.
3.7 Emergency Handling of BSC Service Abnormality

and Interruption
3.7.1 Handling A Interface Faults
Fault Analysis
A interface faults mainly include: a) the No.7 signalling cannot reach the A interface; b)
services cannot be connected; c) calls cannot be got through; d) downloading or browsing
cannot be activated; and e) the signalling point unreachable alarm occurs in the NM. A
interface faults are basically signalling link faults, which are usually caused by incorrect
data modifications, board failures or transmission link abnormalities.
1. Many calls cannot be got through, or the Internet cannot be accessed and the terminal
cannot be activated.
2. Check alarms on the NM alarm management interface to see if there is any office
direction unreachable alarm, and if the alarm occurs in all BSCs. If so, the fault lies
in the CN. If the fault only occurs in one or several BSCs, it is possibly caused by
BSC-side problems.
Recommended Solutions
1. Check to see if all tables are synchronized for the data modifications of the whole
network or a single BSC. If so, recover the data.
2. Check to see if there is any alarm about inaccessible calls or unreachable signals in
all BSCs. If so, check the CN side.
3. Check to see whether the connection configuration of both sides of the A interface are
identical.
4. Check the indicator status of the BSC interface board. If the indicator status is
abnormal, check to see if the fiber connection is correct. If yes, reset or replace the
interface board.
5. If the indicator status is still abnormal, check the CN side.
3-11

3.7.2 Call Failures Handling

Fault Description
Generally, call failures can be caused by the following reasons:
1. If no call can be got through in many BSCs or throughout the network, the problem lies
in the CN side. If the failure only occurs in some areas, the problem lies in the BSC.
2. The No.7 link is abnormal or the call in the A-interface direction is unreachable.
3. A/Abis interface board is abnormal.
4. A great deal of cells are out of service.
5. Check to see if call failures occur regularly. If the call fails once per several times of
calls, it is possible that one of the E1 PCM links at the A interface or one of the logic
links at the optical interface fails.
1. Check to see if the BSC data configuration is modified before the failure occurs. If so,
recover the configuration by importing the backup data.
2. Check the No.7 link status.
3. Reset or replace the interface board.
4. Conduct an active/standby changeover to the interface board.
5. Reset the interface board to which the failed cell belongs.
3.7.3 Handling of Unilateral or Voiceless Conversation Faults

Fault Description
Unilateral or voiceless conversations occur during speech calls. These faults can be
caused by any failure arising from MS, air interface, BTS, BSC user plane, and CN. In
unilateral conversations, data packets cannot be transmitted correctly between the calling
party and the called party, resulting in that only one party can hear the voice. Such a
problem can be located by two means. One is to check statistics; the other is to make a
CS loopback test.
1. When either party or both party cannot be heard in a speech call, replace the terminal,
and then make a test call in the same environment. If the fault does not occur any
more, the problem probably lies in the terminal.
2. If unilateral conversations still occur after testing different brands of terminals for many
times, the problem possibly lies in the system.
3. Use two terminals to make a test call, and do an uplink loopback test and a downlink
loopback test on the calling party or the called party in the signalling trace system. If
you can hear your voice from the calling MS during the uplink loopback test, it means
that there is no problem from the MS to the BSC, and the problem possibly lies in
interface board or the CN side. If not, the problem possibly lies in the user plane or
the Abis interface.
3-12

1. Check to see if a global data modification is made before the failure occurs. If so,
recover to the pre-modification data.
2. Replace the MS. If the failure does not occur any more, the problem lies in the terminal.
Report it to the terminal maker for solution.
3. Reset A interface board.
4. If the fault persists after step 3, reset the service processing board where services are
borne.
5. Reset the interface board to which the unilateral failed cell belongs.
6. If the problem persists after all these steps, contact personnel at the CN side for
troubleshooting.
3.7.4 Handling of Webpage Access Failures

Fault Description
1. When a data card or a mobile phone processes PS services, it cannot open webpages
or download data through FTP after the PS service is activated.
2. Through the signalling trace system, it is found that the signalling service can run
correctly. No webpage can be accessed through the terminal. If the webpage access
failure occurs in all cells, the problem possibly lies in the Gb-interface user plane. If
the failure only occurs in several cells, the problem possibly lies in the poor quality
of the air interface. It is recommended to handle it by following the instructions in
troubleshooting manuals.
3. Make a packet transmission test to the MS by using the tool in the signalling trace
system. If the MS downloads data at a normal rate during the test, it means that there
is no problem from the MS to the BSC user plane.
4. Make a ping packet test. If no problem is found during the test, the problem possibly
lies in the Gb interface, or the IP packet limitation made at the CN side.
5. Replace the terminal. If the download and webpage access failures does not exist any
more, the problem lies in the terminal. Contact the terminal maker for solution.
1. Check to see if the data configuration is modified before the failure occurs. If so,
recover the configuration by importing the backup data.
2. Reset the Gb interface board. If the failure still exists, replace the interface board.
3. If the failure remains, reset the board where the PS service is established.
4. If the failure remains after all these resets, ask personnel at the CN side for
troubleshooting to see if the problem is caused by the MTU packet limitation.
3-13

3.8 Handling of BTS Service and Interruption

3.8.1 Large-Scale Cell Outages Handling
Fault Description
Cell outages are mainly caused by SCTP link disconnections, and base station
transmission failures, which then result in channel establishment failures in the cell.
Generally, the alarms about link disconnections are caused by transmission signalling
processing-related problems, which should be analyzed through such information as the
location where the alarm is generated and the module to which the cell belongs.
1. Check the NM to see if large-scale cell outages occur to all BSCs, and if all
transmission-related boards generate alarms. If so, the problem probably lies in
transmission.
2. Check the alarms on the NM alarm management interface. If the interface board
generates many E1/SCTP link alarms, the cell outage is possibly caused by
transmission-related problems. For IP transmission, check to see if there is any
conflict in terms of MAC address or IP address.
3. If there are cell outage alarms but no interface board transmission failure alarms in the
NM system, the problem may be caused by main processor failure.
4. If cell outages only occur to several interface boards, the problem possibly lies in the
Abis interface board.
1. Check to see if a global parameter modification is made before the failure occurs. If
so, recover the configuration by importing the backup data.
2. If all out-of-service cells belong to the same module and the transmission interface
board generates no alarms, conduct an active/standby changeover to the home
processing module.
3. If all out-of-service cells belong to the same shelf and the transmission interface board
generates no alarms, conduct an active/standby changeover to the EGFS.
4. If all cells that belong to an interface board are out of service, reset or replace the
interface board.
3.8.2 Handling of Cell Abnormal Interruption

Fault Description
1. On the NM client, check whether the cell establishment is normal.
2. Check whether the links over the transmission channel are normal.
3. The abnormalities occur in one or more cells, and all services in the cell are abnormal
or have a quite low success rate, while radio services originated in other cells run
normally.
3-14

1. Check whether the cell is in block status.
2. Unblock/Reset the cell.
3. After the cell is unblocked or reset, check whether the fault still exists.
4. Check whether BTS transceiving/receiving antenna is connected well and whether the
power amplifier is normal.
3.8.3 Handling of Service Interruption Caused by Data Modification

Error
Fault Description
The modification on radio configuration data may not immediately cause the service
abnormality. With the increase of users (such as the coming of traffic peak time) and the
change of user service types, various radio problems can be caused, such as, low access
rate of user service, unstable service rate.
1. Log on to the NM client, view log management, and check whether the radio resource
configuration data is modified.
2. If modified, back up the current BSC configuration data.
3. Recover the data configuration of radio configuration.
4. Wait for the system to recover.
Note:
The radio resource data is based on such factors as on-site call model and on-site
landforms combining with network planning and optimization, so it is recommended not to
modify it. If you want to adjust the parameters, make a proper data backup beforehand.
3.9 Description on Board Resetting and Changeover

Board resetting is an operation that must be performed in some faults. Hot resetting means
to restart the system when the system is being powered on, so it is the software resetting.
All related resettings mentioned subsequently are hot ones.
To guarantee the normal system running and to avoid the abnormal system running caused
by resetting due to the board software and hardware faults, back up important boards.
Board backup is described in Table 3-2.
3-15

Table 3-2 Board Backup Modes
Functional Board Backup Mode Description
UMP(OMP/OMM) 1+1 backup Being the centralized control

point in the whole system,
OMP's backup mode must be
1＋1 backup and cannot be
modified.
ETCB Load sharing backup -
EDTT No backup/1+1 backup -
EDTI No backup/1+1 backup -
ESDTT 1+1 backup -
ESDTI 1+1 backup -
ESDTG 1+1 backup -
EGPB Load sharing backup/1+1 -

backup
EGBS Load sharing backup Fault handling assistance is

provided as soon as fault
occurs.
EGFS Load sharing backup Fault handling assistance is

provided as soon as fault
occurs.
USP(CMP) 1+1 backup -
USP(RUP) Load sharing backup -
3.9.1 Influence of Resetting and Changeover

The changeover of 1+1 backup board brings slight or no impact on services.
Resetting USP (RUP/CMP) board may cause the loss of services borne on that board
currently, but new services can access after successful changeover. Therefore, conduct
changeover to that board in the case of low traffic.
Resetting such boards in load sharing mode as EGBS, EGFS and ETCB will cause the
decrease in the capacity of the control plane and user plane between two boards (shelves),
and in the interface bandwidth, rather than service interruption.
3.9.2 Changeover Modes

1. Normal manual changeover at the background.
On the rack map, select the board to reset. For operation details, refer to ZXUR 9000
GSM Base Station Controller Status Management Operation Guide.
3-16

2. Manual changeover at the NE.

3. Automatic changeover due to NE faults.
The system initiates changeover after detecting abnormalities.
3.10 Link/Cell Fault Confirmation Methods

The two confirmation methods should be taken with the cooperation from the NM client,
one is to confirm link fault (including MTP3), the other is to confirm the sufficiency of cell
resources.
3.10.1 Check of Cell MTP3 Link

On the Status Management interface, you can check the following items. For operation
details, refer to ZXUR 9000 GSM Base Station Controller-Status Management Operation
Guide.
l Check the status of No.7 link.
l Check SCTP status.
3.10.2 Check of Cell Normality

Enter the Status Management interface. For operation details, refer to ZXUR 9000 GSM
Base Station Controller- Status Management Operation Guide.
Check the status of cell and cell channels.
3.11 Overview of Data Backup and Recovery

Before handling ZXUR 9000 GSM emergency faults, back up the configuration data first.
On one hand, the fault recovery may involve configuration data modification, and the data
can restore on-site status to avoid the worse case during the emergency fault recovery.
On the other hand, reserve the first-hand information for ZTEs maintenance and technical
support personnel and the technicians at the home front, helping to analyze and locate
problems and improving the system performance.
Two methods to back up and recover ZXUR 9000 GSM configuration data are as follows:
l Create the database maintenance task.
After creating the database maintenance task, the system can automatically back up
the specified maintenance table according to the maintenance time set by the task.
l Manually back up and recover the data table.
If necessary, manually back up and recover the data table at any time.
3-17

3.12 Description on Board Panel Indicator

3.12.1 Types of Board Panel Indicators
In ZXUR 9000 GSM system, board panel indicators fall into the following two types:
1. Common indicator
The common indicators are available to most boards, including:
l OOS
l OK
l H/S
l ACT
l HOST
2. Special indicators
Besides common indicators mentioned above, different boards have their own special
indicators. For the detailed description of the special indicators, refer to ZXUR 9000
GSM Base Station Controller-Hardware Description.
3.12.2 Description on Board Panel indicator Status

The status of the indicators on board panel is described in Table 3-3.
Table 3-3 Description on Board Panel Indicator Status
Type Run Status Description
1 Always ON The indicator is always ON in a specific

status.
2 Always OFF The indicator is always OFF in a specific

status.
3 Flashing at 5 Hz The period is 0.2 s and the duty ratio is

50%: ON for 0.1 s, and OFF for 0.1 s .
4 Flashing at 2 Hz The period is 0.5 s and the duty ratio is

50%: ON for 0.25 s and OFF for 0.25 s.
5 Flashing at 1 Hz The period is 1 s and the duty ratio is

The period is 1 s and the duty ratio is

6 Flashing at 0.5 Hz The period is 2 s and the duty ratio is

50%: ON for 1 s and OFF for 1 s.
3-18

3.12.3 Description on Common Indicators

The common indicators on the front and back boards are described in Table 3-4.
Table 3-4 Common Indicator Description
Indicator Color Meaning Description
OOS Dual-color Board service and It achieves different levels of alarms through
indicator alarm indicator flashing at different frequencies.
(red/green)
OK Dual-color Normal status It is to indicate the normal status of boards.

indicator indicator
(red/green)
H/S Blue Hot-swap indicator It is to indicate the hot-swap status.
ACT green Active/standby It is to indicate the active/standby status of

indicator the board.
HOST Tri-color indica- Running/Alarm If the indicator is green, it indicates the

tor (red/green/or- indicator running status of boards. If the indicator is
ange) red, it indicates the alarm status of boards.
If the indicator is orange, it indicates the
initialization/loading of memory.
3.12.3.1 Description on ACT

ACT, the active/standby status indicator, indicates that whether there is any service running
on the current board. The ACT indicator is described in Table 3-5.
Table 3-5 ACT Description
Status Name Color ACT Status Meaning
Working Green Always ON No backup board

Status
If the board is in 1+1 backup mode, a logic entity or
a port (currently, the SDH port is supported) on the
board is the active entity/port.
Standby - Always OFF If the board is in 1+1 backup mode, all logic entities
status on the board are the active entities, and all ports
(currently, the SDH port is supported) are not the
active ones.
3.12.3.2 HOST Description

HOST, the run/alarm indictor, is described in Table 3-6.
3-19

Table 3-6 HOST Description
Status Priority Color HOST Duty Meaning

Name Status Ratio
Initial 1 - Always - Initial status

status OFF
Normal 2 Green 1 Hz 50% Normal running

running
The mem- 3 Orange 1 Hz 50% The built-in memory is initializing

ory is or loading, which takes much time.
initializ-
ing/loading
Minor 4 Red 1 Hz 50% Services are applicable when the

alarms board is being changed over.
5 Red 1 Hz 50% The subcard equipment fails.
Critical 6 Red 2 Hz 50% The network port at the media

alarm plane is disconnected.
7 Red 2 Hz 50% HW high-speed data channel is

interrupted.
8 Red 2 Hz 50% Link break with OMP.
9 Red 2 Hz 50% Version and hardware are

inconsistent with the configuration.
10 Red 2 Hz 50% Loss of output clock
11 Red 2 Hz 50% The subcard equipment fails

severely.
Fault 12 Red 5 Hz 50% The version download fails.

alarm for
removing 13 Red 5 Hz 50% The board self-check fails.
14 Red 5 Hz 50% The Support system startup fails.
15 Red 5 Hz 50% Obtaining logic address fails.
16 Red 5 Hz 50% The basic process power-on fails

or times out.
17 Red 5 Hz 50% Initialization of core data district

fails.
18 Red 5 Hz 50% The subcard equipment fails

seriously.
3-20

3.12.3.3 Description on the Combination of H/S, OOS and OK

The combination of H/S, OOS and OK is described in Table 3-7.
Table 3-7 Description on the Combination of H/S, OOS and OK
H/S (Blue) OOS (Red/Green) OK (Red/Green)

Status Duty Symp- Duty Duty Meaning
Symptom Symptom
Ratio tom Ratio Ratio
The board
Green,
Always needs to be
Always OFF always
OFF powered on
on
and reset.
The hardware
address is
wrong. The
Green,
Always OFF status of
Always OFF flashing at 50%
OFF the indicator
5 Hz
does not
occur to the
rear board.
The board is
inserted to
Red, the subrack
Power-on Always
Always ON always bottom,
and OFF
ON but the
Power-off
extractor is
disengaged.
The board is
inserted to
the subrack
Red,
Flashing at 1 Always bottom with
90% always
Hz OFF the extractor
ON
closed and
is ready for
power-on.
The board
Red, is ready
Always
Always OFF always for power
OFF
ON distribution
and power-on.
3-21

H/S (Blue) OOS (Red/Green) OK (Red/Green)

Status Duty Symp- Duty Duty Meaning
Symptom Symptom
Ratio tom Ratio Ratio
The board is
powered on
Un-
Always successfully
Always OFF changed
OFF and is in
status
stable working
status.
The extractors
Un- Un- of the
Flashing at 1
90% changed changed board are
Hz
status status disengaged
for power-off.
The board
Un- Un-
Flashing at 1 is being
90% changed changed
Hz shut down
status status
normally.
Un- Red,
Unchanged Alarms occur
Alarming changed flashing at 50%
status to the board.
status 1 Hz
Running Unchanged Un- Green, The board

status changed flashing at 50% is running
status 1 Hz normally.
3-22

Chapter 4
Fault Feedback Description
Table of Contents
Fault Feedback Information ........................................................................................4-1
Data Recorded for Feedback .....................................................................................4-2
Methods for Obtaining System Records .....................................................................4-4
4.1 Fault Feedback Information

Fault feedback should include the following information:
1. Fault time
2. Fault description
3. Detailed troubleshooting steps
4. System record
5. Fault feedback report
The fault feedback information is described as follows:
1. Fault time
Describes specific time of the fault, including the start/end time of the fault.
2. Fault description
a. Describes the fault symptom, such as board state, dynamic state, NM alarm,
signalling, and calling state. These are the basis of on-site troubleshooting.
b. It describes the fault scope, such as whole BSC or a single site.
c. If you can't express it clearly, you shall copy the pictures. For the channel state in
dynamic management and error messages occurred during operation, you shall
copy it in picture mode.
3. Detailed troubleshooting steps
a. Steps and time about on-site troubleshooting.
b. It includes the operation cases that may cause the fault.
c. It is recommended that on-site operators keep a good habit to record operation
procedures for the server, so it can provide a convenience to check whether there
is any operation error. For the operations on the server, you can use the record
function of NETTERM to remember the operation procedures.
4. System record
It records system operation state and error messages and is the primary method to
locate system errors.
4-1

5. Fault feedback report

For fault feedback report, refer to Appendix A-Emergency Maintenance Record of this
manual.
4.2 Data Recorded for Feedback

Table 4-1 shows the data on BSC faults required for feedback.
Table 4-1 Data on BSC Faults Required for Feedback
System Records Required

for Feedback Purpose of Record Method to Get System Record
The indicator status of the faulty

board To reflect the status of boards. Omitted
Printing files of the equipment

(including active/standby MP
for central peripheral modules): To record the abnormal cases Refer to Section 4.3.1 Obtaining
Exc_Omp.txt, Exc_pp.txt occurred during BSC operation. Equipment Printing Files.
ZDB file in all active MPs for the To know the configuration infor- Refer to section 4.3.2 Obtaining
equipment or ZDB file for NM mation in BSC. ZDB files.
Refer to section 4.3.3 Obtain-

To know the configuration infor- ing Data Backup ZIP Files From
ZIP backup files in NM mation in NM. OMM.
Screenshots of board in-stock

version, general software ver-
sion, and specified version set- To know the software settings Refer to section 4.3.4 Obtaining
tings about boards. Software Settings.
Files on one-week historical Refer to section 4.3.5 Obtaining

alarms and current alarms To record the system alarms. Alarm Files.
Files on one-week historical no- To make a supplement to the Refer to section 4.3.6 Obtaining
tifications system alarms. Notification Files.
Equipment and NM version To know the function of different In accordance with the version of
number versions. on-site records.
Performance report on one hour Refer to section 4.3.7 Obtaining

before and after the cell-level To check the running status of one Hour's Performance Data
fault. the system. Before and After Fault.
The traced signalling at interface Refer to section 4.3.8 Obtaining

A To locate faults. Traced Signalling at Interface A.
The dynamic status of the link

at interface A in case the fault
is related to interface A or the To know the link status at inter- Refer to section 4.3.9 Querying
whole BSC face A. Dynamic Data at Interface A.
4-2

Chapter 4 Fault Feedback Description
System Records Required

for Feedback Purpose of Record Method to Get System Record

The traced signalling at interface ing the Traced Signalling at In-
A To locate faults. terface Abis.
The base station in dynamic sta-

tus (including cell, carrier, and The status of the channel is an-
channel) in case call failure oc- other way to decide the system Refer to section 4.3.11 Querying
curs at the base station status. dynamic data of Base Station.
The base station in dynamic sta-

tus (including cell, carrier, and
channel) in case call failure oc- The status of BVC and NSVC is Refer to section 4.3.13 Querying
curs at the base station to decide the system status. BVC and NSVC Statuses.
PS related signalling in case the Refer to section 4.3.12 Tracing

fault is related to PS services To locate faults. PS Service Signalling.
The operation logs at OMM To analyze the operation condi- Refer to section 4.3.14 Obtain-
server tion of OMM server. ing OMM Server Log.
Refer to section 4.3.15 Checking

whether Overstocked Data Ex-
Overstocked data To analyze incomplete data. ists.
Table 4-2 shows the data on NM faults for feedback.
Table 4-2 Data on NM Faults for Feedback
System Records Required Method to Obtain System

for Feedback Purpose of Record Record
Refer to section 4.3.16 Querying

Information about disk space To reflect the disk utilization. Disk Space.
To record the operation condi- Refer to section 4.3.17 Obtain-

NM printing files tions of the NM system. ing NM Printing Files.
To know the configuration infor- Refer to section 4.3.4 Obtaining

ZIP backup files in NM mation in NM. Data Backup ZIP Files of OMM.
To know the important configura- Refer to section 4.3.18 Obtain-

NM configuration files tion in the system. ing NM Configuration Files.
To record the on-site operations Refer to section 4.3.19 Obtain-

Operation logs at the client on NM. ing Operation Logs at the Client.
To locate the specific time for Refer to section 4.3.20 Checking

System time zone international office. System Time Zone.
To know the functions of different Refer to section 4.3.21 Checking

NM version versions. NM Version.
4-3

Table 4-3 shows the data on base station faults required for feedback.
Table 4-3 Data on Base Station Faults Required for Feedback
System Records Required Method to Obtain System

for Feedback Purpose of Record Records
Site name, site number and site To find the corresponding site in
model ZDB files. Omitted
The status of the channel is an-

Dynamic observations (includ- other way to decide the system Refer to section 4.3.11 Querying
ing cell, carrier, and channel) status. dynamic data of Base Station.

To reflect the startup information ing the Traced Signalling at In-
O&M signalling trace of the base station. terface Abis.

To record call cases in the sys- ing the Traced Signalling at In-
Signaling trace at interface Abis tem. terface Abis.

Files on one-week historical ing Alarm Files and section 4.3.6
alarms and notifications To record fault information. Obtaining Notification Files.
To know different functions of dif- Refer to section 4.3.4.2 Obtain-

Base station version ferent versions. ing BTS Software Settings.
To record and confirm the con- Refer to section 4.3.2.1 Obtain-

ZDB files at NE figuration information at NE. ing Equipment ZDB Files.
4.3 Methods for Obtaining System Records

4.3.1 Obtaining Equipment Printing Files
Steps
1. Create a directory to save files on OMM server.
2. Use the ftp command to connect OMP on OMM. Both the username and password
are ftp123, and the specified port is 21.
3. Use the cd /IDEO command to enter the IDEO directory.

4. Execute the get command to get the Exc_Omp.txt and Exc_pp.txt files.
5. Download the file to OMM server, and use the ftp tool (such as CUTEFTP) to transmit
the file to the client.
– End of Steps –
4-4

Example
1. mkdir bsc1
2. cd bsc1
3. ftp 172.20.6.1 21
4. cd /IDEO
5. get Exc_pp.txt
6. get Exc_Omp.txt
7. bye
4.3.2 Obtaining ZDB Files

4.3.2.1 Obtaining Equipment ZDB Files
Context
ZDB files are under the directory /IDEO/256/DATAO on OMP. While getting ZDB file, if
there are too many files, you had better establish a proper directory for each module on
each BSC, to transfer the ZDB files to the proper directory.
Steps
1. Create a directory to save files on OMM server.
2. Use the ftp command to connect OMP on OMM. Both username and password are
ftpuser, and the specified port is 21.
3. Obtain the desired ZDB files under the DATA1 directory.
a. Use the cd command to enter the directory /IDE0/256/DATAO.
b. Use the get filename command to download the BRSCFG_DB.ZDB,

GSM_DB.ZDB, MCS_DB.ZDB, PLAT_DB.ZDB, RAP_DB.ZDB,
VERINFO_DB.ZDB, GSMBTSVER_DB.ZDB, IPCONF_DB.ZDB, OAM_DB.ZDB,
and RAPRULE_DB.ZDB files one by one.
4. After the files are downloaded onto OMM server, use the ftp tool, such as CUTEFTP,
to compress and upload the files to the client.
Example
1. cd $OMCHOME
2. mkdir bsc1
3. cd bsc1
4. ftp 172.20.6.1 21
5. cd /IDE0/256/DATA0
6. get BRSCFG_DB.ZDB
7. get GSM_DB.ZDB
4-5

8. get MCS_DB.ZDB
9. get PLAT_DB.ZDB
10. get RAP_DB.ZDB
11. get VERINFO_DB.ZDB
12. get GSMBTSVER_DB.ZDB
13. get IPCONF_DB.ZDB
14. get OAM_DB.ZDB
15. get RAPRULE_DB.ZDB
4.3.2.2 Obtaining ZDB Files of OMM
Context
ZDB files of OMM are saved in $OMCHOME/ums-svr/tmp/ftp/rncXX/zdb (XX indicates
ZXUR 9000 GSM ID). Each time when all the tables or the modified tabled are
synchronized, logservice.ZDB files will be generated, and the file generated at last time
will be added a suffix in accordance with the generation time for backup.
Steps
1. Generated file is too small during the synchronization of modified tables. You can use
the ls l command to view the file size. If the current ZDB files belong to the generated
file on modified-table synchronization, you can perform a whole-table synchronization
at NM client, to generate a new complete ZDB file.
2. Use the ftp tool, such as CUTEFTP, to transfer ZDB file to the client.
4.3.3 Obtaining Data Backup ZIP Files of OMM

Steps
1. Right-click the NE in the physical view of topology management, select NE
Management > Configuration Management from the pop-up menu, and open the
configuration management interface.
2. Select Management > Data Management > Data Backup.

3. Select backup path/CM (normally on OMM server) from the pop-up Data Backup
window, type the prefix of backup filename and backup description, select a NE to
back up, and click OK.
4. Use the ftp tool with the username/password as sysbak and port 21, to download the
backed-up ZIP files from OMM server through ftp mode.
4-6

4.3.4 Obtaining Software Settings

4.3.4.1 Obtaining BSC Software Settings
Context
Software version management falls into platform version pack and GSM version pack.
For detailed operations on software version management, refer to ZXUR 9000 GSM Base
Station Controller Software Version Management Operation Guide.
Steps
1. On the Software Version Management window, expand a subnetwork node.
Double-click Controller-OMP on the resource tree. The imported version packages
of the controller type is displayed.
2. Right-click a package of the Controller-OMP type, select the command to display the
detailed information of the package.
4.3.4.2 Obtaining BTS Software Settings

BTS software settings can get Vertable.zdb equipment file for feedback. For operation
details, refer to section 4.3.2.1 Obtaining Equipment ZDB Files.
4.3.5 Obtaining Alarm Files

Steps
1. Query the desired historical alarms of NE. For operation details, refer to NetNumen
U31 R18 Unified Element Management System Alarm Management Operation Guide.
2. Export and save the queried historical alarms.
4.3.6 Obtaining Notification Files

Steps
1. Query the desired historical notifications. For operation details, refer to NetNumen
U31 R18 Unified Element Management System Alarm Management Operation Guide.
2. Export and save the queried historical notifications.
4-7

4.3.7 Obtaining Performance Data one Hour Before and After Fault
Steps
1. Query the performance data one hour before and after the fault. For operation details,
refer to NetNumen U31 R18 Unified Element Management System Performance
Management Operation Guide.
2. Export the queried performance data as an Excel and save it.
4.3.8 Obtaining Traced Signalling at Interface A

Context
The signalling trace (that is, calling trace) tool uses the server/client architecture.
Steps
1. Trace the desired signalling at interface A of BSC. For operation details, refer to ZXUR
9000 GSM Base Station Controller-Calling Trace Operation Guide.
Note:
Trace at interface A has great influence on system load, so each time the trace
operation can't exceed 5 minutes.
2. Save all traced signalling results as csv file format for feedback.
4.3.9 Querying Dynamic Data at Interface A

Steps
1. Enter status management. For operation details, refer to ZXUR 9000 GSM Base
Station Controller-Status Management Operation Guide.
2. Query the status of PCM on the A-Interface PCM tab.
3. Query the status of timeslots on the A-Interface Trunk Circuit Management tab.
4. If the IP A-interface is used, query the status of DSP on the IPA Management tab.
4-8

4.3.10 Obtaining Traced Signalling at Interface Abis

Context
Steps
1. For the BSC/site that needs to be traced, trace the signalling at the interface Abis.
For operation details, refer to ZXUR 9000 GSM Base Station Controller-Calling Trace
Operation Guide.
2. Save all signalling trace results and save as csv file format for feedback.
4.3.11 Querying dynamic data at Base Station

Steps
Station Controller Status Management Operation Guide.
2. On the Status Management interface, query the status of base station.
Table 4-4 shows dynamic data management functions.
Table 4-4 Dynamic Data Management Functions
Functions Description
Cell management query the status of cell
TRX management Query the status of TRX
Channel Management Query channel state
Module Management Query channel statistics on a module
BVC Management Query the BVC status of cell
Cell channel management Query channel statistics of a cell
Query timeslot status measurement of resource

Timeslot management at Abis pool at Abis
Timeslot resource management at Abis Query timeslot state of resource pool at Abis
LAPD status management Query LAPD link status at site
Loopback Management Query the loopback state
4-9

4.3.12 Tracing PS Service Signalling

Context
Steps
1. For the BSC that needs to be traced, trace the PS and RLCMAC signalling at interface
Abis and all signalling at interface Gb. For operation details, refer to ZXUR 9000 GSM
Base Station Controller-Calling Trace Operation Guide.
2. Save all signalling trace results and save as csv file format for feedback.
4.3.13 Querying the Status of BVC and NSVC

Steps
Station Controller-Status Management Operation Guide.
2. Query the status of NSVC.
3. Query the status of BVC.
4.3.14 Obtaining Operation Logs of OMM Server

The operation logs of OMM server are saved under $OMCHOME/log and are named by
their generation time. If you use the cd $OMCHOME/log command, you can enter into this
directory to get corresponding LOG files through the ftp tool.
4.3.15 Checking Overstocked Data

Steps
1. Check whether the backed-up configuration management files under
/home/xxxxxxx/ums-svr/backup/sysmanager/cm in OMM server are overstocked.
2. Check whether the backed-up alarm management files under

/export/home/xxxxxxx/ums-server/backup/sysmanager/fm on the server are
overstocked.
3. Check whether the backed-up performance management files under
/export/home/xxxxxxx/ums-server/backup/sysmanager/pm on the server are
overstocked.
4-10

4. Check whether the backed-up log management files under

/export/home/xxxxxxx/ums-server/backup/sysmanager/log on the server are
overstocked.
5. Check whether the backed-up performance configuration files under
/export/home/xxxxxxx/ums-server/backup/sysmanager/ueppm on the server are
overstocked.
4.3.16 Querying Disk Space

Steps
1. For the Linux or Solaris system, use the df k and vmstat commands to query current
disk space.
2. Use NETTERM to save the operation procedures.
3. For the AIX system, use the df k and vmstat commands to query current disk space.
4.3.17 Obtaining NM Printing Files

Steps
1. The process printing files related with NM are located under the
/export/home/xxxxxxx/ums-server/works directory which only saves the logs at that
day.
l The main process: /export/home/xxxxxxx/ums-server/works/main/main1/log
l EMS proces: /export/home/xxxxxxx/ums-server/works/minos/minos1/log
l Nothward process: /export/home/xxxxxxx/ums-server/works/naf_td/naf_td1/log
l Alarm process:
/export/home/xxxxxxx/ums-server/works/fm/fm1/log/server(fm)-*.log
l Performance process:
/export/home/xxxxxxx/ums-server/works/pm/pm1/log/server(pm)-*.log
l Startup logs:
/export/home/xxxxxxx/ums-server/utils/console/works/console1/log/
l Logs at the client:
xxxxxxx\ums-client\works\full\log\client(cmaint)-20101011-0805-11524246.log
l The historical logs being collected:
/export/home/xxxxxxx/ums-server/rundata/umd/output/timer
2. Use the ftp tool, such as cuteftp, to obtain log files during the failure period of NM.
4-11

4.3.18 Obtaining Configuration Files at NM

The configuration files of OMM server are saved in the $OMCHOME/deploy folder which
can be downloaded to the local client by using the ftp tools, such as CUTEFT. The
configuration files that should be obtained are as follows:
l deploy-010muep.properties
l deploy-*.properties
You can use ftp tools, such as CUTEFTP, to download the configuration files of NM to the
local client. The configuration files that should be obtained are as follows:
l /export/home/xxxxxxx/ums-server/works/global/deploy, deploy-*.properties
l The collected files are packed and saved in the
/export/home/xxxxxxx/ums-server/rundata/umd/output/timer folder.
Real-time alarm files related with the server and NM are saved in the
/export/home/xxxxxxx/ums-server/procs/ppus/gsm.ppu/gsm-gsmv3.pmu/gsm-gsmv3-rtalarm-naf.par/con
folder. The files need to be obtained are as follows:
l fmmgr.properties
l nafproc.properties
4.3.19 Obtaining Operation Logs at the Client

Steps
1. Query the operation logs. For operation details, refer to related chapters of NetNumen
U31 R18 Unified Element Management System Safety Management Operation Guide.
2. Export the operation logs to an excel.
4.3.20 Checking System Time Zone

Steps
1. Check the time zone at the server.
l For the Solaris system, use the command echo $TZ.
l For the Linux system, use the command grep ZONE /etc/sysconfig/clock.
l For the AIX system, use the command echo $TZ.
2. To check the time zone at the client, you can perform as follows:
After opening the control panel of the computer at the client, you can find the current
time zone in the options of region setting.
4-12

4.3.21 Checking NM Version

On the main interface at the client of NM, click Help > About to display the information
about NM version.
4-13

This page intentionally left blank.
4-14

Appendix A
Maintenance Record Table
Table of Contents
Ÿ Fault Record Table ................................................................................................. A-1
Ÿ Troubleshooting Record Table ................................................................................ A-2
Ÿ Equipment Emergency Maintenance Notice ........................................................... A-2
A.1 Fault Record Table

The table below serves as an example only. It is better to optimize according to actual
BSC maintenance items.
Equipment Name Equipment No.
Item Fault Description
Fault occurrence time
Fault occurrence scope
Program version of active OMP
Version of connected BTS/CN
OMC version No.
The board whose BSC indicator shows

abnormality
Serious alarm item reported by OMC
Operation log information of OMC
Project information For example, the environment of the equipment

room: temperature and humidity change. Record
it if any.
Abnormality query information Including the resource name (such as cell ID)
whose status is abnormal through query, and
abnormal contents. Record it if there is any.
Signalling trace information This part of information can be obtained under

the assistance of ZTEs remote technical support
personnel after you launch the emergency
assistance request.
A-1

A.2 Troubleshooting Record Table

Equipment Name Equipment No.
Fault occurrence time Hour Day Month Year Fault handling time Hour Day Month Year
Fault type:
Fault source:
Fault symptom:
Solution:
Summary:
Person on duty: Handled by:
A.3 Equipment Emergency Maintenance Notice

This notice is to notify ZTE technical support center by fax when the operator fails to solve
the fault by himself. It is better to attach the on-site fault record table with the fax, to allow
ZTE personnel to locate and eliminate the faults more easily.
The user should fill in the following items
Equipment Equipment No. Software

Name Version
Complaint HH DD MM YY Complainant Telephone

Time
Complaint In the warranty period or not □Yes □No

company or
organization
Abnormality Record Table (Please attach it on the blank below):
Details of the handling process (as detailed as possible):

Reviewed by:
Chopped by the department:
ZTE personnel should fill in the following items:
Solution: Time of settlement
O Guide through telephone O Remote maintenance O On-site HH DD MM YY

support
Handling result:
Handled by:
Chopped by the department:
Unresolved problems:
A-2

Tables
Table 1-1 User Complaints........................................................................................ 1-1
Table 1-2 Alarm Report on Emergency Maintenance ................................................ 1-2
Table 1-3 KPI Index .................................................................................................. 1-3
Table 3-1 BSC Service Fault Coverage Analysis ...................................................... 3-1
Table 3-2 Board Backup Modes .............................................................................. 3-16
Table 3-3 Description on Board Panel Indicator Status............................................ 3-18
Table 3-4 Common Indicator Description................................................................. 3-19
Table 3-5 ACT Description ...................................................................................... 3-19
Table 3-6 HOST Description ................................................................................... 3-20
Table 3-7 Description on the Combination of H/S, OOS and OK.............................. 3-21
Table 4-1 Data on BSC Faults Required for Feedback .............................................. 4-2
Table 4-2 Data on NM Faults for Feedback ............................................................... 4-3
Table 4-3 Data on Base Station Faults Required for Feedback ................................. 4-4
Table 4-4 Dynamic Data Management Functions ...................................................... 4-9

Tables
II

Figures
Figure 2-1 Emergency Maintenance Flow ................................................................. 2-2
Figure 3-1 Handling Process During System Power Failure ...................................... 3-3
Figure 3-2 Network Location and Alarm Structure of the optical interface
boards .................................................................................................. 3-10
III

Figures
IV

Glossary
ADM
- Add/Drop Multiplexer
AIS
- Alarm Indication Signal
AIX
- Advanced Interactive eXecutive
AS
- Application Server
ASP
- Application Service Process
- Advanced value-added Service Platform
AU
- Admininstrative Unit
AU-AIS
- Administrative Unit - Alarm Indication Signal
AU-LOP
- Administrative Unit-Loss of Pointer
BSC
- Base Station Controller
BTS
- Base Transceiver Station
BVC
- BSSGP Virtual Connection
CMP
- Calling Main Processor
CN
- Core Network
CPU
- Central Processing Unit
CS
- Circuit Switched
CSTM-1
- Channelized STM-1
DSP
- Digital Signal Processor

DXC
- Digital Cross Connect
EDTI
- Enhanced Digital Trunk board IP version
EDTT
- Enhanced Digital Trunk Board TDM Version
EGBS
- ETCA GE Base Switch
EGBS
- Enhanced GE BASE Switch Board
EGFS
- ETCA GE Fabric Switch
EGFS
- Enhanced GE FABRIC Switch Board
EGPB
- ETCA GE Process Board
EMS
- Element Management System
ESDTG
- Enhanced SDH Digital Trunk Board GSM Version
ESDTI
- Enhanced SDH Digital Trunk board IP version
ESDTT
- Enhanced SDH Digital Trunk Board TDM Version
ETCB
- Enhanced TransCoder Board
FERF
- Far End Receive Failure
FTP
- File Transfer Protocol
FUC
- Frame Unit Controller
GSM
- Global System for Mobile Communications
HW
- High speed data Way
ID
- Identification
VI

Glossary
IP
- Internet Protocol
KPI
- Key Performance Index
LAPD
- Link Access Procedure for D-channel
LOF
- Loss Of Frame
LOM
- Loss Of Multiframe
LOP
- Loss Of Pointer
LOS
- Line-out-0f-service Signal
LOS
- Loss Of Signal
LP
- Lower order Path
MP
- Main Processor
MS
- Mobile Station
MS
- Multiplex Section
MSC
- Mobile Switching Center
MTP3
- Message Transfer Part layer 3
MTU
- Maximum Transfer Unit
NSE
- Network Service Entity
NSVC
- Network Service Virtual Connection
ODF
- Optical Distribution Frame
OMC
- Operation & Maintenance Center
VII

OMM
- Operation & Maintenance Module
OMP
- Operation Main Processor
PC
- Personal Computer
PCM
- Pulse Code Modulation
PLM
- PayLoad Mismatch
PPP
- Point-to-Point Protocol
PS
- Packet Switched
PTN
- Packet Transport Network
QoS
- Quality of Service
RAI
- Remote Alarm Indication
RDI
- Remote Defect Indication
REG
- REGenerator
RFI
- Remote Failure Indication
RS
- Regenerator Section
RUP
- Rnc User plane Processor
SCCP
- Signaling Connection Control Part
SCTP
- Stream Control Transmission Protocol
SD
- Signal Degrade
SDCCH
- Standalone Dedicated Control Channel
VIII

Glossary
SDH
- Synchronous Digital Hierarchy
SF
- Signal Failure
SGSN
- Serving GPRS Support Node
SIM
- Subscriber Identity Module
SONET
- Synchronous Optical NETwork
TCH
- Traffic Channel
TIM
- Trace Identifier Mismatch
TM
- Terminal Multiplexer
TU
- Tributary Unit
TU-AIS
- Tributary Unit Alarm Indication Signal
TU-LOP
- Tributary Unit-Loss of Pointer
UMP
- Universal Management Process Board
UNEQ
- UN-Equipped
USP
- Universal Service Process Board
VPN
- Virtual Private Network
IX

SJ-20121227135800-008-ZXUR 9000 GSM (V6.50.102) Emergency Maintenance

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

SJ-20121227135800-008-ZXUR 9000 GSM (V6.50.102) Emergency Maintenance

Încărcat de

Drepturi de autor:

Formate disponibile

ZXUR 9000 GSM

Base Station Controller

Revision No. Revision Date Revision Reason

R1.0 2013-01-30 First Edition

Serial Number: SJ-20121227135800-008

Publishing Date: 2013-01-30(R1.0)

SJ-20121227135800-008|2013-01-30(R1.0) ZTE Proprietary and Confidential

Chapter 2 Emergency Maintenance Flow................................................. 2-1

Chapter 3 Emergency Fault Handling....................................................... 3-1

SJ-20121227135800-008|2013-01-30(R1.0) ZTE Proprietary and Confidential

Chapter 4 Fault Feedback Description ..................................................... 4-1

SJ-20121227135800-008|2013-01-30(R1.0) ZTE Proprietary and Confidential

Appendix A Maintenance Record Table .................................................. A-1

SJ-20121227135800-008|2013-01-30(R1.0) ZTE Proprietary and Confidential

SJ-20121227135800-008|2013-01-30(R1.0) ZTE Proprietary and Confidential

What is in This Manual

1, Overview Describes applicable scope, guideline, and preparations of

2, Emergency Maintenance Describes the emergency maintenance flow.

3, Emergency Faults Describes how to handle emergency faults.

Appendix A, Emergency Describes the emergency maintenance table.

SJ-20121227135800-008|2013-01-30(R1.0) ZTE Proprietary and Confidential

Note: provides additional information about a certain topic.

SJ-20121227135800-008|2013-01-30(R1.0) ZTE Proprietary and Confidential

1.1 Emergency Maintenance Purpose

1.2 Emergency Maintenance Scope

Table 1-1 User Complaints

Complaint Content Description

l Lots of speech users cannot access;

SJ-20121227135800-008|2013-01-30(R1.0) ZTE Proprietary and Confidential

Table 1-2 Alarm Report on Emergency Maintenance

Alarm Type Alarm Description

Alarms on standby boards, such as OMP and

Active board alarm in active/standby mode

Board alarm Board alarm in non-active/standby mode

Abnormal access clock

Phase-locked loop out of lock

Clock alarms Level 1 alarm on lost clock reference source

Alarm on unreachable MTP3 office

Alarms related with interface A SCCP subsystem unavailable

NSVC failure alarm

Alarms related with interface Gb NSE block alarm

Congestion at signalling point

Alarms on traffic control Too high CPU load

Loss of trunk frame

Loss of trunk signal

SDH/SONET: loss of signal

PPP Link Broken

Rack Abis control link broken

Relevant transmission alarms Association Channel Broken

Normally, KPI index is not a direct condition to start emergency maintenance.Table

SJ-20121227135800-008|2013-01-30(R1.0) ZTE Proprietary and Confidential

Table 1-3 KPI Index

Index Type Index Name

SDCCH congestion rate

TCH congestion rate

Congestion TCH availability

TCH assignment success rate

Channel occupation Call success rate

Handover Handover success rate

Call drop TCH call drop rate

1.3 Basic Principles for Emergency Maintenance

SJ-20121227135800-008|2013-01-30(R1.0) ZTE Proprietary and Confidential

1.4 Emergency Maintenance Precautions

1.5 Emergency Maintenance Preparations