SJ-20100603155704-010-ZXWR RNC (V3.09.30) Trouble Shooting - 315445

ZXWR RNC
Radio Network Controller
Trouble Shooting
Version:V3.09.30
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 2010 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
20100705
First Edition (V3.09.30.03)
R1.1
20100830
1. 3.1.4.1:The section Background Knowledge of Ethernet Com

munication Fault is updated.
2. 3.2.3:The section RCB Hardware Startup Fault is updated.
3. 3.2.10:The section Fault of CLKG/ICMG/ICM Failing to Lock
Clock Base Extracted by Optical Interface is updated.
4. 5.2.1:The section ROMP Reboots Once All-table Synchroniza
tion Made is updated.
5. 7.2.2:The section Users Requests Frequently Rejected is up
dated.
6. 13.2.7:The section Status and Implementation of Indicators in
BOOT is updated.
R1.2
20101122
The following sections have been modified:

1. 1.2.2 Fault Analysis
2. 1.2.5 Fault Record
3. 1.4.2 Indicator Status Check
4. 1.4.4 Performance Analysis
Revision No.
Revision Date
Revision Reason
5. 1.4.5 Operation Log Query
6. 1.4.7 Testing and Self-Looping
7. 3.1.1.1 Background Information
8. 3.2.1 Clock Output without Clock
9. 3.2.7 Board Fiber Communication Fault
10. 3.2.9 Rack Fan Startup Fault
Serial Number: SJ-20100603155704-010

Publishing Date: 2011-11-22(R1.2)
Contents
Preface............................................................................................................. I
Chapter 1 Overview .................................................................................... 1-1
1.1 Prerequisites for Maintenance Personnel ............................................................. 1-1
1.2 Trouble Shooting Flow ........................................................................................ 1-1
1.2.1 Information Collection ............................................................................... 1-2
1.2.2 Fault Analysis .......................................................................................... 1-2
1.2.3 Fault Location .......................................................................................... 1-3
1.2.4 Fault Elimination ...................................................................................... 1-3
1.2.5 Fault Record ............................................................................................ 1-3
1.2.6 Experience Sharing .................................................................................. 1-3
1.3 Trouble Shooting Principles ................................................................................ 1-4
1.4 Common Trouble Shooting Method ..................................................................... 1-4
1.4.1 Alarm Information Analysis ....................................................................... 1-4
1.4.2 Indicator Status Check.............................................................................. 1-5
1.4.3 Signaling Tracing Analysis ........................................................................ 1-5
1.4.4 Performance Analysis............................................................................... 1-5
1.4.5 Operation Log Query ................................................................................ 1-6
1.4.6 Instrument and Meter Analysis .................................................................. 1-6
1.4.7 Testing and Self-Looping .......................................................................... 1-6
1.4.8 Plugging/Unplugging and Pressing ............................................................ 1-7
1.4.9 Configuration Analysis and Modification..................................................... 1-7
1.4.10 Comparison and Replacement ................................................................ 1-7
1.5 ZTE CORPORATION Technical Support .............................................................. 1-8
1.5.1 ZTE CORPORATION Technical Support Method ........................................ 1-8
Chapter 2 Analysis and Trouble Shooting of Operation and

Maintenance Fault.................................................................................. 2-1
2.1 Abnormal Display on Client Interface ................................................................... 2-1
2.2 NM Server unable to Start as Normal .................................................................. 2-2
2.3 NM Server FTP unable to Start ........................................................................... 2-2
2.4 Inconsistent Configuration Data between ZXWR RNC and NM.............................. 2-3
2.5 Inconsistent Status Data between NM and RNC................................................... 2-4
2.6 Different Alarming Time at ZXWR RNC and NM ................................................... 2-5
Chapter 3 Analysis and Trouble Shooting of Hardware Fault................ 3-1

I
3.1 Overview to Hardware Fault................................................................................ 3-1

3.1.1 Clock Fault .............................................................................................. 3-1
3.1.2 Link Fault................................................................................................. 3-3
3.1.3 Startup Fault ............................................................................................ 3-5
3.1.4 Ethernet Communication Fault .................................................................. 3-5
3.2 Typical Hardware Faults ..................................................................................... 3-7
3.2.1 Clock Output without Clock ....................................................................... 3-7
3.2.2 Boards Ethernet Channel Fault................................................................. 3-8
3.2.3 ROMB Hardware Startup Fault.................................................................. 3-9
3.2.4 Communication Fault between ROMB and NM........................................... 3-9
3.2.5 RCB Hardware Startup Fault................................................................... 3-10
3.2.6 Board Hardware Startup Fault ................................................................. 3-10
3.2.7 Board Fiber Communication Fault ............................................................3-11
3.2.8 UIMC or UIMU Ethernet Port Communication Fault ...................................3-11
3.2.9 Rack Fan Startup Fault ........................................................................... 3-12
3.2.10 Fault of CLKG/ICMG/ICM Failing to Lock Clock Base Extracted by
Optical Interface.................................................................................... 3-12
3.2.11 Fault of E1 Communication link Slip Code at Node B Side....................... 3-13
Chapter 4 Analysis and Trouble Shooting of System

Communication Fault ............................................................................ 4-1
4.1 Communication Faults at IU/IUR Interface ........................................................... 4-1
4.1.1 Overview to Communication Fault at IU/IUR Interface................................. 4-1
4.1.2 Typical Communication Faults at IU/IUR Interface ...................................... 4-4
4.2 Communication Faults at IUB Interface .............................................................. 4-14
4.2.1 Overview to Communication Fault at IUB Interface ................................... 4-14
4.2.2 Typical Communication Faults at IUB Interface......................................... 4-16
4.3 NM Alarm ........................................................................................................ 4-21
4.3.1 SSCOP Link No Message Response for a Long Time............................... 4-21
4.3.2 SSCOP Link Congested Alarm................................................................ 4-22
4.3.3 SSCOP Link Overload Alarm .................................................................. 4-22
4.3.4 Abnormal Status of No. 7 Link................................................................. 4-22
4.3.5 Unreachable Alarm of Signaling Point...................................................... 4-26
4.3.6 Sccp Subsystem Unavailable Alarm ........................................................ 4-26
4.3.7 NCP Link Fault Alarm ............................................................................. 4-27
4.3.8 CCP Link Fault Alarm ............................................................................. 4-28
4.3.9 SSM Association Setup Failure ............................................................... 4-28
4.3.10 SSM Association Broken-link Alarm ....................................................... 4-28
4.3.11 SSM Association Congested Alarm........................................................ 4-29
II
4.3.12 M3ua Office Unreachable...................................................................... 4-29
Chapter 5 Analysis and Trouble Shooting of Software Installation

Fault......................................................................................................... 5-1
5.1 Overview to Software Loading Fault .................................................................... 5-1
5.2 Typical Software Installation Faults...................................................................... 5-3
5.2.1 ROMP Reboots Once All-table Synchronization Made ................................ 5-3
5.2.2 FPGA Version Unable to Switch ................................................................ 5-3
5.2.3 302 Returned when Version Downloaded to RNC....................................... 5-4
5.2.4 1424 Returned before Version Switched to RNC ........................................ 5-4
5.2.5 1402 Returned before Defaulted/Designated Version Switched to RNC ....... 5-4
5.2.6 FTP Failure, Please Check Whether FTP at the Server is Normal or not
and Please Check Whether the Network is Normal or Not.......................... 5-5
5.2.7 Precautions when Downloading Versions from Non-Server ......................... 5-5
Chapter 6 Analysis and Trouble Shooting of Handover Fault................ 6-1

6.1 Overview to Handover Fault ............................................................................... 6-1
6.2 Handover Troubleshooting Types ........................................................................ 6-2
6.2.1 UE Unable to Report Measurement Report ................................................ 6-2
6.2.2 ZXWR RNC Judgment Fault (False Fault).................................................. 6-3
6.2.3 Handover Process Failure......................................................................... 6-4
6.3 Typical Handover Faults ..................................................................................... 6-5
6.3.1 Unable to Trigger Inter-Frequency Blind Handover ..................................... 6-5
6.3.2 Physical Channel Re-allocation Failure of Inter-Frequency Handover .......... 6-6
6.3.3 Impossible Cross-Iur Interface Soft Handover ............................................ 6-6
6.3.4 Quite Low Handover Success Rate (1) ...................................................... 6-7
6.3.5 Quite Low Handover Success Rate (2) ...................................................... 6-8
Chapter 7 Analysis and Trouble Shooting of Radio Load Fault............. 7-1

7.1 Overview to Radio Load Fault ............................................................................. 7-1
7.2 Typical Radio Load Faults................................................................................... 7-2
7.2.1 All Calls in a Cell Rejected ........................................................................ 7-2
7.2.2 Users Requests Frequently Rejected ........................................................ 7-2
7.2.3 Cell Load Always High.............................................................................. 7-3
7.2.4 Ping Packet Failed ................................................................................... 7-4
7.2.5 Poor QoS of User Services ....................................................................... 7-5
7.2.6 Imbalanced Load between HCS Cells........................................................ 7-6
7.2.7 Impossible Service Establishment due to Incorrect Setting of Cell Status ..... 7-7
7.2.8 Low Access Rate due to Radio Configuration Data Modification Error.......... 7-7
7.2.9 Service Interruption due to Cell NCP Link Fault .......................................... 7-8
III
7.2.10 Service Operation Impossible Caused by Mobile Station Problem ............. 7-9
7.2.11 Very Poor QoS of PS Service Caused by Data Line Fault........................ 7-10
7.2.12 Service Interruption Caused by Network Node Fault ............................... 7-10
7.2.13 Common Channel Congestion Caused by Lots of SMs Sent in
Centralized Way ....................................................................................7-11
7.2.14 Always-High Cell Load Caused by TRX Fault ..........................................7-11
7.2.15 Serious Uplink Interference Caused by Irrational Floor Noise
Configuration ........................................................................................ 7-12
Chapter 8 Analysis and Trouble Shooting of Access Fault.................... 8-1

8.1 Overview to Access Fault.................................................................................... 8-1
8.2 Typical Access Faults ......................................................................................... 8-1
8.2.1 Mobile Terminal Does Not Originate RRC Connection Process.................... 8-1
8.2.2 RNC Equipment Unable to Receive RRC Connection Establishment
Process from Mobile Terminal .................................................................. 8-3
8.2.3 RNC Equipment Having Insufficient Resources to Establish RRC
Connection for Mobile Terminal ................................................................ 8-3
8.2.4 Iu Interface Communication Links between RNC Equipment and CN
Equipment are Blocked ........................................................................... 8-5
Chapter 9 Analysis and Trouble Shooting of Radio Service Bearer

Fault......................................................................................................... 9-1
9.1 Overview to Radio Service Bearer Fault............................................................... 9-1
9.2 Typical Radio Service Bearer Faults .................................................................... 9-1
9.2.1 CS Domain Service Iu Interface Bearer Establishment Failure..................... 9-1
9.2.2 PS Domain Service Iu Interface Bearer Establishment Failure..................... 9-2
9.2.3 Service Iub Interface Bearer Establishment Failure..................................... 9-2
9.2.4 Service Uu Interface Bearer Establishment Failure ..................................... 9-2
9.2.5 QoS of PS Domain Services Failing to Meet Upper-layer Service
Requirements ......................................................................................... 9-3
Chapter 10 Analysis and Trouble Shooting of Radio Global

Resource Fault ..................................................................................... 10-1
10.1 Overview to Radio Global Resource Fault ........................................................ 10-1
10.2 Typical Radio Global Resource Faults.............................................................. 10-1
10.2.1 Cell Fault ............................................................................................. 10-1
10.2.2 Common Channel Fault ........................................................................ 10-2
10.2.3 System Information Broadcast Failure.................................................... 10-4
10.2.4 Iub Interface Public Measurement Fault ................................................. 10-5
10.2.5 Iu Overload Control Failure ................................................................... 10-6
Chapter 11 Trouble Shooting Record Table ........................................... 11-1

IV
11.1 Trouble Shooting Record Tables .......................................................................11-1
Chapter 12 Board and Part Replacement............................................... 12-1

12.1 Overview to Board and Part Replacement........................................................ 12-1
12.2 Board Replacement........................................................................................ 12-1
12.3 Part Replacement........................................................................................... 12-2
12.4 Small Fan Shelf Replacement ......................................................................... 12-4
12.5 Optical Module Replacement .......................................................................... 12-4
12.6 BOOT ROM Replacement............................................................................... 12-5
12.7 M/S Switchover .............................................................................................. 12-5
12.8 Board Reset................................................................................................... 12-5
Chapter 13 Running Information Description........................................ 13-1

13.1 Overview to Running Information..................................................................... 13-1
13.2 Indicator Control Rule ..................................................................................... 13-2
13.2.1 Board Power-on ................................................................................... 13-2
13.2.2 Hardware Reset ................................................................................... 13-2
13.2.3 ENUM Indicator.................................................................................... 13-3
13.2.4 ACT Indicator ....................................................................................... 13-4
13.2.5 Combination of RUN and ALM Indicators ............................................... 13-4
13.2.6 Special Board Indicators ....................................................................... 13-5
13.2.7 Status and Implementation of Indicators in BOOT..................................13-15
13.2.8 Fault Alarm Indicator............................................................................13-16
13.2.9 CLKG/ICMG/ICM Indicator...................................................................13-16
13.2.10 Panel Indicators.................................................................................13-21
13.2.11 PWRD Indicator.................................................................................13-22
13.2.12 Indicator for Clock Loss......................................................................13-23
Figures............................................................................................................. I
Tables ............................................................................................................ III
Glossary .........................................................................................................V
VI
Preface
Purpose
Thank you very much for choosing the UMTS wireless access system of ZTE Coporation
The UMTS wireless access system of ZTE is a 3G mobile communication system
developed on a basis of the UMTS technology. It features strong capability in CS and
PS service processing and provides diversified services. Compared with GSM, UMTS
delivers a wider range of telecommunication services, including such multimedia services
as voice, data, and image transmission, with higher rate and resource utilization ratio.
ZXWR RNC, a new generation radio network controller in the ZTE UMTS V3 family,
delivers functions of system access control, security mode control, mobility management,
and radio resource management and control, etc.
ZXWR RNC provides all the functions defined in the 3GPP R99/R4/R5/R6/R7 protocol,
and offers Iu, Iub, and Iur series standard interfaces, which enable it to connect with CNs,
RNCs, and Node Bs from different manufacturers.
Developed on a basis of ZTE all IP unified hardware platform, ZXWR RNC features
a distributed design, separating control plane and user plane as well as interface and
application. It supports ATM/IP dual protocol stack and can smoothly evolve to full IP
UTRAN.
What is in This Manual

This manual contains the following chapters:
Chapter
Summary
Chapter 1, Overview
Introduces the prerequisites for maintenance

personnel, the trouble shooting flow and common
maintenance measures during the trouble
shooting, to establish a foundation for actual
maintenance operations.
Chapter 2, Analysis and Trouble Shooting of
Introduces the fault phenomenon, causes
Operation and Maintenance Fault
and handling methods on the basis of OMC

software/hardware structure introduction.
Introduces ZXWR RNC common hardware faults.
Hardware Fault
Describes the fault phenomenon, causes and

handling methods on the basis of ZXWR RNC
hardware NM and structure introduction.
Chapter
Summary
Introduces the basic structure of system
System Communication Fault
communication, common trouble shooting

methods, and effective solutions to faults caused
by system communication.
Introduces the software load process and
Software Installation Fault
common faults during the process.
Introduces the handover process and common
Handover Fault
faults during the process.
Introduces the common faults of radio load, fault
Radio Load Fault
analysis and trouble shooting.
Introduces the classification, phenomenon and
Access Fault
internal causes of access faults, and lists on-site

analysis process of some typical access faults.
Introduces the classification, phenomenon and
Radio Service Bearer Fault
internal causes of radio service bearer faults,

gives fault location methods, and lists on-site
analysis process of some typical radio service
bearer faults.
Introduces the common phenomenon and causes
Radio Global Resource Fault
of ZXWR RNC radio global resource faults, and

provides effective solutions.
Appendix A, Trouble Shooting Record Table
Introduces the overall tracing and record after the

fault occurs, including fault phenomenon, type,
occurrence time and trouble shooting.
Appendix B, Board and Part Replacement
Introduces methods to replace board, part, fan

shelf, optical module and BOOT ROM, and
methods of M/S handover and board reset.
Appendix C, Running Information Description
Introduces indicator control rules during the

running of the equipment and helps users to
know equipment running status and locate faults.
II
Chapter 1
Overview
Table of Contents
Prerequisites for Maintenance Personnel ...................................................................1-1
Trouble Shooting Flow................................................................................................1-1
Trouble Shooting Principles........................................................................................1-4
Common Trouble Shooting Method ............................................................................1-4
ZTE CORPORATION Technical Support ....................................................................1-8
1.1 Prerequisites for Maintenance Personnel

1. Knowledge
l Familiar with WCDMA principle and relative professional communication
knowledge
l Familiar with the related signaling protocols, such as, broadband/narrowband No.
7 signaling
l Familiar with the related communication protocol, such as, ATM, TCP/IP
l Familiar with the product knowledge, such as, ZXWR RNC basic structure, calling
flow, and service flow
2. System networking and operation surroundings
l Thorough understanding of networking with ZTEs products
l Understanding of hardware structure of ZXWR RNC system
l Understanding of performance parameters of ZXWR RNC system
l Understanding of the operation and data configuration rules of ZXWR OMC NMS
l Understanding of network hierarchy of transmission equipments.
3. Equipment operation
l Familiar with the basic operations of PC
l Familiar with the routine operations of ZXWR OMC NMS
l Knowing what operations may cause the interruption of some or all services
l Knowing what operations may cause the damages to the equipment
l Familiar with the emergent and backup measures.
4. Using the meters and instruments
l Quick fault location ability using test cell phone and signaling analyzer.
1.2 Trouble Shooting Flow

Generally, the trouble shooting flow consists of six steps: Information collection, fault
analysis, fault location, fault elimination, fault recording and experience sharing.
1-1
SJ-20100603155704-010|2011-11-22(R1.2)
ZTE Proprietary and Confidential
ZXWR RNC Trouble Shooting
The typical trouble shooting flow is as shown in Figure 1-1.

Figure 1-1 TROUBLE SHOOTING FLOW
1.2.1 Information Collection

Obtaining the fault information is the first step in trouble shooting. There are 4 ways to get
the fault information:
l
l
l
l
Fault complaints from user or customer centre

Traffic statistic index analysis
Alarm output of alarm system
Abnormality discovered in routine maintenance of patrol inspection
The maintenance personnel had better fill in Trouble Shooting Record Tables to note down
the fault phenomena for those confirmed faults in time.
1.2.2 Fault Analysis

When a fault occurs, maintenance personnel should analyze the fault based on fault
symptoms first.
1-2
SJ-20100603155704-010|2011-11-22(R1.2)
Chapter 1 Overview
In this manual, common faults fall into the following types:

l
l
l
l
l
l
l
l
l
OMC fault
Hardware fault
System communication fault
Software loading fault
Handover fault
Radio load fault
Access fault
Radio service bearer fault
Radio global resource fault
Maintenance personnel can analyze fault causes according to fault symptoms.
1.2.3 Fault Location

Fault location is the process to find out one cause from all possible causes. The
maintenance personnel can exclude the impossible factors and confirm the actual cause
by analyzing and comparing various possible causes with a certain method or measure.
The correct fault location requires experiences and knowledge.
1.2.4 Fault Elimination

Fault elimination is the process to clear the fault and recover system with proper measures
or steps. For example, line check, board replacement, configuration data modification,
system switchover, and board reset. During the trouble shooting, strictly follow the
measures and steps specified in operation manual or maintenance manual. It must be
carried out with care and should not cause new trouble.
1.2.5 Fault Record

Maintenance personnel should record when and where a fault occurs, who troubleshoots it,
what symptoms the fault shows, and what measures are taken to clear the fault. Good fault
records can help maintenance personnel gain troubleshooting experience and shorten the
time to locate and clear a fault, and help equipment suppliers improve product and service
quality.
Refer to Appendix A, Trouble Shooting Record Table, for the template of fault record.
1.2.6 Experience Sharing

After eliminating the faults and making the fault record, the maintenance personnel should
share the debugging experience to enhance the skills of all maintenance personnel. In
addition, to improve the after-sales service and product performance optimization, they
should send the fault record to ZTE CORPORATION with email or fax in time. All these
fault records will enrich the fault maintenance instances, to find methods to improve product
quality and stability.
1-3
SJ-20100603155704-010|2011-11-22(R1.2)
1.3 Trouble Shooting Principles

When dealing with faults, besides following the trouble shooting flow, comply with the
principle of View > Query > Consider > Work.
View
First view the fault phenomena. View which part the fault occurs, what type of alarming
occurs, what is the grade of the alarm, what is the damage. From the alarm phenomena,
you can finally analyze the fault.
To view the fault, you can use multiple tools that the system provides, such as, performance
statistics, signaling tracing, alarm query, log query, and service observation.
Query
Query the on-site personnel in different phases about the fault causes. For example, does
anybody change the data? Is any files deleted? Is the circuit board replaced? Is there any
power failure, lightening or error operations?
Consider
According to the phenomena and query results, combined with your own knowledge,
consider, analyze and judge the cause of the fault.
Work
Locate the fault. Eliminate the fault by modifying the data or replacing the circuit boards,
etc.
The operation on the equipment must not be in rush time, which will cause serious results.
For more details, contact the technical engineers of ZTE Operation.
1.4 Common Trouble Shooting Method

Common trouble shooting methods are: Alarm and operation log, indicator status analysis,
signaling tracing analysis, performance analysis, instrument and meter analysis, test loop,
plugging/unplugging and pressing, configuration analysis, and replacement. If all methods
mentioned above do not help in eliminating the fault, contact ZTE CORPORATION to
troubleshoot the fault.
1.4.1 Alarm Information Analysis

Alarm information is the information that the NM alarming system outputs. The
maintenance personnel can identify the alarms by audio, light, and output on the screen.
The alarm information should be brief and clear, involving the hardware, link, trunk, and
CPU load. The alarm information is the important basis for the fault analysis and location.
1-4
SJ-20100603155704-010|2011-11-22(R1.2)
Chapter 1 Overview
Alarm information analysis helps to dins the detailed location or cause of the alarm. Since
the alarm information that OMCR alarm management system outputs is abundant and
overall, it can directly locate the fault or help other methods to locate the fault.
The alarms that OMCR generates can highly locate the fault, such as, locating to each
signaling link.
If there are several alarms occurring on the alarm console, deal with the alarm with higher
severity and finally deal with the event alarm.
1.4.2 Indicator Status Check

The purpose of indicator status check is to locate faults by checking the status of indicators
on board panels.
There are running status indicators on each board of ZXWR RNC. Some boards have
functional indicators. These indicators can reflect the working status of the corresponding
boards, and most of them even can reflect the working status of links, optical paths,
nodes, channels, and active and standby modes. Indictor status check is important in
fault analysis and location.
Indicator status check generally can not provide enough information for trouble shooting,
so it is often used along with alarm analysis.
Furthermore, when a board is powered on, it will run a self test, during which the indicators
on it flash regularly. By checking these indicators, maintenance personnel can judge
whether the board is normal.
1.4.3 Signaling Tracing Analysis

The signaling tracing is mostly applicable to finding the failure cause in the user calling
analysis and inter-office signaling cooperation. With the tracing results, the maintenance
personnel can directly get the cause of the call failure and finds the sticking point of the
problem. Or, they can get some ideas from the results, providing a precious help for the
future analysis.
ZXWR RNC provides abundant signaling tracing methods.
1.4.4 Performance Analysis

Performance analysis is made through the performance management interface of ZXWR
OMC. Maintenance personnel can manage the system performance through the interface.
ZXWR provides tools for measuring the traffic performance indices and major KPIs of
the system. Performance measurement tools are often used along with signaling tracing,
playing an important role in finding inter-office signaling interaction failures and incorrect
relay parameter settings.
The performance management interface helps users create performance measurement
tasks, obtain performance reports, and assess the performance indices of the ZXWR RNC
1-5
SJ-20100603155704-010|2011-11-22(R1.2)
system. By analyzing the information, maintenance personnel assess the load allocation
in the network and adjust parameters in time to improve network performance.
1.4.5 Operation Log Query

RNC data configurations are complicated and sometimes faults occur due to negligence.
In this case, it is needed to query data configurations.
ZXWR OMCR provides the log query function.
performed.
The logs record all the operations
1.4.6 Instrument and Meter Analysis

During ZXWR RNC maintenance, the maintenance personnel can analyze, locate, and
eliminate the faults with auxiliary instruments, such as, test MS, signaling analyzer and
BER analyzer.
1.4.7 Testing and Self-Looping

1. Test
Testing is to measure the technical parameters of user lines, transmission channels,
and trunk devices by using instruments, meters, and software measurement tools. The
measurement results can help users judge whether such lines, channels, or devices
are faulty or almost faulty.
2. Self-looping
Self-looping is to perform a self-transceiving test to a piece of transmission equipment
or transmission channel through hardware or software. By checking whether
the transmission equipment, transmission channel, service status, and signaling
interaction are normal after the self-looping, users can know whether the hardware
equipment status and software parameter settings are normal. Self-looping is
commonly used to check whether transmission and trunk parameters are set correctly.
Testing and self-looping are often used together. Self-looping falls into software
self-looping and hardware self-looping. Software self-looping is easy and flexible to use,
but is less reliable than hardware self-looping. Moreover, in new site commissioning and
trunk capacity expansion, the trunk self-looping is often used to check whether the trunk
parameters in the local office and the outgoing routing data is set correctly.
Note
Software self-looping should be stopped as soon as the troubleshooting completes. To
avoid forgetting this, maintenance personnel should always keep maintenance records.
1-6
SJ-20100603155704-010|2011-11-22(R1.2)
Chapter 1 Overview
1.4.8 Plugging/Unplugging and Pressing

If the fault exist in a board, loosen the fixation screws on the front panel of the board
and plug/unplug the board and external interface connectors. This method removes faults
caused by poor contacts or processor faults.
Pressing the cable connectors after power-off, also helps in eliminating the fault due to
insecure contact.
When plugging/unplugging the board, strictly comply with the operation rules. Otherwise,
it may cause the damages on the board or other problems.
1.4.9 Configuration Analysis and Modification

The configured data decides the working and cooperation mode of the system. Usually,
the data can not be modified.
In some special cases, such as, the surrounding change or the mis-operation may cause
the damages or change on he configuration data, thus causing the service interruption.
If the fault has been located to the local system, locate the fault by querying or analyzing
the current configuration data. For the mis-operation on NM, locate the fault by viewing
the user operation log.
The configurations that can be modified include the time slot, slot, board parameter, and
protocol type. Therefore, the configuration modification is applicable to eliminating the fault
caused by the mis-configuration after the fault is located to a site.
For example, the signaling link of a certain office is abnormal and it affects the signaling
transmitted on this link, and thus affecting the services related to this link. Modify the
following data:
l
l
Modifying the signaling route. The new route does not use the signaling link to this
office. If the alarm disappears, the fault is related to the previous route.
Modifying the signaling link group. The new link group does not use the signaling
link to this office. If the fault disappears, the fault is related to the previous link group.
During the update and expansion, if the new configuration is doubted faulty, send the
previous configuration to locate whether the fault is on the configuration.
When the fault can not be located to the board by modifying the time slot, locate the fault
with the replacement method.
The configuration data modification requires a lot for the maintenance personnel. Only
those who are very familiar with the equipment and who are very experienced can modify
the configuration data.
1.4.10 Comparison and Replacement

Compare a possible faulty board with a normal board in the similar position in the system
(for example, a board in the same slot in a multi-module system) for running status, jumpers
and connection cables.
1-7
SJ-20100603155704-010|2011-11-22(R1.2)
Replacing a possible faulty board with a spare board or another normally-running board of
the same type helps in detecting the fault location. Observe that, the fault disappears or not
after the replacement of the board and judge whether the board is faulty or not. Whether
comparison or replacement method is adopted, it should be noted that a board must be
pulled out or inserted in accordance with the related description in Trouble Shooting Record
Tables.
1.5 ZTE CORPORATION Technical Support

1.5.1 ZTE CORPORATION Technical Support Method
ZTE CORPORATION provides 7x24 hours continuous technical support services. Contact
ZTE technical support staffs at any time in the ways as shown below. The contacting ways
are sequenced by following their priorities:
1. Contact ZTE local office directly.
2. Dial ZTE free line: 800-830-1118 or technical service hotline 0755-26770800.
3. Fax to 0755-26770801.
4. Email to ZTE technical support mailbox: 800@zte.com.cn.
5. Log in ZTE technical support website: http://support.zte.com.cn.
1-8
SJ-20100603155704-010|2011-11-22(R1.2)
Chapter 2
Analysis and Trouble

Shooting of Operation
and Maintenance Fault
Table of Contents
Abnormal Display on Client Interface..........................................................................2-1
NM Server unable to Start as Normal .........................................................................2-2
NM Server FTP unable to Start ..................................................................................2-2
Inconsistent Configuration Data between ZXWR RNC and NM ..................................2-3
Inconsistent Status Data between NM and RNC.........................................................2-4
Different Alarming Time at ZXWR RNC and NM .........................................................2-5
2.1 Abnormal Display on Client Interface

Fault phenomena
The client operating interface is not fully displayed, and the pop-up window or dialogue
box oversteps the display area on screen.
Fault cause analysis

Since the NM client interface is designed on 1024 768 pixel display resolutions.
Therefore, if the display resolutions set by the user is 800 600 pixel, the pop-up window
on NM interface oversteps the display area of screen partially.
Trouble shooting
Right-click the desktop of client and select Property. Property dialogue box pops up. Select
Setting label and set the screen area as 1024 768 pixel.
Cautions
None.
2-1
SJ-20100603155704-010|2011-11-22(R1.2)
2.2 NM Server unable to Start as Normal

Fault phenomena
NM Server does not start as normal and the Client cannot connect to NM Server.

Oracle database connection may not be normal, or the properties file configuration of
Server is not correct.
Trouble shooting
1. Check whether Oracle Client connection is created. Run oracle enterprise console and
check whether it has SID_*.*.*.* connection establishment.
2. Check whether the configuration of the database connection in $\ums-svr\deploy-defa
ult.properties file under NM server installation directory is correct.
Cautions
None.
2.3 NM Server FTP unable to Start

Fault phenomena
NM Server does not start as normal and the FTP fails in startup.

The port required for FTP startup is occupied by FTP software of the third party.
Trouble shooting
1. Check all started processes to see whether any process occupies FTP port. If so, exit
from the process and restart the server.
2. Check all services of OS to see whether any process occupies FTP port. If so, exit
from the process and restart the server.
Cautions
None.
2-2
SJ-20100603155704-010|2011-11-22(R1.2)
Chapter 2 Analysis and Trouble Shooting of Operation and Maintenance Fault
2.4 Inconsistent Configuration Data between ZXWR

RNC and NM
Fault phenomena
The configuration data displayed at NM Client is inconsistent with that on ZXWR RNC.

The configuration data modified at NM is not timely synchronized with ZXWR RNC.
Trouble shooting
Perform alltables synchronization to synchronize configuration data on NM with ZXWR
RNC.
The detailed steps are as follows:
1. Confirm the correctness of NM configuration data.
2. On Configuration Resource Tree, choose ZXWR RNC to synchronize and click
to perform the all tables synchronization.
Figure 2-1 SELECTING ALL TABLES SYNCHRONIZATION
Cautions
The whole table synchronization operation may restart ZXWR RNC ROMB board. Decide
to use it on actual situations.
2-3
SJ-20100603155704-010|2011-11-22(R1.2)
2.5 Inconsistent Status Data between NM and RNC

Fault phenomena
The board status on the rack diagram displayed at NM Client is inconsistent with that on
ZXWR RNC.

The status data of the foreground and background is inconsistent.
Trouble shooting
Perform status synchronization operation to synchronize status data between foreground
and background.
The detailed steps are as follows:
1. Start NM client.
2. On Configuration Resource Tree, select UTRAN SubNetwork > RNC Managed
Element > RNC Config Set > RNC Ground Resource Management > Rack node.
Double-click the Rack node to open the rack diagram.
3. Right-click on the rack diagram, select Refresh Rack on the popup shortcut menu.
The NM system will update the foreground status data automatically.
2-4
SJ-20100603155704-010|2011-11-22(R1.2)
Chapter 2 Analysis and Trouble Shooting of Operation and Maintenance Fault
Figure 2-2 Refresh Rack
Cautions
None
2.6 Different Alarming Time at ZXWR RNC and NM

Fault phenomena
The alarming time displayed on Client interface is different from the actual alarming time
reported by ZXWR RNC.

Inconsistent clocks at ZXWR RNC and NM.
Trouble shooting
Synchronize the clocks.
Detailed steps are as below:
1. Start NM Client.
2. On the Configuration Resource Tree, open the RNC Managed Element > RNC
config set > RNC ground resource management node.
2-5
SJ-20100603155704-010|2011-11-22(R1.2)
3. Click
on toolbar to synchronize NEs clock.
Figure 2-3 SYNCHRONIZE NEs CLOCK
2-6
SJ-20100603155704-010|2011-11-22(R1.2)
Chapter 3

Shooting of Hardware Fault
Table of Contents
Overview to Hardware Fault .......................................................................................3-1
Typical Hardware Faults .............................................................................................3-7
3.1 Overview to Hardware Fault

According to different hardware elements faults, hardware faults are classified into four
types:
l
l
l
l
Clock fault
Link fault
Start fault
Ethernet communication fault
The below introduces the NM and phenomena of hardware faults mentioned above.
3.1.1 Clock Fault

3.1.1.1 Background Information
The structure of the RNC synchronous clock system is shown in Figure 3-1 and Figure 3-2.
Figure 3-1 STRUCTURE OF SYNCHRONOUS CLOCK SYSTEM (WITHOUT GPS)
3-1
SJ-20100603155704-010|2011-11-22(R1.2)
Figure 3-2 STRUCTURE OF SYNCHRONOUS CLOCK SYSTEM (WITH GPS)
The synchronous clock is generated and distributed by CLKG/ICMG/ICM, UIMC/GUIM,

and the corresponding backplanes and service boards.
ICMG provides the GPS positioning function while CLKG does not. However, ICMG does
not have those systems that are provided with reference clock by GPS.
The system reference clocks that use CLKG and ICMG are BITS clock (two channels of
2MB clocks and two channels of 2MH clocks), line clock 8 KBASE, and local oscillator 8K
clock.
The ICM board receives GPS signals and generates 1PPS signals and the corresponding
navigation messages (TOD messages). Taking 1PPS signals as the reference for phase
lockup, the board generates PP2S, 19.6608 MHz, and system 8K clock references
required by the RNC or BSC system. Compared with ICMG, GPS subcards cost much
less, making it applicable to the system that requires not much positioning information or
only requires GPS to provide reference clock sources.
The reference clock sources of the system that use the ICM board are BITS clock (two
channels of 2MB clocks and two channels of 2MH clocks), one channel of line clock (8K),
two channels of GPS 8K clocks (one is from the local board and the other is from the
external GPS), and UIM 8K clocks.
3.1.1.2 Fault Phenomena and Cause of Clock Fault

The common phenomena and causes of clock fault are as shown in Table 3-1.
Table 3-1 COMMON PHENOMENA AND CAUSE OF CLOCK FAULT
Fault Phenomena
Fault Cause Analysis
3-2
SJ-20100603155704-010|2011-11-22(R1.2)
Chapter 3 Analysis and Trouble Shooting of Hardware Fault
Check whether there are signals when inputting clock

base.
Check whether 16 M, 32 M, 8 K_16 M, and 8 K_32 M
output clock is lost.
Clock board (CLKG/ICMG/ICM) ALM
Check whether there is PP2S clock input but PP2S output
indicator is on.
clock is lost after expansion.

Check whether OCXO constant temperature trough
used by phase locked loop or degraded discrimination
is alarming.
Check whether SRAM fails in self-test.
Observe clock base selection indication to see whether
corresponding clock base has clock input.
Check whether the clock base is bad and exceeds
CLKG/ICMG/ICM capture range. Check whether the clock
networking is correct and whether phenomena on M/S
CLKG/ICMG/ICM cannot be phase
clock board are consistent. Check the current tracing
locked for a long period and CATCH
clock base to judge the clock level, which must be higher
indicator does not light; CATCH indicator
than clock board level.
is constantly on or flashing with TRACE
Check whether alarm indicator on the panel is on. Judge

whether DAC is invalid by testing and diagnosing whether
the crystal oscillator is good and by comparing several
groups tested DAC data. With condition permitting,
test TRUO50 on the board to check whether there is
something wrong.
Check whether CLKG/ICMG/ICM runs well.
Alarm for NM display UIMU/GUIM board

8K and PP2S lost.
Any problem in cable connection between RUIM1 and

RCKG1/2 clocks.
Check whether CLKG/ICMG/ICM works well
Alarm for NM display board 8 K and
Any problem in cable connection between RUIM1 and
PP2S lost.
RCKG1/2 clocks
Check whether UIMU/GUIM works well
3.1.2 Link Fault

3.1.2.1 Background Knowledge of Link Fault
ZXWR RNC is a part of UTRAN. Except for practicing voice and data link exchange, it
carries out a large amount of internal and external signaling interaction. The signaling is
sent to corresponding units via different links. Therefore, it separates communication links
as external links and internal links to describe.
3-3
SJ-20100603155704-010|2011-11-22(R1.2)
The internal link means the communication links among ZXWR RNC inner modules.
The external link means the communication links among ZXWR RNC and other external
equipments, including Iu interface, Iub interface and Iur interface link. These interfaces
are described below:
l
l
l
Iu interface: It is the interface between ZXWR RNC and CN, including Iu-CS and
Iu-PS interfaces. Iu interface performs signaling interaction and data transfer
between CN and ZXWR RNC.
Iub interface: It is the interface between ZXWR RNC and Node B and performs the
signaling interaction and data transfer between ZXWR RNC and Node B.
Iur interface: It is the interface between ZXWR RNC and ZXWR RNC and performs
the signaling interaction and data transfer intra two ZXWR RNCs.
3.1.2.2 Fault Phenomena and Cause of Link Fault

The common phenomena and causes of link fault are as shown in Table 3-2.
Table 3-2 COMMON PHENOMENA AND CAUSE OF LINK FAULT
Fault Phenomena

Check whether NM configuration is correct. The corresponding indicator is
on, indicating that the NM has been configured.
E1 link fault
Check whether link connection is correct. If the connection is correct,

the corresponding indicator will flash after butting the corresponding E1
receive/transmit lines.
Check whether long/short line toggle switch of DTB is correct
Check whether 75 and 120 toggle switches of DTB is correct
Check whether UIMU works well
E1 Link Slip
Check whether there is any problem with cable connection between

RUIM1 and RCKG1/2 clocks
Check whether the clock base clock selection of CLKG/ICMG/ICM is
proper
Check whether the phase locked of CLKG/ICMG/ICM is correct
Check whether the fiber transceiving connection is correct and whether
SD indicators of optical modules at both sides are on.
Fiber link fault
Check whether fiber is single-mode multiple fibers.

Check whether optical module is configured correctly and whether it works
normally.
3-4
SJ-20100603155704-010|2011-11-22(R1.2)
3.1.3 Startup Fault

3.1.3.1 Background Knowledge of Startup Fault
The start fault refers to the unsuccessful start-up, or board cannot be successfully
powered-on, since the connector needle on backplane is damaged.
The possible causes of such fault are as below:
l
l
l
l
l
The memory bank on sub-card does not plug well or the slot is loosened.
The BOOT or single-chip microcomputer file of board is not burned correctly.
ENUM switch is not closed well or ENUM switch does not match with the thinning
wrench.
It cannot start the small system or network processor on board successfully.
The FLASH or SDRAM chip on board is cold joint or continuously welded.
3.1.3.2 Fault Phenomena and Cause of Startup Fault

The common phenomena and causes of start fault are as shown in Table 3-3.
Table 3-3 COMMON PHENOMENA AND CAUSE OF STARTUP FAULT
Fault Phenomena

Check whether there is BOOT.
Four indicators on board

light constantly
Check whether to burn logically.

Check whether to plug the sub-card well.
Check whether BOOT burned incorrectly.
Board restarts over again
Check whether there is no version file or incorrect version file.
but obtains no imaging
Check whether the board fails in self-test.

Check whether DIP switch configuration on the backplane is correct.
ENUM indicator is constantly

on
Check whether it is ENUM switch fault.
3.1.4 Ethernet Communication Fault

3.1.4.1 Background Knowledge of Ethernet Communication Fault
Internally, ZXWR RNC system offers two sets of individual exchange planes: Control plane
and user plane, as shown in Figure 3-3. The dashed lines in figure indicate the control
plane data stream and the continuous line indicates the user plane data stream. The wide
continuous line is Giga Ethernet, and others are 100 M Ethernets.
3-5
SJ-20100603155704-010|2011-11-22(R1.2)
Figure 3-3 INNER EXCHANGING PLANES OF RNC SYSTEM
Every resource shelf has a pair of UIMU boards practicing the Ethernet exchange inside
the box and the connection with upper level exchange system, to actualize the cross-box
communication. On UIMU, it offers 2 sets of individual Ethernet exchange systems: user
plane and control plane. The Ethernet on control plane of box is converged to CHUB board
via UIMU for actualizing the connection with ROMB board. The Ethernet on user plane
converged to GLI of exchange box through UIMU for actualizing the connections with the
user planes of other boxes.
In the case that the system offers two resource shelves, the two user planes of resource
shelves may be directly connected via Giga Ethernet, as shown in Figure 3-4.
Figure 3-4 CONFIGURATIONS OF TWO RESOURCE SHELVES
ZXWR RNC system offers OMC-R and OMC-B Ethernet interfaces to external systems. It
gives separate connection to HUB with straight network cables from the back board RMPB
of ROMB and RMNIC of GIPI. It also connects to computer with cross network cable.
3.1.4.2 Fault Phenomena and Cause of Ethernet Communication Fault

The common phenomena and causes of Ethernet communication fault are as shown in
Table 3-4.
3-6
SJ-20100603155704-010|2011-11-22(R1.2)
Table 3-4 COMMON PHENOMENA AND CAUSE OF ETHERNET COMMUNICATION

FAULT
Fault Phenomena

Check whether it is HUB fault.
Check whether it is the problem in direct and cross network
cables.
Check whether the network cable connecting ZXWR RNC is
Communication between RNC and

NM failed
plugged in OMC2 interface of RMPB.

Check whether there is only one of the two back board
network cables on ZXWR RNC main/slave ROMB is
connected to HUB.
Check whether the IP configuration of ZXWR RNC/NM
OMC is correct.
Check whether UIMC/U works well.
Check whether the cable connecting control box is well
The communication link of NM display
connected.
board is broken.
Check whether CHUB control box works as normal
Check whether the toggle switch on the backplane is correct.
Check whether UIMC/U works well.
The communication link of NM display
CLKG/ICMG/ICM is broken.
Check whether CLKG/ICMG/ICM works well.

Check whether serial port selecting switch X60 on
CLKG/ICMG/ICM is set as 485 communicating mode.
Check whether the cable connection between PWRD and
ROMB is correct.
Check whether toggle address of PWRD RACK_ID toggle
PWRD communication link is broken.
switch S2 is correct.
Check whether it sets the jumper X8 on PWRD according
to actual conditions for corresponding middle node or end
node.
3.2 Typical Hardware Faults

3.2.1 Clock Output without Clock
Fault phenomena
The clock board has no clock output.
3-7
SJ-20100603155704-010|2011-11-22(R1.2)

1. If TP57 has no clock waveform output, crystal oscillator G2 must be faulty. If there is
no 8K clock output, the problem may lies in the phase-locked frequency divider EPLD.
If there is 16M clock output, but no 32M or 64M clock, TRU050 is possibly damaged.
2. Another possible reason is that the clock board is in standby mode, in which the
board will disable the LVDS output. The fault can also occur when the single-chip
microcomputer is in rosin joint or its program is burned incorrectly.
Trouble shooting
If the chip is damaged, replace it and check whether it works normally. If there is a rosin
joint, solder it again.
Cautions
If the central frequency of the crystal oscillator exceeds 16.384 MHz 2 Hz, it should
be adjusted. Otherwise, the crystal oscillator will be damaged. If the OV_MON and
OV_MON_Q pins are in high level, it means that the crystal oscillator is normal.
3.2.2 Boards Ethernet Channel Fault

Fault phenomena
Board (including RCB, GIPI, EIPI (E1 IP Interface Board), RUB, APBE, IMAB, DTB, SDTA,
SDTB, CHUB, THUB, ET3A (E3 ATM Interface Board), ET3I (E3 IP Interface Board), and
POSI) off-line alarm.

May be on the board Ethernet channel.
Trouble shooting
1. Unplug and plug the board memory bank to check whether the board and the
backplane are in good contact.
2. Check whether LINK flashing light and whether Lx (x: 1~4(6) flashing light
corresponding to CHUB/THUB on Ethernet exchange board (UIMC, UIMU) in rack
frame are normal (lighting means connected). Change relative board if necessary.
Cautions
None
3-8
SJ-20100603155704-010|2011-11-22(R1.2)
3.2.3 ROMB Hardware Startup Fault

Fault phenomena
The board panel indicator is not in operating status all along and there is the ZXWR
RNC/NM link broken alarm.

ROMB board is not started as normal. It might be the problem with memory bank or
harddisk.
Trouble shooting
1. Unplug and plug the ROMB board memory bank again.
2. Replace the memory bank if ROMB board is still unable to start as normal after pulling
and plugging the memory bank.
3. Replace the ROMB board hard disk if the board is still unable to start after change
ROMB board memory bank.
4. If the board is still unable to start as normal after replacing ROMB memory bank and
hard disk replace ROMB.
Cautions
For the replacement methods of boards and parts, refer to Board and Part Replacement.
For the meaning of flashing light, refer to Running Information Description.
3.2.4 Communication Fault between ROMB and NM

Fault phenomena
RUN indicator on board panel is in normal status but there are still ZXWR RNC/NM
broken-link alarm reported.

Ethernet link between ROMB and NM goes error or the board goes error.
Trouble shooting
1. Check whether the contact of board Ethernet plugging components is well.
2. Check whether Ethernet switching board inside the shelf is normal, whether the
network connection between ROMB and NM is normal.
3. Replace ROMB.
3-9
SJ-20100603155704-010|2011-11-22(R1.2)
Cautions
Do use the straight cable to connect ROMB with NMS.
3.2.5 RCB Hardware Startup Fault

Fault phenomena
The RUN indicator on RCB panel is not in running status (running status: RUN is flashing
slowly) and the alarm of RCB off-line occurs.

The startup of RCB is abnormal, which might result from memory error.
Trouble shooting
1. Unplug and plug again the memory bank of RCB, to check whether its contact is good.
2. Replace the memory bank of RCB, to check whether the memory bank is damaged.
3. Replace RCB.
Cautions
For the meaning of flashing light, refer to Running Information Description.
3.2.6 Board Hardware Startup Fault

Fault phenomena
The indicator on board (including RCB, GIPI, EIPI, RUB, APBE, IMAB, DTB, SDTA, SDTB,
CHUB, THUB, ET3A, ET3I, and POSI) panels is not in running status and the alarm of
board off-line occurs.

The board cannot run normally, which might result from BOOT ROM file burning or the
board hardware error.
1. Replace the BOOT ROM on the board.
2. Replace the board.
Trouble shooting
Cautions
For the replacement methods of BOOT ROM on the board, refer to BOOT ROM
Replacement.
3-10
SJ-20100603155704-010|2011-11-22(R1.2)
3.2.7 Board Fiber Communication Fault

Fault phenomena
The optical interface indicator on one or more boards (including GLI, UIMU, APBE, and
SDTA) is out and the NMS shows that the ATM communication link is faulty.

The problem lies in the board or the fiber it connects with.
Trouble shooting
1. Replace the fiber.
2. Replace the optical module. Make sure that it is in the same model as that at the peer
end, and that it is supported at the local end.
3. Replace the board.
Cautions
For how to replace boards and parts, refer to Appendix B, Board and Part Replacement.
3.2.8 UIMC or UIMU Ethernet Port Communication Fault

Fault phenomena
The alarm of board off-line occurs on all or some of boards with Ethernet channels
(including RCB, GIPI, EIPI, RUB, APBE, IMAB, DTB, SDTB, SDTA, ET3A, ET3I, and
POSI).

UIMC or UIMU.
Trouble shooting
1. Perform main/slave UIMC/UIMU changeover.
2. If the board still works abnormally after the reset, replace the board.
Cautions
3-11
SJ-20100603155704-010|2011-11-22(R1.2)
3.2.9 Rack Fan Startup Fault

Fault phenomena
One or more rack fans fail to start.

1. The fan fails.
2. The backplane of the fan is faulty.
3. The power supply to the fan backplane is faulty.
Trouble shooting
Check the power supply and the fan. Replace the fan if necessary.
Cautions
The system supports fan hot-plugging. For how to replace a fan subrack, refer to Appendix
B.4, Replacing a Fan Subrack.
3.2.10 Fault of CLKG/ICMG/ICM Failing to Lock Clock Base

Extracted by Optical Interface
Fault phenomena
CLKG/ICMG/ICM cannot lock the clock base extracted by optical interface.

1. CN clock has poor precision, so ZXWR RNC CLKG/ICMG/ICM may fail to lock because
of the worse inputted clock base.
2. CN does not send clock to ZXWR RNC, which may cause from cable connection error
or NM data configuration error.
3. CLKG/ICMG/ICM has improperly burned single-chip computer program and logical
file.
4. Clock cable fault.
Trouble shooting
1. Check whether RGIM1 of APBE is in proper position, and check whether the clock
base line CLK-004 is available and connected from 8 K OUT of RGIM1 to the clock
input end 8 K IN on RCKG1 of CLKG/ICMG.
2. Check whether the settings of clock extraction on ZXWR RNC NM are correct.
3. Check whether CLKG/ICMG/ICM has properly burned single-chip computer program
and logical file.
3-12
SJ-20100603155704-010|2011-11-22(R1.2)
4. Check the other end of the optical fiber, connecting to APBE optical interface. That is,
the rack frame where CN interface board is. Check whether the board has clock base,
that is, CN high-precision clock is sent to ZXWR RNC. Ensure that CN clock board
has the clock cable distributing clock base to CN optical interface board.
5. Check the configuration of the APBE board and the optical port for extracting clock
signal.
Cautions
None.
3.2.11 Fault of E1 Communication link Slip Code at Node B Side

Fault phenomenon
The communication link at Node B, connected with ZXWR RNC via E1 line, creates the
slip code alarm.

1. Node B does not retain ZXWR RNC high-precision clock from E1 line as its own clock
base. The asynchronous clock causes the slip code.
2. There is no CLKG/ICMG/ICM board inside ZXWR RNC system.
3. ZXWR RNC has CLKG/ICMG/ICM but is not operating well, or it is not sent to the UIMU
in rack frame, where E1 interface board is with clock distributing cable CLK-003.
4. Clock input clock base of ZXWR RNC system is poor and CLKG/ICMG/ICM is in
capture or quality degradation mode.
Trouble shooting
1. Check whether Node B system is extracting the clock on E1 line as clock base input
for its own CLKG, or it adopts the independent clock. Ensure that Node B clock is
synchronizing ZXWR RNC clock.
2. Check whether E1 interface board DTB of ZXWR RNC selects CLKG/ICMG/ICM clock,
that is, the clock is distributed to all slots in rack frame via UIMU. Ensure the connection
of CLK-003 cable is correct.
3. Check whether CLKG/ICMG/ICM operation is normal. Measure the 8K clock precision
inputted by DTB/APBE with frequency meter to see whether it is within 15 ppm range.
4. Check the clock extraction source of CLKG/ICMG/ICM to make sure it is extracted from
CN. Avoid send the clock extracted from Node B to Node B after the synchronization.
Cautions
None.
3-13
SJ-20100603155704-010|2011-11-22(R1.2)
This page intentionally left blank.
3-14
SJ-20100603155704-010|2011-11-22(R1.2)
Chapter 4

Shooting of System
Communication Fault
Table of Contents
Communication Faults at IU/IUR Interface..................................................................4-1
Communication Faults at IUB Interface ....................................................................4-14
NM Alarm .................................................................................................................4-21
4.1 Communication Faults at IU/IUR Interface

4.1.1 Overview to Communication Fault at IU/IUR Interface
Background Knowledge
At IU/IUR interface, ZXWR RNC connects with CN, or connects with the adjacent ZXWR
RNC through No.7 signaling, and the corresponding link is called as No.7 signaling link.
When IU/IUR interface uses ATM transmission, No.7 link is borne on SSCOP link. When
IU/IUR interface uses IP transmission, No,7 link is borne on the association.
1. Signaling path in ATM mode
The words in the brackets are the name of the board where the protocol layer locates.
Figure 4-1 IU/IUR INTERFACE RADIO NETWORK LAYER CONTROL PLANE
SERVICE FLOW IN ATM MODE
4-1
SJ-20100603155704-010|2011-11-22(R1.2)
2. Signaling path in IP mode

SERVICE FLOW IN IP MODE
Fault Description
l
l
l
l
l
l
No response after CR message being sent

Peer subsystem unavailable
Peer office inaccessible
No.7 link disconnected
Association disconnected
Association connected but ASP inactivated
Trouble shooting flow

Taking IP transmission mode as example, the common trouble shooting flow for IU/IUR
interface communication faults is as shown in Figure 4-3.
4-2
SJ-20100603155704-010|2011-11-22(R1.2)
Chapter 4 Analysis and Trouble Shooting of System Communication Fault
Figure 4-3 IU/IUR INTERFACE COMMUNICATION FAULT TROUBLE SHOOTING FLOW
Trouble shooting steps

1. Check the physical connection to see whether the abnormality at IU/IUR interface is
caused by the cable connection. Especially, check the cable connection on IP interface
board.
2. Check the data configuration related to IU/IUR interface on ZXWR RNC.
l Adjacent office configuration
l Port IP address configuration
l SIGTRAN data configuration.
3. Check whether the status of SMP that manages the association module is normal and
whether GIPI status is normal. Check whether there are related alarm.
4. Activate/De-activate the association with the dynamic data management provided by
NM and then check whether the alarm disappears.
5. Locate the fault with the alarm provided by NM steps by steps according to the protocol
layers. Minimize the range and eliminate the fault.
If after trying all above methods, the fault still exists. If conditions allow, reboot GIPI, SMP,
and OMP to see whether the fault can recover.
4-3
SJ-20100603155704-010|2011-11-22(R1.2)
4.1.2 Typical Communication Faults at IU/IUR Interface

4.1.2.1 SCCP Layer No Response after CR Message being Sent
Fault phenomena
Throughout the signaling tracing, find that there is no response after CR message in SCCP
layer is sent.

1. Office is disconnected.
2. Subsystem is unavailable.
Trouble shooting
Note
The above SGSN is only an example. Users can select the office as required.
1. Office is disconnected
Check whether the adjacent office is connected. Choose RNC Config Set >
RNC Equipment resource management > Transmission Configuration > NE
Information Configuration > SGSN and choose Adjacent Office Singalling
Configuration > State Information to check the status of the adjacent office. If the
adjacent office is inaccessible, check whether the downward signaling link under this
office is available.
2. Subsystem is unavailable
If the sybsystem is unavailable, Sccp subsystem unavailable alarm appears on OMCR
alarm interface. Check whether the adjacent office is accessible, refer to the above. If
the adjacent office is accessible, select View > RNC Signal Trace to open the signaling
tracing tool. On the tracing signaling tool, select New Task TNL.
4-4
SJ-20100603155704-010|2011-11-22(R1.2)
Figure 4-4 USING SIGNALING TRACING TOOL
Create the signaling tracing task of the transport layer SCCP module.
Figure 4-5 CREATING SSCP MODULE SIGNALING TRACING TASK
Moreover, observe whether ZXWR RNC has sent SST message to the peer end and
whether the peer end returns SSA message. If the peer end does not response, check
the configurations of the peer element.
4.1.2.2 MTP3B Layer Signaling Link Status Unavailable

Fault phenomena
No.7 link is unavailable.

l
l
l
l
SSCOP/ link is disconnected.

The signaling point code (point code type, point code, and SSF is configured
inconsistent at the two ends.
SLC is configured inconsistent at the two ends.
The signaling test is set at the local end but the test code is null (0), which causes
the failure in sending SLTM message.
Trouble shooting
l
l
For SSCOP link is disconnected, refer to SSCS Layer - SSCOP Link Constantly
Disconnected and SSCS Layer SSCOP Link Discontinuously Connected.
Signaling point code configuration
4-5
SJ-20100603155704-010|2011-11-22(R1.2)
Check the interconnection data configuration (signaling point type, signaling point and
SSF) and configure them same.
Configure the data of the local signaling point: On NM configuration management
interface, choose RNC Config Set > RNC Equipment Resource Management >
Transmission Configuration > NE Information Configuration > RNC:0, and select
Local Office Signaling Configuration tab. Check whether the signaling point of the
local office is correctly configured.
Figure 4-6 LOCAL OFFICE SIGNALING CONFIGURATION TAB
Configure the data of the adjacent signaling point: On NM configuration management

interface, choose RNC Config Set > RNC Equipment resource management >
Transmission Configuration > NE Information Configuration > SGSN, and select
Adjacent Office Singalling Configuration tab. Check whether the signaling point
configuration, SSF, and signaling point code type are correctly configured.
Figure 4-7 ADJACENT OFFICE SIGNALING CONFIGURATION TAB
SLC is not consistently configured.

4-6
SJ-20100603155704-010|2011-11-22(R1.2)
Check the interconnection data and configure the link code same at the two ends.
Configure SLC in the adjacent signaling link configuration: On NM configuration
management interface, choose RNC Config Set > RNC Equipment resource
management > Transmission Configuration > NE Information Configuration >
SGSN, and select Signaling Link Configuration > No.7 Link tab. Check whether
Singaling link code is configured same as that at the peer end.
Figure 4-8 NO.7 LINK TAB
Signaling test code is null.

On NM configuration management interface, set the test code (it can not be 0).
On NM configuration management interface, choose RNC Config Set > RNC
Equipment resource management > Transmission Configuration > NE
Information Configuration > Local RNC, and select No.7 Signaling Configuration
tab. Check whether Test code is 0.
Figure 4-9 NO.7 SIGNALING CONFIGURATION TAB
Cautions
None
4-7
SJ-20100603155704-010|2011-11-22(R1.2)
4.1.2.3 MTP3B Layer Signaling Link Status Available but Office Status Inaccessible
Office route configuration is error.
Trouble shooting
l
Open NM configuration management interface and check whether No.7 link is

available.
Check No.7 link status: On NM configuration management interface, choose
RNC Config Set > RNC Equipment resource management > Transmission
Configuration > NE Information Configuration > NE, and choose Signaling Link
Configuration > No.7 Link > State Information.
Figure 4-10 No.7 Link Tab
l
l
Open NM configuration management interface, check whether the route

configuration is error. If so, modify the configuration.
Modify the office route: On NM configuration management interface, choose
RNC Config Set > RNC Equipment resource management > Transmission
Configuration > NE Information Configuration > SGSN, and select Office Route
tab. Check the route configurations.
Figure 4-11 Office Route Tab
4-8
SJ-20100603155704-010|2011-11-22(R1.2)
4.1.2.4 M3UA Layer Association Connected but ASP Inactivated

Fault phenomena
The association to CN is connected bur ASP is not activated.

l
l
AS properties are configured inconsistent at the two ends.

AS RC (Routing Context) and the service mode are configured inconsistent at the
two ends.
Trouble shooting
1. Open NM configuration management interface, choose RNC Config Set > RNC
Equipment resource management > RNC Config Set > Sigtran Configuration
> AS State Information, and choose AS State Information. Check whether AS
properties are configured correctly.
The configuration rule is that, at IUR interface, one end is configured as IPSP_CLIENT
and the other end is configured as IPSP_SERVER. At IU interface, CN is configured
as SGP and ZXWR RNC is configured as ASP.
Figure 4-12 AS STATIC INFORMATION DIALOG BOX (CHECKING USE TAG)
2. On NM configuration management interface, check whether AS in Sigtran

configuration is configured consistent.
4-9
SJ-20100603155704-010|2011-11-22(R1.2)
Figure 4-13 AS STATIC INFORMATION DIALOG BOX (CHECKING ROUTING

CONTEXT ID)
3. On NM configuration management interface, check whether AS mode in Sigtran

configuration is configured consistent. AS mode involves OVERRIDE and load
sharing. The configuration should be consistent at the two ends.
Figure 4-14 AS STATIC INFORMATION DIALOG BOX (CHECKING AS MODE)
4.1.2.5 SCTP Layer Association Setup Failure

Fault phenomena
SCTP association is set up unsuccessfully and the notification is reported.
4-10
SJ-20100603155704-010|2011-11-22(R1.2)

l
l
l
The four elements (localend IP address, peer-end port No., peer-end IP address,
and peer-end port No.) that decide the association and the association protocol
properties (CLIENT/SERVER) are not configured correctly.
The route is configured incorrectly (if the peer service address and the interface
address of the association are not in the same network segment, the route should
be configured).
The network cable is plugged error or the network cable is disconnected.
The transmission is delayed. The transmission is delayed.
Trouble shooting
l
Association configuration
On NM configuration management interface, check the four elements of the
association are correctly configured and whether consistent with the configurations
at the peer end.
Select RNC Config Set > RNC Equipment resource management > RNC
Config Set > Sigtran Configuration > SCTP Association Configuration > SCTP
Association Configuration 0.
Figure 4-15 IP CONFIGURATION OF SCTP ASSOCIATION TAB
Select IP Configuration of SCTP Association tab and check whether IP address is

correctly set.
l
Route configuration
On NM configuration management interface, check whether the static route is correctly
configured in IP stack. If ZXWR RNC connect the peer element through Ethernet, the
next-hopping address of the static route configuration should be configured as the
interface board address of the peer element but not the GIPI address of the local end.
4-11
SJ-20100603155704-010|2011-11-22(R1.2)
Network cable error or disconnected

Re-plug the network cable or replace the network cable.
Transmission delay
Adjust the cable connection between the two offices and do not use more switching
devices between the two offices.
4.1.2.6 SSCS Layer SSCOP Link Constantly Disconnected

Fault phenomena
On NM configuration management interface, click NE Configuration Information. Select
one piece of signaling link configuration and find that the corresponding SSCOP link is
constantly unavailable.

l
l
l
The fiber connection is error.

The local optical interface is configured error.
PVC interconnection parameters are error.
Trouble shooting
l
Fiber connection error

Check whether the fiber connection on APBE is normal. If the indicator at the optical
interface is not ON, the fiber connection with the peer end is faulty.
Local optical interface configuration error

Make sure that the optical interface where the configured link locates (high-end ATM
Sunit No. in PVC configuration) is configured same as the optical interface where the
fiber is plugged (the optical interface where the fiber is plugged is, from up down, 4,
5, 6, 7).
Transmission Configuration
Choose RNC Config Set > Equipment resource management > > PVC
Configuration > PVC Configuration.
4-12
SJ-20100603155704-010|2011-11-22(R1.2)
Figure 4-16 BASIC CONFIGURATION TAB
Peer parameter error

Check whether CVPI and CVCI are configured same as those at the peer end.
Figure 4-17 PVC CONFIGURATION TAB
4.1.2.7 SSCS Layer SSCOP Link Discontinuously Connected

Fault phenomena
On NM configuration management interface, click NE Configuration Information. Select
one piece of signaling link configuration and find that the corresponding SSCOP link is
switching between available and unavailable.

l
IU interface MTP3B error: SSCOP link at NNI side needs generating the link setup
requests at the both ends. SMP fault at ZXWR RNC side may result in mtp3b not
generating link setup request at ZXWR RNC side. After SSCOP link receives the
BGN PDU link setup request from the peer end, the upper-layer sends ReleaseReq.
4-13
SJ-20100603155704-010|2011-11-22(R1.2)
IU interface link setup validation failure: After sscop is set up at NNI side, some SD
packets are sent to validate the link transmission quality. If packet loss occurs, the
link release request is sent. Sscop link setup is normal at NNI end but immediately,
sscop receives ReleaseReq from the upper-layer or the peer end, which causes the
link release. Or, Test code on Mtp3b layer is not filled in, which cause the NNI link
validation failure.
Trouble shooting
l
IU interface mtp3b error

Check whether SMP that Mtp3b belongs to is running normally.
Checking methods: Check whether OSS communication disconnection alarm occurs
on NM alarming system. Check whether RUN on SMP board is flashing at 1HZ. If
SMP board is abnormal, eliminate the board fault first.
IU interface link setup validation failure

Check whether the fiber connection at IU interface is normal. Check whether the test
code is filled in and the value can not be 0.
On NM configuration management interface, click RNC Config Set > RNC
Information Configuration > Local RNC . Select No.7 Singaling Configuration
tab, and check whether Test code is 0.
Figure 4-18 NO.7 SIGNALING CONFIGURATION TAB
4.2 Communication Faults at IUB Interface

4.2.1 Overview to Communication Fault at IUB Interface
NM knowledge introduction
At IUB interface, ZXWR RNC connects with Node B through NBAP signaling, and the
corresponding link is called as NCP link and CCP link. When IUB interface uses ATM
transmission, NCP link and CCP link are borne on SSCOP link. When IUB interface uses
IP transmission, NCP link and CCP link are borne on the association.
4-14
SJ-20100603155704-010|2011-11-22(R1.2)
1. Signaling path in ATM mode

The words in the brackets are the name of the board where the protocol layer locates.
Figure 4-19 IUB INTERFACE RADIO NETWORK LAYER CONTROL PLANE SERVICE
FLOW IN ATM MODE
Figure 4-20 IUB INTERFACE TRANSMISSION NETWORK LAYER CONTROL PLANE

SERVICE FLOW IN ATM MODE
2. Signaling path in IP mode

Figure 4-21 IUB INTERFACE RADIO NETWORK LAYER CONTROL PLANE SERVICE
FLOW IN IP MODE
4-15
SJ-20100603155704-010|2011-11-22(R1.2)
Fault description
l
l
l
l
l
NCP link error

CCP link error
Repeated common channel deletion and creation
Call failure after common channel successfully created
Call failure after several succeeded
Trouble shooting flow

Refer to IU/IUR INTERFACE COMMUNICATION FAULT TROUBLE SHOOTING FLOW.
4.2.2 Typical Communication Faults at IUB Interface

4.2.2.1 ALCAP Layer Repeating Common Transport Channel Deletion and Setup
Fault phenomena
The common transport channel is set up and deleted repeatedly at Node B side.

l
l
l
l
l
AAL2PATH interconnection parameters are inconsistent.

ATM address is invalid.
AAL2 Path type and the service type are inconsistent.
Transport path bandwidth is inadequate.
On the signaling tracing, the end that initiates the link setup request sends ERQ
and receives RLC.
Trouble shooting
l
Inconsistent interconnection parameters

Information Configuration > IU interface element. On the pop-up window, choose
AAL2 Path Configuration > AAL2 Path Configuration > Basic Configuration .
Check the settings of AAL2 Path basic properties.
AAl2 path ID is the interconnection field, which should be same as PathId of the
peer end.
4-16
SJ-20100603155704-010|2011-11-22(R1.2)
Figure 4-22 AAL2 PATH CONFIGURATION TAB
Figure 4-23 STATE INFORMATION TAB
In NM configuration management, check whether AAl2 Path is available.

Figure 4-24 PVC CONFIGURATION - BASIC CONFIGURATION TAB
Check PVCID, CVPI, and CVCI and compare with PVCID, CVPI, and CVCI in PVC
configuration.
l
Invalid ATM address

In NM configuration management, check whether the ATM address of the local office
is configured same as that of the target office.
4-17
SJ-20100603155704-010|2011-11-22(R1.2)

Information Configuration > Element. On the pop-up window, choose ATM Office
Configuration > ATM Office Configuration, and check whether ATM address is
configured same as that in the peer NE.
Figure 4-25 ATM OFFICE CONFIGURATION TAB
AAl2 Path type inconsistent with service type

In NM configuration management, check whether AAl2 Path type matches the service
type.
Information Configuration > Element. On the pop-up window, choose AAL2 Path
Configuration > AAL2 Path Configuration > Basic Configuration, and check
whether Service Type matches that of the user.
Service Type is the service type that AAl2 path can bear. The value is RT (bearing
the realtime service), NRT1 (bearing R99 non-realtime services), NRT2 (bearing HS
non-realtime service), and MIX (mixed Path, bearing the services of all types).
Figure 4-26 AAL2 PATH CONFIGURATION BASIC CONFIGURATION TAB
4-18
SJ-20100603155704-010|2011-11-22(R1.2)
Inadequate transport path bandwidth

Equipment Resource Management > Transmission Configuration > NE
Information Configuration > Element. On the pop-up window, choose Path
Configuration, and check whether the transport path bandwidth is inadequate.
Forward bandwidth corresponds to the sending direction of ZXWR RNC and
Backward bandwidth corresponds to the receiving direction of ZXWR RNC.
Figure 4-27 CHECKING PATH BANDWIDTH
If the transmission bandwidth admission fails, the failure can be seen from NM
radio performance counter, The detailed counters include the number RAB of RAB
assignment setup failure without queuing in CS domain/PS domain and IU/IUR/IUB
interface transmission admission failure.
l
Receiving RLC after sending ERQ

With the signaling tracing tool, send RLC cause to the peer NE to perform the signaling
tracing analysis.
On NM software, choose View > RNC Signal Trace to open the signaling tracing
software. On the pop-up window, choose Task Manager > New Task (TNL), and
create ALCAP signaling tracing task.
4-19
SJ-20100603155704-010|2011-11-22(R1.2)
Figure 4-28 CHECKING ALCAP SIGNALING TRACING TASK
4.2.2.2 ALCAP Layer Call Failure after Common Transport Channel Created
Fault phenomena
Fail to make calls after the common transport channel is created.

l
l
AAL2 path type is inconsistent with the service type.

The bandwidth of the transport path is inadequate.
Trouble shooting
Refer to ALCAP Layer Repeating Common Transport Channel Deletion and Setup.
4.2.2.3 SCTP Layer

Refer to SCTP Layer Association Setup Failure.
4.2.2.4 SSCS Layer

Refer to SSCS Layer SSCOP Link Constantly Disconnected and SSCS Layer SSCOP
Link Discontinuously Connected.
4-20
SJ-20100603155704-010|2011-11-22(R1.2)
4.3 NM Alarm
When the fault occurs on the transmission layer, the direct information is the alarm
information reported on NM alarming interface.
The following analyzes the alarm information on the transmission layer.
4.3.1 SSCOP Link No Message Response for a Long Time

Fault phenomena
OMCR alarm interface reports Link no message response for a long time
alarm.

NM reports the messages if no status response package STAT is returned from the
peer-end after the status query package POLL is sent on the SSCOP link. The possible
cause is the transmission line fault or peer-end NE error without responses.
Detailed analysis:
1. Physical link or the board hardware fault, including:
l Optical port is damaged and it cannot work normally.
l The contact between the optical port and the fiber is poor.
l The optical fiber is damaged
2. Peer-end NE fault results in the link response message not returning.
Trouble shooting
1. First check whether it is the transmission line fault. Perform the loop on the distribution
frame. If SSCOP link becomes available after the loop, the cause will not be the local
ZXWR RNC fault but the peer-end NE fault. There are two methods to judge the
SSCOP link status: One is to telnet to the board where this SSCOP link locates and to
view the link status with Shell function SscsLinkInfo. The other is to query SSCOP link
status in NE Configuration Information on NM NM interface. In addition, with NM alarm
information, check whether there are alarms on the application link on this SSCOP link.
Iu interface gives No. 7 link alarm. Iub interface gives NCP link alarms and CCP link
alarms.
2. If SAAL link is still unavailable after the loop, APBE/IMAB of the local NE may be faulty
or the fiber/E1 connection gets faulty. Reset or replace the board can remove the fault.
Replacing the fiber/E1 cable can remove the physical line fault. If the contact between
the fiber and the optical module is not well, pull out the fiber by a little but the indicator
that this optical port on APBE corresponds to should be constantly green.
Cautions
None.
4-21
SJ-20100603155704-010|2011-11-22(R1.2)
4.3.2 SSCOP Link Congested Alarm

Fault phenomena
OMCR alarm interface reports Broadband link congested alarm.

The link reports the congestion alarm when SSCOP detects that the ratio of the sending
buffer district and the queue usage with the sent but not verified packages is over 220. It
reports the congestion removed when the ratio is low than 180.
Trouble shooting
1. Query the congestion of the SSCOP link in NE Configuration Information on NM
interface, to determine that the link is congested.
2. Reduce the service message traffic.
Cations
None.
4.3.3 SSCOP Link Overload Alarm

Fault phenomena
OMCR alarm interface reports Broadband link overload alarm.

The link reports the overload alarm when SSCOP detects the sending buffer district and
the queue usage reaches 42,000.
Trouble shooting
Add some interface boards to share the data sending traffic.
Cautions
None.
4.3.4 Abnormal Status of No. 7 Link

Fault phenomena
OMCR alarm interface reports Mtp3 link unavailable or Mtp3 link congested
alarm.
The abnormal phenomena of No.7 signaling link are as below:
4-22
SJ-20100603155704-010|2011-11-22(R1.2)
l
l
l
l
Link broken, that is, unable to locate link. In this case, NM will report Mtp3 link
unavailable alarm.
Unstable link, that is, link practices initial location frequently and unable to transmit
signaling services. In this case, NM will report Mtp3 link unavailable alarm.
Link inhibited, that is, far-end processor fault. In this case, NM will not report Mtp3
Link unavailable alarm.
Link blocked, that is, link overload. In this case, NM will report Mtp3 link congested
alarm.

1. Transmission fault: Transmission interruption can result in broken link. Transmission
flashing stop, transmission error code, and bad contact of Iu/Iur interface optical
fibers may increase the link error rate and increases the times resending message
between ZXWR RNC and adjacent NE. In severe status, the link performs initial
location frequently and cause link blockage or link instability.
2. APBE interface board fault.
3. Remote processor fault may cause link inhibited and cause link blocked also.
4. Remote manually inhibit signaling link.
5. Improper data configuration: If DPC and SLC in MTP3B data mismatches with
the peer end, the link will be unable to pass Layer 3 service test (Mtp3b link test)
after succeeding in initial location. This causes frequent link performing location,
and unstable link operation. Check the link. If the configuration is required to test,
configure the test codes. If the static route information of No.7 link is set improperly
in data configuration, it causes unbalanced load on multiple links, and cause the link
with heavy load blocked.
Trouble shooting
l
Broken-link fault process

1. Check whether transmission system interrupts
Transmission system interruption is the common cause of signaling link broken.
Check whether the corresponding optical fiber disconnects. This can depend on
SD indicator on APBE. SD1 ~ SD4 are 4 optical interface signal indicators. If
there is optical signal inputted in receiving direction, SD indicator is on, and vice
versa. If the external transmission system interrupts, contact with transmission
department.
2. Check whether related board is normal
No.7 link process protocol is on APBE, so APBE fault or the optical interface
module fault on APBE is one of common causes of signaling link broken.
In general, viewing the alarm information at alarm console can judge the reason
of board error.
3. Loop
4-23
SJ-20100603155704-010|2011-11-22(R1.2)
Loop is one of the common method to locate link fault, which is mainly to estimate
fault scope.
When No.7 signaling link practices loop, the following ways can judge whether all
parts are normal.
a. If the home signaling point is in normal status (for example, no Unable to
reach signaling point alarm occurs on NM alarm interface), the
link may normally locates at Layer 2 SAAL after the loop. Then, SSCOP
link corresponding to No.7 link will be in normal status. However, since the
parameters as SLC and DPC mismatched, the link will break again because
it cannot pass the Mtp3b link test on Layer 3, and repeat the initial location
process. In link status, all above Steps will reflect as the phenomena that
SSCOP link corresponding to a No.7 signaling link on APBE releases after
established over again and again, and with about 1 min cycle.
b. If the home signaling point is in abnormal status, SSCOP link corresponding
to a No.7 signaling link on APBE will be not through all along to indicate link
broken at all time.
The first is performing the loop of NE to butt for locating the problem. No.7 link
flow direction at RNC side is APBE > distribution frame > loop. No.7 link
flow direction of peer-end NE is Peer-end NE > distribution frame > loop. If
the loop succeeds at both ends, check whether the configurations of butting
VPI/VCI parameters are correct.
Broken links has 2 cases: No.7 signaling link is unable to establish a link and
No.7 signaling link disconnects after normal operation. If the link is unable to
establish, check whether the data configuration if consistent, whether cable
connection is correct and firm, and whether the transmission. Then, confirm
whether there is any problem with boards. If the link breaks after normal
operation, check whether there is any problem with relative board, whether the
connection of external cables is firm and whether the transmission is normal.
l
Unstable link fault process

1. Check whether the transmission system bit error rate exceeds.
a. Check whether the transmission system bit error rate exceeds.
Iu/Iur interface demands for higher link transmission quality. When BER of
transmission system exceeds 10-6, link error code increases greatly and
the message resending time between exchanges increases, too. When it is
severe, it causes link re-release and re-establishment and makes unstable
link operation. If the lower layer link is congested, it also causes link release
and establishment repeatedly because of decreased transmission quality.
b. Check whether related board is correct.
2. Check whether MTP link data is correct.
SLC and DPC are important parameters for butt-connection. Both DPC
configuration error and the mismatch between SLC and the peer end cause
4-24
SJ-20100603155704-010|2011-11-22(R1.2)
the link failure in SMP after it succeeds in the initial location. That is, the link
cannot bear signaling services. Then, the system will perform the initial location
for link again. Since data configuration is wrong, the process mentioned above
will repeat frequently. The link cannot operate normally all the time and will be
unstable.
DPC settings are according to network plan, but SLC settings require the
negotiation of both parties.
l
Link inhibition fault process

The cause of link inhibition is that home end receives the inhibition request (LIN)
from the far-end, which causes the messages over Layer 3 unable processing.
Far-end performs link inhibition command man-made, which causes far-end message
sending; and the system transmits LIN message via man-machine command. In
such a situation, it is necessary to contact with the opposite office to make clear the
real cause of link inhibition and recover link to normal as soon as possible.
Link congestion fault process

When the link congestion occurs, the system will report No.7 link congestion
notice via alarm system. Locate it by following the steps below:
1. Check whether the operation of transmission system is normal. Contact the
transmission department to make clear the transmission system operating status.
2. Check whether APBE goes error. If necessary, replace the board to locate the
fault under the permission of the system.
3. Check whether data configuration is correct.
If the static route information on data configuration R1Route Table mismatches with
actual No.7 link quantity, some links being selected never transmits No.7 signaling
even in normal situation. This causes the severely unbalanced signaling load
distributing to all links, and the link with heavy load will be congested when link flow
increased.
Cautions
For Iu interface, when ZXWR RNC and MSC are not at same location, No.7 signaling
link fault depends mostly on transmission quality. Therefore, pay more attention to
routine transmission equipment maintenance, and timely communicate with transmission
department when fault occurs. No.7 signaling link of Iu interface covers ZXWR RNC and
MSC, so analyze the cause form both sides when No.7 signaling link fails.
When handling with No.7 signaling fault, if signaling analyzer is available, it is better to
trace Iu interface signaling, or trace the message with signaling trace function offered by
ZXWR RNC maintenance console.
4-25
SJ-20100603155704-010|2011-11-22(R1.2)
4.3.5 Unreachable Alarm of Signaling Point

Fault phenomena
OMCR alarm interface reports Mtp3 office unreachable alarm.

l
All No.7 links corresponding to the signaling point are not established. Check the
status fields of links on R_N7LINK list of ROMP with digital probe. If the status is not
equal to zero, it means all No.7 links to the adjacent office fail.
Route not configured to the signaling point at the peer end causes the signaling
point to restart abnormally and unable to set the signaling point as reachable.
Check whether the route information in the office direction on R_N7ROUTE and
R_N7OFFICE list of ROMB match with digital probe.
Signaling point is manually blocked.
Trouble shooting
1. If all No.7 links to the adjacent office fail, find out the cause of abnormal No.7 link
status.
2. If there is at least one normal No.7 link, check data configuration and estimate whether
the route configured to the signaling point at the peer end is correct.
3. If No.7 link and route are normal, continue the data configuration check to see whether
the adjacent office is manually blocked. Check whether the Bit1 of Info field on R_O
FFICE list of ROMP is 1 with digital probe. If it is 1, it means the signaling point is
manually blocked. Unblock the signaling point from NM configuration interface.
Cautions
Disconnection of all No.7 links in the office direction will cause the adjacent signaling point
unreachable. First, exclude the transmission system problem or the possibility of APBE
interface board fault at ZXWR RNC side.
If it is the first time to configure data, check whether the route configuration is correct,
especially when ZXWR RNC connects with multiple adjacent NEs. The route configuration
to different NEs is easy to get error.
4.3.6 Sccp Subsystem Unavailable Alarm

Fault phenomena
OMCR alarm interface reports Sccp subsystem unavailable alarm.
4-26
SJ-20100603155704-010|2011-11-22(R1.2)

1. Adjacent office signaling point is unreachable. Check R_OFFICE list on ROMB with
digital probe. The corresponding adjacent offices status field is not 0, which means
the signaling point to adjacent office is unreachable.
2. Adjacent office signaling point does not give SSA after it receives ZXWR RNC SST
message, which causes the related SSN unavailable and needs to check the NE
problem.
Trouble shooting
1. If the signaling point to adjacent office is unreachable, find out the cause.
2. If the signaling point to adjacent office is reachable, check whether the adjacent office
sends subsystem test message SST with signaling tracing tool. Observe whether
it receives the answer message SSA from opposite end subsystem. If it does not
receive SSA, check whether the route configuration of both sides if correct, as well as
the subsystem configuration. The possible causes are that the remote signaling point
subsystem exits the service, or the remote office deletes SSN configurations, or the
SSN is not configured at the remote but at the local.
Cautions
None.
4.3.7 NCP Link Fault Alarm

Fault phenomena
OMCR alarm interface reports NCP link fault alarm.

The possible cause is that SSCOP gets faulty or PVC is unavailable.
Trouble shooting
After NCP link disconnects, ZXWR RNC will originate the link re-establishment
continuously. During the course, it does not require the involvement of maintenance staff.
If the link establishment is unsuccessful for a long period, it requires maintenance staff to
check whether related fault exists and to perform relative process. Check whether Node
B SSCOP configuration and ZXWR RNC SSCOP configuration is consistent, or check
whether Node B PVC configuration and ZXWR RNC PVC configuration is consistent.
Cautions
None.
4-27
SJ-20100603155704-010|2011-11-22(R1.2)
4.3.8 CCP Link Fault Alarm

Fault phenomena
OMCR alarm interface reports CCP link fault alarm.

It might be SSCOP link fault or unavailable PVC.
Trouble shooting
ZXWR RNC will attempt to establish the communication link continuously via relative
TNL module. If the communication link cannot recover for a long period, check whether
any other alarm exists. If so, resolve it. Check whether Node B SSCOP configuration
and ZXWR RNC SSCOP configuration is consistent, or check whether Node B PVC
configuration and ZXWR RNC PVC configuration is consistent.
Cautions
None.
4.3.9 SSM Association Setup Failure

Fault phenomena
OMCR alarm interface reports Association setup failure alarm.

Sctp fails to set up the link.
Trouble shooting
l
l
l
Check whether RUB is running normally.

Check whether the line is unblocked.
Check whether the configurations of the association (IP address of the both ends
and the port ID) are correct.
Cautions
None.
4.3.10 SSM Association Broken-link Alarm

Fault phenomena
OMCR alarm interface reports SSM association broken-link alarm.
4-28
SJ-20100603155704-010|2011-11-22(R1.2)

1. The association is deleted.
2. The association is released manually.
3. The transmission link between the association ends is broken.
Trouble shooting
Configure one IP in the same network segment with the RUB interface address on the
debugging machine. Access the machine into the transmission network where the RUB
interface board locates. Ping the IP address if the interface boards at both ends, to check
whether the transmission network is normal or not.
Cautions
None.
4.3.11 SSM Association Congested Alarm

Fault phenomena
OMCR alarm interface reports SSM association congested alarm.

The sending buffer of the SCTP layer association is congested.
Trouble shooting
The upper-layer users decrease Tx data traffic.
Cautions
None.
4.3.12 M3ua Office Unreachable

Fault phenomena
OMCR alarm interface reports M3ua office unreachable alarm.

1. The association is released or the AS is not in service.
2. The data in SIOLOCAS table is not configured for this office, so AS cannot be bound
with the office that M3ua manages.
4-29
SJ-20100603155704-010|2011-11-22(R1.2)
Trouble shooting
1. Check the association status (use the available debugging function SsmState if no
NM tool is available) via the dynamic management. If the status is normal, query
the AS status that serve this office with the dynamic management (use the available
debugging function UamShowOmpASASPStatus if no NM tool is available) and put it
into service to enable the office reachable. If the association is unavailable, see SSM
alarm.
2. Check the data configuration and find whether the SIO is configured and whether
there is ASP service. If no, add SIOLOCAS configuration into this configuration
management.
Cautions
None.
4-30
SJ-20100603155704-010|2011-11-22(R1.2)
Chapter 5

Shooting of Software
Installation Fault
Table of Contents
Overview to Software Loading Fault ...........................................................................5-1
Typical Software Installation Faults.............................................................................5-3
5.1 Overview to Software Loading Fault

Background Knowledge
Software loading is usually generated by NM, including the operations on the version file
and the version configuration information.
ZXWR RNC adopts the uniform platform. According to the board type, the software loading
process falls into two cases: OMP board and non-OMP board.
l
OMP board
During the startup, OMP requests the configuration file from the OMCS address that
is configured during the serial interface debugging. If the configuration file can be
obtained, OMP compares the file with the local file. If the files are same, call the
version from the local harddisk and start. If the files are different, get the version
file from OMCS and start, and meanwhile, modify the local configuration file. If the
configuration file can not be obtained, start according to the local configuration file.
Non-OMP board
During the startup, it does not directly intercommunicate with OMCS but requests the
version file from the master OMP. The board compares the version information on the
local FLASH and the version information configured on ROMP. If the version files are
same, start with the version file stored on FLASH. If the version files are different, start
with the version file obtained on OMP.
Fault Phenomena
l
The indicators on the board are not ON normally.

NM alarming system prompts that the board is offline or the status is not stable,
sometimes normal and sometimes abnormal.
5-1
SJ-20100603155704-010|2011-11-22(R1.2)
All services related to the board are disconnected.
Trouble Shooting Flow

The trouble shooting flow of the board loading abnormality is as shown in Figure 5-1.
Figure 5-1 TROUBLE SHOOTING FLOW OF BOARD LOADING ABNORMALITY
Trouble Shooting Steps

1. Check Version Management in NM to check whether all boards have performed the
version loading. Open the folder ofzxwomcs\ums-svr under OMCS server installation
directory to check whether there is a configuration file of OMPCFG.INI and whether
there is loaded version file under the directory of zxwomcs\ums-svr\cnvmVerFile.
If there is no file of OMPCFGx.INI under the specified directory, create OMP booting
file in Version Management. If there is no laded version file under the designated
directory, load the version again.
2. With File Management of the local maintenance tool, view whether there is a version
on OMP harddisk (the device name is \IDE0).
If no version files can be found on the designated directory on OMP harddisk, load the
version again.
3. With File Management of the local maintenance tool, view whether the version files on
other boards are correct.
If the version file query fails, check the operation status of the board and follow the
trouble shooting flow. If the version file is queried as incorrect, load the correct version
file on this board in version management again.
5-2
SJ-20100603155704-010|2011-11-22(R1.2)
Chapter 5 Analysis and Trouble Shooting of Software Installation Fault
4. Check the operation status of UIM and CHUB. If UIM and CHUB are error, the
communication between other board and OMP disconnects, and the version loading
from OMP fails.
If the working status of UIM and CHUB are abnormal, check the hardware
configurations and version loading of UIM and CHUB. Make sure that UIM and CHUB
can run normally.
5.2 Typical Software Installation Faults

5.2.1 ROMP Reboots Once All-table Synchronization Made
Fault phenomena
The system does not change ROMP version file, but ROMP reboots after the all-table
synchronization is launched through OMCR client.

1. The system detects that the version run on ZXWR RNC ROMP is inconsistent with the
version configured on NM. The version switching occurs.
2. The FTP server at NM that is to download the version does not close, which causes
ROMP to download the version from NM but not activate the version at the local.
Trouble shooting
1. For cause 1: Check whether the version run on ROMP is the required version. If not,
change the version again.
2. For cause 2: Close the FTP downloading the version at NM. Change the starting mode
of ROMP to Start from Board after OMP is started.
Cautions
When the commercial FTP service software, server-U, runs as NM FTP server, only closing
the operating window does not mean stopping the service. Click stop server on the
interface to stop the service. If it is not the first time to configure ROMP version, it is
better to set the start mode as local in priority.
5.2.2 FPGA Version Unable to Switch

Fault phenomena
During RNC version upgrade, FPGA version switching fails.
5-3
SJ-20100603155704-010|2011-11-22(R1.2)

FPGA error information in ompcfg.inf configuration file on FLASH results from the low
version of VMMBACK.
Trouble shooting
Upgrade VMMBACK to high version, forming ROMP version information. Recreate omp
cfg.inf file.
Cautions
When upgrading the version, do recreate ROMP configuration information with VMMBA
CK of higher version.
5.2.3 302 Returned when Version Downloaded to RNC

In most cases, this return code occurs on FTP. Users should set the FTP server, username,
password, and IP on the NM.
5.2.4 1424 Returned before Version Switched to RNC

This code indicates that the database operation succeeds, obtaining the logic address of
the target board fails, and the board should be reset.
If this fault occurs when switching the defaulted version, the ZXWR RNC database
operation succeeds but the board can not be reset automatically. After being rebooted
manually, the board will run the new version.
5.2.5 1402 Returned before Defaulted/Designated Version Switched

to RNC
This code indicates that the database operation succeeds.
This code includes two cases:
1. All boards are off line during the multicast.
2. Some boards are on line but the multiplexing files can not be received for certain
reasons. The version file multicast can not be performed, so use the values in the
multicast fields to indicate.
When the switching multicast code of the designated version belongs to the following
multicast code, the records are not written on ZXWR RNC and NM regards it as error.
1. 6: The target board of APTD table fails in switching the database but does not start
the multicast (valid to physical switching/cancelling switching).
2. 17: For OMP, during the version switching, the version file name is same as the
opposite board version file name and the contents are also same, so the multicast
fails (valid to logic/physical switching).
5-4
SJ-20100603155704-010|2011-11-22(R1.2)
Chapter 5 Analysis and Trouble Shooting of Software Installation Fault
3. 18: DSP is not configured and DSP version physical switching/cancelling switching.
4. 19: The board does not need this file.
5. 20: The version file fails to be created on OMP during the switching.
6. 21: DOC space is not enough to save the version file during the switching.
5.2.6 FTP Failure, Please Check Whether FTP at the Server is

Normal or not and Please Check Whether the Network is
Normal or Not
FTP may be used before creating, deleting, or downloading the version to the ZXWR RNC.
This fault occurs mostly because the platform FTP service is not enabled.
Make the following checks: Check the windows process management to see whether ftps
erver.exeexists. If there is not this process, run zxwomc\tools\ftpserver\ftpserver.bat to start
FTP Server. IF FTP server is enabled but this fault still exists, check whether the breakup
is set correctly.
5.2.7 Precautions when Downloading Versions from Non-Server

1. Copy ums-license.LCS under ums-svr\deploy from the server to cover ums-svr\deploy
\ums-license.LCS.
2. Delete all files from temp at the server and the client.
In ums-svr\deploy\deploy-020womcr.properties, modify zxwomc-cm-sw-osf-rnc.ftpserve
r.ip and zxwomc-cm-sw-osf-bme.ftpserver.ip to the IP of the network segment same as
the NE of the local server.
5-5
SJ-20100603155704-010|2011-11-22(R1.2)
5-6
SJ-20100603155704-010|2011-11-22(R1.2)
Chapter 6

Shooting of Handover Fault
Table of Contents
Overview to Handover Fault ......................................................................................6-1
Handover Troubleshooting Types ...............................................................................6-2
Typical Handover Faults .............................................................................................6-5
6.1 Overview to Handover Fault

The handover of UTRAN system includes intra-frequency handover, inter-frequency
handover and inter-system handover. In terms of the handover process, these three kinds
of handover consist of the following three steps:
1. UE reports the measurement report
2. ZXWR RNC makes handover judgment
3. ZXWR RNC and UE implements corresponding handover flow
Step 2 is a process of judgment decision, that is, a process of ZXWR RNC thinking.
This process involves no ZXWR RNC interaction with other equipment nodes and no
factors of handover process and radio quality, so the handover judgment of ZXWR RNC
must be correct. But in some cases, ZXWR RNC does not handover when it receives
a measurement report in view of RRM such as load sharing and load control. This is a
correct handover judgment, and this case is often mistaken as handover faults when the
handover judgment mechanism of ZXWR RNC is not understood. To make instruction
easy, this case that appears to be a fault is analyzed here, to differentiate it from other
handover faults, and it is referred to as false fault.
Corresponding to the handover Stepss, the handover faults fall into following types:
1. UE unable to report measurement report
2. False fault of ZXWR RNC handover judgment
3. The handover process failure.
6-1
SJ-20100603155704-010|2011-11-22(R1.2)
6.2 Handover Troubleshooting Types

6.2.1 UE Unable to Report Measurement Report
Fault phenomena
l
l
UE does not report any measurement reports

The reported measurement reports are null and there is no information of adjacent
cells

1. Adjacent cells are not configured.
2. NOKIA mobile phone reports no measurement report after frequency locking.
3. The single-mode terminal cannot report the inter-system measurement report.
4. The cause of radio quality results in handoffs that meet no handover conditions.
5. The irrational parameter setting makes it hard to meet the handover conditions.
6. The protocol provides: Fail to make inter-frequency measurement unless setting the
inter-frequency adjacent cells in the inter-frequency measurement control as reading
the destination cell SFN and UE must adopt the downlink compression mode. UE
will deem it a measure task incompletely configured, and not report the measurement
report (send some UE reports as empty).
Trouble shooting
1. Check whether the configuration of adjacent cells is correct.
2. If testing with NOKIA mobile phone, remove its frequency locking.
3. In the inter-system handover, set the mobile phone as dual-mode terminal.
4. Modify the measurement report as periodic reporting, and the measurement reports
reported periodically. Observe the changes in the quality of active set and radio quality
of adjacent cells, and judges whether it meets the triggering conditions of handover.
5. Check whether the handover parameters are the configuration parameters given
after network planning and optimization. If no configuration parameters are given,
the default ones should be used.
6. For the inter-frequency measurement, set inter-frequency adjacent cells as no reading
destination cell SFN.
Cautions
None.
6-2
SJ-20100603155704-010|2011-11-22(R1.2)
Chapter 6 Analysis and Trouble Shooting of Handover Fault
6.2.2 ZXWR RNC Judgment Fault (False Fault)

Fault phenomena
l
l
l
l
l
Handover does not occur when receiving the intra-frequency event 1A or 1C.
ZXWR RNC triggers hard handover when receiving 1D.
The destination cell under hard handover is not the one that triggers the
measurement report.
UE originates a call in 3G network, but the final call is established in 2G network.
UE reports no measurement report but intra-frequency, inter-frequency or
inter-system handover occurs.

It is possible to mistake the above cases for handover faults, but in fact, this is a restriction
under the influence of the radio resource management algorithm, so they are normal cases.
The following is the explanation of the above cases.
1. When the adjacent cells that trigger the 1A and 1C events do not report OFF and Tm
values, the radio links established in these adjacent cells cannot synchronize with the
radio links in the active set, nor conduct soft handover.
In addition, if ZXWR RNC cell without Iur interface triggers 1A or 1C event, nor
handover judgment is made. This is because relocation is the only choice if Iur
interface is not available, and the success rate of relocation cannot be ensured unless
the destination cell of ZXWR RNC cell has changed into the best cell.
2. The intra-frequency or inter-frequency hard handover may be done if the 1D event
is received. The inter-frequency hard handover is based on inter-frequency load
balance. That is, the load of the adjacent cell that triggers the 1D event is high and
exceeds the threshold of load balance in the configured system. In addition, the
difference between the load margin of the adjacent intra-coverage and inter-frequency
cells and the load margin of this cell is larger than the threshold of a configured load
balance difference. Co-frequency hard handover means the best cell has changed
into an adjacent cell after 1D event is triggered. To ensure that the conversation
quality must be handed over but soft handover is impossible. For example, UE
reports no OFF/Tm value of the adjacent cells, ZXWR RNC cell triggers 1D cell and
has no Iur interface.
3. The destination cell under hard handover is not the cell that triggers the inter-frequency
measurement report. This is also the reason of inter-frequency load balance. That
is, the load of the cell that triggers the inter-frequency measurement report, and the
load of the adjacent cells in the same coverage and different frequencies, meet the
conditions of inter-frequency load balance.
4. UE originates a call in 3G network, but the final call is established in 2G network for
the reason of inter-system load balance. That is, 3G cell in which UE resides, has
a high load, exceeding the threshold of a configured inter-system load balance. UE
is capable of running in a 2G system and the applied services can be borne by this
6-3
SJ-20100603155704-010|2011-11-22(R1.2)
system. UE can be handed over to 2G system in the process of service establishment

through directed retry.
5. For the same reason, UE reports no measurement report but intra-frequency,
inter-frequency or inter-system handover occurs. When the cell is overloaded, the
load control algorithm can make soft handover on UE in the macro set status and
delete the link in the overloaded cell. After this, the cell is still overloaded, UE in
the overloaded cell is blindly handed over to the inter-frequency and intra-coverage
cells. If there is no inter-frequency and intra-coverage cell, or the inter-frequency and
intra-coverage cell is overloaded, the capability of the load control algorithm to select
UE and the undergoing service can be handed over to 2G system and UE is handed
over to 2G cell under the same coverage of the overloaded cell.
Trouble shooting
1. For the case of no report of OFF/Tm value by UE and no Iur interface, only hard
handover can be done.
2. Disabling the switch for load balance and control in the cell can avoid the affect on
normal handover judgment after the load balance and control function.
3. Adjusting the thresholds of the cell-level load balance and control can increase or
decrease the probability to enable load balance and control. Increasing the threshold
of load balance in the system and the difference threshold of load balance can reduce
the enabling probability of load balance.
Cautions
None.
6.2.3 Handover Process Failure

Fault phenomena
l
l
The cell resource application fails.

The active set update, the physical channel re-allocation and RB re-allocation or
the inter-system handover fail.

l
l
The admission of the destination cell fails due to load and code resource.
The handover process fails due to too poor radio quality which causes ZXWR RNC
not to be able to receive the handover acknowledge message. Some terminals
cannot make inter-frequency handover due to frequency locking and some cannot
make inter-system handover due to frequency locking, or set as single-mode
terminals.
6-4
SJ-20100603155704-010|2011-11-22(R1.2)
Trouble shooting
1. Check the resource allocation of the destination cell. Check whether there are enough
code resources to be allocated to the new links, and whether the destination cell
is limited to the load and cannot be admitted. Increase the threshold for admitting
the destination cell by releasing the calls from the destination cell and then make a
handover attempt.
2. Remove the frequency locking of the mobile phone in inter-frequency handover.
Remove the frequency locking of the mobile phone and set the phone as dual-mode
terminal.
3. Active set update Failure, physical channel re-allocation failure, RB re-allocation
failure, or inter-system handover failure are caused by the radio quality. The periodinc
measurement report can observe the radio environment quality of the handover
areas. If the radio environment of the handover area is poor in quality with much
interference and high fluctuation, and the signal of multiple cells can be received
simultaneously and the signal of each cell is weak, this shows the handover area
is not good. Its position and the radio quality can be changed and the handover
success rate can be improved through adjusting the antenna dip and power of the
adjacent cells. If it is the handover failure due to frequent handovers, it may be
caused by inappropriate setting of handover parameters except for the reason of
radio environment. In this case, the hysteresis coefficient for handover judgment can
be added properly to increase the trigger time for the handover events, which can
effectively lower the frequency of handover and increase its success rate.
Cautions
None.
6.3 Typical Handover Faults

6.3.1 Unable to Trigger Inter-Frequency Blind Handover
Fault phenomena
An indoor environment cannot trigger the inter-frequency blind handover.

Check and find that the inter-frequency measurement is enabled instead of blind handover
being triggered, so it may be due to adjacent cell configuration. Check the configuration
and find that the inter-frequency adjacent cell is not configured as the adjacent cell in the
same coverage.
Trouble shooting
Modify it as the adjacent cell in the same coverage, and trigger it through blind handover.
6-5
SJ-20100603155704-010|2011-11-22(R1.2)
Cautions
When handover becomes abnormal, check the parameters configured by ZXWR RNC first.
6.3.2 Physical Channel Re-allocation Failure of Inter-Frequency

Handover
Fault phenomena
An indoor environment is subject to inter-frequency handover, and the re-allocation of
physical channel fails.

Made the inter-frequency blind handover test with a NOKIA 7600 mobile phone and finds
that the blind handover can be triggered but UE always fails to return the physical channel
re-allocation. Check through the debugging command of the mobile phone, 4606, and find
that its frequency point is not 0. This shows the mobile phone is in the phase of frequency
locking and the hard handover cannot be done.
Trouble shooting
Remove the frequency locking of the mobile phone, and the blind handover of the mobile
phone can implement normally.
Cautions
When handover becomes abnormal, check the mobile phone settings.
6.3.3 Impossible Cross-Iur Interface Soft Handover

Fault phenomena
An indoor environment fails in implementation with the cross-Iur interface soft handover.

After checking, find that all undergoing Iur interface handovers are co-frequency hard
handover. The reason may be the trigger of co-frequency hard handover without Iur
interface. But the person in charge of environment said that Iur interface has been
configured and could be soft-handed over in the previous day. After a careful examination,
no problem is found in the data configuration, but Iur interface link is found in abnormal
status with the help of data probe. It is doubted to be the problem of physical connection.
After checking the connection of the optical interface, it is found that a piece of optical
fiber breaks away from its normal position due to external force which results in the
interruption of Iur interface connection.
6-6
SJ-20100603155704-010|2011-11-22(R1.2)
Trouble shooting
All NEs of UTRAN connect through optical fiber. If the optical fiber cabling is unreasonable,
there are many possibilities that the cable is disturbed while walking in the room. This may
easily cause abnormal connection of optical fibers.
Cautions
Insert the fiber properly and the soft handover of Iur interface is normal.
6.3.4 Quite Low Handover Success Rate (1)

Fault phenomena
The success rate of soft handover is quite low and there are only two cells in adjacency.

Through an on-site survey, find that the handover area is right under a crossing bridge,
with a wide roadway, and its two exits can receive signals of Cell A and B in good quality
separately, but the signal under the bridge is poor in quality. Through analysis, the reason
for a quite low handover success rate is the improper handover area. The signal of the
handover area has a very high attenuation. The signals of the two cells in the handover
area are weak and interfere mutually. The call-drop rate here is high even if handover is
not implemented.
Trouble shooting
Adjust the antenna dip of Cell A downwards to reduce the coverage of Cell A, and adjust
the antenna dip of Cell B upwards to increase the coverage of Cell B, which is to be used
for covering the whole crossing bridge. Properly increase the pilot frequency of Cell B,
in this case, the handover area is adjusted to a side close to Cell A outside the crossing
bridge. Due to their breakaway from the crossing bridge, the signal has no deep fading and
the handover success rate is greatly improved. Meanwhile, the area under the bridge is
completely covered by Cell B, and the call drop rate under the bridge is obviously lowered
without the interference of Cell A.
Cautions
Such phenomenon as low call completion rate and high handover call drop rate, individual
places in the external field environment, instead of the whole network are generally
because of improper network planning in this place, or may be some new building
shielding the signals of the related cells. In this case, test these abnormal areas for route,
and plan the radio networks in these areas again.
6-7
SJ-20100603155704-010|2011-11-22(R1.2)
6.3.5 Quite Low Handover Success Rate (2)

Fault phenomena
The success rate of soft handover is quite low, and the handover areas cover four cells,
A, B, C and D.

Through an on-spot survey, find that the handover area locates in the express ringway
of the city with a driving speed of over 60 km/h. The four sites, A, B, C and D locate in
parallel along the ring way, and the space between the sites is small. For example, the
space between Site B and Site C is smaller than 200 m. When passing this section at
a high speed, handovers are frequent and calls are easy to drop. Through analysis, the
antenna down-tilt angle of the above sites is very large, and the inter-site interference is
small in the initial site layout, to avoid mutual interference or even overlapped coverage
of sites. There is no problem in handover in the case of walking. However, it can result
in continuous coverage by means of micro-cell nearby the expressway, with frequent and
poor-quality handovers in the case of vehicle running.
Trouble shooting
Shut down Cell B and Cell C, and adjust the antenna dip of Cell A and Cell D upwards to
realize continuous coverage of Cell A and Cell D. This reduces the handover times and
apparent improvement of handover success rate.
Cautions
If low call completion rate and high handover call drop rate in some areas due to
improper network planning. It may not necessarily means that this area is not covered
by the network, but this area may possibly be covered by multiple cells. WCDMA is a
self-interference system, the coverage over this area may become very poor if multiple
cells can separately have a good coverage on this area and they are opened at the same
time. It is because the signals from other cells are part of the noises for a specific cell,
which is the so-called pilot pollution. In this case, make network plan to this area.
6-8
SJ-20100603155704-010|2011-11-22(R1.2)
Chapter 7

Shooting of Radio Load
Fault
Table of Contents
Overview to Radio Load Fault ....................................................................................7-1
Typical Radio Load Faults ..........................................................................................7-2
7.1 Overview to Radio Load Fault

In WCDMA equipment, the monitoring over radio load is an important precondition to
ensure a stable equipment running and provide reliable QoS.
In ZXWR RNC, the radio load monitoring includes admission control, congestion control
and load control. In the normal running of the system, the ZXWR RNC can take effective
measures for the new services according to the use of radio resources to ensure the system
load to be within the controllable range. Meanwhile, it ensures service requests by users.
However, there will be some faults occurring in the system process, such as blocked calls,
poor quality communication, constant interruption of services, and long-term high-load of
cells. These faults can be are caused due to the following:
l
l
l
l
l
l
Improper network planning

Insufficient coverage
Too large co-frequency interference
Geographical environment
Improper system parameter configuration
Abnormal hardware status
There may be various phenomena, but the way of handling can be referred. This chapter
describes the analysis and handling of radio load faults.
7-1
SJ-20100603155704-010|2011-11-22(R1.2)
7.2 Typical Radio Load Faults

7.2.1 All Calls in a Cell Rejected
Fault phenomena
All calls in a cell are rejected.

All the calls in a cell cannot get through, which is definitely due to the cell configuration or
the hardware error.
Check the faults in the following aspects:
1. Check the status of the cell, its total emission power and the power setting of the
physical channels at the background.
2. Check the communication link.
3. Check whether there is any alarm through alarm management.
4. Make a test call again by replacing slots or boards.
5. Check the configurations of the current cell and cell overload threshold
Trouble shooting
1. If the cell status is not existent, de-blocking and no resource faults,
the cell establishment is unsuccessful. Unblock the cell and re-establish it.
2. If parameters such as background power are too low, properly adjust them, higher
within the range of power setting.
3. For the reason of hardware, replace the parts.
4. If the reason is the overload on the uplink or downlink, refer to Cell Load Always
High to find out why the cell load is too high or check whether cell overload threshold
configuration is unreasonable.
Cautions
None.
7.2.2 Users Requests Frequently Rejected

Fault phenomena
Users requests are frequently rejected.

1. The cell is sure to have large traffic strength and a high load.
7-2
SJ-20100603155704-010|2011-11-22(R1.2)
Chapter 7 Analysis and Trouble Shooting of Radio Load Fault
2. Improper parameter configurations cause the rejection of admission.

3. CN has not passed the UE inspection.
Trouble shooting
1. Check the load and traffic strength of the congested cell. If the congestion results from
the normal traffic, expand the base station.
2. If the system load of the hot-spot area is very high, try HCS hierarchical cell. Use the
micro-cell with the same coverage as of macro-cell to share the load of macro-cell.
3. View the settings of background admission threshold parameters.
configuration is not correct, adjust it.
If parameter
4. Use other UEs to make a call request test on the cell. If other UEs can be admitted for
implementing the same service request, modify the registration message for this UE
in the clock base of other UEs at CN agent.
5. If the admission is refused, measure via the background performance and check the
statistics of all acceptance failure. Adjust the cell power according to actual cases and
distribute the channelized codes.
Cautions
None.
7.2.3 Cell Load Always High

Fault phenomena
The load of the cell always remains high.

1. The reason may be too high configuration of such parameters as cell overload
threshold. The load of the cell is already high, but it does not reach the overload
threshold, so the load control fails.
2. The cell load goes but the configuration of load overload recovery threshold is too high,
which results in cell load rise, and the bandwidth increases when the traffic increases
suddenly.
3. The traffic or the data throughput of this cell is very high indeed and the actual need
of users is great.
4. It may be inaccurate measurement due to hardware failure.
5. Downlink public physical channel occupies too much power. The power parameter of
public physical channel is related to P-CPICH. If the power parameter configuration of
P-CPICH is unreasonable, other public physical channels may occupy high power.
6. There is serious interference on the uplink.
7-3
SJ-20100603155704-010|2011-11-22(R1.2)
The following methods can deal with the faults:

1. View the thresholds related to load control at ZXWR RNC background
2. Check whether there is any alarm through alarm management
3. Make a statistics on traffic and data throughput
4. Replace slots and boards and then make a comparison test.
5. Check the configuration parameters on the background, or check the reported value
of cell downlink public measurement in the case of no calls.
6. Check the reported value of cell uplink public measurement in the case of no calls.
Trouble shooting
1. If it is for the reason of parameter configuration, change the configuration
2. If both traffic and data-throughput are very high, expansion is needed or the HCS
hierarchical cell is used for load sharing.
3. If it is for the reason of the hardware fault, replace the hardware.
4. Modify configuration parameters related to background common channel power.
5. If it is for the reason of WCDMA co-frequency interference or other interference due
to GSM1800 and PHS, make the network planning again.
Cautions
None.
7.2.4 Ping Packet Failed

Fault phenomena
Pinging a packet failed.

1. If this packet is large, try replacing it with a smaller one.
2. All the packets of different sizes cannot be pinged through, which may result from
abnormal startup of PDN. Especially the batch processing of the route service, Route
_Add.bat, has not normally run.
3. Routing table may be incorrect
4. ZXWR RNC Ethernet transmission may posses problems.
1. Ping a smaller packet.
2. Check the batch processing program of PDN and routing service.
7-4
SJ-20100603155704-010|2011-11-22(R1.2)
3. Ping packets from PDN to UE, to see if there is any data increase. If it is not available,
check the routing table.
4. Change the PC and make a test of pinging a packet.
5. Ping packets from PDN to UE, to see whether there is any data increase on the user
panel. If is not available, check the ZXWR RNC Ethernet transmission.
Trouble shooting
1. Modify MTU of CN to a larger value if the larger packet cannot be pinged through.
2. Restart PDN and run the batch processing program of Route_Add.bat.
3. Modify the routing table.
4. Modify the local IP.
5. Replace the hardware.
Cautions
None.
7.2.5 Poor QoS of User Services

Fault phenomena
The QoS of the user services is poor.

1. It may be the reason of its geographical location, such as the shadow of a high building,
some corners, where coverage is not so good.
2. It may be the reason of incorrect information about user subscription. The maximum
rate of uplink/downlink link and the ensured bit rate are smaller than the expected
settings, and with a large delay.
3. It may be the reason of wrong configuration of parameters of ZXWR RNC background
physical layer, RLC layer and PDCP layer.
4. PC performance of UE connection is low.
5. The network cable connection is improper.
6. The optical interface is abnormal.
7. The rate is lower than the data line due to the use of the Bluetooth technology.
8. The speed is affected due to the network cable connected to the slot corresponding
to the user board.
1. Check the receiving pilot strength of UE.
7-5
SJ-20100603155704-010|2011-11-22(R1.2)
2. View the user subscription on the agent of CN.

3. View the parameter configuration at the ZXWR RNC background.
4. Use a PC and a network cable with higher performance for comparison.
5. Check the slot of optical interface, data line and slot.
Trouble shooting
1. Change the position.
2. Modify the users subscription information.
3. Modify the service parameters of ZXWR RNC background, including the configuration
of parameters of physical layer, RLC layer and PDCP layer.
4. Change the PC, the network cable or the data line.
Cautions
None.
7.2.6 Imbalanced Load between HCS Cells

Fault phenomena
The load between HCS cells is imbalanced.

The HCS cells can improve the user QoS and the load balance between cells. Handover
some users to the cells in the same coverage to achieve the goal of load balance when
the load of a cell is too high while that of the cells in the same coverage is too low. There
may be the following reasons for load imbalance:
1. The parameters related to load balance are wrongly configured. For example,
triggering the load threshold for cell balance, or setting an extremely high inter-cell
load margin differences.
2. It may be the problem of parameter configuration of the adjacent cells, that is, the
micro-cell in the same coverage has not been configured to an adjacent cell of the
macro-cell.
3. It may be the problem of network planning, that is, irrational coverage of HCS hierarchy,
and the micro-cell cannot provide users with the same service quality as the macro cell.
The following methods can be used to troubleshoot the faults:
1. Check the configuration of load balance threshold parameters and the adjacent cell
list at the ZXWR RNC background.
2. Test the coverage of the HCS cell by means of a route tester.
7-6
SJ-20100603155704-010|2011-11-22(R1.2)
Trouble shooting
1. Configure the load balance threshold parameters properly.
2. Add the micro cell to the adjacent cell list of the macro cell.
3. Make the network planning again.
Cautions
None,
7.2.7 Impossible Service Establishment due to Incorrect Setting

of Cell Status
Fault phenomena
A cell originated a call but failed.

The call of the whole cell fails. Troubleshoot step by step, by checking if the cell is
successfully established, if there is any board alarm and if the transmission line is normal.
Trouble shooting
1. Check whether this cell establishment is successful through OMC unified client, and
whether the cell status is correct.
2. Un-block the cell at Node B background.
3. Make a call again, and establish the service successfully and the fault disappears.
Cautions
None.
7.2.8 Low Access Rate due to Radio Configuration Data

Modification Error
Fault phenomena
The admission success rate of some cells is very low and the service rate is extremely
unstable. It is found through traffic and data throughput that both traffic and throughput
are not large.

This problem is generally due to parameter configuration and unstable transmission.
7-7
SJ-20100603155704-010|2011-11-22(R1.2)
Trouble shooting
1. Check the alarm management and find no board alarm and the indicators of the boards
are normal.
2. Check the connection cables and find all are normal.
3. Check the log management of ZXWR RNC background and find that there is a record
for modifying the radio resource configuration parameter recently.
4. Back up the current data and recover the radio parameter configuration before
modification recovery.
5. Run the same service after the system becomes stable, and the fault disappears.
Cautions
None.
7.2.9 Service Interruption due to Cell NCP Link Fault

Fault phenomena
The stream media service is extremely unstable and often interrupted.

Check whether the cell establishment is normal through OMC unified client and check
whether Iu interface resource (mainly No.7 link/AAL2) establishment is normal. Check the
status of physical configuration resources to see whether it is the resource fault. The main
contents to check include NCP/CCP/ALCAP link.
Trouble shooting
1. Check whether the cell establishment is normal. Query the cell status and find its
status as Existent, de-blocking and no resource fault, which shows that the cell
establishment is successful
2. Check the cell link. Query the status of ZXWR RNC ground resource management
links, and find NCP is error.
3. Observe Iub interface transmission signaling with a special tool to analyze the causes
for failed link setup.
4. Back up the current ZXWR RNC configuration data.
5. According to the operation record in ZXWR RNC operation log and combining the
above mentioned fault analysis result, check the corresponding configuration data.
Find out the error data that result in abnormal user service, and modify them.
6. Wait for the system to recover and enter the stable status. Observe if the service has
been restored to normal, and it is found that the fault disappears.
7-8
SJ-20100603155704-010|2011-11-22(R1.2)
Cautions
None.
7.2.10 Service Operation Impossible Caused by Mobile Station

Problem
Fault phenomena
After successful dialup, such services as file downloading and stream-media playback
cannot run.

This phenomenon has a special nature, which is tested by pinging a packet. An easy way
is to install a DUMETER, to see if the mobile phone sends or receives a packet.
Originate the packet PING from UE, and there is a problem of dialup if there is no display
on DUMETER, then upgrade the dialing version. If there is a packet and the statistics shows
uplink but no downlink, then check CN.
Alternatively, originate packet Ping from PDN. If DUMETER displays a received packet but
no packet is returned, this shows the problem of the mobile phone.
Trouble shooting
1. Install DUMETER software and monitor whether the mobile phone sends or receives a
packet in the way of packet Ping.
2. Originate the packet Ping from UE, and DUMETER displays a packet sent. The user
plane statistics shows the packet can be received, which indicates no problem of
uplink. The user plane statistics shows a packet is also sent at the downlink, which
indicates no problem of the network side.
3. Run the command of IPConfig on the connected machine to see the subnet address
is with same IP as PDN, which corresponds to UE address.
4. Originate packet Ping from PDN. The address of PING is the one allocated to UE.
DUMETER shows that UE can receive the packet but no packet is sent. Judging from
this, UE has no problem, and no fault occurs to such services as packet pinging. Run
file downloading and stream media playback by changing the mobile phone for dialing.
Cautions
None.
7-9
SJ-20100603155704-010|2011-11-22(R1.2)
7.2.11 Very Poor QoS of PS Service Caused by Data Line Fault

Fault phenomena
The playback of stream media is interrupted continually and its rate is often lowered or
interrupted.

Data line fault.
Trouble shooting
1. View OMC alarm management and find that the interface board DTB generates an
alarm.
2. Check the E1 indicator of DTB and find that the indicator is always ON instead
of the slow-blinking status in the normal case, which shows the blocked link data
configuration.
3. Plug and unplug the data line again and the fault still exists.
4. Change a piece of normal data line for observation again, and the fault disappears.
Cautions
None.
7.2.12 Service Interruption Caused by Network Node Fault

Fault phenomena
The playback of stream media is interrupted continually and its rate is often lowered or
interrupted.

Network node fault.
Trouble shooting
1. View OMC alarm management and find no alarm information.
2. Make a comparison test and the interruption still exists in the use of downloading
service.
3. Reduce the source rate. If the fault still exists, the fault is unrelated to the playback
rate supported by the application layer software.
4. Check whether virus attacks the server. The fault still exists when a PC with higher
performance is used.
7-10
SJ-20100603155704-010|2011-11-22(R1.2)
5. Change the position of network node on HUB and the fault disappears, which shows
the problem of the original jack on HUB.
Cautions
None.
7.2.13 Common Channel Congestion Caused by Lots of SMs Sent

in Centralized Way
Fault phenomena
The radio call completion rate is low, because of the congestion of common channel from
the traffic statistics.

The common channel is congested but not the private channel, which is completely caused
by the signaling or service only using the common channel. If lots of position update
messages or lots of SMs are sent simultaneously, it is easy for the common channel
resources configured statically to congest. This is because the common channel provides
a small bandwidth in general.
Trouble shooting
1. From the traffic statistics, the strength of the public physical channel is little higher than
a high congestion rate, which results in a little low radio call completion rate.
2. This case usually occurs on holidays, festivals, or widespread emergencies. A large
quantity of SMs are sent simultaneously and the occurrence of congestion of the
physical common channel is extremely easy. This is because, the transmission of
SMs only occupies the common channel, but not the private channel and the common
channel has not a large bandwidth.
3. During holidays, increase the configuration of public physical channel or allocate the
public physical channel dynamically.
Cautions
None.
7.2.14 Always-High Cell Load Caused by TRX Fault

Fault phenomena
A base station has a configuration of 2-carrier 6-sector, and one of its cells has a very high
load since a day but the traffic and throughput is not so high, and many channels are idle.
7-11
SJ-20100603155704-010|2011-11-22(R1.2)

The cell load is always high due to TRX fault.
Trouble shooting
1. Through the public measurement of base station, find that the load of several cells of
Carrier 1 is high.
2. View the alarm management interface and find that TRX1 has alarms and RUN
indicator on TRX1 board blinks abnormally.
3. Through the diagnosis test and the unit test of TRX1, find the result is abnormal.
4. Replace the slot of TRX1. The fault still exists after the cell load statistics for a period.
5. Replace TRX1 and make a frequency-locked dialing test. The cell load becomes
normal and the fault disappears after the cell load statistics for a period.
Cautions
None.
7.2.15 Serious Uplink Interference Caused by Irrational Floor Noise

Configuration
Fault phenomena
The uplink interference of a cell is very serious but still can approach the new service, and
it appears to be the failure of admission control.

The uplink interference is very serious due to the irrational floor noise configuration.
Trouble shooting
1. View the alarm management and find no board alarm currently.
2. Check the blinking of indicators on the boards and find all are in normal status, so the
measurement result must be accurate.
3. Record the uplink interference value of the current measurement to serve as the
admission threshold for uplink interference. Configure it in the parameters related to
the background admission control of ZXWR RNC.
4. Make several calls consecutively and find that admission succeeds, so the
pre-estimated uplink interference and the original uplink value have not changed.
5. It may be the irrational setting of floor noise, which is quite different from the
actual value through analyzing several factors of affecting the pre-estimated uplink
interference.
7-12
SJ-20100603155704-010|2011-11-22(R1.2)
6. Re-configure the floor noise and configure according to the uplink interference value
upon empty cell load. Make a test again and find that the uplink interference has been
under a good control and the fault disappears.
Cautions
None.
7-13
SJ-20100603155704-010|2011-11-22(R1.2)
7-14
SJ-20100603155704-010|2011-11-22(R1.2)
Chapter 8

Shooting of Access Fault
Table of Contents
Overview to Access Fault ...........................................................................................8-1
Typical Access Faults.................................................................................................8-1
8.1 Overview to Access Fault

Mobile terminal needs to make NAS interaction with the network side. NAS interaction
includes request for services, registration report and shutdown report to the network side,
which requires origination of access process.
Access process includes two parts:
1. The terminal establishes the RRC connection with UTRAN.
2. The terminal interacts with CN.
8.2 Typical Access Faults

8.2.1 Mobile Terminal Does Not Originate RRC Connection Process
Fault phenomena
The test terminal shows that the terminal has not originated the process of RRC connection
establishment request.

1. Check whether the cell is running normally.
View the attribute of the cell related to OMC-R to determine the cell normality.
2. Check whether the common channel establishment is normal. View the signaling trace
in OMC-R, and observe whether the cell related to Iur interface has the process of
repeating deletion and creation of public transport channel. If the fault still exits, the
common transport channel cannot run normally.
3. Check whether the system message broadcast is normal.
8-1
SJ-20100603155704-010|2011-11-22(R1.2)
View the signaling trace in OMC-R to observe whether the cell related to Iur interface
has delivered the system broadcast message. Carefully check whether Access Class
Barred list cell and Cell Barred in SIB5 message bar the cell access or bar the terminal
access of some Access Class and whether Qqualmin and Qrxlevmin configuration
values are too large to make UE hard to select this cell.
Trouble shooting
l
The establishment of the cell and the common transport channel is in the abnormal
status.
1. Check whether the connection of ATM link between ZXWR RNC and Node B is
normal.
Use link status dynamic query function of OMC-R to observe whether ATM link
is in normal status. If not, check the configuration of ATM link at both sides. If
they are not consistent, configure the parameter of ATM link at both sides again
and pay attention to data synchronization. If they are consistent, check whether
the physical connection is normal (optical fiber or E1) and whether the physical
connection attempt can be updated.
2. Check whether the cell configuration at ZXWR RNC and Node B is consistent.
View the configuration of related cell in OMC-R at ZXWR RNC and Node B. Check
whether the frequency point is consistent. Configure it again if it is not consistent,
and pay attention to data synchronization.
3. Check whether parameters of ZXWR RNC common transport channel are correct.
View the parameter configuration of the common transport channel in OMC-R.
Carefully check whether the configuration of TFS and CTFC is consistent with
that provided in default background data configuration. If there is any difference,
correct it or ask related technicians.
Abnormal system message broadcast

1. The related cell has not delivered any system message broadcast.
View the parameters according to ZXWR RNC parameter configuration manual
to determine whether all necessary SIBs are completely configured. Configure
the incorrect SIBs by the correction at the background OMC-R, and data
synchronization should be noted.
2. Irrational setting of cell selection parameters
3. If Access Class Barred list cell and Cell Barred in SIB5 message bar the cell
access or the terminal access of some Access Class. Use OMC-R to lift this
access barring and observe whether the terminal can be accessed. Otherwise,
lower Qqualmin and Qrxlevmin thresholds in the background OMC-R of related
cell to minimum, and observe whether the terminal can start to access. If
not, check whether the system broadcast message configuration parameter is
correct through the background OMC-R according to ZXWR RNC parameter
8-2
SJ-20100603155704-010|2011-11-22(R1.2)
Chapter 8 Analysis and Trouble Shooting of Access Fault
configuration manual. The data synchronization is necessary after modifying the

configuration through the background OMC-R.
Cautions
None.
8.2.2 RNC Equipment Unable to Receive RRC Connection

Establishment Process from Mobile Terminal
Fault phenomena
1. The test terminal shows that the terminal has originated the process of RRC connection
establishment request in the related cell.
2. ZXWR RNC background signaling trace observes no RRC connection establishment
request message in related cell.

1. Check whether RACH channel parameter configuration of related cell is correct.
2. Query the preamble access threshold of RACH channel on OMC-R of ZXWR RNC
background.
Trouble shooting
RACH channel parameter configuration is incorrect. If the preamble access threshold for
RACH channel is lower than 13.5, correct it to 13.5.
Cautions
None.
8.2.3 RNC Equipment Having Insufficient Resources to Establish

RRC Connection for Mobile Terminal
Fault phenomena
1. The test terminal shows that the terminal has originated the process of RRC connection
establishment request in related cell.
2. ZXWR RNC background signaling trace does not observe any reject message about
delivering RRC connection in related cell due to congestion.

1. Check the radio congestion counters of related cells at the background.
Observe whether the admission rejection counter is not 0.
8-3
SJ-20100603155704-010|2011-11-22(R1.2)
2. View the alarm management of the background.

Check whether some processing boards have the overload alarm.
3. Check the load balance parameter of related cell at the background.
Check whether the load balance parameter of related cell at the background is
configured. ZXWR RNC foreground must judge the load balance in the process of
accessing the mobile terminal RRC. If the related load balance parameter is not
found, the current cell is deemed as incapable of providing services.
Trouble shooting
l
The related cell has rejected admissions.

In this case, the radio load of related cell has exceeded the admission load threshold.
To solve the problem, check whether the admission load threshold configuration
meets ZXWR RNC parameter configuration manual. If not, correct it. If the threshold
configuration is correct, make the network planning again according to local traffic
model, to ensure to control the radio load below the admission load threshold and
meet the requirements of cell services.
Some processing boards have overall load overload alarm.

1. The processing capability of some ZXWR RNC processing boards has reached
the rated limit and cannot normally process new services. Check whether
background physical board-processing threshold configuration meets ZXWR
RNC parameter configuration manual. If not, correct it.
2. If the threshold configuration is correct, check the indicators on the physical board
of ZXWR RNC rack to see whether there is any physical board failing to start or
abnormal, which results in overloaded running of other boards under load sharing.
If so, restart these boards.
3. If the board fails to start or is abnormal, the network planning personnel
should calculate the processing capability supported by ZXWR RNC equipment
and judge whether it exceeds ZXWR RNC design capability. If so, add the
configuration of ZXWR RNC processing board to improve overall overloading
situation.
The related cell has not been configured the load balance parameters at the
background.
Configure the load balance parameters at the background according to ZXWR RNC
parameter configuration manual. Note the data synchronization.
Cautions
None.
8-4
SJ-20100603155704-010|2011-11-22(R1.2)
Chapter 8 Analysis and Trouble Shooting of Access Fault
8.2.4 Iu Interface Communication Links between RNC Equipment

and CN Equipment are Blocked
Fault phenomena
UE cannot be successfully registered after being started up.

The communication link between ZXWR RNC and CN is blocked, and the initial direct
transmission of UE uplink cannot arrive at CN.
Trouble shooting
1. Observe the background signaling trace and find that the network side receives initial
direct transmission message of UE at Uu interface but not from Iu interface to CN.
2. Check the bottom layer physical link of Iu interface and find it is normal.
3. ZXWR RNC and CN verify Iu interface communication link configuration, and find
that No.7 link signaling point configuration of MSC office direction at both sides is
inconsistent. Modify the configuration of ZXWR RNC signaling point.
4. The mobile terminal can successfully access the network.
Cautions
After the equipment at the network side starts to run normal, ZXWR RNC and CN must
verify the consistency of the link configuration parameters at both sides.
8-5
SJ-20100603155704-010|2011-11-22(R1.2)
8-6
SJ-20100603155704-010|2011-11-22(R1.2)
Chapter 9

Shooting of Radio Service
Bearer Fault
Table of Contents
Overview to Radio Service Bearer Fault .....................................................................9-1
Typical Radio Service Bearer Faults ...........................................................................9-1
9.1 Overview to Radio Service Bearer Fault

The radio service bearer is the radio transmission bearer provided by UTRAN to support
different application services. The radio transmission bearer meets the application service
QoS requirements.
The radio service bearer involves the following aspects:
l
l
l
l
Radio
Radio
Radio
Radio
service Iu interface bearer establishment

service Iub interface bearer establishment
service Uu interface bearer establishment
service bearer QoS guarantee
9.2 Typical Radio Service Bearer Faults

9.2.1 CS Domain Service Iu Interface Bearer Establishment Failure
Fault phenomena
1. ZXWR RNC receives the establishment request of CS domain radio bearer of CN.
2. ZXWR RNC fails to establish Iu interface user plane bearer Iuup, which causes the
establishment failure of the service bearer.

Check whether CS domain data-link data-configuration at ZXWR RNC and CN is correct.
9-1
SJ-20100603155704-010|2011-11-22(R1.2)
Trouble shooting
If CS domain data link data configuration at ZXWR RNC and CN is inconsistent, modify
the configuration at two sides.
Cautions
None.
9.2.2 PS Domain Service Iu Interface Bearer Establishment Failure

Fault phenomena
1. ZXWR RNC receives the establishment request of PS domain radio bearer of CN.
2. ZXWR RNC fails to establish Iu interface bearer GTP-U, which causes the
establishment failure of service bearer.
9.2.3 Service Iub Interface Bearer Establishment Failure

Fault phenomena
ZXWR RNC fails to establish Iub interface ground bearer, which causes the establishment
failure of service bearer.

Check whether the bandwidth configuration of Iub interface service data AAL2 link at
ZXWR RNC side meets the service requirements.
Trouble shooting
The bandwidth of Iub interface service data AAL2 link at ZXWR RNC side is too small
and cannot meet the service bearer requirements. According to ZXWR RNC parameter
configuration requirements, increase AAL2 link bandwidth in the background OMC-R
interface.
Cautions
None.
9.2.4 Service Uu Interface Bearer Establishment Failure

Fault phenomena
ZXWR RNC fails to allocate Uu radio resources, which causes the establishment failure
of service bearer.
9-2
SJ-20100603155704-010|2011-11-22(R1.2)
Chapter 9 Analysis and Trouble Shooting of Radio Service Bearer Fault

1. View the counter statistics of the radio bearer establishment in corresponding cells.
Check whether the radio bearer establishment counter has the failure caused by radio
congestion.
2. Check the background signaling tracing.
Check the capability report of corresponding UE. Especially focus on the maximum
number of TFC and maximum number of simultaneous transport channels limitation
of UE.
Trouble shooting
1. The failure of radio bearer establishment results from radio congestion.
In this case, the radio load of the related cell has exceeded the admission load
threshold. To solve the problem, check whether the admission load threshold
configuration meets ZXWR RNC parameter configuration manual. If not, correct it.
If the threshold configuration is correct, make the network planning again according
to local traffic model, to ensure to control the radio load below the admission load
threshold and meet the requirements of cell services.
2. The establishment failure of the radio bearer may result form the old UE version, which
has a too low capability and cannot meet the service requirements.
In WCDMA system, multi-service concurrent is usually supported. However, there are
some special requirements for the number of transmission channels and maximum
number of TFCs supported by UE at a time. The old version mobile phones may not
meet the requirements, so they cannot enjoy the service.
Cautions
None.
9.2.5 QoS of PS Domain Services Failing to Meet Upper-layer

Service Requirements
Fault phenomena
1. ZXWR RNC successfully establishes the radio bearer for the upper-layer application.
2. QoS provided by the radio bearer cannot meet the upper-layer service requirements.

1. Check the priority configuration of the upper-layer service through the background
OMC-R.
Check the priority of the corresponding service configuration according to ZXWR
RNC parameter configuration manual. If the configuration is inconsistent, modify it as
9-3
SJ-20100603155704-010|2011-11-22(R1.2)
appropriate. If the priority of a service is set too low, it is normal if the service cannot
obtain the higher QoS. The service with a high priority, frequently suppresses its QoS
during the high load phase.
2. Check the parameter configuration of dynamic radio bearer control in the background
OMC-R.
Check whether the parameter configuration of dynamic radio bearer control in the
background is consistent according to ZXWR RNC parameter configuration manual. If
incorrect, modify it. If the parameter configuration of dynamic radio bearer control is not
consistent with the manual configuration, the adjustment frequency of the PS service
bottom velocity is not correct. Sometimes, the rate adjustment algorithm becomes
invalid, and the service QoS cannot be guaranteed, when there are enough radio
resources.
Trouble shooting
Fault locating has been introduced.
Cautions
None.
9-4
SJ-20100603155704-010|2011-11-22(R1.2)
Chapter 10

Shooting of Radio Global
Resource Fault
Table of Contents
Overview to Radio Global Resource Fault ................................................................10-1
Typical Radio Global Resource Faults ......................................................................10-1
10.1 Overview to Radio Global Resource Fault

The radio global resources at ZXWR RNC side include the global resource of Iu interface,
Iub interface and Iur interface. Iub interface refers to cells, common channels, common
measurement, and system information. Iu interface refers to the office direction overload
information. Iur interface refers to public measurement.
10.2 Typical Radio Global Resource Faults

10.2.1 Cell Fault
Fault phenomena
1. The cell establishment failed.
2. The cell establishment failed.
3. The cell is abnormally deleted.

The cell establishment process includes resource application on RUB, sending of
establishment message to Node B, and returning of response messages by Node B. The
fault is analyzed as follows according to the establishment process:
1. RUP is not powered on for running.
View the RUP status at the background. If DSP on RUP is blocked, this RUP is not
running normally.
2. NCP link between Node B and ZXWR RNC is interrupted.
10-1
SJ-20100603155704-010|2011-11-22(R1.2)
View NCP status at the background. Refer to NCP Link Fault Alarm if the status is
abnormal.
3. If the data configuration of ZXWR RNC and Node B is inconsistent, check the data at
both ends.
Compare the cell configuration of this Node B at ZXWR RNC and Node B background.
It shows mismatched data at both ends if they are inconsistent.
4. The protocol version or protocol cell supported by ZXWR RNC and Node B is not
consistent.
Use the signaling meter and version description to compare the radio protocol version
or protocol cell supported by ZXWR RNC and Node B.
Trouble shooting
l
l
l
l
If RUP is not powered on for running, insert RUP tightly in the shelf or replace RUP.
If NCP link is interrupted, clear NCP link interruption fault according to NCP Link
Fault Alarm.
If the data configuration of ZXWR RNC and Node B is not consistent, modify the
configuration data according to the actual condition of resources.
If the protocol versions or protocol cells supported by ZXWR RNC and Node B are
not consistent, upgrade the related software version.
Cautions
None.
10.2.2 Common Channel Fault

Fault phenomena
l
l
The common channel not established.

Repeating deletion and creation of common channel.

Establish the common channel after establishing the cell. The cell establishment includes
sending an establishment message to Node B, returning of a response by Node B, AAL2
link establishment and FP synchronization. The establishment message to Node B is sent
on NCP and the cause may be NCP interruption. Establishing and ERQ in AAL2 is sent on
ALCAP link, so ALCAP link failure may result in AAL2 link establishment failure. Fiber fault
and misconnection may result in the failure because the data fails to get to the peer end. To
send ERQ to the peer end on AAL2 link, get the office direction according to ATM address.
The inconsistent ATM address configuration may result in incorrect office direction.
Therefore, possible causes are:
1. NCP link broken
2. Cell Fault
10-2
SJ-20100603155704-010|2011-11-22(R1.2)
Chapter 10 Analysis and Trouble Shooting of Radio Global Resource Fault
View the cell status at the background. If the cell is in the abnormal status, make a
fault cause analysis on the cell fault referring to CS Domain Service Iu Interface Bearer
Establishment Failure.
3. ALCAP link fault
View ALCAP link status at the background. If ALCAP link is in abnormal status, ALCAP
link from ZXWR RNC to this Node B is blocked.
4. Optical fiber is faulty or wrongly connected.
View whether the optical fiber is faulty, the self-loop mode of SSCOP link or the auxiliary
instrument can be used. Check whether the input and output at the two sides of the
optical fiber are according to the fiber connection map.
5. If the data configuration of ZXWR RNC and Node B is inconsistent, check the data at
both ends.
Check whether ATM address and AAL2 link ID of ZXWR RNC and Node B are
consistent. Observe whether the common channel parameter configuration of ZXWR
RNC and Node B is consistent.
6. ZXWR RNC parameter configuration is incorrect.
Check whether the parameter related to ZXWR RNC common channel is wrongly
configured according to ZXWR RNC parameter, such as TFCS.
7. The protocol version or protocol cell supported by ZXWR RNC and Node B is not
consistent.
Use the signaling meter and version description to compare the protocol version or
protocol cell supported by ZXWR RNC and Node B, including the radio network layer
and the transmission network layer.
Trouble shooting
1. If NCP link is broken, refer to NCP Link Fault Alarm.
2. If it is the cell fault, use the handling method of cell faults according to CS Domain
Service Iu Interface Bearer Establishment Failure.
3. If ALCAP link is faulty, check whether DTB and IMAB are offline on O&M interface.
If ALCAP link is not successfully established for long time, ZXWR RNC attempts to
re-establish ALCAP link. Check whether E1 line of DTB is correctly inserted.
4. If the optical fiber is faulty, replace it. If it is wrongly inserted, change the position of
the optical fiber.
5. If the data configuration of ZXWR RNC and Node B is not consistent, modify the
configuration data according to actual condition of resources.
6. If ZXWR RNC parameter is wrongly configured, modify the common channel
parameter according to ZXWR RNC parameter configuration manual.
7. If the protocol versions or protocol cells supported by ZXWR RNC and Node B are not
consistent, upgrade the related software version.
10-3
SJ-20100603155704-010|2011-11-22(R1.2)
Cautions
Check the data configurations of the two NEs before interconnecting them. When
repeatedly deleting and establishing common channels, check the configuration data first.
In addition, Path ID inconsistence of AAL2 link that ZXWR RNC and Node B configure
may result in same fault.
10.2.3 System Information Broadcast Failure

Fault phenomena
No system information broadcasted, and UE displays no service.

The system information broadcast is sent on NCP to Node B, and the content of broadcast
is determined according to DBS data configuration. According to this process, the fault
cause analysis is:
View NCP status at the background. For the abnormal status, refer to NCP Link Fault
Alarm.
2. Common channel fault
If there is no FACH or PCH available in the cell, the system information is not broadcast
because the actual channel status of this cell is not reflected yet. Refer to Common
Channel Fault.
3. Parameter is not configured
Check whether all necessary SIB parameters have been configured at the background.
4. The parameter configuration is incorrect.
The parameter configuration error may result in coding failure. Refer to ZXWR RNC
(V3.09.30) Radio Network Controller Ground Parameter Reference for the correctness
of the parameters.
Trouble shooting
1. If NCP link is interrupted, clear NCP link interruption fault according to NCP Link
Broken.
2. If the common channel is faulty, refer to Common Channel Fault.
3. If the parameter is not configured, refer to ZXWR RNC (V3.09.30) Radio Network
Controller Ground Parameter Reference for the SIB parameter configuration.
4. If the parameter is wrongly configured, refer to ZXWR RNC (V3.09.30) Radio Network
Controller Ground Parameter Reference to modify related parameters.
10-4
SJ-20100603155704-010|2011-11-22(R1.2)
Chapter 10 Analysis and Trouble Shooting of Radio Global Resource Fault
Cautions
None.
10.2.4 Iub Interface Public Measurement Fault

Fault phenomena
The public measurement of Iub is not reported.

Iub public measurement sends the public measurement control message to Node B
through NCP after the cell or common channel is established. The measurement
parameter depends on DBS data configuration, and Node B reports the measurement
results according to the measurement control information parameter. According to this
process, the fault cause analysis is:
View NCP status at the background. For the abnormal status, refer to NCP Link Fault
Alarm.
2. Cell Fault
View the cell status at the background. If the cell is in the abnormal status, make a
fault cause analysis on the cell fault according to Cell Fault.
3. Common channel fault
View the status of common channel at the background. If it is abnormal, refer to
Common Channel Fault.
4. The measurement parameter is incorrectly configured.
Wrong parameter configuration may result in no report of public measurement. For
example, the periodical report time is set too long, or the delay time is set too long.
5. The measurement function is not supported.
Node B may not support some public measurements, which can be determined
according to the version description of Node B.
Trouble shooting
1. If NCP link is interrupted, clear the NCP link interruption fault according to NCP Link
Fault Alarm.
2. If it is the cell fault, use the handling method of cell faults according to Cell Fault.
3. If the common channel is faulty, refer to Common Channel Fault.
4. If the measurement parameter is wrongly configured, modify the related parameter
according to ZXWR RNC parameter configuration manual.
5. If the measurement function is not supported, upgrade Node B software version.
10-5
SJ-20100603155704-010|2011-11-22(R1.2)
Cautions
None.
10.2.5 Iu Overload Control Failure

Fault phenomena
ZXWR RNC reports to CN in the case of low ZXWR RNC traffic that overload causes failing
to get through mobile phone.

There are two reasons for ZXWR RNC to send the overload message: RCPs with CPU
overloaded reach a certain number or No.7 signaling reports congestion. According to the
trigger cause, the fault cause analysis is:
1. CPU overload threshold is set too low.
Check whether CPU overload threshold is too low at the background. CPU overload
threshold means that CPU overload can be triggered if CPU load of RCP exceeds this
threshold.
2. The number of the overloaded RCPs has a too low threshold.
View the threshold for the number of overloaded RCPs at the background. The
threshold for overloaded RCPs means to send a signaling overload message when
the number of RCPs with CPU overloaded exceeds this number threshold.
3. No.7 Link Interruption
View the status of No.7 signaling link at the background. Since the interruption of
some No.7 signaling links may lead all the signaling to be sent in a signaling link in
a centralized way and cause blocked signaling link. ZXWR RNC sends a signaling
overload message to CN after it detects the congested signaling link between it and
CN.
Trouble shooting
1. If the CPU overload threshold is set too low, modify CPU overload threshold value.
2. If the threshold for the overloaded RCPs is too low, modify it.
3. For the interruption of No.7 signaling link, refer to Abnormal Status of No. 7 Link.
Cautions
Verify the correctness of data configuration and avoid any missing data. Possible causes
for Iu overload in the case of low ZXWR RNC traffic are CPU overload. It may because
Link No. 7 congestion in the case of heavy traffic.
10-6
SJ-20100603155704-010|2011-11-22(R1.2)
Chapter 11
Trouble Shooting Record

Table
Table of Contents
Trouble Shooting Record Tables...............................................................................11-1
11.1 Trouble Shooting Record Tables

Office Name: __________________
Time of Fault Occurrence: (HH-MM-DD-YY)
Time of Solution: (HH-MM-DD-YY)
Device name
Equipment No.
OMC
Major alarm
Routine
Radio load
maintenance
User complaint
Hardware
Fault type
Others
Radio service bearer
Fault source
Switch
Radio global resource
Software load
Access
System communication
Symptom
Fault causes
11-1
SJ-20100603155704-010|2011-11-22(R1.2)
Trouble shooting
method
Cautions
Summary
Outstanding problems:
11-2
SJ-20100603155704-010|2011-11-22(R1.2)
Chapter 11 Trouble Shooting Record Table
Maintenance personnels advice and
Supervisors comment and signature:
signature:
11-3
SJ-20100603155704-010|2011-11-22(R1.2)
11-4
SJ-20100603155704-010|2011-11-22(R1.2)
Chapter 12
Board and Part Replacement

Table of Contents
Overview to Board and Part Replacement ................................................................12-1
Board Replacement..................................................................................................12-1
Part Replacement ....................................................................................................12-2
Small Fan Shelf Replacement ..................................................................................12-4
Optical Module Replacement....................................................................................12-4
BOOT ROM Replacement ........................................................................................12-5
M/S Switchover ........................................................................................................12-5
Board Reset .............................................................................................................12-5
12.1 Overview to Board and Part Replacement

In the process of routine maintenance, replacing the faulty boards and parts is a common
yet important maintenance means. Pay attention to the following principles during the
board replacement:
1. Keep the spare parts in antistatic bags (attached with desiccant) and store in cardboard
boxes. Label the bags and boxes for convenience.
2. Be sure to wear antistatic wrist straps when plugging/unplugging the board. When
holding a board, keep your hands off the board circuit, components, and cabling. Do
not apply too much force on the board to prevent damaging the connectors of the
board and the backplane.
3. Mark the fault information on the replaced faulty board before storing it in the antistatic
bag.
4. When plugging the board, make sure it completely fits into the shelf.
5. Never plug or unplug power boards with the power switched on.
12.2 Board Replacement

Preparations
1. Analyze the fault causes and determine the faulty board to be replaced.
2. Make sure that the spare parts for replacement is in good condition and their models
are consistent. Confirm that the physical board versions, logical board configuration,
programmable logic versions, and boot version tags are same as on the faulty board.
3. Prepare antistatic bags, desiccant, right cardboards and labels.
12-1
SJ-20100603155704-010|2011-11-22(R1.2)
4. Prepare the straight screwdriver and cross screwdriver.
Steps
1. Properly wear the antistatic strap and make sure that the other end of the strap is
grounded.
2. To replace a master board or an optical module of the master board, perform M/S
switching first, to make the current slave board or slave optical path turn to master.
Perform M/S switching to the faulty board or faulty link through NM. When the ACT
indicator in the faulty board becomes off and ACT indicator on slave board becomes
on, the board successfully changed the M/S status.
3. To just replace the optical module
Record the optical fiber type and the connection locations at two ends. Unplug the two
optical fibers of faulty optical paths, open the lock device of the faulty optical module,
unplug the faulty optical module, then plug the spare optical module, close the lock
device, and then connect the optical fibers according to the corresponding connection
relationship.
4. Use a screwdriver to screw off the screws at the board levers, turn outside both
extractor levers to plug off the board from the rack. Draw out the board slowly. During
this process, avoid touching the components and circuits on the board.
5. Align the spare board with the slot, press the lever on it and gently push it in along
the track until the lever is locked, which indicates that the board has been properly
plugged in position. Screw on the captive screws at the board levers.
6. Place the faulty board or optical module into an antistatic bag attached with desiccant.
Label the bag marking the boards or optical module model number, slot number,
program version and fault information, and then store it in the right category.
Verification
Observe the power-on and startup process of the replaced board. If self-test is passed, the
panel indicators display the normal running status, the fault alarm is cleared, and related
services are normal during the test, the replacement is successful.
If the board self-check fails, it performs the self-check again and finally shows abnormality,
and the relevant unit service is not resumed. This indicates the unsuccessful replacement.
In this case, first check whether the replaced spare part is damaged. If it is normal, continue
with fault analysis.
12.3 Part Replacement

Here, parts refer to the whole layer of shelf, whole layer of fan shelf, or the corresponding
backplane.
12-2
SJ-20100603155704-010|2011-11-22(R1.2)
Chapter 12 Board and Part Replacement
Preparation
The preparation process is consistent with that before board replacement. Refer to Board
Replacement for details.
Steps
1. Wear the antistatic strap and power off the shelf or the rack.
2. Record the cables, optical fiber types, the connection locations at two ends, and DIP
switch locations on the backplane. Unplug all cables from back boards and all optical
fibers from front boards.
3. Record the current front board, back board and its slot. Unplug all boards in the shelf.
4. Unscrew the fixing screws of this whole layer of shelf from the front of the rack, and
then the fixation screws for shelf grounding. Pull out the power cable of the shelf and
then the whole shelf from the front.
5. Screw off the fixing screws of the backplane on the shelf and then take out backplane
from the rear.
6. Install a new backplane to the vacant shelf (or install the backplane to a new shelf).
Do not install it upside down. Because of tolerance for installation, it is recommended
to loosen the screws on the four corners first to fix the backplane, and then plug three
boards in Slots 1, 9 and 17. In this way, the backplane can be accurately positioned.
Next, tighten all the rest bolts between the backplane and the shelf.
7. Pull the shelf installed with backplane into the rack properly, and then tighten all fixing
screws.
8. Plug all boards and back boards into the slots properly according to the record.
9. Restore cables and optical fiber connections of the system according to the record.
10. Check whether all cable and optical fiber connections, and DIP switch locations on the
backplane are correct.
11. Power on the shelf or the rack again and restart the system.
Verification
Observe the power-on and startup process of the system after replacement. If MP and
board self-tests are passed, the panel indicators display the normal running status, the fault
alarm is cleared, and related services are restored normally, the replacement is successful.
If an MP or a board cannot pass the self-test, the original fault cannot be cleared, and
related system services cannot be restored, the replacement fails. In this case, check
whether the shelf or backplane is damaged. If the new parts are normal, continue with
fault analysis.
12-3
SJ-20100603155704-010|2011-11-22(R1.2)
12.4 Small Fan Shelf Replacement

Preparation
The preparation process is same as that before board replacement. For details, refer to
the relevant content in Board Replacement.
Steps
1. Wear an antistatic wrist strap correctly.
2. Press the shielding finger switch on the small fan shelf with your thumb and then unplug
the fan shelf where the fault fan is located.
3. Replace the faulty fan or the corresponding faulty circuit board.
4. Pull the replaced small fan shelf into the fan shelf.
Verification
Observe the panel indicator of the replaced small fan shelf. If the indicator shows the
normal running and fault alarms are cleared, the replacement is successful.
Otherwise, the replacement fails. If so, continue with fault cause analysis.
12.5 Optical Module Replacement

Preparation
Board Replacement.
Steps
2. Unplug the optical fiber.
3. Lift up the iron ring of the optical module (vertical to the panel)
4. Unplug the optical module through the iron ring
5. Plug the optical module to be replaced and press the iron ring (parallel with the panel)
Verification
Plug the optical fiber and check whether the indicator is ON. If yes, the contact is fine.
12-4
SJ-20100603155704-010|2011-11-22(R1.2)
Chapter 12 Board and Part Replacement
12.6 BOOT ROM Replacement

Preparation
Board Replacement.
Steps
2. Dismount the BOOT ROM chip with a chip extractor.
3. Place the new BOOT ROM in BOOT ROM socket flatly. The dip of BOOT ROM aligns
with that of BOOT ROM socket. Then, press BOOT ROM into BOOT ROM socket.
Verification
Plug the board into the shelf and observe whether the indicator blinks. If yes, the system
is normal.
12.7 M/S Switchover

There are two methods of originating M/S switching: Switching from NM, and hardware
M/S switching.
1. Method of originating switching from NM
Select the board to be switched from OMM client, right-click the master board node
(rack diagram), click M/S Switching in the pop-up menu to send the M/S switching
command.
2. Method of M/S hardware switching
First, confirm that M/S boards exist at the same time and run normally (RUN indicator
normally blinks). The ACT indicator on the master board is ON. Click EXCH to originate
the switching.
3. Verification
The ACT indicator on the slave board becomes on and that of the master board
becomes OFF, the switching is successful.
12.8 Board Reset

There are two methods to reset M/S: Reset operation originated from NM, and hardware
reset.
1. Reset operation originated from NM
Select the board to be reset from OMM client, right-click the board node (rack diagram),
click Reset in the pop-up menu to send the reset command.
12-5
SJ-20100603155704-010|2011-11-22(R1.2)
2. Hardware reset
Click the RST button on the panel to originate a reset.
3. Verification
If RUN indicator on the board stops blinking and then blinks, the reset succeeds.
12-6
SJ-20100603155704-010|2011-11-22(R1.2)
Chapter 13
Running Information
Description
Table of Contents
Overview to Running Information..............................................................................13-1
Indicator Control Rule...............................................................................................13-2
13.1 Overview to Running Information

The running information sources of ZXWR RNC are the panel indicators of the board
modules. Equipment running status can be determined through the specific definitions
of each blinking indicators.
The blinking status of the indicators on the board panel is as shown in Table 13-1.
Table 13-1 FLASHING STATUS AND DESCRIPTION OF BOARD PANEL INDICATORS
Type
Flashing Status
ON
OFF
Description
The indicator will be ON in a
certain status.
The indicator will be OFF in a
certain status.
The period is 0.2 seconds and
Flashing at 5 Hz
the duty ratio is 50%, that is, it

is ON for 0.1 second and OFF
for 0.1 second.
The period is 0.5 seconds and
Flashing at 2 Hz
the duty ratio is 50%, that is, it

is ON for 0.25 second and OFF
for 0.25 second.
The period is 1 second and the
Flashing at 1 Hz
duty ratio is 50%, that is, it is

ON for 0.5 seconds and OFF for
0.5 seconds.
The period is 2 seconds and the
Flashing at 0.5 Hz
duty ratio is 50%, that is, it is

ON for 1 second and OFF for 1
second.
13-1
SJ-20100603155704-010|2011-11-22(R1.2)
13.2 Indicator Control Rule

13.2.1 Board Power-on
The changes of indicators on successful board power-on are as shown in Figure 13-1.
Figure 13-1 CHANGES OF INDICATORS UPON SUCCESSFUL BOARD POWER-ON
13.2.2 Hardware Reset

The indicator blinking flow in the case of normal hardware system reset is as shown in
Figure 13-2.
13-2
SJ-20100603155704-010|2011-11-22(R1.2)
Chapter 13 Running Information Description
Figure 13-2 INDICATOR FLASHING FLOW FOR NORMAL HARDWARE RESET
13.2.3 ENUM Indicator

ENUM indicator is independent from other indicators of the board, only to indicate the
board status and its tact switch. The statuses of ENUM indicators are as shown in Table
13-2.
Table 13-2 STATUS OF ENUM INDICATOR
Status
ENUM Status
The tact switch is ON.
ON
An alarm occurs to the tact

switch.
Description
The board is not in position and
does not load its version.
The tact switch is ON at a time
Flashing at 5 Hz
when the board is running and

thus an alarm occurs.
The tact switch is ON at a time
The board can be unplugged.
Flashing at 1 Hz
when the board is running, and

the board becomes slave and
can thus be unplugged.
The tact switch is normal.
OFF
The tact switch is normal.
13-3
SJ-20100603155704-010|2011-11-22(R1.2)
13.2.4 ACT Indicator

ACT indicator only shows M/S status of a board. The board without backup is master by
default. The statuses of ENUM indicators are as shown in Table 13-3.
Table 13-3 STATUS OF ACT INDICATOR
Status
ACT Status
Description
The board is master.
ON
The board is currently master.
The board is slave.
OFF
The board is currently slave.
13.2.5 Combination of RUN and ALM Indicators

The combination of RUN and ALM indicators can indicate different board status. These
status combinations represent different statuses during the board power-on and indicate
the faults found inside SCS and OSS after the version runs. The statuses of RUN and
ALM indicator combination are as shown in Table 13-4.
Table 13-4 STATUS OF RUN AND ALM INDICATOR COMBINATION
Status
RUN Status
ALM Status
Description
Flashing at 1 Hz
OFF
Normal running
Flashing at 5 Hz
OFF
Normal
Running
Version
The version is being

downloaded
The version download
failed. The board
Downloading
Flashing at 1 Hz
Flashing at 5 Hz
does not match the

configuration and
cannot download its
version.
DEBUG version
downloads VxWorks
successfully and is
waiting to download
and run the version.
ON
OFF
RELEASE version
indicates the version
download is successful
and the version is being
started.
Self-test
OFF
Flashing at 5 Hz
The board self-test

failed.
13-4
SJ-20100603155704-010|2011-11-22(R1.2)
Status
RUN Status
ALM Status
Failure
OFF
Flashing at 2 Hz
Flashing at 5 Hz
Flashing at 5 Hz
Description
The support failed to
start.
Getting logical address
failed.
The basic processes
Flashing at 5 Hz
Flashing at 2 Hz
failed to be powered on
or timed out.
Flashing at 5 Hz
Flashing at 1 Hz
The kernel data area

failed to be initialized.
Alarm of mismatch
Flashing at 2 Hz
Flashing at 5 Hz
Running fault alarm
among version,
hardware and
configurations.
Flashing at 2 Hz
Flashing at 2 Hz
Flashing at 2 Hz
Flashing at 1 Hz
Flashing at 1 Hz
Flashing at 2 Hz
M/S changeover is
under way.
HW interruption.
The link to the OMP is
interrupted.
The media plane
Flashing at 1 Hz
Flashing at 1 Hz
communication is
interrupted.
No change
ON
Loss of hardware clock.
13.2.6 Special Board Indicators

The statuses of E/AL/R/AC indicators are as shown in Table 13-5.
Table 13-5 STATUS OF BOARD INDICATORS
Physical Board
Indicator
Controllable Software
Description
ACT software can not
be controlled. It is the
E/AL/R/AC
Yes
board master indicator.

ON: The CS domain or
GUIM
PS domain is master.
100 M Ethernet
AP
No
master indicator on
the backplane.
13-5
SJ-20100603155704-010|2011-11-22(R1.2)
Physical Board
Indicator
Description
ON: The 100 M
Ethernet port on the
backplane is master.
Four optical interface
M/S indicators.
ACT
No
ON: The optical

interface is master.
OFF: The optical
interface is slave.
signal indicator.
SD
No
ON: There are fibers

inserted.
OFF: No fibers are
inserted.
L1 ~ 6
No
ON: FE1 ~ 6 ports link

up on RGUM1/2.
E/AL/R/AC
Yes

ON: CS domain or PS
domain is master.
Board PS domain
master indicator.
ACT-P
No
ON: The board PS
domain is master.
Board CS domain
UIMU
master indicator.
ACT-T
No
ON: The board CS
domain is master.
Optical interface 1 is
ACT1
No
master when GXS/2

subcard is inserted.
Optical interface 2 is
ACT2
No
master when GXS/2

LINK1
No
ON: FE-C1/2 port links

up on RUIM1.
13-6
SJ-20100603155704-010|2011-11-22(R1.2)
Physical Board
Indicator
LINK2
No
LINK3
No
LINK4
No
Description
up on RUIM1.
up on RUIM1.
up on RUIM1.
Optical interface 1
SD1
No
links up when GXS/2

Optical interface 2
SD2
No
links up when GXS/2

E/AL/R/AC
Yes

ON: The CS domain or
PS domain is master.
LINK1
No
LINK2
No
LINK3
No
LINK4
No
LINK5
No
LINK6
No
LINK7
No
LINK8
No
LINK9
No
LINK10
No
UIMC
ON: FE1 port links up

on RUIM2.
on RUIM3.
on RUIM2.
on RUIM3.
on RUIM2.
on RUIM3.
on RUIM2.
on RUIM3.
on RUIM2.
on RUIM3.
13-7
SJ-20100603155704-010|2011-11-22(R1.2)
Physical Board
Indicator
Description
Refer to ENUM
Indicator, ACT Indicator
and Combination
E/AL/R/AC
Yes
of RUN and ALM

Indicators. ACT
CHUB
software can not be

controlled.
L1~46
No
ON: The corresponding

port on CHUB is UP.
Refer to ENUM
E1/AL1/R1/AC1
Yes
and Combination
of RUN and ALM
Indicators.
Refer to ENUM
ROMB
E2/AL2/R2/AC2
Yes
and Combination
of RUN and ALM
Indicators.
OMC1-2
No
ON: OMC1 ~ 2 port

links up on RMPB.
Indicates the two
HD1-2
No
harddisk access status

inside the board.
Refer to ENUM
E1/AL1/R1/AC1
Yes
and Combination
of RUN and ALM
Indicators.
RCB
Refer to ENUM
E2/AL2/R2/AC2
Yes
and Combination
of RUN and ALM
Indicators.
13-8
SJ-20100603155704-010|2011-11-22(R1.2)
Physical Board
Indicator
Description
Refer to ENUM
E/AL/R/AC
Yes
and Combination
of RUN and ALM
Indicators.
OFF: E1 link is not
configured.
DTB
ON: E1 link is
L1-32
Yes
configured but
disconnected.
Flashing at 1Hz: E1
link is configured and
connected.
Refer to ENUM
IMAB
E/AL/R/AC
Yes
and Combination
of RUN and ALM
Indicators.
Refer to ENUM
EIPI
E/AL/R/AC
Yes
and Combination
of RUN and ALM
Indicators.
Refer to ENUM
E/AL/R/AC
Yes
and Combination
of RUN and ALM
Indicators.
M/S indicators.
APBE
ACT1-4
No
ON: The optical

OFF: The optical
interface is slave.
signal indicator.
SD1-4
No
inserted.
13-9
SJ-20100603155704-010|2011-11-22(R1.2)
Physical Board
Indicator
Description
OFF: No fibers are
inserted.
Refer to ENUM
E/AL/R/AC
Yes
and Combination
of RUN and ALM
Indicators.
M/S indicators.
ACT
No
GIPI
ON: The optical

OFF: The optical
interface is slave.
signal indicator.
SD
No

inserted.
OFF: No fibers are
inserted.
Refer to ENUM
E/AL/R/AC
Yes
and Combination
of RUN and ALM
Indicators.
Harddisk indicator. Do
HD
No
not plug or unplug the

board when it is ON.
Harddisk indicator. Do
SBCX
PWR
No
not plug or unplug the

board when it is ON.
SAS harddisk 1 running
indicator.
SAS1-2
No
ON: The harddisk is
running.
SAS harddisk alarm
indicator.
ALM1-2
Yes
OFF: There are no
alarms on the harddisk.
13-10
SJ-20100603155704-010|2011-11-22(R1.2)
Physical Board
Indicator
Description
Refer to ENUM
PSN
E/AL/R/AC
Yes
and Combination
of RUN and ALM
Indicators.
Refer to ENUM
E/AL/R/AC
Yes
and Combination
of RUN and ALM
Indicators.
OFF: There is logic in
FPGA.
GLI
OM: There is no logic

Optical interface ACT
No
on FGPA.
It flashes according to
the transceiving data
after the logic gets
normal.
Optical interface SD
No
ON: There is data on

the optical interface.
Refer to ENUM
E/AL/R/AC
Yes
and Combination
of RUN and ALM
Indicators.
CLKG/ICMG/ICM
CATCH
Yes
ICM is in Fast mode.
TRACE
Yes
ICM is in Tracing mode.
KEEP
Yes
ICM is in Hold mode.
FREE
Yes
ICM is in Free mode.

Channel 1 2Mbits
clock base selection
Bps1
Yes
indicator.
ON: This clock base is
selected.
Channel 2 2Mbits
Bps2
Yes

indicator.
13-11
SJ-20100603155704-010|2011-11-22(R1.2)
Physical Board
Indicator
Description
selected.
Channel 1 2MHZ
Hz1
Yes
indicator.
selected.
Channel 2 2MHZ
Hz2
Yes
indicator.
selected.
ON: The selected clock
8K1
Yes
base is the 8K clock

extracted on the line.
8K2
Yes
base is the 8K clock of

the master GPS.
8K3
Yes
base is the 8K clock

provided by UIM.
8K4
Yes
base id the 8K clock

provided by the local
board GPS.
NULL
Yes
ON: There are no

available clock bases.
Clock base degrading
indicator.
QUTD
Yes
base is degrading.
Manual clock base
enabling indicator.
MANI
Yes
ON: The clock base

allowed manual
selection.
SCS
No
Used only on ICM

board.
13-12
SJ-20100603155704-010|2011-11-22(R1.2)
Physical Board
Indicator
Description
ON: The system clock
is normal.
OFF: 16chip
phase-locked loop
is unlocked.
Flashing quickly: The
output 16chip signals
are abnormal.
Flashing slowly: The
output pp2s signals are
abnormal.
Used only on ICM
board.
CCS
No
Circuit clock 12.8 M
PLL is locked normally.
Used only on ICM
board.
OFF (black): GPS
single-mode receiver.
ON (green):
GPS/GONOLASS
dual-mode receiver.
ON (yellow):
GPS/GONOLASS/Be
Dou tri-mode receiver.
Indicators for receiver
ANT
No
initialization, feeder
open-circuit, and
normal running.
ON: The feeder is
normal.
OFF: The feeder and
satellite are normal,
being initialized.
feeder circuit breaks.
feeder is normal but
13-13
SJ-20100603155704-010|2011-11-22(R1.2)
Physical Board
Indicator
Description
it can not receive the
satellite.
Flashing very slowly:
The antenna is
short-circuited.
Flashing very quickly:
It is initialized but the
report is not received.
Used only on ICM
board.
OFF (black): GPS
TYP
No
ON (green):
GPS/GONOLASS
dual-mode receiver.
ON (yellow):
GPS/GONOLASS/Bei
Flashing at 1 HZ: It is
running normally.
RUN
Yes
Flashing at 5 HZ: The

version program is
upgrading.
Channel 1 power
supply alarm indicator.
-48VI
Yes
ON indicates there
are alarms and OFF
indicates there are no
PWRD
alarms.
Channel 2 power
supply alarm indicator.
-48VII
Yes
ON indicates there
are alarms and OFF
alarms.
Fan alarm indicator.
FAN
Yes
ON indicates there
are alarms and OFF
13-14
SJ-20100603155704-010|2011-11-22(R1.2)
Physical Board
Indicator
Description
alarms.
Temperature alarm
indicator. ON indicates
HOT
Yes
there are alarms and

OFF indicates there
are no alarms.
Smog alarm indicator.
ON indicates there
SMOKE
Yes
are alarms and OFF

alarms.
Door control alarm
DOOR
Yes
the door is opened and

OFF indicates the door
is closed.
Lightening alarm
ARRESTER
Yes
there are alarms and

OFF indicates there
are no alarms.
13.2.7 Status and Implementation of Indicators in BOOT

When initializing the power-on and resetting the board, BSP lets all controllable indicators
be on for 0.5 seconds and then off. This is to ensure that all indicators are working fine.
When any controllable indicator is OFF, this indicator itself is faulty.
BSP checks whether the tact switch is closed or not: If the tact switch is not closed, BSP will
turn on ENUM indicator so that it is on while shutting off all the other controllable indicators.
BSP keeps querying the status of the tact switch until the tact switch is closed (then it
switches off ENUM indicator and enters the process of version downloading).
In version downloading, RUN blinks at 5 Hz, and ALM is OFF.
When downloading CPU version, if the downloading fails because of board configuration
error, RUN indicator flashes at 1 Hz and ALM indicator flashes at 5. Stop starting the board,
or reboot the board. The RUN indicator is off after the downloading is completed, showing
the version downloading is successful. The RUN indicator is ON during the starting period
of the version. It turns OFF when the version is in normal operation.
13-15
SJ-20100603155704-010|2011-11-22(R1.2)
13.2.8 Fault Alarm Indicator

When a fault occurs during the version running, the system turns on the alarm indicator
and then restarts the board within one minute.
13.2.9 CLKG/ICMG/ICM Indicator

The statuses of CLKG/ICMG/ICM indicator are as shown in Table 13-6.
Table 13-6 STATUS OF CLKG/ICMG/ICM INDICATOR
Indicator
Color
Description
Meaning
Flashing at 1 Hz (slow):
Normal status.
RUN
Green
Running indicator
ON: The crystal is

being preheated.
OFF: The board is
abnormal.
ON: ENUM is on by
default when the board
is in the slot. That is,
ENUM is on after the
board is powered on
and before the software
starts.
OFF: When the
software detects the
close of the extractor,
the software switches
off ENUM. The system
starts working.
ENUM
Yellow
Board Indicators
Plugging/unplugging
of the board: Open
the extractor. An
ENUM interruption
signal is sent to CPU.
Controlled by the
system, CPU stops
working and ENUM is
on (the ENUM signal is
still be detected). Now,
pull out SDU. If ENUM
indicator is not on,
donot pull out the board
by force. Otherwise,
13-16
SJ-20100603155704-010|2011-11-22(R1.2)
Indicator
Color
Description
Meaning
the services may be
lost.
To close the extract
instead of pulling out
the board, the software
will detect the signal
change. As a result,
it restarts to work and
switches off ENUM.
ON: The board is
master.
ACT
Green
M/S state indicator

OFF: The board is
slave.
ON: The board detects
ALM
Red
Alarm indicator
an error in SRAM and

output clock loss.
ON: The board is
currently in the fast
CATCH
Green
Fast catch state
catch state, that is, it
indicator
has a clock base but

has not locked this
clock base yet.
ON: The board is
currently in the trace
TRACE
Green
Locked state Indicator
state, that is, it has a

clock base and has
locked this clock base.
KEEP
Green
Hold state indicator
ON: The board locks a

clock base, but loses it.
ON: The board is in the
free-running state, that
FREE
Green
Free-run state indicator
is, it neither has locked

any clock base nor has
any clock base.
13-17
SJ-20100603155704-010|2011-11-22(R1.2)
Indicator
Color
Description
Meaning
Indicating the clock
base selected by
CLKG.
2MBps1/Bps1
Green
Clock base indicator
ON: The first channel

of 2 M clock base
provided by BITS and
transmitted in HDB3
format.
base selected by
CLKG.
2Mbps2/Bps12
Green
ON: The second

channel of 2M clock
base provided by BITS
and transmitted in
HDB3 format.
base selected by
CLKG/ICMG.
2MHz1/Hz1
Green
ON: The first channel

of 2M clock base
provided by BITS and
transmitted in TTL
differential format.
base selected by
CLKG/ICMG.
2MHz2/Hz2
Green
ON: The second

channel of 2 M clock
base provided by BITS
and transmitted in TTL
differential format.
base selected by
CLKG/ICMG.
8K1
Green
ON: The clock base

is line 8 K clock base
provided by boards
such as DTEC, APBE,
SDTB, and SPB.
13-18
SJ-20100603155704-010|2011-11-22(R1.2)
Indicator
Color
Description
Meaning
base selected by
CLKG/ICMG.
8K2
Green

ON: The clock base is 8
K clock base provided
by GPS.
base selected by
CLKG/ICMG.
8K3
Green

ON: The selected
clock base is 8 K clock
provided by UIM.
base selected by
CLKG/ICMG/ICM.
8K4
Green

ON: The selected
clock base is 8 K clock
provided by UIM.
base selected by
NULL
Green
CLKG/ICMG.
On: No available
external clock base.
On: The clock base
QUID
Red
Clock base degrade
is degraded. It is
indicator
stratum 3 clock or
lower standard.
On: Manual selection
of the clock base is
MANI
Green
Manual selection of
enabled.
clock base
OFF: Manual selection

of the clock base is
disabled.
13-19
SJ-20100603155704-010|2011-11-22(R1.2)
Indicator
Color
Description
Meaning
Used only on ICM
board.
ON: The system clock
is normal.
OFF: 16chip
SCS
System clock state
Green
indicator
phase-locked loop
is unlocked.
output 16chip signals
are abnormal.
output pp2s signals are
abnormal.
Used only on ICM
CCS
System clock state
Green
indicator
board.
Circuit clock 12.8 M
PLL is locked normally.
Used only on ICM
board.
OFF (black): GPS
ON (green):
GPS/GONOLASS
dual-mode receiver.
ON (yellow):
GPS/GONOLASS/Be
Indicators for the

ANT
receiver initialization,
Green
feeder open-circuited,
normal running
Indicators for receiver

initialization, feeder
open-circuit, and
normal running.
ON: The feeder is
normal.
OFF: The feeder and
satellite are normal,
being initialized.
feeder circuit breaks.
13-20
SJ-20100603155704-010|2011-11-22(R1.2)
Indicator
Color
Description
Meaning
feeder is normal but
it can not receive the
satellite.
Flashing very slowly:
The antenna is
short-circuited.
Flashing very quickly:
It is initialized but the
report is not received.
Used only on ICM
board.
OFF (black): GPS
TYP
Green
GPS receiver type
ON (green):
indicator
GPS/GONOLASS
dual-mode receiver.
ON (yellow):
GPS/GONOLASS/Bei
13.2.10 Panel Indicators

1. RUN, CATCH, TRACE, KEEP and FREE indicators blink simultaneously
It shows the board is being preheated, which takes eight minutes in powering on.
2. RUN indicator blinks
MCU runs as normal.
3. ALM indicator is on
An alarm occurs due to one of the following possible reasons:
l
l
l
l
SRAM self-test error

Loss of output clock 16 M, 32 M, 8 K_16 M or 8 K_32 M
There is PP2S clock input but PP2S output clock loses after the bandwidth
expands
OCXO thermostatic bath used by the phase lock loop generates an alarm.
4. QUTD indicator is on
The clock base currently selected by the board has degraded.
5. CATCH indicator is on
13-21
SJ-20100603155704-010|2011-11-22(R1.2)
The board is currently in the fast catch state, that is, it has a clock base but has not
locked yet.
6. TRACE indicator is on
The board is currently in the tracing status, that is, it has a clock base and has been
locked.
7. KEEP indicator is on
The board is currently in the holdover state, that is, it has no clock base but has locked
a clock.
8. FREE indicator is on
The board is currently in the free-running state, that is, it has no clock base and has
not locked any clock yet.
9. CATCH or TRACE indicator blink
The phase-lock loop currently failed to discriminate the phase, in general, which results
from input clock base error.
10. CATCH and the TRACE indicator blinks simultaneously
The current clock base is beyond the catch range of the clock board and cannot be
locked.
11. All the indicators will be on and then off for twice when the board is being reset or
powered on.
The first means the board enters the BOOT program and the second means the board
enters the version program.
12. RUN indicator blinks at 5 Hz.
The version program of the single-chip microcomputer is automatically updated.
13.2.11 PWRD Indicator

The statuses of PWRD indicator are as shown in Table 13-7.
Table 13-7 STATUS OF PWRD INDICATOR
Indicator
RUN
Description
When the board is running, the indicator blinks at 1 Hz. When the
version program is being updated, the indicator blinks at 5 Hz.
Alarm indicator of the first channel of power supply.
-48 VI
ON: There is alarm.

OFF: There is no alarm.
Alarm indicator of the second channel of power supply. ON: There
-48 VII
is alarm.
13-22
SJ-20100603155704-010|2011-11-22(R1.2)
Indicator
Description
Fan alarm indicator.
FAN
ON: There is alarm.

Temperature alarm indicator.
HOT
ON: There is alarm.

Smoke alarm indicator.
SMOKE
ON: There is alarm.

Door control alarm indicator.
DOOR
ON: The door is open and there is alarm.

OFF: The door is closed and there is no alarm.
Lightning alarm indicator.
ARRESTER
ON: There is alarm.

13.2.12 Indicator for Clock Loss

ALARM is constantly ON when the UIM/GUIM board detects any clock lost.
13-23
SJ-20100603155704-010|2011-11-22(R1.2)
13-24
SJ-20100603155704-010|2011-11-22(R1.2)
Figures
Figure 1-1 TROUBLE SHOOTING FLOW................................................................. 1-2
Figure 2-1 SELECTING ALL TABLES SYNCHRONIZATION .................................... 2-3
Figure 2-2 Refresh Rack ........................................................................................... 2-5
Figure 2-3 SYNCHRONIZE NEs CLOCK ................................................................. 2-6
Figure 3-1 STRUCTURE OF SYNCHRONOUS CLOCK SYSTEM (WITHOUT
GPS) ..................................................................................................... 3-1
Figure 3-2 STRUCTURE OF SYNCHRONOUS CLOCK SYSTEM (WITH
GPS) ..................................................................................................... 3-2
Figure 3-3 INNER EXCHANGING PLANES OF RNC SYSTEM ................................ 3-6
Figure 3-4 CONFIGURATIONS OF TWO RESOURCE SHELVES ............................ 3-6
SERVICE FLOW IN ATM MODE ........................................................... 4-1
SERVICE FLOW IN IP MODE ............................................................... 4-2
Figure 4-3 IU/IUR INTERFACE COMMUNICATION FAULT TROUBLE SHOOTING
FLOW.................................................................................................... 4-3
Figure 4-4 USING SIGNALING TRACING TOOL...................................................... 4-5
Figure 4-5 CREATING SSCP MODULE SIGNALING TRACING TASK ..................... 4-5
Figure 4-6 LOCAL OFFICE SIGNALING CONFIGURATION TAB ............................. 4-6
Figure 4-7 ADJACENT OFFICE SIGNALING CONFIGURATION TAB ...................... 4-6
Figure 4-8 NO.7 LINK TAB........................................................................................ 4-7
Figure 4-9 NO.7 SIGNALING CONFIGURATION TAB .............................................. 4-7
Figure 4-10 No.7 Link Tab......................................................................................... 4-8
Figure 4-11 Office Route Tab .................................................................................... 4-8
Figure 4-12 AS STATIC INFORMATION DIALOG BOX (CHECKING USE
TAG)...................................................................................................... 4-9
Figure 4-13 AS STATIC INFORMATION DIALOG BOX (CHECKING ROUTING
CONTEXT ID) ..................................................................................... 4-10
Figure 4-14 AS STATIC INFORMATION DIALOG BOX (CHECKING AS
MODE) ................................................................................................ 4-10
Figure 4-15 IP CONFIGURATION OF SCTP ASSOCIATION TAB .......................... 4-11
Figure 4-16 BASIC CONFIGURATION TAB ............................................................ 4-13
Figure 4-17 PVC CONFIGURATION TAB ............................................................... 4-13
Figure 4-18 NO.7 SIGNALING CONFIGURATION TAB .......................................... 4-14
I
Figure 4-19 IUB INTERFACE RADIO NETWORK LAYER CONTROL PLANE

SERVICE FLOW IN ATM MODE ......................................................... 4-15
Figure 4-20 IUB INTERFACE TRANSMISSION NETWORK LAYER CONTROL
PLANE SERVICE FLOW IN ATM MODE ............................................. 4-15
Figure 4-21 IUB INTERFACE RADIO NETWORK LAYER CONTROL PLANE
SERVICE FLOW IN IP MODE ............................................................. 4-15
Figure 4-22 AAL2 PATH CONFIGURATION TAB .................................................... 4-17
Figure 4-23 STATE INFORMATION TAB................................................................. 4-17
Figure 4-24 PVC CONFIGURATION - BASIC CONFIGURATION TAB.................... 4-17
Figure 4-25 ATM OFFICE CONFIGURATION TAB.................................................. 4-18
Figure 4-26 AAL2 PATH CONFIGURATION BASIC CONFIGURATION
TAB ..................................................................................................... 4-18
Figure 4-27 CHECKING PATH BANDWIDTH.......................................................... 4-19
Figure 4-28 CHECKING ALCAP SIGNALING TRACING TASK............................... 4-20
Figure 5-1 TROUBLE SHOOTING FLOW OF BOARD LOADING
ABNORMALITY..................................................................................... 5-2
Figure 13-1 CHANGES OF INDICATORS UPON SUCCESSFUL BOARD
POWER-ON ........................................................................................ 13-2
Figure 13-2 INDICATOR FLASHING FLOW FOR NORMAL HARDWARE
RESET ................................................................................................ 13-3
II
Tables
Table 3-1 COMMON PHENOMENA AND CAUSE OF CLOCK FAULT ...................... 3-2
Table 3-2 COMMON PHENOMENA AND CAUSE OF LINK FAULT .......................... 3-4
Table 3-3 COMMON PHENOMENA AND CAUSE OF STARTUP FAULT .................. 3-5
Table 3-4 COMMON PHENOMENA AND CAUSE OF ETHERNET
COMMUNICATION FAULT .................................................................... 3-7
Table 13-1 FLASHING STATUS AND DESCRIPTION OF BOARD PANEL
INDICATORS....................................................................................... 13-1
Table 13-2 STATUS OF ENUM INDICATOR ........................................................... 13-3
Table 13-3 STATUS OF ACT INDICATOR............................................................... 13-4
Table 13-4 STATUS OF RUN AND ALM INDICATOR COMBINATION .................... 13-4
Table 13-5 STATUS OF BOARD INDICATORS ....................................................... 13-5
Table 13-6 STATUS OF CLKG/ICMG/ICM INDICATOR......................................... 13-16
Table 13-7 STATUS OF PWRD INDICATOR ......................................................... 13-22
III
Tables
Glossary
AAL2
- ATM Adaptation Layer type 2
ALCAP
- Access Link Control Application Protocol
APBE
- ATM Process Board Enhanced version
ATM
- Asynchronous Transfer Mode
BER
- Bit Error Rate
BSP
- Board Support Package
CCP
- Communication Control Port
CHUB
- Control plane HUB
CN
- Core Network
CPU
- Central Processing Unit
CS
- Circuit Switched
DBS
- Database Subsystem
DSP
- Digital Signal Processor
DTB
- Digital Trunk Board
EPLD
- Erasable Programmable Logic Device
FACH
- Forward Access Channel
FP
- Frame Protocol
V
FPGA
- Field Programmable Gate Array
FTP
- File Transfer Protocol
GIPI
- GE IP Interface
GLI
- Gigabit Line Interface
GTP-U
- GTP User Plane
ICM
- Integrated Clock Module
ICMG
- Integrated Clock Module (GPS)
IMAB
- IMA Board
IP
- Internet Protocol
KPI
- Key Performance Indicator
LVDS
- Low Voltage Differential Signaling
MCU
- Micro Control Unit
MTP3B
- B-ISDN Message Transfer Part level 3
MTU
- Maximum Transfer Unit
NAS
- Non-Access Stratum
NBAP
- Node B Application Part
NCP
- Node B Control Port
NMS
- Network Management System
NNI
- Network Node Interface
VI
Glossary
OMC
- Operation & Maintenance Center
OMCR
- Operations & Maintenance CenterRadio
OMM
- Operation & Maintenance Module
OMP
- Operation & Maintenance Processor
OS
- Open System
OSS
- Operating System Subsystem
PCH
- Paging Channel
PDCP
- Packet Data Convergence Protocol
PDN
- Packet Data Network
POSI
- POS Interface Board
PS
- Packet Switched
QoS
- Quality of Service
RAB
- Radio Access Bearer
RACH
- Random Access Channel
RCB
- RFS Circuit Breaker
RCP
- Radio Channel Processing module
RLC
- Radio Link Control
RMNIC
- Rear Board of MNIC
RMPB
- Rear Board of MPB
VII
RNC
- Radio Network Controller
ROMB
- RNC Operation & Maintenance Board
RRC
- Radio Resource Control
RRM
- Radio Resource Management
RUB
- RNC User Plane Board
SAAL
- Signaling ATM Adaptation Layer ATM
SCCP
- Signaling Connection Control Part
SCS
- System Control Subsystem
SCTP
- Stream Control Transmission Protocol
SDTA
- SONET Digital Trunk Board (ATM)
SDTB
- Sonet Digital Trunk Board
SGSN
- Service GPRS Supporting Node
SIB
- System Information Block
SLC
- Signaling Link Code
SMP
- Signal Main Processor
SSCOP
- Service Specific Connection Oriented Protocol
SSF
- Session Service Function
SSM
- Synchronization Status Message
TCP
- Transfer Control Protocol
VIII
Glossary
TFC
- Transfer Controlled signal
TFS
- Time and Frequency Subsystem
THUB
- Trunk HUB
UE
- User Equipment
UIM
- Universal Interface Module
UIMC
- Universal Interface Module for Control plane (BCTC or BPSN)
UIMU
- Universal Interface Module for User Plane
UTRAN
- UMTS Terrestrial Radio Access Network
WCDMA
- Wideband Code Division Multiple Access
IX

SJ-20100603155704-010-ZXWR RNC (V3.09.30) Trouble Shooting - 315445

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

SJ-20100603155704-010-ZXWR RNC (V3.09.30) Trouble Shooting - 315445

Cargado por

Copyright:

Formatos disponibles

ZXWR RNC

Radio Network Controller

First Edition (V3.09.30.03)

1. 3.1.4.1:The section Background Knowledge of Ethernet Com

The following sections have been modified:

Serial Number: SJ-20100603155704-010

Chapter 2 Analysis and Trouble Shooting of Operation and

Chapter 3 Analysis and Trouble Shooting of Hardware Fault................ 3-1

3.1 Overview to Hardware Fault................................................................................ 3-1

Chapter 4 Analysis and Trouble Shooting of System

4.3.12 M3ua Office Unreachable...................................................................... 4-29

Chapter 5 Analysis and Trouble Shooting of Software Installation

Chapter 6 Analysis and Trouble Shooting of Handover Fault................ 6-1

Chapter 7 Analysis and Trouble Shooting of Radio Load Fault............. 7-1

Chapter 8 Analysis and Trouble Shooting of Access Fault.................... 8-1

Chapter 9 Analysis and Trouble Shooting of Radio Service Bearer

Chapter 10 Analysis and Trouble Shooting of Radio Global

Chapter 11 Trouble Shooting Record Table ........................................... 11-1

11.1 Trouble Shooting Record Tables .......................................................................11-1

Chapter 12 Board and Part Replacement............................................... 12-1

Chapter 13 Running Information Description........................................ 13-1

What is in This Manual

Introduces the prerequisites for maintenance

Chapter 2, Analysis and Trouble Shooting of

Introduces the fault phenomenon, causes

Operation and Maintenance Fault

and handling methods on the basis of OMC

Chapter 3, Analysis and Trouble Shooting of

Introduces ZXWR RNC common hardware faults.

Describes the fault phenomenon, causes and

Chapter 4, Analysis and Trouble Shooting of

Introduces the basic structure of system

System Communication Fault

communication, common trouble shooting

Chapter 5, Analysis and Trouble Shooting of

Introduces the software load process and

Software Installation Fault

common faults during the process.

Chapter 6, Analysis and Trouble Shooting of

Introduces the handover process and common

faults during the process.

Chapter 7, Analysis and Trouble Shooting of

Introduces the common faults of radio load, fault

Radio Load Fault

analysis and trouble shooting.

Chapter 8, Analysis and Trouble Shooting of

Introduces the classification, phenomenon and

internal causes of access faults, and lists on-site

Chapter 9, Analysis and Trouble Shooting of

Introduces the classification, phenomenon and

Radio Service Bearer Fault

internal causes of radio service bearer faults,

Chapter 10, Analysis and Trouble Shooting of

Introduces the common phenomenon and causes

Radio Global Resource Fault

of ZXWR RNC radio global resource faults, and

Appendix A, Trouble Shooting Record Table

Introduces the overall tracing and record after the

Appendix B, Board and Part Replacement

Introduces methods to replace board, part, fan

Appendix C, Running Information Description

Introduces indicator control rules during the

1.1 Prerequisites for Maintenance Personnel