SJ-20160328171815-013-ZXUR 9000 UMTS (V4.15.10.20) Emergency Maintenance

ZXUR 9000 UMTS
Radio Network Controller

Emergency Maintenance Guide
Version: V4.15.10.20
ZTE CORPORATION
No. 55, Hi-tech Road South, ShenZhen, P.R.China
Postcode: 518057
Tel: +86-755-26771900
Fax: +86-755-26770801
URL: http://support.zte.com.cn
E-mail: 800@zte.com.cn
LEGAL INFORMATION
Copyright © 2016 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 the ZTE technical support website http://support.zte.com.cn to inquire for related information.
The ultimate right to interpret this product resides in ZTE CORPORATION.
Revision History
Revision No. Revision Date Revision Reason
R1.0 2016-04-30 The following are the changes that were made in this version
compared with the early version (V4.14.10.14).
l Added the chapter "B.3 Reset Mode".

l Modified the descriptive contents in the manual, including
rewording the manual..
Serial Number: SJ-20160328171815-013
Publishing Date: 2016-04-30 (R1.0)
SJ-20160328171815-013|2016-04-30 (R1.0) ZTE Proprietary and Confidential

Contents
About This Manual ......................................................................................... I
Chapter 1 Overview .................................................................................... 1-1
1.1 Introduction to Emergency Maintenance .............................................................. 1-1
1.2 Basic Principles.................................................................................................. 1-1
1.3 Precautions........................................................................................................ 1-1
1.4 Proper Operation Characteristics of the System ................................................... 1-2
1.4.1 Criteria for Proper OMM Operation ............................................................ 1-2
1.4.2 Criteria for Proper RNC Operation ............................................................. 1-2
1.4.3 Criteria for Proper Base Station Operation ................................................. 1-3
Chapter 2 Emergence Maintenance Flow................................................. 2-1

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

3.1 Handling Flow .................................................................................................... 3-1
3.2 Determining the Location of an RNC Fault ........................................................... 3-1
3.3 Power Supply Check .......................................................................................... 3-2
3.3.1 Checking Power Supply in Equipment Room.............................................. 3-3
3.3.2 Checking the Power Supply of the Rack .................................................... 3-4
3.3.3 Checking the Power Supply of the Shelf .................................................... 3-4
3.3.4 Powering-on the System for Check............................................................ 3-5
3.4 Handling Service Interruption Caused by Board Failure ........................................ 3-5
3.5 Checking the Operation Status of the System Clock ............................................. 3-7
3.6 Handling Transmission Faults ............................................................................. 3-7
3.6.1 Principles for Handling Transmission Alarms .............................................. 3-8
3.6.2 Transmission Alarm Types ........................................................................ 3-9
3.6.3 Methods for Handling Transmission Alarms.............................................. 3-10
3.7 Handling RNC Service Interruption .................................................................... 3-10
3.7.1 Handling Iu Interface Faults .................................................................... 3-10

3.7.2 Handling Call Failures..............................................................................3-11
3.7.3 Handling of Unilateral or Voiceless Conversation Faults.............................3-11
3.7.4 Handling Webpage Access Failures ........................................................ 3-12
3.8 Handling Node B Service and Interruption.......................................................... 3-13
3.8.1 Handling Large-Scale Cell Outages ......................................................... 3-13
3.8.2 Handling Absence of Cell Signals and Low Success Rate of RRC
Establishments ..................................................................................... 3-13
3.8.3 Handling Service Interruption Caused by Radio Cell Failure ...................... 3-14
3.8.4 Handling Service Interruption Caused by Improper Data Modification ........ 3-15
Appendix A Link and Cell Faults Location.............................................. A-1

A.1 Checking Link Status ......................................................................................... A-1
A.2 Checking Cell Status and Channel Status............................................................ A-1
Appendix B Reset and Board Switchover............................................... B-1

B.1 Influence of Reset and Changeover .................................................................... B-2
B.2 Changeover Modes............................................................................................ B-2
B.3 Reset Mode....................................................................................................... B-2
Appendix C Board Indicators ................................................................... C-1

C.1 Indicator Types ..................................................................................................C-1
C.2 Description on Board Panel indicator Status ........................................................C-1
C.3 Common Indicators............................................................................................C-2
Appendix D Emergency Maintenance Record Tables............................ D-1

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

About This Manual
Purpose
This manual describes how to perform emergency maintenance on the ZXUR 9000 UMTS
radio network controller and provides emergency maintenance record tables.
Intended Audience
This manual is intended for:
l System engineers
l Maintenance engineers
What Is in This Manual

This manual contains the following chapters and appendixes.
Chapter Summary
Chapter 1, Overview Describes the basic principles and precautions for

emergency maintenance.
Chapter 2, Emergence Maintenance Provides the emergency maintenance flow.

Flow
Chapter 3, Emergency Faults Handling Describes how to handling emergency faults.
Appendix A, Link and Cell Faults Describes how to locate Link and Cell Faults.
Location
Appendix B, Reset and Board Switchover Describes how to reset and switchover board.
Appendix C, Board Indicators Describes the board indicators.
Appendix D, Emergency Maintenance Provides emergency maintenance record tables, and

Record Tables describes the indicators on board panels.
Related Documentation
The following documentation is related to this manual:
l ZXUR 9000 UMTS Radio Network Controller Hardware Description
l ZXUR 9000 UMTS Radio Network Controller Status Management Operation Guide
Conventions
This manual uses the following conventions.
Italics Variables in commands. It may also refer to other related manuals and
documents.

Bold Menus, menu options, function names, input fields, option button names, check
boxes, drop-down lists, dialog box names, window names, parameters, and
commands.
Note: provides additional information about a topic.
II

Chapter 1
Overview
Table of Contents
Introduction to Emergency Maintenance.....................................................................1-1
Basic Principles..........................................................................................................1-1
Precautions ................................................................................................................1-1
Proper Operation Characteristics of the System .........................................................1-2
1.1 Introduction to Emergency Maintenance

Emergency maintenance refers to taking emergent measures to resolve system or
equipment critical faults, to restore the system or equipment and minimize losses.
Emergency maintenance is a process to analyze and locate faults, find fault causes, and
remove faults in accordance with prompt messages, signalling trace (that is, calling trace),
and error logs when critical faults occur to the system during system operations.
1.2 Basic Principles

The basic principles for emergency maintenance of theZXUR 9000 UMTS:
l Before the emergency maintenance, locate faults and perform troubleshooting in the
principle of "from interior to exterior, or from global to local".
l Make schemes for emergency faults.
l Relevant maintenance personnel should be familiar with the entire system, including
Network Management System (NMS) alarms, Radio Network Controller (RNC) panel
indicators, and data backup and restoration tools.
l If an emergency fault occurs to the system or equipment, maintenance personnel
should check the RNC hardware and transmission to determine whether the fault is
caused by RNC. If yes, perform troubleshooting in accordance with emergency fault
schemes or relevant procedures in this manual.
l Before, during, or after emergency maintenance, maintenance personnel should
collect the alarm information about faults, and send the troubleshooting report, alarm
file, and log file to ZTE for analysis.
l Critical faults must be resolved as soon as possible. Fault location and analysis tools
should be used to reserve related information for fault location and analysis before
any switchover, reset, and restart.
1.3 Precautions
The following precautions should be observed during emergency maintenance:
1-1

ZXUR 9000 UMTS Emergency Maintenance Guide
l Some restoration operations (for example, board reset) may greatly affect the system
operation, so these operations should be performed by experienced maintenance
personnel.
l Attach all contact information of ZTE CORPORATION in prominent positions in the
equipment room.
l If a fault greatly affects network operations, maintenance personnel should contact
ZTE Customer Support Center or local ZTE office immediately for technical support,
no matter whether they can resolve the fault.
1.4 Proper Operation Characteristics of the System

1.4.1 Criteria for Proper OMM Operation
The following criteria are used together to determine whether the OMM is operating
properly:
l Users can log in to the server from the client.
l Users can query performance statistics on the performance management tab.
l Users can view the current alarms and notifications on the alarm management tab.
All alarms are accurately reported in time.
l Users can check the real-time status of all managed objects on the status
management tab.
l Users can configure data through the configuration management function.
1.4.2 Criteria for Proper RNC Operation

The following criteria are used together to determine whether the RNC is operating
properly:
1. Check the operation status of the RNC at NM:
l Links between the OMM server and the OMP are established successfully, the
OMP address can be pinged from the OMM by entering the #ping 129.0.31.1
command (for example, OMP IP is 129.0.31.1), and the link connection between
the NE and NM is displayed as proper at the NM.
l There is no alarm about any board on the alarm management tab of the NM
system, especially no alarm saying that the control-plane communication link is
broken.
l On the alarm management tab of the NM system, all boards are in proper
active/standby status.
l On the status management tab of the NM system, all units, subunits, neighboring
office signaling points, No. 7 links, IMA groups, IMA links, PVCs, signalling links,
AAL2 channels, SCTP connections, AS & ASP, Node B ports, cells, and channels
are in unblocked / activated / available status.
On the status management tab of the NM system, all base stations are unblocked,
or without blocking.
1-2

Chapter 1 Overview
2. Check whether the operation status of the board indicators at the RNC-rack side is
proper.
1.4.3 Criteria for Proper Base Station Operation

The following criteria are used together to determine whether the base station is operating
properly:
l There is no alarm at the NM alarm management station.
l The performance indices in the NM statistics are proper.
l All cells in the NM status-management base station are in proper status.
l The KPI statistics show that the number of RRC connection requests is not 0, and the
success rate of RRC establishments is above 98%.
l There are no board alarms and all indicators flash properly at the base station side.
1-3

This page intentionally left blank.
1-4

Chapter 2
Emergence Maintenance
Flow
The emergency maintenance involves the following steps:
1. Check services.
2. Record abnormalities and output Abnormality Record Table.
3. Make initial location and analysis of faults.
4. Launch the emergency aid, record and send Equipment Emergency Maintenance
Requisite.
5. Recover services.
6. Observe services.
7. Make records of 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-3
Fault Records.............................................................................................................2-4
Initial Location and Analysis of Fault Causes..............................................................2-5
Emergency Aid...........................................................................................................2-5
Service Recovery .......................................................................................................2-6
Service Observation ...................................................................................................2-6
Fault Information Collection ........................................................................................2-6
2-2

Chapter 2 Emergence Maintenance Flow
2.1 Service Check

When an emergency fault occurs, perform the following steps to check services:
1. Check the power supply of each cabinet to see whether a major power failure occurs.
Yes->2
No->3
2. Notify the power supply maintenance personnel to troubleshoot the power supply and
power off all cabinets. Wait until the power supply operates stably, and then power on
the cabinets and check whether the fault is resolved. For information on how to power
on or power off the ZXUR 9000 UMTS, refer to 3.3 Power Supply Check".
Yes->End
No->3
3. If the external power supply operates properly, check the calls of all offices on the
performance statistics console according to users’ complaints to determine whether
the fault occurs in all offices or one office.
If the fault occurs in all offices->13
If the fault occurs in one office->4
4. Notify the personnel in the office to check the interface and link to determine whether
the fault is in the local office.
Yes->6
No->5
5. Ask the peer office to troubleshoot the fault.
6. Check whether the indicators on the panels of all boards show no errors.
Yes->8
No->7
7. Notify the maintenance personnel to perform troubleshooting, and then check whether
the emergency fault is resolved.
Yes->End
No->8
8. Check the alarm information displayed on the OMC client to see whether there are
board fault or link fault alarms.
Yes->9
No->10
9. Clear the alarms according to the alarm codes, and then check whether the fault is
resolved. For information on how to handle alarms, refer to the ZXUR 9000 UMTS
Radio Network Controller Alarm and Notification Handling Reference.
Yes->End
2-3

No->10
10. Check the cells to see whether they are correctly connected to other NEs.
Yes->13
No->11
11. Check the operation log to see whether any data is modified or deleted incorrectly and
the system is crashed.
Note:
You can check the man-machine command operation log and alarm time to determine
the relevance between operations and faults.
Yes->12
No->13
12. Restore the data and check whether the fault is resolved.
Yes->End
No->13
13. Notify the maintenance personnel for other NEs, such as Node B and CN, to perform
joint troubleshooting, or refer to the emergency maintenance manuals for other NEs
to determine the possible causes.
Note:
After a fault occurs, it is very important to locate the fault as soon as possible. Determining
whether the fault is in the local office or other offices is especially helpful for resolving the
fault quickly.
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
"2.1 Service Check", in the Fault Record Table (see "D.1 Fault Record Table").
Before handling ZXUR 9000 UMTS emergency faults, back up the configuration data of
OMM first, then after the fault recovery restore the configuration data from a data backup.
Refer to ZXUR 9000 UMTS Radio Network Controller Data Backup and Restoration Guide.
2-4

Note:
Fault records are very useful in emergency aid and subsequent fault analysis and
summary, so users should make an exhaustive fault record.
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 UMTS equipment or
other reasons, and determine its involved scope.
If the fault is located as being caused by the ZXUR 9000 UMTS 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, RNC, or Node B 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 RNC 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 Hotline of ZTE's customer service center
Domestic: 800-830-1118, 400-830-1118, and +86-755-26770800
International: +86–755–26771900
2-5

Before making a call, record the fault information in the emergency maintenance
notice (refer to "D.3 Equipment Emergency Maintenance Notice"), which may be
required by ZTE technical support engineers for troubleshooting.
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.
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.
Note:
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.
Note:
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 Fault Information Collection

Collecting fault information is important for asking for technical support, analyzing and
locating the fault cause, and preventing such faults from occurrence.
2-6

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 ZXUR 9000 UMTS through the file manager.
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. For
information on how to handle alarms, refer to ZXUR 9000 UMTS Radio Network
Controller Alarm and Notification Handling Reference.
4. Command log information
Collect the command log information about ZXUR 9000 UMTS 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. For information on how to handle logs, refer to NetNumen U31 R18 Unified
Element Management System Log Management Operation Guide .
5. Signalling trace information
Collect the signalling trace information aboutZXUR 9000 UMTS 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 information on signalling
tracing, refer to ZXUR 9000 UMTS Radio Network Controller Call Tracing Operation
Guide.
2-7

2-8

Chapter 3
Emergency Faults Handling
Table of Contents
Handling Flow ............................................................................................................3-1
Determining the Location of an RNC Fault..................................................................3-1
Power Supply Check ..................................................................................................3-2
Handling Service Interruption Caused by Board Failure..............................................3-5
Checking the Operation Status of the System Clock...................................................3-7
Handling Transmission Faults.....................................................................................3-7
Handling RNC Service Interruption...........................................................................3-10
Handling Node B Service and Interruption ................................................................3-13
3.1 Handling Flow

The following describes procedures to check ZXUR 9000 UMTS emergency faults.
1. Analyze RNC Fault Coverage.
2. Check the power supply.
3. Handle the user service interruption caused by ZXUR 9000 UMTS board fault.
4. Check the system clock working status.
5. Handle the user service interruption caused by abnormal transmission.
6. Handle BSC service abnormality and interruption.
7. Handle BTS service and interruption.
8. If the fault still exists, ask for emergency aid. Refer to "2.4 Emergency Aid".
3.2 Determining the Location of an RNC Fault

Table 3-1 provides a reference for determining the location of an RNC fault and the
corresponding handling suggestion.
Table 3-1 RNC Fault Locations
Fault Possible Cause Handling Suggestion
CS and PS services in the entire Power failure Check the power supply.
network are interrupted.
CN failure Perform troubleshooting on the
CN.
CS services in the entire CN failure Perform troubleshooting on the

network are interrupted. CN.
3-1

Fault Possible Cause Handling Suggestion
PS services in the entire CN failure Perform troubleshooting on the

network are interrupted. CN.
CS and PS services of a single Iu interface board failure Check the interface board
RNC are interrupted. and replace the board when
necessary.
Incorrect configuration of the Correct the office configuration.

corresponding office at the CN
side
CS services of a single RNC are Iu interface board failure Check the interface board
interrupted. and replace the board when
necessary.
SS7 link failure Check the SS7 link

configuration.
PS services of a single RNC are Iu interface board failure Check the interface board
interrupted. and replace the board when
necessary.
SS7 link failure Check the SS7 link

configuration.
The services of a single Node B Failure of the corresponding link Check and analyze the Iub link
are interrupted. status.
Node B failure Perform troubleshooting on the

Node B.
The services of a single cell are Incorrect cell configuration Check the cell configuration.
interrupted.
Manually blocked cell Unblock the cell.
3.3 Power Supply Check

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.
Figure 3-1 illustrates the handling process for system power failure.
3-2

Chapter 3 Emergency Faults Handling
Figure 3-1 Handling Process During System Power Failure
3.3.1 Checking Power Supply in Equipment Room

This section describes how to check the power supply system in the equipment room.
3-3

Steps
1. Before the power supply in the equipment room recovers, to prevent from any accident,
power off all switches on the cabinet power distribution subrack which connects with
the external power supply system, and toggle the dual-path power switch on the rack
to off.
2. Check the power supply system in the equipment room.
3. After the power supply in the equipment room recovers, power on the system again.
The power-on order is as the following:
a. Power on the power distribution subrack. Check whether the power supply voltage
is within the proper range: -57 V to -40 V.
b. Power on the dual-path on the racks. Check whether the power supply voltage is
within the proper range: -57 V to -40 V.
c. Recover the power supply of the network cabinet and server cabinet. Start the
NM server, charging dual-machine server, and disk machine.
– End of Steps –
3.3.2 Checking the Power Supply of the Rack

This section describes how to check whether the power supply of the rack is proper.
1. 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 proper. 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 inlet power
supplies of the power distribution subrack are 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.
2. Recover the power supply on the rack.
Check whether the dual-channel power supply voltage of the power distribution
subrack is within the proper range (-57 V to -40 V). If so, toggle the power switch to
on, to resume the power supply of the rack.
3.3.3 Checking the Power Supply of the Shelf

This section describes how to check whether the power supply of the shelf is proper.
Steps
1. Check whether the power supply on the shelf is proper.
a. If all LED indicators on the shelf are off, the power supply on the shelf is improper.
3-4

b. If the switch on the shelf of the power distribution subrack is off, the power supply
on the shelf is improper.
2. 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, toggle the power switch on each shelf corresponding
to the power distribution subrack to on, to resume the power supply of the shelf.
3.3.4 Powering-on the System for Check

This section describes how to power on the system for check.
Steps
1. Power on the rack, shelf, and boards of ZXUR 9000 UMTS.
Note:
For the power-on sequence, the main control shelf takes priority over other shelves.
2. Observe indicator statuses on boards to check whether the system is started properly.
3. Verify that the OMM server is started properly.
4. Check whether there is communication fault through the fault management. For
example, if the communication between modules is proper, remove the fault.
5. Check and remove the signalling link fault in the office direction through the fault
management.
6. Perform the basic service test, and ensure that services are recovered through the
signalling trace and failure observation.
3.4 Handling Service Interruption Caused by Board

Failure
This procedure describes how to handle service interruption caused by board failure.
Context
Table 3-2 describes the boards that are closely related to services.
3-5

Table 3-2 Boards Closely Related to Services
Unit Board Description
Interface unit l EAPB and EAPB1b Provides Iu, Iub, or Iur interfaces
l EDTA and EDTA1b for service access over of IP,
l ESDTA and ESDTA1b STM-1/CSTM-1, or E1/T1.
l EDTI and EDTI2a
l ESDTI and ESDTI2a
l EGPB, EGPB2a, EGPB2c,
EGPB1a, and EGPB1b
,
Switching unit l EGBS and EGBS2a Provides a communication platform

l EGFS and EXFS1a for inter-board services.
System control board UMP and UMP1b Provides operation and maintenance
functions, support the processing of
global procedures, and controls the
operation and maintenance of the
entire system.
Processing unit USP and USP2a Processes control-plane and

user-plane protocols.
Steps
1. Log in to the EMS client, select View > Alarm Management and check whether any
alarm related to a board exists in the alarm list. If yes. view the details of the alarm to
obtain the board information, such as the board type.
2. Locate the board reporting the alarm and observe the statuses of indicators on the
board panel.
Generally, the following common indicators are available on each board.

l HOST and OK: If these two indicators flash green at 1 Hz at the same time, it can
be determined that the board is operating properly.
l ACT: If the ACT indicator is lit, the board is determined as an active board. If the
ACT indicator is not lit, the board is determined as a standby board. This indicator
can be used to locate an active/standby switchover failure.
3. Analyze the alarm cause and handle the alarm according to the handling suggestions.
After the failure of the board is resolved, observe whether the alarm is cleared and
whether the service recovers.
4. If the status of any indicator is unexpected when the board is operating properly or the
alarm cannot be cleared in the EMS, reset the board or replace the board.
3-6

Note:
Do not reset a board in the RNC unless absolutely necessary. Resetting a board in
the RNC has great impact on services. For example, if a CMP board is reset, all user
services on this board are interrupted. If an interface board is reset, all parameters
allocated to this board become unavailable.
3.5 Checking the Operation Status of the System Clock

This section describes how to check the operation status of the system clock.
Context
The clock system fault may result in global service interruption.
Steps
1. Check whether the external connection of the EGFS/EXFS1a board is proper.
2. Check whether the system clock of EFGS/EXFS1a is proper, and check whether the
NE and NM clock data are consistent.
3.6 Handling Transmission Faults

Check with the following methods to decide the user service interruption caused by
improper transmission:
1. At the NM client, check the status of the transmission links, such as NCP, CCP,
ALCAP, MTP3B links, signalling link, and association , to see whether there is any
link fault.
2. At the NM client, check whether there is any resource alarm for the cell public
transmission channel, No.7 link, NCP, CCP, and association. Check whether the
alarm persists and cannot be removed.
3. Check the indicator status on the interface board to see whether the transmission cable
is normal.
Proposals to handle the link resource fault:
1. Check whether the data to be negotiated by such external NEs as Node B, CN and
ZXUR 9000 UMTS are consistent (such as NCP, CCP, MTP3B link, ATM address,
signalling point code, and IP address). If there is any abnormal configuration data,
the cause may be local NE or other NEs have modified the configuration data. Make
confirmation and modify them.
3-7

2. If there is not abnormality, perform the self-loop on optical interface or IMA group at
ZXUR 9000 UMTS side.
3. If the conditions allow (for example, the distance between NEs is very small), perform
the self-loop at the corresponding remote NE according to link fault location. For
example, for Iub link, perform the self-loop on the optical interface of the interface
board at Node B side. For Iu interface, perform the self-loop on the optical interface
of the interface board at CN side.
4. If the fault disappears after the local self-loop, the cause may be the abnormal
running of the peer NE. If the peer NE becomes normal after the self-loop, the cause
is transmission network configuration fault.
5. If the fault persists after the self-loop, check the transmission cable for connection and
good contact, and cables for damages and exposing.
6. For IP network, when all equipment is running normally, if the global services
disconnect, the maintenance personnel should examine whether IP network is
running 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, connect the
cable from the interface to another PC. Set the IP address as the local interface IP
address and check the IP network through pinging the peer interface IP address.
b. In the performance management, check the office IP link type QoS statistics. 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, jitter of the IP network, confirming whether such faults as network blocking,
network thunderstorm, and virus attack, occur in the IP network.
7. 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 "Appendix
B Reset and Board Switchover".
3.6.1 Principles for Handling Transmission Alarms

Principles for handling transmission alarms are as follows:
l Handle the near-end alarms before handling the far-end alarms
Near-end alarms are reported by the optical interface board when it detects that the
signals received are improper. Far-end alarms are reported to the optical interface
board when the equipment at the peer end detects that the signals received are
improper. If the near-end alarms (original alarms) on the interface board is eliminated,
the remote alarms on the interface board disappear.
l Observe the commonness of alarms
When several optical 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 switches at the peer end are the same
model.
3-8

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 RNC, inter-boards, and inter-shelves, to check whether
there is any packet loss resulting form hardware fault in RNC.
l Handle transmission alarms
Handle the alarms for packet loss at the bottom bearer layer caused by improper or
unstable transmission.
l Capture packets
Packet capture at the external switch is to check which NE packet loss and disorder
occur. Packet capture at the site and RNC is used together for comparison. The PTN
equipment at the Iub interface can also support to capture packets.
The function of packet capture varies from different manufactures, so users can
contact the transmission manufacturer for support.
3.6.2 Transmission Alarm Types

Transmission alarms fall into the following types:
l LOS and LOF
These alarms may indicate that the REG equipment directly connecting the interface
board is faulty, or the pigtail/flange between the local ODF and the equipment is faulty.
l AU-AIS, AU-LOP, HP-UNEQ, and HP-PLM
These alarms indicate that the SDH transport network does not enable/configure the
higher-order path.
l TU-AIS, TU-LOP, LP-UNEQ, and LP-PLM
These alarms indicate that the lower-order path is not established in the SDH transport
network, or the DXC is not configured in accordance with network requirements.
l E1-AIS and E1-LOF

These alarms indicate that the connection between the peer-end switch and the SDH
transport equipment is failure. For example, E1 cable connection is failure.
l RS-TIM, HP-TIM, and LP-TIM

These alarms indicate that the values of local J0, J1, and J2 are inconsistent with the
configurations for the SDH transport equipment. However, these alarms do not affect
services.
l RS-FERF, HP-FERF, LP-RDI, and E1-RAI
3-9

These alarms (belonging to the remote-end alarms) indicate that near-end alarms
may exist on the corresponding layer. For the E1-RAI alarm, contact the maintenance
personnel of the peer-end switch to confirm whether the E1 frame format is consistent
with that at the local end.
l E1-SLIP
This alarm indicates the clock fault when the board is operating properly.
3.6.3 Methods for Handling Transmission Alarms

l Determine the fault type by comparison
When the alarm exists on some interface boards, if possible, change the boards or
transmission cables to determine whether the alarm is related to the board or office.
l Locate the fault through loopback
The NM test management interface provides different loopback settings for the optical
interface boards and E1 interface boards, including the line loopback of the optical
path, test loopback of the optical path, line loopback of the optical path at the system
side, line loopback of E1, and the test loopback of E1.
3.7 Handling RNC Service Interruption

3.7.1 Handling Iu Interface Faults
Faults Description
Iu interface faults mainly include: a) the SS7 cannot reach the Iu 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 at the NM. Iu
interface faults are basically signalling link faults, which are usually caused by incorrect
data modifications, board failures or transmission link faults.
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 RNCs. If so, the fault lies
in the CN. If the fault only occurs in one or several RNCs, it is possibly caused by
RNC-side problems.
Recommended Solutions
1. Check to see if all tables are synchronized for the data modifications of the whole
network or a single RNC. If so, recover the data.
2. Check to see if there is any alarm about inaccessible calls or unreachable signals in
all RNCs. If so, check the CN side.
3-10

3. Check to see if there are frequent SSCOP link establishments and disconnections
(The message is "BGN, END".) Make sure that the PVC bandwidth and the PVC type
of both sides of the Iu interface are identical.
4.
5. Check the CN side if the problem persists after replacing the interface board.
3.7.2 Handling Call Failures

Fault Description
Generally, call failures can be caused by the following reasons:
1. If no call can be got through in many RNCs or throughout the network, the problem lies
in the CN side. If the failure only occurs in some areas, the problem lies in the RNC.
2. The No.7 link is improper or the AAL2 channel in the Iu office direction is improper.
3. The interface board is abnormal.
4. Many public channels are improper and 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 AAL2 channels at the Iu interface fails.
1. Check to see if the RNC 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 UE, air interface, Node B, RNC 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. Generally,
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 UE first,
and then make a test call in the same environment. If the fault does not occur any
more, the problem probably lies in the UE.
2. If unilateral conversations still occur after testing different brands of UEs for many
times, the problem possibly lies in the system.
3. Use two UEs to make a test call, and perform an uplink loopback test and a downlink
loopback test on the calling party or the called party in the signalling trace system.
3-11

If users can hear their voice from the calling UE during the uplink loopback test, it
means that there is no problem from the UE to the RNC, and the problem possibly lies
in interface board or the CN side. If not, the problem possibly lies in the user plane or
the Iub interface.
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 UE. If the failure does not occur any more, the problem lies in the UE.
Report it to the UE maker for solution.
3. Reset the Iu interface board.
4. If the fault persists, reset the service processing board where services are borne.
5. Reset the interface board to which the failed cell belongs.
6. If the problem still persists, contact personnel at the CN side for troubleshooting.
3.7.4 Handling 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.
Through the signalling trace system, it is found that the signalling service can operate
correctly. No webpage can be accessed through the UE. If the webpage access
failure occurs in all cells, the problem possibly lies in the Iu-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.
2. Make a packet transmission test to the UE by using the tool in the signalling tracking
system. If the UE downloads data at a proper rate during the test, it means that there
is no problem from the UE to the RNC user plane.
3. Make a ping packet test. If no problem is found during the test, the problem possibly
lies in the Iu interface, or the IP packet limitation made at the CE/CN side.
4. Replace the UE. If the download and webpage access failures do not exist any more,
the problem lies in the UE. Contact the UE 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 interface board. If the failure persists, replace it.
3. If the changeover doesn’t work, reset the service board where the PS service is
established.
4. If the failure remains after all these resets, ask personnel at the CE and the CN sides
for troubleshooting to see if the problem is caused by the MTU packet limitation.
3-12

3.8 Handling Node B Service and Interruption

3.8.1 Handling Large-Scale Cell Outages
Fault Description
Cell outages are mainly caused by NCP link or CCP link disconnections, SCTP
disconnections, and common channel establishment failures, which then result in
cell establishment failures or repeated deletions and creations of common channels.
Generally, the alarms about NCP/CCP/SCTP link disconnections are caused by
transmission- and 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 system to see if large-scale cell outages occur to all RNCs, and if
all transmission-related boards generate alarms. If so, the problem probably lies in
transmission.
2. Check the alarms on the alarm management interface. If the interface board
generates many E1/IMA/SCTP link alarms, the cell outage is possibly caused by
transmission-related problems. For IP transmission, check whether there is any
MAC-address or IP-address conflict.
3. If there are cell outage alarms but no interface board transmission failure alarms in the
NM system, the problem may be caused by RCP failure.
4. If cell outages only occur to several interface boards, the problem possibly lies in the
Iub interface board.
1. Check whether a global parameter modification is made before the failure occurs. If
yes, 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, perform 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, perform active/standby changeover to the EGFS or EXFS1a.
4. If all cells that belong to an interface board are out of service, reset or replace the
interface board.
3.8.2 Handling Absence of Cell Signals and Low Success Rate of

RRC Establishments
Fault Description
The absence of cell signals is mainly caused by failures arising from common transmission
channel establishments, system message broadcasts, and UE-dedicated radio link (on
3-13

Node B) releases, or by transmission bandwidth resource leakage. Such problems are

analyzed by checking fault notifications, QoS alarms, success rate of RRC establishments,
and users’ complaints, or by making tests.
1. Check the NM to see if there are QoS alarms about the success rate of RRC
establishments. If so, it means that the current common transmission channels are
established successfully and the UE has initiated RRC establishments.
2. Check the alarm management interface to see if there are notifications about system
message update failure. If so, it means that broadcast messages cannot be delivered
and the UE cannot access the network correctly due to the update failure.
3. Connect an LMT to the site to see if the BCH packet transmission increases properly.
If not, it means that the Node B fails to deliver broadcast messages.
4. Perform ALCAP and FP signalling trace through RNC or LMT signalling trace
to see if the transmission allocation and the FP synchronization fail during RRC
establishments.
1. Check whether a global parameter modification is made before the failure occurs. If
yes, recover the configuration by importing the backup data.
2. If there are notifications about system message update failure, modify the SIB1 value
of the cell and trigger the system message once to refresh the updating process.
3. If the Node B fails to deliver broadcasts, or if the transmission allocation and FP
synchronization fails, block and unblock the cell.
4. If the problem persists, reset the Node B.
3.8.3 Handling Service Interruption Caused by Radio Cell Failure

Fault Description
1. On the NM client, check whether the cell establishment is proper.
2. Check whether the cell establishment and the public channel establishment are proper.
3. Radio services in one or several cells are interrupted or are established with a low
success rate, while the radio services in other cells operate properly.
Proposals to handling radio cell establishment abnormality:

1. Check whether the cell is in block status.
2. Reset the cell.
3. Wait for the system to recover, and then check whether the fault still exists.
4. Check whether Node B transceiving antenna is connected properly and whether the
power amplifier is proper.
3-14

3.8.4 Handling Service Interruption Caused by Improper Data

Modification
The modification on radio configuration data may not immediately cause the service
abnormality. With the increase in users (such as at traffic peak time) and the change in
user service types, various radio problems can be caused, such as, low access rate of
user service, unstable service rate.
Proposals to handling such fault:
1. Log in to the NM client, and check ZXUR 9000 UMTS log management to see whether
the configuration data for radio resources are modified.
2. If there radio resource configuration data modification, back up the current ZXUR 9000
UMTS configuration data.
3. Recover the data configuration of radio configuration.
4. Wait for the system to recover.
Note:
It is recommended not to modify the radio resource data without backing up the data,
because the data are based on the on-site call model, on-site landforms, and network
planning and optimization.
3-15

3-16

Appendix A
Link and Cell Faults Location
Maintenance personnel can locate a link or cell fault by using a client of the element
management system. The following two procedures can be performed for fault location:
l Check the statuses of related links, including ALCAP, NCP, CCP, AAL5, and MTP3B
links.
l Check cell status and channel status to verify that the required cell resources have
been properly established.
Table of Contents
Ÿ Checking Link Status .............................................................................................. A-1
Ÿ Checking Cell Status and Channel Status............................................................... A-1
A.1 Checking Link Status

This procedure describes how to check the status of different links on the client of the
element management system.
Steps
1. On the Status Management tab, expand UMTS Radio Resource and Transmission
Resource in the left navigation tree.
2. Double-click Iub Port under UMTS Radio Resource, and then check the statuses of
NCP links and CCP links in the right pane.
3. Double-click AAL2 Path under Transmission Resource, and then check the status
of the AAL2 path in the right pane.
A.2 Checking Cell Status and Channel Status

This procedure describes how to check the statuses of cells and channels on the client of
the element management system.
Steps
1. On the Status Management tab, expand UMTS Radio Resource in the left navigation
tree.
2. Double-click Cell under UMTS Radio Resource, and then check the status of each
cell in the right pane.
A-1

3. Double-click Channel under UMTS Radio Resource, and then check the status of
each channel in the right pane.
A-2

Appendix B
Reset and Board Switchover
Resetting is an operation that must be performed when some faults occur, including
resetting a board, resetting cells and resetting the RNC.
Hot resetting means to restart the system that is being powered on, so it is the software
resetting. All related resettings mentioned in this manual are hot ones.
To guarantee the proper system operation and to avoid the improper system operation
caused by resetting due to the board software and hardware faults, back up important
boards. Board backup is described in Table B-1.
Table B-1 Board Backup Modes
Functional Board Backup Mode Description
UMP (OMP/OMM)/UMP1c 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.
EAPB/EAPB1b 1 + 1 backup -
EDTI/EDTI2a 1 + 1 backup -
ESDTA/ESDTA1b 1 + 1 backup -
ESDTI/ESDTI2a 1 + 1 backup -
EDTA/EDTA1b 1 + 1 backup -
EGPB/EGPB2a/EGPB1a/EGP- Load sharing backup and 1 + 1 -

B1b/EGPB2d backup
EGBS/EGBS2a Load sharing backup Fault handling assistance is

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

provided as soon as fault
occurs.
USP (CMP)/USP2a/USP1b 1 + 1 backup -
USP Load sharing backup -

(DMP/RUP)/USP2a/USP1b
USP (CDR)/USP2a/USP1b 1 + 1 backup & Load sharing -

backup
B-1

Table of Contents
Ÿ Influence of Reset and Changeover........................................................................ B-2
Ÿ Changeover Modes ................................................................................................ B-2
Ÿ Reset Mode ............................................................................................................ B-2
B.1 Influence of Reset and Changeover

l Resetting boards
à The changeover of 1+1 backup board brings slight or no impact on services.
à Resetting a USP, USP1b or USP2a board (Load sharing backup) may cause the
loss of services borne on that board currently, but new services can access after
successful changeover. Therefore, perform changeover to that board in the case
of low traffic.
à Resetting boards (such as EGBS/EGBS2a and EGFS/EXFS1a) in load-sharing
mode causes 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.
l Resetting cells: All the user services in this cell are released after reset.
l Resetting the RNC: Restarting the RNC interrupts all the RNC services.
B.2 Changeover Modes

1. Normal manual changeover at the background.
On the rack map, select the board to reset. For operation details, refer to the ZXUR
9000 UMTS (V4.14.10.09) Radio Network Controller Status Management Operation
Guide.
2. Manual changeover at the NE.
Reset the active board on the rack.
3. Automatic changeover due to NE faults.
The system initiates changeover after detecting faults.
B.3 Reset Mode

Reset operations of the emergency maintenance include resetting boards, cells and
the RNC. For details, refer to the ZXUR 9000 UMTS Radio Network Controller Status
Management Operation Guide.
B-2

Appendix C
Board Indicators
Table of Contents
Ÿ Indicator Types ....................................................................................................... C-1
Ÿ Description on Board Panel indicator Status ........................................................... C-1
Ÿ Common Indicators ................................................................................................ C-2
C.1 Indicator Types

In ZXUR 9000 UMTS system, board panel indicators fall into the following two types:
l Common indicators
The common indicators are available to most boards, including:
à OOS
à OK
à H/S
à ACT
à HOST
l Special indicators
Besides common indicators mentioned above, different boards have their own special
indicators. For the detailed description of the special indicators, refer to the ZXUR
9000 UMTS (V4.13.10.15) Radio Network Controller Hardware Description.
C.2 Description on Board Panel indicator Status

The status of the indicators on board panel is described in Table C-1.
Table C-1 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.
C-1

Type Run Status Description
5 Flashing at 1 Hz The period is 1 s and the duty ratio is 50%: on for 0.5 s
and off for 0.5 s.
The period is 1 s and the duty ratio is 90%: on for 0.9 s

and off for 0.1 s.
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.
C.3 Common Indicators

The common indicators on the front and rear boards are described in Table C-2.
Table C-2 Common Indicator Descriptions
Indicator Color Meaning Description
OOS Dual-color Board service and Indicates different levels of alarms through
indicator alarm indicator flashing at different frequencies.
(red/green)
OK Dual-color Proper status Indicates whether a board is operating

indicator indicator properly.
(red/green)
H/S Blue Hot-swap indicator Indicates the hot-swap status.
ACT green Active/standby Indicates the active/standby status of a

indicator board.
HOST Tri-color indica- Operation/Alarm The indicator in green indicates that the
tor (red/green/or- indicator board is operating.
ange) The indicator in red indicates alarm
occurrence in the board.
The indicator in orange indicates that the
memory of the board is being initialized or
loading data.
ACT
ACT, the active/standby status indicator, indicates that whether a board is an active board
in service. The ACT indicator is described in Table C-3.
C-2

Appendix C Board Indicators
Table C-3 ACT Indicator
Board Color ACT Status Meaning

Status
Active Green Solid on No standby board is configured.
The board is in 1+1 backup mode, meaning that a

logical entity or port (SDH port) on the board is in
active status.
Standby - Off The board is in 1+1 backup mode, meaning all

logical entities and ports (SDH ports) on the board
are in standby status.
HOST
HOST, the operation/alarm indictor, is described in Table C-4.
Table C-4 HOST Indicator
Board Priority Color HOST Duty Meaning

Status Status Ratio
Initial status 1 - Off - Initial status
Proper 2 Green 1 Hz 50% Proper operation

operation
Memory in 3 Orange 1 Hz 50% The built-in memory is initializing or

initializa- loading, which takes much time.
tion/loading
Minor alarms 4 Red 1 Hz 50% Services are available when the

board is being swtiched over.
5 Red 1 Hz 50% A minor fault occurs in the subcard

equipment.
Critical alarm 6 Red 2 Hz 50% The network port at the media

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 input clock.
11 Red 2 Hz 50% A severe fault occurs in the subcard

equipment.
C-3

Board Priority Color HOST Duty Meaning

Status Status Ratio
Alarm for 12 Red 5 Hz 50% The version download fails.

immediate
13 Red 5 Hz 50% The board self-test fails.
handling
14 Red 5 Hz 50% The support system startup fails.
15 Red 5 Hz 50% The logic address fails to be

obtained.
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.
H/S, OSS, and OK

The combination of H/S, OOS and OK indicators is described in Table C-5.
Table C-5 H/S, OOS and OK Indicators
Status H/S (Blue) OOS (Red/Green) OK (Red/Green) Meaning
Symptom Duty Symp- Duty Symptom Duty

Ratio tom Ratio Ratio
Power-on Off - Lit in - Off - The board

and green needs to be
Power-off powered on
and reset.
Off - Off - Flashing in 50% The hardware

green at 5 address is
Hz wrong. The
off status of
the indicator
does not
occur to the
rear board.
On - Lit in red - Off - The board is

inserted to
the subrack
bottom,
but the
extractor is
disengaged.
C-4

Appendix C Board Indicators
Status H/S (Blue) OOS (Red/Green) OK (Red/Green) Meaning
Symptom Duty Symp- Duty Symptom Duty

Ratio tom Ratio Ratio
Flashing at 1 90% Lit in red - Off - The board is

Hz inserted to
the subrack
bottom with
the extractor
closed and
is ready for
power-on.
Off - Lit in red - Off - The board

is ready
for power
distribution
and power-on.
Off - Off - Retaining - The board is

the powered on
previous successfully
status and is
in stable
operation
status.
Flashing at 1 90% Retaining - Retaining - The extractors

Hz the the of the
previous previous board are
status status disengaged
for power-off.
Flashing at 1 90% Retaining - Retaining - The board

Hz the the is being
previous previous shut down
status status properly.
Alarming Retaining - Retaining - Flashing in 50% Alarms occur

the previous the red at 1 Hz to the board.
status previous
status
Running Retaining - Retaining - Flashing in 50% The board

the previous the green at 1 is operating
status previous Hz properly.
status
C-5

C-6

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

The table below serves as an example only. It is better to optimize according to actual
RNC maintenance items.
Equipment Name Equipment No.
Item Fault Description
Fault occurrence time
Fault occurrence scope
Program version of active OMP
Version of connected Node B/CN
OMC version No.
The board whose RNC indicator shows failures.
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.
Fault query information Including the resource name (such as cell ID,
ATM No.) whose status is abnormal through
query, and failure contents. Record it if there is
any.
D-1

Signalling trace information This part of information can be obtained under

the assistance of ZTEs remote technical support
personnel after users launch the emergency
assistance request.
D.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:
D.3 Equipment Emergency Maintenance Notice

This notice is to notify ZTE technical support center by fax when the operator fails to remove
the fault by himself. It is better to attach the on-site fault record table with the fax, to facilitate
ZTE personnel to locate and eliminate the fault.
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
Fault 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
D-2

Appendix D Emergency Maintenance Record Tables
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:
D-3

D-4

Figures
Figure 2-1 Emergency Maintenance Flow ................................................................. 2-2
Figure 3-1 Handling Process During System Power Failure ...................................... 3-3

Figures
II

Tables
Table 3-1 RNC Fault Locations ................................................................................. 3-1
Table 3-2 Boards Closely Related to Services........................................................... 3-6
Table B-1 Board Backup Modes................................................................................B-1
Table C-1 Description on Board Panel Indicator Status ............................................ C-1
Table C-2 Common Indicator Descriptions ............................................................... C-2
Table C-3 ACT Indicator........................................................................................... C-3
Table C-4 HOST Indicator ........................................................................................ C-3
Table C-5 H/S, OOS and OK Indicators ................................................................... C-4
III

Tables
IV

Glossary
AAL2
- ATM Adaptation Layer type 2
AAL5
- ATM Adaptation Layer type 5
ALCAP
- Access Link Control Application Protocol
ASP
- Application Server Process
ATM
- Asynchronous Transfer Mode
AU-AIS
- Administrative Unit - Alarm Indication Signal
AU-LOP
- Administrative Unit-Loss of Pointer
BCH
- Broadcast Channel
BSC
- Base Station Controller
BTS
- Base Transceiver Station
CCP
- Communication Control Port
CE
- Channel Element
CMP
- Common signaling MP
CN
- Core Network
CS
- Circuit Switched
CSTM-1
- Channelized STM-1
DMP
- Dedicated signaling MP

DXC
- Digital Cross Connect
EAPB
- Enhanced ATM Process Board
EAPB1b
- Enhanced ATM Process Board 1b
EDTA
- Enhanced Digital Trunk Board ATM version
EDTA1b
- Enhanced Digital Trunk Board ATM version 1b
EDTI
- Enhanced Digital Trunk board IP version
EDTI2a
- Enhanced Digital Trunk board IP version 2a
EGBS
- Enhanced GE BASE Switch Board
EGBS2a
- Enhanced GE Base Switch board 2a
EGFS
- Enhanced GE FABRIC Switch Board
EGPB
- Enhanced GE Process Board
EGPB2a
- Enhanced GE Process Board 2a
EGPB2c
- Enhanced GE Process Board 2c
EGPB2d
- Enhanced GE Process Board 2d
EMS
- Element Management System
ESDTA
- Enhanced SDH Digital Trunk board ATM version
ESDTA1b
- Enhanced SDH Digital Trunk Board ATM version 1b
ESDTI
- Enhanced SDH Digital Trunk board IP version
ESDTI2a
- Enhanced SDH Digital Trunk board IP version 2a
VI

Glossary
EXFS1a
- Enhanced XGE Fabric Switch board 1a
FP
- Frame Protocol
HW
- High speed data Way
IMA
- Inverse Multiplexing over ATM
IP
- Internet Protocol
KPI
- Key Performance Index
LED
- Light Emitting Diode
LMT
- Local Maintenance Terminal
LOF
- Loss of Frame
LOS
- Loss of Signal
MTP3B
- B-ISDN Message Transfer Part level 3
MTU
- Maximum Transfer Unit
NCP
- Network Control Protocol
NE
- Network Element
NM
- Network Management
NMS
- Network Management System
Node B
- Node B
ODF
- Optical Distribution Frame
OMC
- Operation & Maintenance Center
VII

OMM
- Operation & Maintenance Module
OMP
- Operation & maintenance Main Processor
PS
- Packet Switched
PTN
- Packet Transport Network
PVC
- Permanent Virtual Channel
QoS
- Quality of Service
RNC
- Radio Network Controller
RRC
- Radio Resource Control
RUP
- Rnc User plane Processor
SCTP
- Stream Control Transmission Protocol
SDH
- Synchronous Digital Hierarchy
SS7
- Signaling System No. 7
SSCOP
- Service Specific Connection Oriented Protocol
TU-AIS
- Tributary Unit Alarm Indication Signal
TU-LOP
- Tributary Unit-Loss of Pointer
UE
- User Equipment
UMP
- Universal Management Process Board
UMP1b
- Universal Management Process board 1b
UMP1c
- Universal Management Process board 1c
VIII

Glossary
USP
- Universal Service Process Board
USP1b
- Universal Service Process board 1b
USP2a
- Universal Service Process board 2a
IX

SJ-20160328171815-013-ZXUR 9000 UMTS (V4.15.10.20) 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-20160328171815-013-ZXUR 9000 UMTS (V4.15.10.20) Emergency Maintenance

Încărcat de

Drepturi de autor:

Formate disponibile

ZXUR 9000 UMTS

Radio Network Controller

Revision No. Revision Date Revision Reason

l Added the chapter "B.3 Reset Mode".

Serial Number: SJ-20160328171815-013

Publishing Date: 2016-04-30 (R1.0)

SJ-20160328171815-013|2016-04-30 (R1.0) ZTE Proprietary and Confidential

Chapter 2 Emergence Maintenance Flow................................................. 2-1

Chapter 3 Emergency Faults Handling..................................................... 3-1

SJ-20160328171815-013|2016-04-30 (R1.0) ZTE Proprietary and Confidential

Appendix A Link and Cell Faults Location.............................................. A-1

Appendix B Reset and Board Switchover............................................... B-1

Appendix C Board Indicators ................................................................... C-1

Appendix D Emergency Maintenance Record Tables............................ D-1

SJ-20160328171815-013|2016-04-30 (R1.0) ZTE Proprietary and Confidential

What Is in This Manual

Chapter 1, Overview Describes the basic principles and precautions for

Chapter 2, Emergence Maintenance Provides the emergency maintenance flow.

Chapter 3, Emergency Faults Handling Describes how to handling emergency faults.

Appendix C, Board Indicators Describes the board indicators.

Appendix D, Emergency Maintenance Provides emergency maintenance record tables, and

SJ-20160328171815-013|2016-04-30 (R1.0) ZTE Proprietary and Confidential

Note: provides additional information about a topic.

SJ-20160328171815-013|2016-04-30 (R1.0) ZTE Proprietary and Confidential

1.1 Introduction to Emergency Maintenance

1.2 Basic Principles

SJ-20160328171815-013|2016-04-30 (R1.0) ZTE Proprietary and Confidential

1.4 Proper Operation Characteristics of the System

1.4.2 Criteria for Proper RNC Operation

SJ-20160328171815-013|2016-04-30 (R1.0) ZTE Proprietary and Confidential

1.4.3 Criteria for Proper Base Station Operation

SJ-20160328171815-013|2016-04-30 (R1.0) ZTE Proprietary and Confidential

This page intentionally left blank.

SJ-20160328171815-013|2016-04-30 (R1.0) ZTE Proprietary and Confidential

SJ-20160328171815-013|2016-04-30 (R1.0) ZTE Proprietary and Confidential

Figure 2-1 Emergency Maintenance Flow

SJ-20160328171815-013|2016-04-30 (R1.0) ZTE Proprietary and Confidential

2.1 Service Check

SJ-20160328171815-013|2016-04-30 (R1.0) ZTE Proprietary and Confidential

2.2 Fault Records

SJ-20160328171815-013|2016-04-30 (R1.0) ZTE Proprietary and Confidential

2.3 Initial Location and Analysis of Fault Causes

2.4 Emergency Aid

SJ-20160328171815-013|2016-04-30 (R1.0) ZTE Proprietary and Confidential

2.5 Service Recovery

2.6 Service Observation

2.7 Fault Information Collection

SJ-20160328171815-013|2016-04-30 (R1.0) ZTE Proprietary and Confidential

SJ-20160328171815-013|2016-04-30 (R1.0) ZTE Proprietary and Confidential

This page intentionally left blank.

SJ-20160328171815-013|2016-04-30 (R1.0) ZTE Proprietary and Confidential

3.1 Handling Flow

3.2 Determining the Location of an RNC Fault

Table 3-1 RNC Fault Locations

Fault Possible Cause Handling Suggestion

CS services in the entire CN failure Perform troubleshooting on the

SJ-20160328171815-013|2016-04-30 (R1.0) ZTE Proprietary and Confidential

Fault Possible Cause Handling Suggestion

PS services in the entire CN failure Perform troubleshooting on the

Incorrect configuration of the Correct the office configuration.

SS7 link failure Check the SS7 link

SS7 link failure Check the SS7 link

Node B failure Perform troubleshooting on the

3.3 Power Supply Check