Professional Documents
Culture Documents
SJ-20120319104909-012-ZXUR 9000 UMTS (V4.11.20) Alarm and Notification Handling Reference
SJ-20120319104909-012-ZXUR 9000 UMTS (V4.11.20) Alarm and Notification Handling Reference
Version: V4.11.20
ZTE CORPORATION
NO. 55, Hi-tech Road South, ShenZhen, P.R.China
Postcode: 518057
Tel: +86-755-26771900
Fax: +86-755-26770801
URL: http://ensupport.zte.com.cn
E-mail: support@zte.com.cn
LEGAL INFORMATION
Copyright © 2012 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
II
III
IV
VII
VIII
XIV
Target Group
l EMS Engineer
l Network Optimization Engineer
l Testing Engineer
Chapter Summary
Chapter 1, Overview Introduces the concepts and terms used in this manual.
Alarm code is defined by a 32-bit field indicating the specific code value.
Alarm sub-code is the identifier which same alarms alarm code.
1-1
l Environment alarm: related with the environment where the equipment is located
(ITU-T Recommendation X.733).
l QoS alarm: related with degradation of service quality (ITU-T Recommendation
X.733).
l OMS alarm: related with the network management system.
1.4.2 Notification
Notification refers to the non-repeated/instantaneous fault or event that occurs during
system operation. Examples include board reset, signaling overload, etc.
1.5 Severity
There are four alarm severity levels, which are indicated in descending order of severity
as Critical, Major, Minor and Warning.
l Critical alarm causes system breakdown and service interruption. It requires
immediate troubleshooting.
l Major alarm significantly affects system operation or weakens network service
capability. It requires troubleshooting as soon as possible.
l Minor alarm affects system operation and network service capability in a nonsignificant
way. A timely troubleshooting is required to avoid severity escalation.
l Warning alarm poses a potential hazard to system operation and network service
capability. It requires troubleshooting at an appropriate time so as to avoid severity
escalation.
The degree of impact as described in the definition of alarm severity refers to the impact of
a single index, such as reliability and security. Once the impact on any of the index reaches
the specified threshold, the severity level of the alarm can be roughly determined. If an
alarm has an impact on multiple indices, alarm severity should be escalated accordingly.
1-2
Note:
Alarm severity can be modified in NetNumen M31 NMS (network management system) if
necessary.
Generally speaking, the default alarm severity is reasonably set. Users should think twice
before making any modification.
In addition, the severity of few alarms is Undefined. It is up to users to define the severity
of such alarms.
1-3
1-4
Probable Cause
System Impact
Handling Suggestion
2-1
Probable Cause
Two ends have no common ground; the clocks are not synchronous; transmission equipment has a
failure.
System Impact
Handling Suggestion
Check if the equipment cable impedance of our company matches, if the board's DIP switch matches
the cable and if the rear board's jumper cap matches the cable.
Y-> Go to "2"
Re-set the board's DIP switch or rear board's jumper cap and then check if the alarm is eliminated. If
the alarm is eliminated, end alarm handling, otherwise, go to "2".
2. Use the multimeter to detect if the grounding signal of the equipment from both ends is reliable.
Y-> Go to "3"
Use the multimeter to detect if the grounding signal of the equipment from both ends is reliable and
then check if the alarm is eliminated. If the alarm is eliminated, end alarm handling, otherwise,
go to "3".
3. Check if the CLKG board locks the clock (TRACE evergreen)
Y-> Go to "4"
N-> Lock the clock.
4. Check if the clock references of two matching NEs or nodes are consistent.
Y-> Go to "5"
4. Modify the clock benchmark, ensuring the clock references of two matching NEs or nodes are
consistent.
5. Ask for assistant of the transmission equipment maintaining personnel to check if the transmission
equipment is exceptional. If there is any exception, locate the fault through step-by-step physical
diagnosis and circulating test. Please contact ZTE Corporation if the problem can not be solved.
2-2
Probable Cause
The wire E1 is not connected or wrongly connected on DDF ; E1 breaks; the upstream equipment is
exceptional.
System Impact
Handling Suggestion
Probable Cause
System Impact
2-3
Handling Suggestion
Check and remove alarms relating to E1 of upstream equipment. If the alarm can not be eliminated,
please contact ZTE Corporation.
Probable Cause
System Impact
Handling Suggestion
Check if the frame format for the two matching ends is consistent. If it is not consistent, configure the
same one for the two ends. If the alarm can not be eliminated, please contact ZTE Corporation.
Probable Cause
There is something wrong with the signals sent by the local end or with the intermediate transmission
equipment. All kinds of faults that may result in LOS, AIS, LOF on the peer end would probably
cause this alarm.
2-4
System Impact
Handling Suggestion
1.At this time, at least one alarm among LOS, AIS LOF occurs on the peer end. Check and record the
peer-end alarm. Check the intermediate transmission equipment for this trunk link to see if there
is any failure. If there is , eliminate the failure.
2. Please contact ZTE Corporation if the problem can not be solved.
Probable Cause
The equipment at end A sends CSU link building code to end B, and this trunk link is set to loopback
at end B. And CSU test starts. If this trunk link is not used for CSU loopback test, this alarm won't be
triggered.
System Impact
Handling Suggestion
After diagnosis and test, do some settings, where end A sends the command of canceling CSU
loopback to end B.
2-5
Probable Cause
HEC is damaged. The cell can not be located from the physical layer's frame.Usually it is triggered
by bottom faults or it is because the local-end equipment and the peer-end equipment process
HEC in different ways.
System Impact
Handling Suggestion
1. Check if there are other alarms accompanying it's occurrence. If there are, eliminate other alarms
firstly and then check if this alarm is eliminated.
Y-> The alarm is eliminated. End alarm handling.
N-> Go to "2"
2. Check if both two ends are configured to SDH mode or SONET mode. If the mode is not same,
configure a correct signal mode for them and then check if the alarm is eliminated.
Y-> The alarm is eliminated. End alarm handling.
N->Please contact ZTE Corporation.
Probable Cause
System Impact
2-6
Handling Suggestion
1. Check if there are other alarms accompanying it's occurrence. If there are, eliminate other alarms
firstly and then check if this alarm is eliminated.
Y-> The alarm is eliminated. End alarm handling.
N-> Go to "2"
2. Check if both two ends are configured to SDH mode or SONET mode. If the mode is not same,
configure a correct signal mode for them and then check if the alarm is eliminated.
Y-> The alarm is eliminated. End alarm handling.
N->Please contact ZTE Corporation.
Probable Cause
The HEC field of cell header is corrupted which result in loss of delineation. This may happen when
physical layer problem occurs or different HEC processes by two ends are taken.
System Impact
Handling Suggestion
1.Check if there are other alarms accompanying it's occurrence. If there are, eliminate other alarms
firstly and then check if this alarm is eliminated.
Y->The alarm is eliminated. End alarm handling.
N->Go to "2"
2. Pull out and insert the board. Reset the board to check if the alarm is eliminated.
Y->End.
N->Please contact ZTE Corporation.
2-7
Probable Cause
The board experiences reset. The SETS chip and the crystal oscillator needs to be fully preheated.
System Impact
Handling Suggestion
Normal procedure after board reset, please wait for the end of warm-up procedure. Clock tests can
be taken unless this alarm is cleared.
Probable Cause
System Impact
2-8
Handling Suggestion
1. Check if the two clock boards in the same shelf are normal, if one of them is normal, then no
need to handle.
2. Replace the board.
Probable Cause
Upstream optical transmit device has faults; Optical fiber transmission line has faults; Fiber pigtail
and flange between local-end optical distribution frame and equipment have faults; Local-end
fiber-optical receiver has faults.
System Impact
Handling Suggestion
The normal receiving optical power should be less than -8dBm and more than -28dBm.
1. It needs to check if the fiber modules of both ends are matching,including data rate、optical
wavelength、multi mode、single mode and so on.
If they are not matching,please replace the correct fiber module.
Y-> The alarm is eliminated. End alarm handling.
N-> Go to "2"
2. Use optical power meter to detect the power for receiving optical signal at local end to see if
the power is within the above-mentioned range.
Y-> If it is within this range, go to step 4.
Y-> If it is not within this range, it can be concluded that the optical transceiver module has faults. In
this case, go to step 3.
3. Replace this fiber module or board, and then check if the alarm is eliminated.
Y-> The alarm is eliminated. End alarm handling.
N-> Go to "4"
4. Detect the transmitting optical signal by use of the transmitting end at the peer end office to
see if it is within the prescribed range.
Y-> If it is within this range, go to step 6.
2-9
Y-> If it is not within this range, it can be concluded that some faults have occurred at the peer
end. In this case, go to step 5.
5. It needs to ask maintenance personnel to check the peer-end office. After troubleshooting at
the peer end, check if the alarm is eliminated.
Y-> The alarm is eliminated. End alarm handling.
N-> Go to "6"
6. There may be something wrong with the transmission equipment. It needs to ask the maintenance
personnel to do troubleshooting of maintaining transmission equipment or contact ZTE Corporation.
Probable Cause
System Impact
Handling Suggestion
2-10
Probable Cause
The optical fiber on the optical distribution frame is wrongly connected during optical fiber cutover and
scheduling, or the expected value is wrongly set in the network management system.
System Impact
Handling Suggestion
1. Check if there is something wrong with the optical fiber connections on ODFs at the local end
and the peer end.
Y-> If there is, go to step 2.
Y-> If there isn't , go to step 3.
2. Have the optical fiber well connected, and check if the alarm is eliminated.
Y-> The alarm is eliminated. End alarm handling.
N-> Go to "3"
3. Check if the expected values of the "section access point identifier" at both ends are consistent.
Y-> If they are consistent, go to step 5.
Y-> If they aren't consistent, go to step 4.
4. Configure the same expected value for the "section access point identifier" at both ends, and
then check if the alarm is eliminated.
Y-> The alarm is eliminated. End alarm handling.
N-> Go to "5"
5. Please contact ZTE Corporation if the problem can not be solved.
Probable Cause
System Impact
All received trunk signals transmitted by this SDH/SONET line are broken.
2-11
Handling Suggestion
Eliminate the "primary fault" according to the alarm generated from the network node equipment in
the corresponding multiplexing section. If the alarm can not be eliminated, please contact ZTE
Corporation.
Probable Cause
System Impact
All sended trunk signals transmitted by this SDH/SONET line are broken.
Handling Suggestion
Eliminate the "primary fault" according to the alarm generated from the network node equipment in
the corresponding multiplexing section. If the alarm can not be eliminated, please contact ZTE
Corporation.
2-12
Probable Cause
As for all NEs in the multiplexing section where the board is located, the fiber pigtail connectors in
the down direction are contaminated and the transmission line attenuation enhances, or optical
transmission mode changes, which result in error codes; It may also be caused by ADM transmitting
device failure.
System Impact
All recevied trunk signals transmitted by this SDH/SONET line generate kinds of alarms.
Handling Suggestion
Probable Cause
Eliminate SF first when SD and SF occur at the same time; If SD occurs alone, it can be concluded
that the ADM transmission device has faults.
2-13
System Impact
Handling Suggestion
1. If SF occurs, eliminate SF first. If the problem can still not be eliminated after SF is eliminated, go
to step 2.
2. Check the optical fibers and fiber optical transceivers at the local end and the peer end, and make
sure the fibers are well connected and the optical transceiver modules are not loose.
Y-> The alarm is eliminated. End alarm handling.
N-> Go to "3"
3. Replace this fiber module or board, and then check if the alarm is eliminated.
Y-> The alarm is eliminated. End alarm handling.
N-> Go to "4"
4. It needs to ask maintenance personnel to check the peer-end office. After troubleshooting at
the peer end, check if the alarm is eliminated.
Y-> The alarm is eliminated. End alarm handling.
N-> Go to "5"
5. There may be something wrong with the transmission equipment. It needs to ask the maintenance
personnel to do troubleshooting of transmission equipment, or contact ZTE Corporation.
Probable Cause
System Impact
All received trunk signals transmitted by this SDH/SONET line are broken.
Handling Suggestion
Ask the maintenance personnel of transmission network to check if the upstream VC-4 channel
control unit has faults. If the transmission is found no problem, please contact ZTE Corporation.
2-14
Probable Cause
System Impact
All received trunk signals transmitted by this SDH line are broken.
Handling Suggestion
Ask the maintenance personnel of transmission network to check if the upstream VC-4 channel
control unit has faults. If the transmission is found no problem, please contact ZTE Corporation.
Probable Cause
The optical fiber on the optical distribution frame is wrongly connected, or the expected value is
wrongly set in the network management system during optical fiber cutover and scheduling.
System Impact
2-15
Handling Suggestion
1. Check if there is something wrong with the optical fiber connections on ODFs at the local end
and the peer end.
Y-> Go to "3"
N-> Go to "2"
2. Correctly connect the optical fibers on ODFs at the local end and the peer end and then check if
the alarm is eliminated.
Y-> The alarm is eliminated. End alarm handling.
N-> Go to "3"
3. Check if the expected values of the "VC-4 channel access point identifier (J1B)" at both ends
are consistent.
Y-> Go to "5"
N-> Go to "4"
4. Configure the same expected values for the "VC-4 channel access point identifier (J1B)" at both
ends, and then check if the alarm is eliminated.
Y-> The alarm is eliminated. End alarm handling.
N-> Go to "5"
5. Please contact ZTE Corporation.
Probable Cause
During project installation, the internal cross connection of SDH network is not complete, or the SDTB
remote device isn't equipped with the channel where SDTB locates.
System Impact
All received trunk signals transmitted by this SDH line are broken.
Handling Suggestion
Ask the maintenance personnel for transmission network to check if the upstream VC-4 channel
control unit has faults(C2B).
2-16
Probable Cause
During project installation, the internal cross connection of SDH network is not complete.
System Impact
All received trunk signals transmitted by this SDH line may be broken.
Handling Suggestion
Ask the maintenance personnel for transmission network to check if the upstream and downstream
circuit configuration (C2B) of the DXC devices in each station during the corresponding timeslot
is correct.
Probable Cause
System Impact
All sended trunk signals transmitted by this SDH/SONET line are broken.
2-17
Handling Suggestion
Eliminate the "source fault" according to the alarm generated from the network node equipment in
VC-4 channel where the board locates. If the alarm can not be eliminated, please contact ZTE
Corporation.
Probable Cause
System Impact
All received trunk signals transmitted by this SDH line may be broken.
Handling Suggestion
Ask the maintenance personnel for transmission network to check if the upstream VC-4 channel
control unit (H4) has faults.
Probable Cause
2-18
System Impact
Handling Suggestion
Ask the maintenance personnel of transmission network to check if the upstream TU-12 tributary
pointer has faults. If the problem can still not be solved, please contact ZTE Corporation.
Probable Cause
There is failure of the upstream TU-12 tributary pointer processing unit, which may includes TU
AIS\TU LOM\TU LOP\TU UNEQ.
System Impact
Handling Suggestion
Ask the maintenance personnel of transmission network to check if the upstream TU-12 tributary
pointer has faults. If the problem can still not be solved, please contact ZTE Corporation.
2-19
l Severity:Warning
l Alarm Type:Equipment Alarm
Probable Cause
1. Local TU-12 tributary function is fault. 2. The equipment of other nodes on TU-12 tributary may
has tributary function faults.
System Impact
Handling Suggestion
1. Check if there is something wrong with the optical fiber connections on ODFs at the local end and
the peer end and check if the processing of TU-12 tributary pointer of the upstream equipment
has faults.
Y-> If there is, go to step 2.
Y-> If there isn't, go to step 3.
2. Have the optic fiber well connected, and check if the alarm is eliminated. This is upstream
troubleshooting.
Y-> The alarm is eliminated. End alarm handling.
N-> Go to "3"
3. Check the alarm forms at both ends. Firstly detect the peer-end alarm forms. The peer-end
alarms should be firstly eliminated.Trough loopback operation, perform troubleshooting for local-end
equipment, transmission equipment and peer-end equipment step by step. Software loopback and
hardware loopback can be applied.
Please contact ZTE Corporation or replace the board if the problem can not be solved.
Probable Cause
2-20
System Impact
Handling Suggestion
1. Check if there is something wrong with the optical fiber connections on ODFs at the local end and
the peer end and check if the processing of TU-12 tributary pointer of the upstream equipment
has faults.
Y-> If there is, go to step 2.
Y-> If there isn't, go to step 3.
2. Have the optic fiber well connected, and check if the alarm is eliminated. This is the upstream
troubleshooting.
Y-> The alarm is eliminated. End alarm handling.
N-> Go to "3"
3. Check the alarm forms at both ends. Firstly detect the peer-end alarm forms. The peer-end
alarms should be firstly eliminated.Trough loopback operation, perform troubleshooting for local-end
equipment, transmission equipment and peer-end equipment step by step. Software loopback and
hardware loopback can be applied.
Please contact ZTE Corporation or replace the board if the problem can not be solved.
Probable Cause
The cable on the optical distribution frame (DDF) is wrongly connected, or the expected value is
wrongly set in the network management system during cable cutover and scheduling.
System Impact
2-21
Handling Suggestion
1. Check if there is something wrong with the optical fiber connections on ODFs at the local end
and the peer end.
Y-> Go to "3"
N-> Go to "2"
2. Correctly connect the optic fibers on ODFs at the local end and the peer end and then check if
the alarm is eliminated.
Y-> The alarm is eliminated. End alarm handling.
N-> Go to "3"
3. Check if the expected values of the "VC-12 channel access point identifier (J2B)" at both ends
are consistent.
Y-> Go to "5"
N-> Go to "4"
4. Configure the same expected values for the "VC-12 channel access point identifier (J2B)" at both
ends, and then check if the alarm is eliminated.
Y-> The alarm is eliminated. End alarm handling.
N-> Go to "5"
5. Please contact ZTE Corporation or replace the board.
Probable Cause
During project installation, the internal cross connection of SDH network is not complete, or the
remote device isn't equipped with the tributary.
System Impact
The received trunk signal transmitted by this tributary unit may be broken.
2-22
Handling Suggestion
1. Check the optical fibers and fiber transceiver modules at the local end and the peer end, and make
sure the fibers are well connected and the fiber modules are not loose.
Y-> The alarm is eliminated. End alarm handling.
N-> Go to "2"
2. The configuration connection at both ends needs to be checked by the maintenance personnel.
Check if the signal label received by this tributary is consistent with that configured at local end. After
confirmation, check if the alarm has been eliminated.
Y-> The alarm is eliminated. End alarm handling.
N-> Go to "3"
Ask the maintenance personnel for transmission equipment to use SDH tester to check if the
upstream and downstream circuit configuration of each DXC node device on the transmission line
during the corresponding timeslot is correct, and check if V5 byte configuration is consistent with that
at peer-end. (The default configuration at local end is asynchronous mapping.)
4.Replace the board, view alarm information, or contact ZTE Corporation.
Probable Cause
The upstream and downstream circuit configuration of each DXC during the corresponding timeslot is
incomplete. The information of V5 signal label is inconsistent with that at the peer end.
System Impact
The received trunk signal transmitted by this tributary unit may be broken.
2-23
Handling Suggestion
1. Check the optical fibers and fiber transceiver modules at the local end and the peer end, and make
sure the fibers are well connected and the fiber modules are not loose.
Y-> The alarm is eliminated. End alarm handling.
N-> Go to "2"
2. The configuration connection at both ends needs to be checked by the maintenance personnel.
Check if the information of V5 signal label is consistent with that at the peer end. After confirmation,
check if the alarm has been eliminated.
Y-> The alarm is eliminated. End alarm handling.
N-> Go to "3"
3. Replace the board, view alarm information, or contact ZTE Corporation.
Probable Cause
(1) Signal reception attenuation is excessive. (2) There is failure of transmitting part of directly
connected transmission equipment. (3)Optical fiber connectors is unclean or connection of them is
incorrect.(4) Local-end receiving part is failure.
System Impact
Noise or call lose appears in the tone service on this SDH line. Error code appears in the data
service path.
Handling Suggestion
1. Check the optical fibers and fiber transceiver modules at the local end and the peer end, and make
sure the fibers are well connected and the fiber modules are not loose.
Y-> The alarm is eliminated. End alarm handling.
N-> Go to "2"
2. Replace this fiber module or board, and then check if the alarm is eliminated.
Y-> The alarm is eliminated. End alarm handling.
N-> Go to "3"
3. It needs to ask maintenance personnel to check the peer-end office. After troubleshooting at
the peer end, check if the alarm is eliminated.
2-24
Probable Cause
(1) Signal reception attenuation is excessive. (2) Optical fiber connectors are unclean or connection
of them are incorrect. (3)Peer-end transmitting part failed in multiplexing section.(4) Local-end
receiving part failure in multiplexing section. (5) B1 error code.
System Impact
Noise or call lose appears in the tone service on this SDH line. Error code appears in the data
service path.
Handling Suggestion
1. Check the optical fibers and fiber transceiver modules at the local end and the peer end, and make
sure the fibers are well connected and the fiber modules are not loose.
Y-> The alarm is eliminated. End alarm handling.
N-> Go to "2"
2. Replace this fiber module or board, and then check if the alarm is eliminated.
Y-> The alarm is eliminated. End alarm handling.
N-> Go to "3"
3. It needs to ask maintenance personnel to check the peer-end office. After troubleshooting at
the peer end, check if the alarm is eliminated.
Y-> The alarm is eliminated. End alarm handling.
N-> Go to "4"
4. There may be something wrong with the transmission equipment. It needs to ask the maintenance
personnel special for maintaining transmission equipment to do troubleshooting or contact ZTE
Corporation.
2-25
Probable Cause
(1) Signal reception attenuation is excessive. (2) Optical fiber connectors are unclean or connection
of them is incorrect. (3)There is failure of the peer-end transmitting part based on higher order path
(4) Local-end receiving part is failure. (5) B1, B2 error codes.
System Impact
Noise or call lose appears in the tone service on this HP. Error code appears in the data service path.
Handling Suggestion
1. Check the optical fibers and fiber transceiver modules at the local end and the peer end, and make
sure the fibers are well connected and the fiber modules are not loose.
Y-> The alarm is eliminated. End alarm handling.
N-> Go to "2"
2. Replace this fiber module or board, and then check if the alarm is eliminated.
Y-> The alarm is eliminated. End alarm handling.
N-> Go to "3"
3. It needs to ask maintenance personnel to check the peer-end office. After troubleshooting at
the peer end, check if the alarm is eliminated.
Y-> The alarm is eliminated. End alarm handling.
N-> Go to "4"
4. There may be something wrong with the transmission equipment. It needs to ask the maintenance
personnel special for maintaining transmission equipment to do troubleshooting or contact ZTE
Corporation.
2-26
Probable Cause
(1) Low order path is interfered. (2) There is failure of the peer-end transmitting part based on lower
order path. (3) Local-end receiving part is failure.
System Impact
Noise or call lose appears in the tone service on this tributary unit. Error code appears in the data
service path.
Handling Suggestion
1. Check the optical fibers and fiber transceiver modules at the local end and the peer end, and make
sure the fibers are well connected and the fiber modules are not loose.
Y-> The alarm is eliminated. End alarm handling.
N-> Go to "2"
2. Replace this fiber module or board, and then check if the alarm is eliminated.
Y-> The alarm is eliminated. End alarm handling.
N-> Go to "3"
3. It needs to ask maintenance personnel to check the peer-end office. After troubleshooting at
the peer end, check if the alarm is eliminated.
Y-> The alarm is eliminated. End alarm handling.
N-> Go to "4"
4. There may be something wrong with the transmission equipment. It needs to ask the maintenance
personnel special for maintaining transmission equipment to do troubleshooting or contact ZTE
Corporation.
Probable Cause
(1) Signal reception attenuation is excessive. (2) There is failure of transmitting part of directly
connected transmission equipment. (3) Optical fiber connectors are unclean or connection of them is
incorrect. (4) Local-end receiving part is failure.
2-27
System Impact
Noise or call lose appears in the tone service on this SDH line. Error code appears in the data
service path.
Handling Suggestion
1. Check the optical fibers and fiber transceiver modules at the local end and the peer end, and make
sure the fibers are well connected and the fiber modules are not loose.
Y-> The alarm is eliminated. End alarm handling.
N-> Go to "2"
2. Replace this fiber module or board, and then check if the alarm is eliminated.
Y-> The alarm is eliminated. End alarm handling.
N-> Go to "3"
3. It needs to ask maintenance personnel to check the peer-end office. After troubleshooting at
the peer end, check if the alarm is eliminated.
Y-> The alarm is eliminated. End alarm handling.
N-> Go to "4"
4. There may be something wrong with the transmission equipment. It needs to ask the maintenance
personnel special for maintaining transmission equipment to do troubleshooting or contact ZTE
Corporation.
Probable Cause
(1) Signal reception attenuation is excessive. (2) There is failure of transmitting part of directly
connected transmission equipment. (3) Optical fiber connectors are unclean or connection of them is
incorrect.(4) Local-end receiving part is failure.
System Impact
Noise or call lose appears in the tone service on this SDH line. Error code appears in the data
service path.
2-28
Handling Suggestion
1. Check the optical fibers and fiber transceiver modules at the local end and the peer end, and make
sure the fibers are well connected and the fiber modules are not loose.
Y-> The alarm is eliminated. End alarm handling.
N-> Go to "2"
2. Replace this fiber module or board, and then check if the alarm is eliminated.
Y-> The alarm is eliminated. End alarm handling.
N-> Go to "3"
3. It needs to ask maintenance personnel to check the peer-end office. After troubleshooting at
the peer end, check if the alarm is eliminated.
Y-> The alarm is eliminated. End alarm handling.
N-> Go to "4"
4. There may be something wrong with the transmission equipment. It needs to ask the maintenance
personnel special for maintaining transmission equipment to do troubleshooting or contact ZTE
Corporation.
Probable Cause
(1) Signal reception attenuation is excessive. (2)There is failure of transmitting part of directly
connected transmission equipment. (3)Optical fiber connectors are unclean or connection of them is
incorrect. (4) Local-end receiving part is failure.
System Impact
Noise or call lose appears in the tone service on this tributary unit. Error code appears in the data
service path.
2-29
Handling Suggestion
1. Check the optical fibers and fiber transceiver modules at the local end and the peer end, and make
sure the fibers are well connected and the fiber modules are not loose.
Y-> The alarm is eliminated. End alarm handling.
N-> Go to "2"
2. Replace this fiber module or board, and then check if the alarm is eliminated.
Y-> The alarm is eliminated. End alarm handling.
N-> Go to "3"
3. It needs to ask maintenance personnel to check the peer-end office. After troubleshooting at
the peer end, check if the alarm is eliminated.
Y-> The alarm is eliminated. End alarm handling.
N-> Go to "4"
4. There may be something wrong with the transmission equipment. It needs to ask the maintenance
personnel special for maintaining transmission equipment to do troubleshooting or contact ZTE
Corporation.
Probable Cause
Configure is error.
System Impact
Handling Suggestion
1. Check the additional information for this alarm, and look for the configuration error.
2.If this configuration-item is supported in the configure-dialog?
Y->Goto 3
N->Contact ZTE
3. If setting is incorrect, re-configure this item to correct value.
4. If setting is correct, replace the board with witch surpport the setting.
5. If the alarm is still existing?
Y->Goto 4
2-30
N->Contact ZTE
Probable Cause
System Impact
Handling Suggestion
2-31
Probable Cause
The hard disk capacity of used has been over the alarm threshold which configured by user.
System Impact
Handling Suggestion
1. Please make sure the hard disk usage settings are appropriate. If inappropriate please modify
as appropriate value.
2: Remove non-used data on the hard disk.
Probable Cause
The hard disk becomes error or can not been detected by system.
System Impact
the hard disk can not use, the date can not be stored.
Handling Suggestion
2-32
Probable Cause
The hard disk file system gets error when reading or writing.
System Impact
Handling Suggestion
Probable Cause
1. The clock extraction reference is changed, including the case that the clock output is closed by
the interface board when optical port is faulty. This leads to the change of clock board input. Or,
configuration is modified at NMS and a new optical port is used to extract the clock.
2. The change in input of clock board results in the change in output.
3. The board lock phase loop has hardware faults.
2-33
System Impact
The service clock and system clock are inconsistent on the board with unlocked phase-lock loop. As
a result, the service carried by the board is interrupted.
Handling Suggestion
1. On NMS fault management interface, check if the related clock alarm occur. If yes, handle the
alarm by referring to the corresponding suggestions.
2. On NMS fault management interface, check if related alarms occur on the optical port for clock
extraction. If yes, handle the alarm by referring to the corresponding suggestions.
3. Check the operation and maintenance logs. If the operation of changing the clock extraction
reference for the loop is recorded, report the alarm as a normal phenomenon. In this case, no
handling operation is required.
4. Switch to the standby clock board.
5. Replace the board.
Probable Cause
System Impact
2-34
Handling Suggestion
1.Check the connection between the port on this board and the peer end one if it is correct.
Y->Go to "2"
N->Check physical cable ,if it is not good, please replace a good cable, and check the alarm if
it is eliminated.
Y-> End.
N-> Go to "2".
2.Replace the board on the local end or the interface on the remote peer end and then check the
alarm if it is eliminated.
Y->End.
N->Go to "3"
3.Replace the remote peer board or the interface on the local end and then check the alarm if it is
eliminated.
Y->End.
N->Please contact ZTE Corporation.
Probable Cause
System Impact
Handling Suggestion
2-35
l Alarm Sub-code:0
l Description:Clock source is not available
l Severity:Critical
l Alarm Type:Equipment Alarm
Probable Cause
System Impact
The slave clock port can not synchronize to the connected port.
Handling Suggestion
Check the physical connection, reconfigure the clock port or reconnect the port.
Probable Cause
The setting of the dial switch on the CMM board has been changed.
System Impact
2-36
Handling Suggestion
Probable Cause
System Impact
Handling Suggestion
2-37
Probable Cause
The speed mode settings of Ethernet port does not take effect.
System Impact
Ethernet port does not work on the speed mode which is set.
Handling Suggestion
1.Check the speed settings on the both end ports if they are correct and consistent.
Y->Go to "2".
N->Modify the speed settings on the both end to make it correct and consistent with each other, and
then check the alarm if it is eliminated.
Y->End.
N->Go to "2".
2.Please contact ZTE Corporation.
2.1.53 199005768 All of the board input clocks which have the same
frequency are lost. 0
Alarm Property
l Alarm Code:199005768
l Alarm Sub-code:0
l Description:All of the board input clocks which have the same frequency are lost.
l Severity:Major
l Alarm Type:Equipment Alarm
2-38
Probable Cause
1. The board is not in place (not properly inserted) in the slot.
2. The output clock of the clock board in the same shelf is error.
3. Clock board is faulty.
4. Clock cable is faulty.
5. Board is faulty.
System Impact
The board fails to synchronize with system clock and fails to work normally, leading to UE access
failure and interruption of board services.
Handling Suggestion
1. Check if the clock board in the same shelf is normal and the clock input cable is properly connected.
2. Replace the board.
Probable Cause
The master and slave mode settings of Ethernet port does not take effect.
System Impact
The Ethernet port does not work on the master and slave mode which is set.
Handling Suggestion
1.Check the master and slave mode settings on the both end ports if they are correct and consistent.
Y->Go to "2".
N->Modify the master and slave mode settings on the both end ports to make them correct and
consistent with each other, and then check the alarm if it is eliminated.
Y->End.
N->Go to "2".
2.Please contact ZTE Corporation.
2-39
2.1.55 199005770 The OMP board doesn't have any OMC port 0
Alarm Property
l Alarm Code:199005770
l Alarm Sub-code:0
l Description:The OMP board doesn't have any OMC port
l Severity:Warning
l Alarm Type:Equipment Alarm
Probable Cause
System Impact
Handling Suggestion
Probable Cause
The duplex mode settings of Ethernet port does not take effect.
System Impact
Ethernet port does not work on the duplex mode which is set.
2-40
Handling Suggestion
1.Check the duplex mode settings on the both ports end if they are correct and consistent.
Y->Go to "2".
N->Modify the duplex mode settings on the both end ports to make them correct and consistent with
each other, and then check the alarm if it is eliminated.
Y->End.
N->Go to "2".
2.Please contact ZTE Corporation.
Probable Cause
Fault occur when read or write the register on the board, this is may be the hardware fault.
System Impact
Handling Suggestion
2-41
Probable Cause
The E1/T1 link is faulty or there is any other equipment fault in the uplink direction of the trunk link.
System Impact
Handling Suggestion
1. Check whether the trunk link at the local end is faulty and eliminate the primary fault. After that,
check if the alarm is eliminated.
Y-> The alarm is eliminated. End alarm handling.
N-> Go to "2"
2. Check whether there is any other equipment fault in the uplink direction of the trunk link. After
that, check if the alarm is eliminated.
Y-> The alarm is eliminated. End alarm handling.
N->Please contact ZTE Corporation.
Probable Cause
The E1/T1 link is faulty or there is any other equipment fault in the uplink direction of the trunk link.
System Impact
2-42
Handling Suggestion
1. Check whether the trunk link at the local end is faulty and eliminate the primary fault. After that,
check if the alarm is eliminated.
Y-> The alarm is eliminated. End alarm handling.
N-> Go to "2"
2. Check whether there is any other equipment fault in the uplink direction of the trunk link. After
that, check if the alarm is eliminated.
Y-> The alarm is eliminated. End alarm handling.
N->Please contact ZTE Corporation.
Probable Cause
The E1 link is faulty or there is any other equipment fault in the downlink direction of the trunk link.
System Impact
Handling Suggestion
1. Check whether the trunk link at the local end is faulty and eliminate the primary fault. After that,
check if the alarm is eliminated.
Y-> The alarm is eliminated. End alarm handling.
N-> Go to "2"
2. Check whether there is any other equipment fault in the uplink direction of the trunk link. After
that, check if the alarm is eliminated.
Y-> The alarm is eliminated. End alarm handling.
N->Please contact ZTE Corporation.
2-43
Probable Cause
System Impact
The board fails to synchronize with system clock and fails to work normally, leading to UE access
failure and interruption of board services.
Handling Suggestion
Probable Cause
System Impact
2-44
Handling Suggestion
1.Check whether the switch board is in the same shelf as this board, or the switch board in the shelf
where the OMP is located and the switch board (if there is any) are working normally.
Y-> Go to Step 2
N-> Restore the boards above to normal state, and check whether this alarm disappears: Y-> Go
to Step 2, N-> Contact ZTE.
2.Update the EPLD version again, and chek the board EPLD version is the new version number.
Y-> End.
N-> Contact ZTE.
Probable Cause
System Impact
Handling Suggestion
2-45
Probable Cause
System Impact
as for PP board,the link connected with switch board does not work. As for switch board,if all of the
stack ports trunk failed, all ports of the poor board do not work.
Handling Suggestion
2-46
l Severity:Minor
l Alarm Type:Equipment Alarm
Probable Cause
1. The duplex mode of the switch port is abnormal and can't heal self.
2. The speed of the switch port is abnormal and can't heal self.
3. The duplex mode of the mac port is abnormal and can't heal self.
4. The speed of the mac port is abnormal and can't heal self.
System Impact
Handling Suggestion
Probable Cause
System Impact
Handling Suggestion
2-47
Probable Cause
1.Media ports between the shelf are not linked or trunk failed
System Impact
Handling Suggestion
Probable Cause
the network process part such as the media cores, microengines or APP650/APP100 are abnormal
System Impact
Handling Suggestion
Most probably because of the hardware error. If occurs repeatly, replace the board.
2-48
Probable Cause
the number of bad frames that the media interfaces have received at a certain period of time exceeds
the threshold
System Impact
Handling Suggestion
Probable Cause
Peer-end faults (configuration faults or devices which do not support exist, the symptom is the
bridging channel that the remote end indicates through K2 is not the one required by the local).
System Impact
APS automatic protection switching function is paralyzed. When the work optical port is abnormal,
protection optical port will not work, leading to service interruption on this optical interface.
2-49
Handling Suggestion
Probable Cause
System Impact
When fiber connection is correct and work optical port works, service is not affected.
When work optical port is faulty, APS automatic protection switching might fail, and service on this
optical interface might be interrupted due to lack of protection.
2-50
Handling Suggestion
Probable Cause
1.APS channel between master and slave board gets hardware fault.
2.The connection on the backplane between the slot and the neighboring slot gets errors.
System Impact
Handling Suggestion
2-51
l Alarm Sub-code:0
l Description:Fan Device Absent
l Severity:Major
l Alarm Type:Equipment Alarm
Probable Cause
System Impact
Device damaged
Handling Suggestion
Probable Cause
System Impact
Handling Suggestion
2-52
Probable Cause
System Impact
Handling Suggestion
Probable Cause
Reason A: The line clock of the frame where this board is located in has jitters.
Reason B: There is a hardware fault in the switching chip of this board.
System Impact
2-53
Handling Suggestion
1.Check connect chip clock is working order. Check whether the problem is repaired when the
worked out clock error.
Y->Done N->Go to step2
2.Change the board, Check whether the problem is repaired when changed the board.
Y->Done N->contact ZTE
Probable Cause
The temperature of the rack exceeds the pre-set upper limit of the alarm threshold.
System Impact
Handling Suggestion
1.Check if the pre-set high limit of the alarm threshold configured in the background for rack
temperature is reasonable.
Y->Go to "2".
N->Modify the alarm threshold and synchronize it to the foreground. Check if the alarm is eliminated:
if so, end. If not, go to "2".
2.Increase the temperature of the rack and check if the alarm is eliminated.
Y->End.
N->Contact ZTE Corporation.
2-54
l Severity:Minor
l Alarm Type:Equipment Alarm
Probable Cause
System Impact
Handling Suggestion
1.Check if the pre-set lower limit of the alarm threshold configured in the background for rack
temperature is reasonable.
Y->Go to "2".
N->Modify the alarm threshold and synchronize it to the foreground. Check if the alarm is eliminated:
if so, end. If not, go to "2".
2.Increase the temperature of the rack and check if the alarm is eliminated.
Y->End.
N->Contact ZTE Corporation.
Probable Cause
The temperature in the equipment room exceeds the upper limit of the alarm threshold
System Impact
2-55
Handling Suggestion
1.Check the high threshold of equipment room temperature on background to see whether it is
rational.
Y->Go to "2".
N->Modify the threshold and upload it to the foreground, and then check whether the alarm
disappears. The handling of this alarm is ended if it disappears, or go to "2" if it does not.
2.Cool the equipment room, and check whether the alarm disappears.
Y->End.
N->Contact ZTE.
Probable Cause
System Impact
Handling Suggestion
1.Check the low threshold of equipment room temperature on background to see whether it is rational.
Y->Go to "2".
N->Modify the threshold and upload it to the foreground, and then check whether the alarm
disappears. The handling of this alarm is ended if it disappears, or go to "2" if it does not.
2.Warm up the equipment room, and check whether the alarm disappears.
Y->End.
N->Contact ZTE.
2-56
Probable Cause
System Impact
Handling Suggestion
Probable Cause
System Impact
2-57
Handling Suggestion
Probable Cause
The humidity in equipment room exceeds the upper limit of the alarm threshold.
System Impact
Handling Suggestion
2-58
Probable Cause
System Impact
Handling Suggestion
Probable Cause
System Impact
2-59
Handling Suggestion
1.Check whether the fan plug-in box and its power line are connected securely (indicators are normal).
Y->go to "2".
N->Secure the fan plug-in box and connect the power line, and then check whether this alarm
disappears. The handling of this alarm is ended if it disappears, or go to "2" if it does not.
2.Replace the fan plug-in box with a good one and check whether the alarm disappears.
Y->End.
N->Contact ZTE.
Probable Cause
System Impact
Handling Suggestion
2-60
l Alarm Sub-code:0
l Description:Smoke alarm
l Severity:Minor
l Alarm Type:Equipment Alarm
Probable Cause
System Impact
Handling Suggestion
Probable Cause
System Impact
2-61
Handling Suggestion
1.Check whether there is any animals or human near the infrared detector.
Y->Make the animal or human away from the detector.
N->go to "2".
2.Check whether the setting of the infrared detector is correct.
Y or do not know how to check ->Contact ZTE.
N->Set the infrared detector, and check whether this alarm disappears. Y->End., N->Contact ZTE.
Probable Cause
System Impact
Handling Suggestion
2-62
Probable Cause
1.Atmosphere switch is open and configured.
2.The setting of the atmosphere switch detector is error
System Impact
Shelf power supply might be affected.
Handling Suggestion
1.Check if the power switch is closed and check if the ALM indicator light is normal
Y->Go to "2"
N->Close the power switch please Y->The end, N->Go to "2"
2.Check if the power switch signal is shielded by the background
Y->The end
N->Please contact ZTE Corporation.
Probable Cause
The power type configured in the database does not accord with the board hardware equipment.
System Impact
The board is faulty.
Handling Suggestion
1.Check the background configuration according to the additional information of the alarm to see
if the configuration conforms to the board hardware equipment.
Y->If yes, go to "2".
N->If no, modify the configuration according to the hardware equipment and re-power on the board.
The alarm will be eliminated.
2.The database configuration is consistent with the equipment hardware while the alarm still can not
be eliminated. In this case, please contact ZTE Corporation.
2-63
Probable Cause
System Impact
When all configured clock reference sources are lost, the clock board comes to free running or
hold-over state. Accuracy of output clock is determined by the crystal oscillator of clock board.
No impact on service.
Handling Suggestion
Probable Cause
Input clock reference is in unavailable status for more than 10 minutes and less than 24 hours.
Probable causes include:
1. Clock reference input is abnormal.
2. The configured clock reference does not exist.
2-64
System Impact
When all configured clock reference sources are lost, the clock board comes to free running or
hold-over state. Accuracy of output clock is determined by the crystal oscillator of clock board.
No impact on service.
Handling Suggestion
Probable Cause
System Impact
When all configured clock reference sources are lost, the clock board comes to free running or
hold-over state. Accuracy of output clock is determined by the crystal oscillator of clock board.
No impact on service.
Handling Suggestion
2-65
Probable Cause
Hardware is faulty.
System Impact
The synchronization of system clock will fail and service interruption will occur.
Handling Suggestion
Probable Cause
System Impact
2-66
Handling Suggestion
Probable Cause
Velocity of fan is larger than normal;Temperature of environment is too low( Not often happen)
System Impact
Handling Suggestion
2-67
Probable Cause
System Impact
Maybe make the velocity of processing going down and some data missing
Handling Suggestion
Probable Cause
System Impact
Handling Suggestion
2-68
Probable Cause
Velocity of fan is lower than normal;Temperature of environment is too high.(Not often happen)
System Impact
Handling Suggestion
Probable Cause
Velocity of fan is too low or the temperature of environment is too high(Not often happen)
System Impact
Maybe the velocity of processing will go down and some data missing.
2-69
Handling Suggestion
Probable Cause
System Impact
Handling Suggestion
Probable Cause
Power fluctuate
2-70
System Impact
Handling Suggestion
Probable Cause
System Impact
Handling Suggestion
Probable Cause
2-71
System Impact
Handling Suggestion
Probable Cause
Power fluctuate
System Impact
Handling Suggestion
Probable Cause
2-72
System Impact
Handling Suggestion
Probable Cause
System Impact
Handling Suggestion
2-73
Probable Cause
System Impact
Handling Suggestion
Probable Cause
Power fluctuate
System Impact
Handling Suggestion
2-74
Probable Cause
Maybe aroused by payload changing
System Impact
Some system functions maybe lost or arouse more serous trouble
Handling Suggestion
Check the payload and power
Probable Cause
Resistance invalid;Influenced by environment
System Impact
Parts of circuit may be damaged
Handling Suggestion
Power off right now and repaired it
2-75
Probable Cause
Power fluctuate
System Impact
Handling Suggestion
Probable Cause
System Impact
Handling Suggestion
2-76
Probable Cause
Resistance invalid;Influenced by environment
System Impact
Parts of circuit may be damaged
Handling Suggestion
Power off right now and repaired it
Probable Cause
Machine malfunction;Voltage abnormal
System Impact
Will arouse the rising of shelf temperature
Handling Suggestion
Check the fan
2-77
Probable Cause
System Impact
Handling Suggestion
Probable Cause
System Impact
Handling Suggestion
2-78
Probable Cause
System Impact
Handling Suggestion
Check board
Probable Cause
System Impact
Handling Suggestion
2-79
Probable Cause
System Impact
Handling Suggestion
Probable Cause
Waterlog alarm
System Impact
N/A
Handling Suggestion
Perform different process methods according to the type of the exterior device. User can define the
treatment measures according to the actual situation.
2-80
Probable Cause
Power loss
System Impact
N/A
Handling Suggestion
Perform different process methods according to the type of the exterior device. User can define the
treatment measures according to the actual situation.
Probable Cause
System Impact
N/A
Handling Suggestion
Perform different process methods according to the type of the exterior device. User can define the
treatment measures according to the actual situation.
2-81
Probable Cause
System Impact
N/A
Handling Suggestion
Perform different process methods according to the type of the exterior device. User can define the
treatment measures according to the actual situation.
Probable Cause
AC power abnormal
System Impact
N/A
Handling Suggestion
Perform different process methods according to the type of the exterior device. User can define the
treatment measures according to the actual situation.
2-82
Probable Cause
Battery under-voltage
System Impact
N/A
Handling Suggestion
Perform different process methods according to the type of the exterior device. User can define the
treatment measures according to the actual situation.
Probable Cause
System Impact
N/A
Handling Suggestion
Perform different process methods according to the type of the exterior device. User can define the
treatment measures according to the actual situation.
2-83
Probable Cause
System Impact
N/A
Handling Suggestion
Perform different process methods according to the type of the exterior device. User can define the
treatment measures according to the actual situation.
Probable Cause
Device suspended
System Impact
N/A
Handling Suggestion
Perform different process methods according to the type of the exterior device. User can define the
treatment measures according to the actual situation.
2-84
l Severity:Major
l Alarm Type:Equipment Alarm
Probable Cause
System Impact
N/A
Handling Suggestion
Perform different process methods according to the type of the exterior device. User can define the
treatment measures according to the actual situation.
Probable Cause
System Impact
N/A
Handling Suggestion
Perform different process methods according to the type of the exterior device. User can define the
treatment measures according to the actual situation.
2-85
Probable Cause
System Impact
N/A
Handling Suggestion
Perform different process methods according to the type of the exterior device. User can define the
treatment measures according to the actual situation.
Probable Cause
System Impact
N/A
Handling Suggestion
Perform different process methods according to the type of the exterior device. User can define the
treatment measures according to the actual situation.
2-86
l Alarm Sub-code:0
l Description:User-defined Dry contact alarm 5
l Severity:Major
l Alarm Type:Equipment Alarm
Probable Cause
System Impact
N/A
Handling Suggestion
Perform different process methods according to the type of the exterior device. User can define the
treatment measures according to the actual situation.
Probable Cause
System Impact
N/A
Handling Suggestion
Perform different process methods according to the type of the exterior device. User can define the
treatment measures according to the actual situation.
2-87
Probable Cause
System Impact
N/A
Handling Suggestion
Perform different process methods according to the type of the exterior device. User can define the
treatment measures according to the actual situation.
Probable Cause
System Impact
N/A
Handling Suggestion
Perform different process methods according to the type of the exterior device. User can define the
treatment measures according to the actual situation.
2-88
Probable Cause
System Impact
N/A
Handling Suggestion
Perform different process methods according to the type of the exterior device. User can define the
treatment measures according to the actual situation.
Probable Cause
System Impact
N/A
Handling Suggestion
Perform different process methods according to the type of the exterior device. User can define the
treatment measures according to the actual situation.
2-89
Probable Cause
System Impact
N/A
Handling Suggestion
Perform different process methods according to the type of the exterior device. User can define the
treatment measures according to the actual situation.
Probable Cause
System Impact
Handling Suggestion
2-90
Probable Cause
After OMP board is restarted, it reports this alarm and then the alarm is restored immediately.
Generally, after this alarm is generated, it can only be queried in history alarms.
System Impact
This alarm affects the operation and maintenance during OMP malfunction. It has no effect on
the services.
Handling Suggestion
OMP reports this alarm when being reset and then restores the alarm. No handling operations
are required.
Probable Cause
System Impact
2-91
Handling Suggestion
1. Check for the proper placing of the board, and insert the board firmly if it is not properly placed.
2. Plug/unplug the board.
3. Replace the board.
4. Change the slot.
5. Replace the CMM of the same shelf.
Probable Cause
System Impact
Handling Suggestion
2-92
Probable Cause
System Impact
Handling Suggestion
1. Inquire CPU alarm limit from backstage, judge if CPU alarm limit is too low
Y-> Reset the CPU alarm limit, wait dozens of seconds, check if the alarm is eliminated, if alarm is
restored, end, else go to "2".
N-> Go to "2".
2. Do nothing, wait dozens of seconds for the system recover automatically, check if the alarm is
eliminated
Y-> End.
N-> Go to "3".
3. Check if the business is running busily
Y-> Wait until the business finished, check if the alarm is eliminated, if alarm is restored, end, else
go to "4".
N-> Go to "4".
4. Please record the alarm information and contact ZTE Corporation
2-93
Probable Cause
System Impact
Handling Suggestion
Probable Cause
1. The slot is configured to 'OMP'type in CMM, but is not configured to OMP in the database of OMP.
System Impact
OMP can't run normally, so the services in this net element are affected.
Handling Suggestion
1.Change OMP address on CMM board or OMP board, and reboot board.
2-94
Probable Cause
System Impact
Handling Suggestion
Get log file, and find out lacked version. Then add and active it.
Probable Cause
System Impact
Handling Suggestion
Get log file,and find out download failed version. Then check if file exist in version server.
2-95
Probable Cause
System Impact
Handling Suggestion
Get log file, and find error code. Then anylize it.
Probable Cause
System Impact
Handling Suggestion
2-96
Probable Cause
System Impact
Handling Suggestion
1. Check alarm details on the NMS fault management interface to find the PVC ID and locate the
faulty port.
For example, the PVC ID is 1. Select PVC Configuration on the NMS Configuration Management
interface to find a record with a PVC ID of 1. Check the record for the Subsystem NO, Unit NO, and
ATM Port No. By using the information, you can find the location of the corresponding interface
board and port.
2. If the faulty PVC port is carried by an optical interface, check the optical port and make sure that
the fibber is well connected. Replace the fibber if necessary.
3. Check if the peer-end equipment is powered on successfully. If not, refer to the corresponding
equipment maintenance manual to solve the problem.
4. Check whether the peer-end equipment has normal PVC status. If not, please refer to
corresponding equipment maintenance manual to solve the problem.
5. Check whether the PVC continuity check is started, If it is started, please deactivate the CC test at
the local end, or activate the CC test at the peer end.
2-97
Probable Cause
Since the group parameters configured in near end IMA group does not match with that configured in
far end IMA group and the IMA configuration parameters sent by the remote end through ICP cells
are rejected. The system comes into Config_Aborted status.
System Impact
Handling Suggestion
On NMS fault management interface, view alarm details where information of the faulty IMA group is
given.
On NMS configuration management interface (IMA group configuration), locate the corresponding
IMA group according to the information given in alarm details. Compare the configuration of the
following parameters on both sides. If the configuration on both sides is inconsistent, modify
configuration at either end to keep consistency.The parameters can be modified are as follows:
'Near-End OAM Label'
'Rx Frame Length (cells)'
'Tx Frame Length (cells)'
'Near-End Symmetry'.
Probable Cause
2-98
System Impact
Some board functions listed in alarm description are unavailable. When "configuration
request type" in additional alarm information is "media panel IP configuration", the media
panel function will be impacted, other reasons will result in an entire unavailable TCP/IP
protocol stack.
Handling Suggestion
1. Wait for several mins, and check whether the alarm is eliminated.
Y->End
N->2
2. Check whether an alarm ALM-8393985 Communication Exception of
Control panel Between Board and Affiliated Module occurs.
Y->3
N->4
3. Refer to the handling suggestions of ALM-8393985 Communication Exception
of Control panel Between Board and Affiliated Module occurs, and
check whether the alarm is eliminated.
Y->End
N->6
4. Plug this board and reset hardware, and check whether the alarm is eliminated.
Y->End
N->5
5. Replace the faulty board, and check whether the alarm is eliminated.
Y->End
N->6
6. Contact the ZTE office.
Probable Cause
There are too many alarms for this board, and the alarm pool is full of board alarms.
2-99
System Impact
Handling Suggestion
Probable Cause
The connection check switch is off, causing PP service process unable to execute connection check.
System Impact
Board connection check disabled, automatic check of connection error cannot be performed. Thus
the connection error might not be self-cured.
Handling Suggestion
Probable Cause
Local port goes to oam loopback state because remote enable loopback.
2-100
System Impact
Handling Suggestion
1.Check remote Oam configuratio ,see if remote enable ethernet oam loopback function,if it is
enable,check loopback test is over. Disable remote’s ethernet oam loopback。Observe if alarm
restore.
Yes->alarm restore
No->phone ZTE corporation
Probable Cause
1.Heavy traffic
2.Uneven load among links
3.Poor physical transmission
4.Low links Bandwidth
System Impact
Congestion may cause packet loss, call abortion and even link breakdown.
Handling Suggestion
1.Make no manual intervention and wait for automatic system recovery. Check whether this alarm
disappears after 30 seconds.
Y->End.
N->Go to Step 2.
2.Check whether the system is busy with its current services.
Y->Go to Step 3.
N->Go to Step 4.
3.Check whether there are sufficient link resources.
Y->3.1 Query performance statistic data to check whether the load is evenly shared among links.
Y->Go to Step 1.
N->Go to Step 4.
2-101
N->3.2 Add new links and check whether this alarm disappears.
Y->End.
N->Go to Step 3.1.
5.Perform physical link self-loop on the devices at the both ends of the link, and check whether
this alarm disappears.
Y->Check the bottom layer transmission and ask a transmission engineer to solve the problem.
N->Go to Step 5.
5.Note down detailed information.
5.1 Back up related local office configuration data and peer-end office configuration data.
5.2 Back up related local office and peer-end office history alarms and notifications, as well as
current alarms.
5.3 Contact ZTE Corporation and end the alarm handling procedure.
Probable Cause
1.Heavy traffic
2.Uneven load among links
3.Poor physical transmission
4.Low links Bandwidth
System Impact
Overload may cause packet loss, call abortion and even link breakdown.
Handling Suggestion
1.Make no manual intervention and wait for automatic system recovery. Check whether this alarm
disappears after 30 seconds.
Y->End.
N->Go to Step 2.
2.Check whether the system is busy with its current services.
Y->Go to Step 3.
N->Go to Step 4.
3.Check whether there are sufficient link resources.
Y->3.1 Query performance statistic data to check whether the load is evenly shared among links.
2-102
Y->Go to Step 1.
N->Go to Step 4.
N->3.2 Add new links and check whether this alarm disappears.
Y->End.
N->Go to Step 3.1.
5.Perform physical link self-loop on the devices at the both ends of the link, and check whether
this alarm disappears.
Y->Check the bottom layer transmission and ask a transmission engineer to solve the problem.
N->Go to Step 5.
5.Note down detailed information.
5.1 Back up related local office configuration data and peer-end office configuration data.
5.2 Back up related local office and peer-end office history alarms and notifications, as well as
current alarms.
5.3 Contact ZTE Corporation and end the alarm handling procedure.
Probable Cause
1.Heavy traffic.
2.Uneven load among links.
3.Insufficient link resources.
System Impact
Congestion may cause packet loss, call abortion and even link breakdown.
Handling Suggestion
1.Make no manual intervention and wait for automatic system recovery. Check whether this alarm
disappears after 30 seconds.
Y->End.
N->Go to Step 2.
2.Check whether the system is busy with its current services.
Y->Go to Step 3.
N->Go to Step 4.
3.Check whether there are sufficient link resources.
2-103
Y->3.1 Query performance statistic data to check whether the load is evenly shared among links.
Y->Go to Step 1.
N->Go to Step 4.
N->3.2 Add new links and check whether this alarm disappears.
Y->End.
N->Go to Step 3.1.
4.Note down detailed information.
4.1 Back up related local office configuration data and peer-end office configuration data.
4.2 Back up related local office and peer-end office history alarms and notifications, as well as
current alarms.
4.3 Contact ZTE Corporation and end the alarm handling procedure.
Probable Cause
System Impact
Handling Suggestion
2-104
Probable Cause
There are too many alarms for OMP board, and the alarm pool is full of board alarms.
System Impact
Handling Suggestion
Probable Cause
The minus of time on OMP and time from Sntp server over alarm limit
System Impact
2-105
Handling Suggestion
1. Inquire time difference alarm limit from backstage, judge if time difference alarm limit is too low
Y-> Reset the time difference alarm limit, wait dozens of seconds, check if the alarm is eliminated, if
alarm is restored, end, else go to "2".
N-> Go to "2".
2. check time on SNTP server and the system time, judge which time is more accurater
Time on SNTP server-> Enforce SNTP time synchronization from SNTP server, wait dozens of
seconds, check if the alarm is eliminated, if alarm is restored, end, else go to "3".
System time-> Check SNTP server organization, find out the reason of the inaccurate time, if cannot
solve, go to "3".
3. Please record the alarm information and contact ZTE Corporation
Probable Cause
The sending payload of MTP3 link exceeds the threshold set by sending flow control.
System Impact
Handling Suggestion
1.Make no manual intervention and just wait the system to recover. Check whether this alarm
disappears 30 seconds later.
Y->End.
N->Go to "2".
2.Check whether the system has a heavy traffic.
Y->Go to "3".
N->Go to "4".
3.Check whether there are sufficient link resources.
Y->3.1 Query performance statistic data to check whether load are evenly shared among links.
Y->Go to "1"
N->Go to "4"
N->3.2 Add new links and check whether this alarm disappears.
2-106
Y->End.
N->Go to "3.1"
4.Note down detailed information.
4.1 Back up related local office configuration data and peer-end office configuration data.
4.2 Back up related local office and peer-end office history alarms and notifications, as well as
current alarms.
4.3 Contact ZTE Corporation and end the alarm handling procedure.
Probable Cause
Unknown
System Impact
The cell is unavailable and fails to provide services. Users fail to gain access through this cell.
Handling Suggestion
1.Baseband Resource Pool. Check if the values of Local Cell ID, Receiving Frequency Point, and
Transmitting Frequency Point in"Local Cell Basic Parameters" are consistent with those at RNC side.
If not, modify the RNC or Node B configurations to make them consistent.
2) On NMS fault management interface, check if Node B has generated "199084129 Board reboots
alarm". If yes, it indicates that the Node B has just been started or hardware has been just replaced
or added. In this case, wait for the Node B to finish powering on.
2.Alarm reason: Cell CGID is zero audit by NodeB.
1) Local cell is blocked
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management >Baseband Resource Pool. View
the Status in Local Cell Status Parameters. If the status is blocked, unblock it.
2) Node B is blocked or faulty
On the ground resource configuration interface, view Node B status. If the status is blocked, unblock
the Node B. If the status is faulty, it indicates that FS board may be faulty. In this case, check if related
alarms exist. If yes, follow the suggestions on handling the related alarms.
The related alarms are as follows:
Application software monitoring alarm
2-107
Probable Cause
Cell delete:Cell SSCH at RNC side is not consistent with which at Node B side
2-108
System Impact
The cell is unavailable and fails to provide services. Users fail to gain access through this cell.
Handling Suggestion
1.Baseband Resource Pool. Check if the values of Local Cell ID, Receiving Frequency Point, and
Transmitting Frequency Point in"Local Cell Basic Parameters" are consistent with those at RNC side.
If not, modify the RNC or Node B configurations to make them consistent.
2) On NMS fault management interface, check if Node B has generated "199084129 Board reboots
alarm". If yes, it indicates that the Node B has just been started or hardware has been just replaced
or added. In this case, wait for the Node B to finish powering on.
2.Alarm reason: Cell CGID is zero audit by NodeB.
1) Local cell is blocked
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management >Baseband Resource Pool. View
the Status in Local Cell Status Parameters. If the status is blocked, unblock it.
2) Node B is blocked or faulty
On the ground resource configuration interface, view Node B status. If the status is blocked, unblock
the Node B. If the status is faulty, it indicates that FS board may be faulty. In this case, check if related
alarms exist. If yes, follow the suggestions on handling the related alarms.
The related alarms are as follows:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
3) Local cell is faulty
View the"Local Cell Status Parameters" interface. If the current status is faulty, it indicates that FS
board or RTR board is faulty or restarted. In this case, check if the following alarms are generated. If
yes, follow the suggestions on handling the related alarms:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
4) Baseband board is blocked
View the BPC board status. If the status is blocked, unblock it.
5) Baseband board is faulty
View the BPC board status. If the status is faulty, handle the alarm by referring to the following
suggestions:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
3.Alarm reason: Cell is blocked at NodeB side.
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management > Baseband Resource Pool. If
the cell status is blocked, unblock it.
2-109
Probable Cause
Cell delete:Cell PCPICH at RNC side is not consistent with which at NodeB side
System Impact
The cell is unavailable and fails to provide services. Users fail to gain access through this cell.
Handling Suggestion
1.Baseband Resource Pool. Check if the values of Local Cell ID, Receiving Frequency Point, and
Transmitting Frequency Point in"Local Cell Basic Parameters" are consistent with those at RNC side.
If not, modify the RNC or Node B configurations to make them consistent.
2) On NMS fault management interface, check if Node B has generated "199084129 Board reboots
alarm". If yes, it indicates that the Node B has just been started or hardware has been just replaced
or added. In this case, wait for the Node B to finish powering on.
2.Alarm reason: Cell CGID is zero audit by NodeB.
1) Local cell is blocked
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management >Baseband Resource Pool. View
the Status in Local Cell Status Parameters. If the status is blocked, unblock it.
2) Node B is blocked or faulty
On the ground resource configuration interface, view Node B status. If the status is blocked, unblock
the Node B. If the status is faulty, it indicates that FS board may be faulty. In this case, check if related
alarms exist. If yes, follow the suggestions on handling the related alarms.
The related alarms are as follows:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
2-110
Probable Cause
Cell delete:Cell SCPICH at RNC side is not consistent with which at Node B side
System Impact
The cell is unavailable and fails to provide services. Users fail to gain access through this cell.
2-111
Handling Suggestion
1.Baseband Resource Pool. Check if the values of Local Cell ID, Receiving Frequency Point, and
Transmitting Frequency Point in"Local Cell Basic Parameters" are consistent with those at RNC side.
If not, modify the RNC or Node B configurations to make them consistent.
2) On NMS fault management interface, check if Node B has generated "199084129 Board reboots
alarm". If yes, it indicates that the Node B has just been started or hardware has been just replaced
or added. In this case, wait for the Node B to finish powering on.
2.Alarm reason: Cell CGID is zero audit by NodeB.
1) Local cell is blocked
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management >Baseband Resource Pool. View
the Status in Local Cell Status Parameters. If the status is blocked, unblock it.
2) Node B is blocked or faulty
On the ground resource configuration interface, view Node B status. If the status is blocked, unblock
the Node B. If the status is faulty, it indicates that FS board may be faulty. In this case, check if related
alarms exist. If yes, follow the suggestions on handling the related alarms.
The related alarms are as follows:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
3) Local cell is faulty
View the"Local Cell Status Parameters" interface. If the current status is faulty, it indicates that FS
board or RTR board is faulty or restarted. In this case, check if the following alarms are generated. If
yes, follow the suggestions on handling the related alarms:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
4) Baseband board is blocked
View the BPC board status. If the status is blocked, unblock it.
5) Baseband board is faulty
View the BPC board status. If the status is faulty, handle the alarm by referring to the following
suggestions:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
3.Alarm reason: Cell is blocked at NodeB side.
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management > Baseband Resource Pool. If
the cell status is blocked, unblock it.
4.Alarm reason: System information update fail.
The alarm is caused by the failure to update system messages, that is, system message broadcast
fails. Handle the alarm by referring to the suggestion for "Broadcast fail".
2-112
5.For other alarm causes, the system re-establishes the cell automatically. No human intervention
is required.
Probable Cause
Cell delete:Cell PCCPCH at RNC side is not consistent with which at Node B side
System Impact
The cell is unavailable and fails to provide services. Users fail to gain access through this cell.
Handling Suggestion
1.Baseband Resource Pool. Check if the values of Local Cell ID, Receiving Frequency Point, and
Transmitting Frequency Point in"Local Cell Basic Parameters" are consistent with those at RNC side.
If not, modify the RNC or Node B configurations to make them consistent.
2) On NMS fault management interface, check if Node B has generated "199084129 Board reboots
alarm". If yes, it indicates that the Node B has just been started or hardware has been just replaced
or added. In this case, wait for the Node B to finish powering on.
2.Alarm reason: Cell CGID is zero audit by NodeB.
1) Local cell is blocked
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management >Baseband Resource Pool. View
the Status in Local Cell Status Parameters. If the status is blocked, unblock it.
2) Node B is blocked or faulty
On the ground resource configuration interface, view Node B status. If the status is blocked, unblock
the Node B. If the status is faulty, it indicates that FS board may be faulty. In this case, check if related
alarms exist. If yes, follow the suggestions on handling the related alarms.
The related alarms are as follows:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
3) Local cell is faulty
2-113
View the"Local Cell Status Parameters" interface. If the current status is faulty, it indicates that FS
board or RTR board is faulty or restarted. In this case, check if the following alarms are generated. If
yes, follow the suggestions on handling the related alarms:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
4) Baseband board is blocked
View the BPC board status. If the status is blocked, unblock it.
5) Baseband board is faulty
View the BPC board status. If the status is faulty, handle the alarm by referring to the following
suggestions:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
3.Alarm reason: Cell is blocked at NodeB side.
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management > Baseband Resource Pool. If
the cell status is blocked, unblock it.
4.Alarm reason: System information update fail.
The alarm is caused by the failure to update system messages, that is, system message broadcast
fails. Handle the alarm by referring to the suggestion for "Broadcast fail".
5.For other alarm causes, the system re-establishes the cell automatically. No human intervention
is required.
Probable Cause
Cell delete:Cell BCH at RNC side is not consistent with which at Node B side
System Impact
The cell is unavailable and fails to provide services. Users fail to gain access through this cell.
2-114
Handling Suggestion
1.Baseband Resource Pool. Check if the values of Local Cell ID, Receiving Frequency Point, and
Transmitting Frequency Point in"Local Cell Basic Parameters" are consistent with those at RNC side.
If not, modify the RNC or Node B configurations to make them consistent.
2) On NMS fault management interface, check if Node B has generated "199084129 Board reboots
alarm". If yes, it indicates that the Node B has just been started or hardware has been just replaced
or added. In this case, wait for the Node B to finish powering on.
2.Alarm reason: Cell CGID is zero audit by NodeB.
1) Local cell is blocked
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management >Baseband Resource Pool. View
the Status in Local Cell Status Parameters. If the status is blocked, unblock it.
2) Node B is blocked or faulty
On the ground resource configuration interface, view Node B status. If the status is blocked, unblock
the Node B. If the status is faulty, it indicates that FS board may be faulty. In this case, check if related
alarms exist. If yes, follow the suggestions on handling the related alarms.
The related alarms are as follows:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
3) Local cell is faulty
View the"Local Cell Status Parameters" interface. If the current status is faulty, it indicates that FS
board or RTR board is faulty or restarted. In this case, check if the following alarms are generated. If
yes, follow the suggestions on handling the related alarms:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
4) Baseband board is blocked
View the BPC board status. If the status is blocked, unblock it.
5) Baseband board is faulty
View the BPC board status. If the status is faulty, handle the alarm by referring to the following
suggestions:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
3.Alarm reason: Cell is blocked at NodeB side.
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management > Baseband Resource Pool. If
the cell status is blocked, unblock it.
4.Alarm reason: System information update fail.
The alarm is caused by the failure to update system messages, that is, system message broadcast
fails. Handle the alarm by referring to the suggestion for "Broadcast fail".
2-115
5.For other alarm causes, the system re-establishes the cell automatically. No human intervention
is required.
Probable Cause
System Impact
The cell is unavailable and fails to provide services. Users fail to gain access through this cell.
Handling Suggestion
1.Baseband Resource Pool. Check if the values of Local Cell ID, Receiving Frequency Point, and
Transmitting Frequency Point in"Local Cell Basic Parameters" are consistent with those at RNC side.
If not, modify the RNC or Node B configurations to make them consistent.
2) On NMS fault management interface, check if Node B has generated "199084129 Board reboots
alarm". If yes, it indicates that the Node B has just been started or hardware has been just replaced
or added. In this case, wait for the Node B to finish powering on.
2.Alarm reason: Cell CGID is zero audit by NodeB.
1) Local cell is blocked
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management >Baseband Resource Pool. View
the Status in Local Cell Status Parameters. If the status is blocked, unblock it.
2) Node B is blocked or faulty
On the ground resource configuration interface, view Node B status. If the status is blocked, unblock
the Node B. If the status is faulty, it indicates that FS board may be faulty. In this case, check if related
alarms exist. If yes, follow the suggestions on handling the related alarms.
The related alarms are as follows:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
3) Local cell is faulty
2-116
View the"Local Cell Status Parameters" interface. If the current status is faulty, it indicates that FS
board or RTR board is faulty or restarted. In this case, check if the following alarms are generated. If
yes, follow the suggestions on handling the related alarms:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
4) Baseband board is blocked
View the BPC board status. If the status is blocked, unblock it.
5) Baseband board is faulty
View the BPC board status. If the status is faulty, handle the alarm by referring to the following
suggestions:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
3.Alarm reason: Cell is blocked at NodeB side.
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management > Baseband Resource Pool. If
the cell status is blocked, unblock it.
4.Alarm reason: System information update fail.
The alarm is caused by the failure to update system messages, that is, system message broadcast
fails. Handle the alarm by referring to the suggestion for "Broadcast fail".
5.For other alarm causes, the system re-establishes the cell automatically. No human intervention
is required.
Probable Cause
System Impact
The cell is unavailable and fails to provide services. Users fail to gain access through this cell.
2-117
Handling Suggestion
1.Baseband Resource Pool. Check if the values of Local Cell ID, Receiving Frequency Point, and
Transmitting Frequency Point in"Local Cell Basic Parameters" are consistent with those at RNC side.
If not, modify the RNC or Node B configurations to make them consistent.
2) On NMS fault management interface, check if Node B has generated "199084129 Board reboots
alarm". If yes, it indicates that the Node B has just been started or hardware has been just replaced
or added. In this case, wait for the Node B to finish powering on.
2.Alarm reason: Cell CGID is zero audit by NodeB.
1) Local cell is blocked
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management >Baseband Resource Pool. View
the Status in Local Cell Status Parameters. If the status is blocked, unblock it.
2) Node B is blocked or faulty
On the ground resource configuration interface, view Node B status. If the status is blocked, unblock
the Node B. If the status is faulty, it indicates that FS board may be faulty. In this case, check if related
alarms exist. If yes, follow the suggestions on handling the related alarms.
The related alarms are as follows:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
3) Local cell is faulty
View the"Local Cell Status Parameters" interface. If the current status is faulty, it indicates that FS
board or RTR board is faulty or restarted. In this case, check if the following alarms are generated. If
yes, follow the suggestions on handling the related alarms:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
4) Baseband board is blocked
View the BPC board status. If the status is blocked, unblock it.
5) Baseband board is faulty
View the BPC board status. If the status is faulty, handle the alarm by referring to the following
suggestions:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
3.Alarm reason: Cell is blocked at NodeB side.
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management > Baseband Resource Pool. If
the cell status is blocked, unblock it.
4.Alarm reason: System information update fail.
The alarm is caused by the failure to update system messages, that is, system message broadcast
fails. Handle the alarm by referring to the suggestion for "Broadcast fail".
2-118
5.For other alarm causes, the system re-establishes the cell automatically. No human intervention
is required.
Probable Cause
System Impact
The cell is unavailable and fails to provide services. Users fail to gain access through this cell.
Handling Suggestion
1.Baseband Resource Pool. Check if the values of Local Cell ID, Receiving Frequency Point, and
Transmitting Frequency Point in"Local Cell Basic Parameters" are consistent with those at RNC side.
If not, modify the RNC or Node B configurations to make them consistent.
2) On NMS fault management interface, check if Node B has generated "199084129 Board reboots
alarm". If yes, it indicates that the Node B has just been started or hardware has been just replaced
or added. In this case, wait for the Node B to finish powering on.
2.Alarm reason: Cell CGID is zero audit by NodeB.
1) Local cell is blocked
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management >Baseband Resource Pool. View
the Status in Local Cell Status Parameters. If the status is blocked, unblock it.
2) Node B is blocked or faulty
On the ground resource configuration interface, view Node B status. If the status is blocked, unblock
the Node B. If the status is faulty, it indicates that FS board may be faulty. In this case, check if related
alarms exist. If yes, follow the suggestions on handling the related alarms.
The related alarms are as follows:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
3) Local cell is faulty
2-119
View the"Local Cell Status Parameters" interface. If the current status is faulty, it indicates that FS
board or RTR board is faulty or restarted. In this case, check if the following alarms are generated. If
yes, follow the suggestions on handling the related alarms:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
4) Baseband board is blocked
View the BPC board status. If the status is blocked, unblock it.
5) Baseband board is faulty
View the BPC board status. If the status is faulty, handle the alarm by referring to the following
suggestions:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
3.Alarm reason: Cell is blocked at NodeB side.
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management > Baseband Resource Pool. If
the cell status is blocked, unblock it.
4.Alarm reason: System information update fail.
The alarm is caused by the failure to update system messages, that is, system message broadcast
fails. Handle the alarm by referring to the suggestion for "Broadcast fail".
5.For other alarm causes, the system re-establishes the cell automatically. No human intervention
is required.
Probable Cause
System Impact
The cell is unavailable and fails to provide services. Users fail to gain access through this cell.
2-120
Handling Suggestion
1.Baseband Resource Pool. Check if the values of Local Cell ID, Receiving Frequency Point, and
Transmitting Frequency Point in"Local Cell Basic Parameters" are consistent with those at RNC side.
If not, modify the RNC or Node B configurations to make them consistent.
2) On NMS fault management interface, check if Node B has generated "199084129 Board reboots
alarm". If yes, it indicates that the Node B has just been started or hardware has been just replaced
or added. In this case, wait for the Node B to finish powering on.
2.Alarm reason: Cell CGID is zero audit by NodeB.
1) Local cell is blocked
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management >Baseband Resource Pool. View
the Status in Local Cell Status Parameters. If the status is blocked, unblock it.
2) Node B is blocked or faulty
On the ground resource configuration interface, view Node B status. If the status is blocked, unblock
the Node B. If the status is faulty, it indicates that FS board may be faulty. In this case, check if related
alarms exist. If yes, follow the suggestions on handling the related alarms.
The related alarms are as follows:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
3) Local cell is faulty
View the"Local Cell Status Parameters" interface. If the current status is faulty, it indicates that FS
board or RTR board is faulty or restarted. In this case, check if the following alarms are generated. If
yes, follow the suggestions on handling the related alarms:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
4) Baseband board is blocked
View the BPC board status. If the status is blocked, unblock it.
5) Baseband board is faulty
View the BPC board status. If the status is faulty, handle the alarm by referring to the following
suggestions:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
3.Alarm reason: Cell is blocked at NodeB side.
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management > Baseband Resource Pool. If
the cell status is blocked, unblock it.
4.Alarm reason: System information update fail.
The alarm is caused by the failure to update system messages, that is, system message broadcast
fails. Handle the alarm by referring to the suggestion for "Broadcast fail".
2-121
5.For other alarm causes, the system re-establishes the cell automatically. No human intervention
is required.
Probable Cause
System Impact
The cell is unavailable and fails to provide services. Users fail to gain access through this cell.
Handling Suggestion
1.Baseband Resource Pool. Check if the values of Local Cell ID, Receiving Frequency Point, and
Transmitting Frequency Point in"Local Cell Basic Parameters" are consistent with those at RNC side.
If not, modify the RNC or Node B configurations to make them consistent.
2) On NMS fault management interface, check if Node B has generated "199084129 Board reboots
alarm". If yes, it indicates that the Node B has just been started or hardware has been just replaced
or added. In this case, wait for the Node B to finish powering on.
2.Alarm reason: Cell CGID is zero audit by NodeB.
1) Local cell is blocked
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management >Baseband Resource Pool. View
the Status in Local Cell Status Parameters. If the status is blocked, unblock it.
2) Node B is blocked or faulty
On the ground resource configuration interface, view Node B status. If the status is blocked, unblock
the Node B. If the status is faulty, it indicates that FS board may be faulty. In this case, check if related
alarms exist. If yes, follow the suggestions on handling the related alarms.
The related alarms are as follows:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
3) Local cell is faulty
2-122
View the"Local Cell Status Parameters" interface. If the current status is faulty, it indicates that FS
board or RTR board is faulty or restarted. In this case, check if the following alarms are generated. If
yes, follow the suggestions on handling the related alarms:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
4) Baseband board is blocked
View the BPC board status. If the status is blocked, unblock it.
5) Baseband board is faulty
View the BPC board status. If the status is faulty, handle the alarm by referring to the following
suggestions:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
3.Alarm reason: Cell is blocked at NodeB side.
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management > Baseband Resource Pool. If
the cell status is blocked, unblock it.
4.Alarm reason: System information update fail.
The alarm is caused by the failure to update system messages, that is, system message broadcast
fails. Handle the alarm by referring to the suggestion for "Broadcast fail".
5.For other alarm causes, the system re-establishes the cell automatically. No human intervention
is required.
Probable Cause
System Impact
The cell is unavailable and fails to provide services. Users fail to gain access through this cell.
2-123
Handling Suggestion
1.Baseband Resource Pool. Check if the values of Local Cell ID, Receiving Frequency Point, and
Transmitting Frequency Point in"Local Cell Basic Parameters" are consistent with those at RNC side.
If not, modify the RNC or Node B configurations to make them consistent.
2) On NMS fault management interface, check if Node B has generated "199084129 Board reboots
alarm". If yes, it indicates that the Node B has just been started or hardware has been just replaced
or added. In this case, wait for the Node B to finish powering on.
2.Alarm reason: Cell CGID is zero audit by NodeB.
1) Local cell is blocked
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management >Baseband Resource Pool. View
the Status in Local Cell Status Parameters. If the status is blocked, unblock it.
2) Node B is blocked or faulty
On the ground resource configuration interface, view Node B status. If the status is blocked, unblock
the Node B. If the status is faulty, it indicates that FS board may be faulty. In this case, check if related
alarms exist. If yes, follow the suggestions on handling the related alarms.
The related alarms are as follows:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
3) Local cell is faulty
View the"Local Cell Status Parameters" interface. If the current status is faulty, it indicates that FS
board or RTR board is faulty or restarted. In this case, check if the following alarms are generated. If
yes, follow the suggestions on handling the related alarms:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
4) Baseband board is blocked
View the BPC board status. If the status is blocked, unblock it.
5) Baseband board is faulty
View the BPC board status. If the status is faulty, handle the alarm by referring to the following
suggestions:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
3.Alarm reason: Cell is blocked at NodeB side.
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management > Baseband Resource Pool. If
the cell status is blocked, unblock it.
4.Alarm reason: System information update fail.
The alarm is caused by the failure to update system messages, that is, system message broadcast
fails. Handle the alarm by referring to the suggestion for "Broadcast fail".
2-124
5.For other alarm causes, the system re-establishes the cell automatically. No human intervention
is required.
Probable Cause
Cell delete: RNC control plane and user plane handshake timeout
System Impact
The cell is unavailable and fails to provide services. Users fail to gain access through this cell.
Handling Suggestion
1.Baseband Resource Pool. Check if the values of Local Cell ID, Receiving Frequency Point, and
Transmitting Frequency Point in"Local Cell Basic Parameters" are consistent with those at RNC side.
If not, modify the RNC or Node B configurations to make them consistent.
2) On NMS fault management interface, check if Node B has generated "199084129 Board reboots
alarm". If yes, it indicates that the Node B has just been started or hardware has been just replaced
or added. In this case, wait for the Node B to finish powering on.
2.Alarm reason: Cell CGID is zero audit by NodeB.
1) Local cell is blocked
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management >Baseband Resource Pool. View
the Status in Local Cell Status Parameters. If the status is blocked, unblock it.
2) Node B is blocked or faulty
On the ground resource configuration interface, view Node B status. If the status is blocked, unblock
the Node B. If the status is faulty, it indicates that FS board may be faulty. In this case, check if related
alarms exist. If yes, follow the suggestions on handling the related alarms.
The related alarms are as follows:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
3) Local cell is faulty
2-125
View the"Local Cell Status Parameters" interface. If the current status is faulty, it indicates that FS
board or RTR board is faulty or restarted. In this case, check if the following alarms are generated. If
yes, follow the suggestions on handling the related alarms:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
4) Baseband board is blocked
View the BPC board status. If the status is blocked, unblock it.
5) Baseband board is faulty
View the BPC board status. If the status is faulty, handle the alarm by referring to the following
suggestions:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
3.Alarm reason: Cell is blocked at NodeB side.
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management > Baseband Resource Pool. If
the cell status is blocked, unblock it.
4.Alarm reason: System information update fail.
The alarm is caused by the failure to update system messages, that is, system message broadcast
fails. Handle the alarm by referring to the suggestion for "Broadcast fail".
5.For other alarm causes, the system re-establishes the cell automatically. No human intervention
is required.
Probable Cause
System Impact
The cell is unavailable and fails to provide services. Users fail to gain access through this cell.
2-126
Handling Suggestion
1.Baseband Resource Pool. Check if the values of Local Cell ID, Receiving Frequency Point, and
Transmitting Frequency Point in"Local Cell Basic Parameters" are consistent with those at RNC side.
If not, modify the RNC or Node B configurations to make them consistent.
2) On NMS fault management interface, check if Node B has generated "199084129 Board reboots
alarm". If yes, it indicates that the Node B has just been started or hardware has been just replaced
or added. In this case, wait for the Node B to finish powering on.
2.Alarm reason: Cell CGID is zero audit by NodeB.
1) Local cell is blocked
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management >Baseband Resource Pool. View
the Status in Local Cell Status Parameters. If the status is blocked, unblock it.
2) Node B is blocked or faulty
On the ground resource configuration interface, view Node B status. If the status is blocked, unblock
the Node B. If the status is faulty, it indicates that FS board may be faulty. In this case, check if related
alarms exist. If yes, follow the suggestions on handling the related alarms.
The related alarms are as follows:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
3) Local cell is faulty
View the"Local Cell Status Parameters" interface. If the current status is faulty, it indicates that FS
board or RTR board is faulty or restarted. In this case, check if the following alarms are generated. If
yes, follow the suggestions on handling the related alarms:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
4) Baseband board is blocked
View the BPC board status. If the status is blocked, unblock it.
5) Baseband board is faulty
View the BPC board status. If the status is faulty, handle the alarm by referring to the following
suggestions:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
3.Alarm reason: Cell is blocked at NodeB side.
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management > Baseband Resource Pool. If
the cell status is blocked, unblock it.
4.Alarm reason: System information update fail.
The alarm is caused by the failure to update system messages, that is, system message broadcast
fails. Handle the alarm by referring to the suggestion for "Broadcast fail".
2-127
5.For other alarm causes, the system re-establishes the cell automatically. No human intervention
is required.
Probable Cause
System Impact
The cell is unavailable and fails to provide services. Users fail to gain access through this cell.
Handling Suggestion
1.Baseband Resource Pool. Check if the values of Local Cell ID, Receiving Frequency Point, and
Transmitting Frequency Point in"Local Cell Basic Parameters" are consistent with those at RNC side.
If not, modify the RNC or Node B configurations to make them consistent.
2) On NMS fault management interface, check if Node B has generated "199084129 Board reboots
alarm". If yes, it indicates that the Node B has just been started or hardware has been just replaced
or added. In this case, wait for the Node B to finish powering on.
2.Alarm reason: Cell CGID is zero audit by NodeB.
1) Local cell is blocked
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management >Baseband Resource Pool. View
the Status in Local Cell Status Parameters. If the status is blocked, unblock it.
2) Node B is blocked or faulty
On the ground resource configuration interface, view Node B status. If the status is blocked, unblock
the Node B. If the status is faulty, it indicates that FS board may be faulty. In this case, check if related
alarms exist. If yes, follow the suggestions on handling the related alarms.
The related alarms are as follows:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
3) Local cell is faulty
2-128
View the"Local Cell Status Parameters" interface. If the current status is faulty, it indicates that FS
board or RTR board is faulty or restarted. In this case, check if the following alarms are generated. If
yes, follow the suggestions on handling the related alarms:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
4) Baseband board is blocked
View the BPC board status. If the status is blocked, unblock it.
5) Baseband board is faulty
View the BPC board status. If the status is faulty, handle the alarm by referring to the following
suggestions:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
3.Alarm reason: Cell is blocked at NodeB side.
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management > Baseband Resource Pool. If
the cell status is blocked, unblock it.
4.Alarm reason: System information update fail.
The alarm is caused by the failure to update system messages, that is, system message broadcast
fails. Handle the alarm by referring to the suggestion for "Broadcast fail".
5.For other alarm causes, the system re-establishes the cell automatically. No human intervention
is required.
Probable Cause
System Impact
The cell is unavailable and fails to provide services. Users fail to gain access through this cell.
2-129
Handling Suggestion
1.Baseband Resource Pool. Check if the values of Local Cell ID, Receiving Frequency Point, and
Transmitting Frequency Point in"Local Cell Basic Parameters" are consistent with those at RNC side.
If not, modify the RNC or Node B configurations to make them consistent.
2) On NMS fault management interface, check if Node B has generated "199084129 Board reboots
alarm". If yes, it indicates that the Node B has just been started or hardware has been just replaced
or added. In this case, wait for the Node B to finish powering on.
2.Alarm reason: Cell CGID is zero audit by NodeB.
1) Local cell is blocked
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management >Baseband Resource Pool. View
the Status in Local Cell Status Parameters. If the status is blocked, unblock it.
2) Node B is blocked or faulty
On the ground resource configuration interface, view Node B status. If the status is blocked, unblock
the Node B. If the status is faulty, it indicates that FS board may be faulty. In this case, check if related
alarms exist. If yes, follow the suggestions on handling the related alarms.
The related alarms are as follows:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
3) Local cell is faulty
View the"Local Cell Status Parameters" interface. If the current status is faulty, it indicates that FS
board or RTR board is faulty or restarted. In this case, check if the following alarms are generated. If
yes, follow the suggestions on handling the related alarms:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
4) Baseband board is blocked
View the BPC board status. If the status is blocked, unblock it.
5) Baseband board is faulty
View the BPC board status. If the status is faulty, handle the alarm by referring to the following
suggestions:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
3.Alarm reason: Cell is blocked at NodeB side.
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management > Baseband Resource Pool. If
the cell status is blocked, unblock it.
4.Alarm reason: System information update fail.
The alarm is caused by the failure to update system messages, that is, system message broadcast
fails. Handle the alarm by referring to the suggestion for "Broadcast fail".
2-130
5.For other alarm causes, the system re-establishes the cell automatically. No human intervention
is required.
Probable Cause
System Impact
The cell is unavailable and fails to provide services. Users fail to gain access through this cell.
Handling Suggestion
1.Baseband Resource Pool. Check if the values of Local Cell ID, Receiving Frequency Point, and
Transmitting Frequency Point in"Local Cell Basic Parameters" are consistent with those at RNC side.
If not, modify the RNC or Node B configurations to make them consistent.
2) On NMS fault management interface, check if Node B has generated "199084129 Board reboots
alarm". If yes, it indicates that the Node B has just been started or hardware has been just replaced
or added. In this case, wait for the Node B to finish powering on.
2.Alarm reason: Cell CGID is zero audit by NodeB.
1) Local cell is blocked
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management >Baseband Resource Pool. View
the Status in Local Cell Status Parameters. If the status is blocked, unblock it.
2) Node B is blocked or faulty
On the ground resource configuration interface, view Node B status. If the status is blocked, unblock
the Node B. If the status is faulty, it indicates that FS board may be faulty. In this case, check if related
alarms exist. If yes, follow the suggestions on handling the related alarms.
The related alarms are as follows:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
3) Local cell is faulty
2-131
View the"Local Cell Status Parameters" interface. If the current status is faulty, it indicates that FS
board or RTR board is faulty or restarted. In this case, check if the following alarms are generated. If
yes, follow the suggestions on handling the related alarms:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
4) Baseband board is blocked
View the BPC board status. If the status is blocked, unblock it.
5) Baseband board is faulty
View the BPC board status. If the status is faulty, handle the alarm by referring to the following
suggestions:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
3.Alarm reason: Cell is blocked at NodeB side.
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management > Baseband Resource Pool. If
the cell status is blocked, unblock it.
4.Alarm reason: System information update fail.
The alarm is caused by the failure to update system messages, that is, system message broadcast
fails. Handle the alarm by referring to the suggestion for "Broadcast fail".
5.For other alarm causes, the system re-establishes the cell automatically. No human intervention
is required.
Probable Cause
System Impact
The cell is unavailable and fails to provide services. Users fail to gain access through this cell.
2-132
Handling Suggestion
1.Baseband Resource Pool. Check if the values of Local Cell ID, Receiving Frequency Point, and
Transmitting Frequency Point in"Local Cell Basic Parameters" are consistent with those at RNC side.
If not, modify the RNC or Node B configurations to make them consistent.
2) On NMS fault management interface, check if Node B has generated "199084129 Board reboots
alarm". If yes, it indicates that the Node B has just been started or hardware has been just replaced
or added. In this case, wait for the Node B to finish powering on.
2.Alarm reason: Cell CGID is zero audit by NodeB.
1) Local cell is blocked
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management >Baseband Resource Pool. View
the Status in Local Cell Status Parameters. If the status is blocked, unblock it.
2) Node B is blocked or faulty
On the ground resource configuration interface, view Node B status. If the status is blocked, unblock
the Node B. If the status is faulty, it indicates that FS board may be faulty. In this case, check if related
alarms exist. If yes, follow the suggestions on handling the related alarms.
The related alarms are as follows:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
3) Local cell is faulty
View the"Local Cell Status Parameters" interface. If the current status is faulty, it indicates that FS
board or RTR board is faulty or restarted. In this case, check if the following alarms are generated. If
yes, follow the suggestions on handling the related alarms:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
4) Baseband board is blocked
View the BPC board status. If the status is blocked, unblock it.
5) Baseband board is faulty
View the BPC board status. If the status is faulty, handle the alarm by referring to the following
suggestions:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
3.Alarm reason: Cell is blocked at NodeB side.
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management > Baseband Resource Pool. If
the cell status is blocked, unblock it.
4.Alarm reason: System information update fail.
The alarm is caused by the failure to update system messages, that is, system message broadcast
fails. Handle the alarm by referring to the suggestion for "Broadcast fail".
2-133
5.For other alarm causes, the system re-establishes the cell automatically. No human intervention
is required.
Probable Cause
System Impact
The cell is unavailable and fails to provide services. Users fail to gain access through this cell.
Handling Suggestion
1.Baseband Resource Pool. Check if the values of Local Cell ID, Receiving Frequency Point, and
Transmitting Frequency Point in"Local Cell Basic Parameters" are consistent with those at RNC side.
If not, modify the RNC or Node B configurations to make them consistent.
2) On NMS fault management interface, check if Node B has generated "199084129 Board reboots
alarm". If yes, it indicates that the Node B has just been started or hardware has been just replaced
or added. In this case, wait for the Node B to finish powering on.
2.Alarm reason: Cell CGID is zero audit by NodeB.
1) Local cell is blocked
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management >Baseband Resource Pool. View
the Status in Local Cell Status Parameters. If the status is blocked, unblock it.
2) Node B is blocked or faulty
On the ground resource configuration interface, view Node B status. If the status is blocked, unblock
the Node B. If the status is faulty, it indicates that FS board may be faulty. In this case, check if related
alarms exist. If yes, follow the suggestions on handling the related alarms.
The related alarms are as follows:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
3) Local cell is faulty
2-134
View the"Local Cell Status Parameters" interface. If the current status is faulty, it indicates that FS
board or RTR board is faulty or restarted. In this case, check if the following alarms are generated. If
yes, follow the suggestions on handling the related alarms:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
4) Baseband board is blocked
View the BPC board status. If the status is blocked, unblock it.
5) Baseband board is faulty
View the BPC board status. If the status is faulty, handle the alarm by referring to the following
suggestions:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
3.Alarm reason: Cell is blocked at NodeB side.
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management > Baseband Resource Pool. If
the cell status is blocked, unblock it.
4.Alarm reason: System information update fail.
The alarm is caused by the failure to update system messages, that is, system message broadcast
fails. Handle the alarm by referring to the suggestion for "Broadcast fail".
5.For other alarm causes, the system re-establishes the cell automatically. No human intervention
is required.
Probable Cause
System Impact
The cell is unavailable and fails to provide services. Users fail to gain access through this cell.
2-135
Handling Suggestion
1.Baseband Resource Pool. Check if the values of Local Cell ID, Receiving Frequency Point, and
Transmitting Frequency Point in"Local Cell Basic Parameters" are consistent with those at RNC side.
If not, modify the RNC or Node B configurations to make them consistent.
2) On NMS fault management interface, check if Node B has generated "199084129 Board reboots
alarm". If yes, it indicates that the Node B has just been started or hardware has been just replaced
or added. In this case, wait for the Node B to finish powering on.
2.Alarm reason: Cell CGID is zero audit by NodeB.
1) Local cell is blocked
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management >Baseband Resource Pool. View
the Status in Local Cell Status Parameters. If the status is blocked, unblock it.
2) Node B is blocked or faulty
On the ground resource configuration interface, view Node B status. If the status is blocked, unblock
the Node B. If the status is faulty, it indicates that FS board may be faulty. In this case, check if related
alarms exist. If yes, follow the suggestions on handling the related alarms.
The related alarms are as follows:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
3) Local cell is faulty
View the"Local Cell Status Parameters" interface. If the current status is faulty, it indicates that FS
board or RTR board is faulty or restarted. In this case, check if the following alarms are generated. If
yes, follow the suggestions on handling the related alarms:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
4) Baseband board is blocked
View the BPC board status. If the status is blocked, unblock it.
5) Baseband board is faulty
View the BPC board status. If the status is faulty, handle the alarm by referring to the following
suggestions:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
3.Alarm reason: Cell is blocked at NodeB side.
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management > Baseband Resource Pool. If
the cell status is blocked, unblock it.
4.Alarm reason: System information update fail.
The alarm is caused by the failure to update system messages, that is, system message broadcast
fails. Handle the alarm by referring to the suggestion for "Broadcast fail".
2-136
5.For other alarm causes, the system re-establishes the cell automatically. No human intervention
is required.
Probable Cause
System Impact
The cell is unavailable and fails to provide services. Users fail to gain access through this cell.
Handling Suggestion
1.Baseband Resource Pool. Check if the values of Local Cell ID, Receiving Frequency Point, and
Transmitting Frequency Point in"Local Cell Basic Parameters" are consistent with those at RNC side.
If not, modify the RNC or Node B configurations to make them consistent.
2) On NMS fault management interface, check if Node B has generated "199084129 Board reboots
alarm". If yes, it indicates that the Node B has just been started or hardware has been just replaced
or added. In this case, wait for the Node B to finish powering on.
2.Alarm reason: Cell CGID is zero audit by NodeB.
1) Local cell is blocked
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management >Baseband Resource Pool. View
the Status in Local Cell Status Parameters. If the status is blocked, unblock it.
2) Node B is blocked or faulty
On the ground resource configuration interface, view Node B status. If the status is blocked, unblock
the Node B. If the status is faulty, it indicates that FS board may be faulty. In this case, check if related
alarms exist. If yes, follow the suggestions on handling the related alarms.
The related alarms are as follows:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
3) Local cell is faulty
2-137
View the"Local Cell Status Parameters" interface. If the current status is faulty, it indicates that FS
board or RTR board is faulty or restarted. In this case, check if the following alarms are generated. If
yes, follow the suggestions on handling the related alarms:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
4) Baseband board is blocked
View the BPC board status. If the status is blocked, unblock it.
5) Baseband board is faulty
View the BPC board status. If the status is faulty, handle the alarm by referring to the following
suggestions:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
3.Alarm reason: Cell is blocked at NodeB side.
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management > Baseband Resource Pool. If
the cell status is blocked, unblock it.
4.Alarm reason: System information update fail.
The alarm is caused by the failure to update system messages, that is, system message broadcast
fails. Handle the alarm by referring to the suggestion for "Broadcast fail".
5.For other alarm causes, the system re-establishes the cell automatically. No human intervention
is required.
Probable Cause
System Impact
The cell is unavailable and fails to provide services. Users fail to gain access through this cell.
2-138
Handling Suggestion
1.Baseband Resource Pool. Check if the values of Local Cell ID, Receiving Frequency Point, and
Transmitting Frequency Point in"Local Cell Basic Parameters" are consistent with those at RNC side.
If not, modify the RNC or Node B configurations to make them consistent.
2) On NMS fault management interface, check if Node B has generated "199084129 Board reboots
alarm". If yes, it indicates that the Node B has just been started or hardware has been just replaced
or added. In this case, wait for the Node B to finish powering on.
2.Alarm reason: Cell CGID is zero audit by NodeB.
1) Local cell is blocked
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management >Baseband Resource Pool. View
the Status in Local Cell Status Parameters. If the status is blocked, unblock it.
2) Node B is blocked or faulty
On the ground resource configuration interface, view Node B status. If the status is blocked, unblock
the Node B. If the status is faulty, it indicates that FS board may be faulty. In this case, check if related
alarms exist. If yes, follow the suggestions on handling the related alarms.
The related alarms are as follows:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
3) Local cell is faulty
View the"Local Cell Status Parameters" interface. If the current status is faulty, it indicates that FS
board or RTR board is faulty or restarted. In this case, check if the following alarms are generated. If
yes, follow the suggestions on handling the related alarms:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
4) Baseband board is blocked
View the BPC board status. If the status is blocked, unblock it.
5) Baseband board is faulty
View the BPC board status. If the status is faulty, handle the alarm by referring to the following
suggestions:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
3.Alarm reason: Cell is blocked at NodeB side.
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management > Baseband Resource Pool. If
the cell status is blocked, unblock it.
4.Alarm reason: System information update fail.
The alarm is caused by the failure to update system messages, that is, system message broadcast
fails. Handle the alarm by referring to the suggestion for "Broadcast fail".
2-139
5.For other alarm causes, the system re-establishes the cell automatically. No human intervention
is required.
Probable Cause
System Impact
The cell is unavailable and fails to provide services. Users fail to gain access through this cell.
Handling Suggestion
1.Baseband Resource Pool. Check if the values of Local Cell ID, Receiving Frequency Point, and
Transmitting Frequency Point in"Local Cell Basic Parameters" are consistent with those at RNC side.
If not, modify the RNC or Node B configurations to make them consistent.
2) On NMS fault management interface, check if Node B has generated "199084129 Board reboots
alarm". If yes, it indicates that the Node B has just been started or hardware has been just replaced
or added. In this case, wait for the Node B to finish powering on.
2.Alarm reason: Cell CGID is zero audit by NodeB.
1) Local cell is blocked
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management >Baseband Resource Pool. View
the Status in Local Cell Status Parameters. If the status is blocked, unblock it.
2) Node B is blocked or faulty
On the ground resource configuration interface, view Node B status. If the status is blocked, unblock
the Node B. If the status is faulty, it indicates that FS board may be faulty. In this case, check if related
alarms exist. If yes, follow the suggestions on handling the related alarms.
The related alarms are as follows:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
3) Local cell is faulty
2-140
View the"Local Cell Status Parameters" interface. If the current status is faulty, it indicates that FS
board or RTR board is faulty or restarted. In this case, check if the following alarms are generated. If
yes, follow the suggestions on handling the related alarms:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
4) Baseband board is blocked
View the BPC board status. If the status is blocked, unblock it.
5) Baseband board is faulty
View the BPC board status. If the status is faulty, handle the alarm by referring to the following
suggestions:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
3.Alarm reason: Cell is blocked at NodeB side.
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management > Baseband Resource Pool. If
the cell status is blocked, unblock it.
4.Alarm reason: System information update fail.
The alarm is caused by the failure to update system messages, that is, system message broadcast
fails. Handle the alarm by referring to the suggestion for "Broadcast fail".
5.For other alarm causes, the system re-establishes the cell automatically. No human intervention
is required.
Probable Cause
System Impact
The cell is unavailable and fails to provide services. Users fail to gain access through this cell.
2-141
Handling Suggestion
1.Baseband Resource Pool. Check if the values of Local Cell ID, Receiving Frequency Point, and
Transmitting Frequency Point in"Local Cell Basic Parameters" are consistent with those at RNC side.
If not, modify the RNC or Node B configurations to make them consistent.
2) On NMS fault management interface, check if Node B has generated "199084129 Board reboots
alarm". If yes, it indicates that the Node B has just been started or hardware has been just replaced
or added. In this case, wait for the Node B to finish powering on.
2.Alarm reason: Cell CGID is zero audit by NodeB.
1) Local cell is blocked
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management >Baseband Resource Pool. View
the Status in Local Cell Status Parameters. If the status is blocked, unblock it.
2) Node B is blocked or faulty
On the ground resource configuration interface, view Node B status. If the status is blocked, unblock
the Node B. If the status is faulty, it indicates that FS board may be faulty. In this case, check if related
alarms exist. If yes, follow the suggestions on handling the related alarms.
The related alarms are as follows:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
3) Local cell is faulty
View the"Local Cell Status Parameters" interface. If the current status is faulty, it indicates that FS
board or RTR board is faulty or restarted. In this case, check if the following alarms are generated. If
yes, follow the suggestions on handling the related alarms:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
4) Baseband board is blocked
View the BPC board status. If the status is blocked, unblock it.
5) Baseband board is faulty
View the BPC board status. If the status is faulty, handle the alarm by referring to the following
suggestions:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
3.Alarm reason: Cell is blocked at NodeB side.
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management > Baseband Resource Pool. If
the cell status is blocked, unblock it.
4.Alarm reason: System information update fail.
The alarm is caused by the failure to update system messages, that is, system message broadcast
fails. Handle the alarm by referring to the suggestion for "Broadcast fail".
2-142
5.For other alarm causes, the system re-establishes the cell automatically. No human intervention
is required.
Probable Cause
System Impact
The cell is unavailable and fails to provide services. Users fail to gain access through this cell.
Handling Suggestion
1.Baseband Resource Pool. Check if the values of Local Cell ID, Receiving Frequency Point, and
Transmitting Frequency Point in"Local Cell Basic Parameters" are consistent with those at RNC side.
If not, modify the RNC or Node B configurations to make them consistent.
2) On NMS fault management interface, check if Node B has generated "199084129 Board reboots
alarm". If yes, it indicates that the Node B has just been started or hardware has been just replaced
or added. In this case, wait for the Node B to finish powering on.
2.Alarm reason: Cell CGID is zero audit by NodeB.
1) Local cell is blocked
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management >Baseband Resource Pool. View
the Status in Local Cell Status Parameters. If the status is blocked, unblock it.
2) Node B is blocked or faulty
On the ground resource configuration interface, view Node B status. If the status is blocked, unblock
the Node B. If the status is faulty, it indicates that FS board may be faulty. In this case, check if related
alarms exist. If yes, follow the suggestions on handling the related alarms.
The related alarms are as follows:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
3) Local cell is faulty
2-143
View the"Local Cell Status Parameters" interface. If the current status is faulty, it indicates that FS
board or RTR board is faulty or restarted. In this case, check if the following alarms are generated. If
yes, follow the suggestions on handling the related alarms:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
4) Baseband board is blocked
View the BPC board status. If the status is blocked, unblock it.
5) Baseband board is faulty
View the BPC board status. If the status is faulty, handle the alarm by referring to the following
suggestions:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
3.Alarm reason: Cell is blocked at NodeB side.
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management > Baseband Resource Pool. If
the cell status is blocked, unblock it.
4.Alarm reason: System information update fail.
The alarm is caused by the failure to update system messages, that is, system message broadcast
fails. Handle the alarm by referring to the suggestion for "Broadcast fail".
5.For other alarm causes, the system re-establishes the cell automatically. No human intervention
is required.
Probable Cause
System Impact
The cell is unavailable and fails to provide services. Users fail to gain access through this cell.
2-144
Handling Suggestion
1.Baseband Resource Pool. Check if the values of Local Cell ID, Receiving Frequency Point, and
Transmitting Frequency Point in"Local Cell Basic Parameters" are consistent with those at RNC side.
If not, modify the RNC or Node B configurations to make them consistent.
2) On NMS fault management interface, check if Node B has generated "199084129 Board reboots
alarm". If yes, it indicates that the Node B has just been started or hardware has been just replaced
or added. In this case, wait for the Node B to finish powering on.
2.Alarm reason: Cell CGID is zero audit by NodeB.
1) Local cell is blocked
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management >Baseband Resource Pool. View
the Status in Local Cell Status Parameters. If the status is blocked, unblock it.
2) Node B is blocked or faulty
On the ground resource configuration interface, view Node B status. If the status is blocked, unblock
the Node B. If the status is faulty, it indicates that FS board may be faulty. In this case, check if related
alarms exist. If yes, follow the suggestions on handling the related alarms.
The related alarms are as follows:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
3) Local cell is faulty
View the"Local Cell Status Parameters" interface. If the current status is faulty, it indicates that FS
board or RTR board is faulty or restarted. In this case, check if the following alarms are generated. If
yes, follow the suggestions on handling the related alarms:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
4) Baseband board is blocked
View the BPC board status. If the status is blocked, unblock it.
5) Baseband board is faulty
View the BPC board status. If the status is faulty, handle the alarm by referring to the following
suggestions:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
3.Alarm reason: Cell is blocked at NodeB side.
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management > Baseband Resource Pool. If
the cell status is blocked, unblock it.
4.Alarm reason: System information update fail.
The alarm is caused by the failure to update system messages, that is, system message broadcast
fails. Handle the alarm by referring to the suggestion for "Broadcast fail".
2-145
5.For other alarm causes, the system re-establishes the cell automatically. No human intervention
is required.
Probable Cause
System Impact
The cell is unavailable and fails to provide services. Users fail to gain access through this cell.
Handling Suggestion
1.Baseband Resource Pool. Check if the values of Local Cell ID, Receiving Frequency Point, and
Transmitting Frequency Point in"Local Cell Basic Parameters" are consistent with those at RNC side.
If not, modify the RNC or Node B configurations to make them consistent.
2) On NMS fault management interface, check if Node B has generated "199084129 Board reboots
alarm". If yes, it indicates that the Node B has just been started or hardware has been just replaced
or added. In this case, wait for the Node B to finish powering on.
2.Alarm reason: Cell CGID is zero audit by NodeB.
1) Local cell is blocked
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management >Baseband Resource Pool. View
the Status in Local Cell Status Parameters. If the status is blocked, unblock it.
2) Node B is blocked or faulty
On the ground resource configuration interface, view Node B status. If the status is blocked, unblock
the Node B. If the status is faulty, it indicates that FS board may be faulty. In this case, check if related
alarms exist. If yes, follow the suggestions on handling the related alarms.
The related alarms are as follows:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
3) Local cell is faulty
2-146
View the"Local Cell Status Parameters" interface. If the current status is faulty, it indicates that FS
board or RTR board is faulty or restarted. In this case, check if the following alarms are generated. If
yes, follow the suggestions on handling the related alarms:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
4) Baseband board is blocked
View the BPC board status. If the status is blocked, unblock it.
5) Baseband board is faulty
View the BPC board status. If the status is faulty, handle the alarm by referring to the following
suggestions:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
3.Alarm reason: Cell is blocked at NodeB side.
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management > Baseband Resource Pool. If
the cell status is blocked, unblock it.
4.Alarm reason: System information update fail.
The alarm is caused by the failure to update system messages, that is, system message broadcast
fails. Handle the alarm by referring to the suggestion for "Broadcast fail".
5.For other alarm causes, the system re-establishes the cell automatically. No human intervention
is required.
Probable Cause
System Impact
The cell is unavailable and fails to provide services. Users fail to gain access through this cell.
2-147
Handling Suggestion
1.Baseband Resource Pool. Check if the values of Local Cell ID, Receiving Frequency Point, and
Transmitting Frequency Point in"Local Cell Basic Parameters" are consistent with those at RNC side.
If not, modify the RNC or Node B configurations to make them consistent.
2) On NMS fault management interface, check if Node B has generated "199084129 Board reboots
alarm". If yes, it indicates that the Node B has just been started or hardware has been just replaced
or added. In this case, wait for the Node B to finish powering on.
2.Alarm reason: Cell CGID is zero audit by NodeB.
1) Local cell is blocked
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management >Baseband Resource Pool. View
the Status in Local Cell Status Parameters. If the status is blocked, unblock it.
2) Node B is blocked or faulty
On the ground resource configuration interface, view Node B status. If the status is blocked, unblock
the Node B. If the status is faulty, it indicates that FS board may be faulty. In this case, check if related
alarms exist. If yes, follow the suggestions on handling the related alarms.
The related alarms are as follows:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
3) Local cell is faulty
View the"Local Cell Status Parameters" interface. If the current status is faulty, it indicates that FS
board or RTR board is faulty or restarted. In this case, check if the following alarms are generated. If
yes, follow the suggestions on handling the related alarms:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
4) Baseband board is blocked
View the BPC board status. If the status is blocked, unblock it.
5) Baseband board is faulty
View the BPC board status. If the status is faulty, handle the alarm by referring to the following
suggestions:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
3.Alarm reason: Cell is blocked at NodeB side.
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management > Baseband Resource Pool. If
the cell status is blocked, unblock it.
4.Alarm reason: System information update fail.
The alarm is caused by the failure to update system messages, that is, system message broadcast
fails. Handle the alarm by referring to the suggestion for "Broadcast fail".
2-148
5.For other alarm causes, the system re-establishes the cell automatically. No human intervention
is required.
Probable Cause
System Impact
The cell is unavailable and fails to provide services. Users fail to gain access through this cell.
Handling Suggestion
1.Baseband Resource Pool. Check if the values of Local Cell ID, Receiving Frequency Point, and
Transmitting Frequency Point in"Local Cell Basic Parameters" are consistent with those at RNC side.
If not, modify the RNC or Node B configurations to make them consistent.
2) On NMS fault management interface, check if Node B has generated "199084129 Board reboots
alarm". If yes, it indicates that the Node B has just been started or hardware has been just replaced
or added. In this case, wait for the Node B to finish powering on.
2.Alarm reason: Cell CGID is zero audit by NodeB.
1) Local cell is blocked
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management >Baseband Resource Pool. View
the Status in Local Cell Status Parameters. If the status is blocked, unblock it.
2) Node B is blocked or faulty
On the ground resource configuration interface, view Node B status. If the status is blocked, unblock
the Node B. If the status is faulty, it indicates that FS board may be faulty. In this case, check if related
alarms exist. If yes, follow the suggestions on handling the related alarms.
The related alarms are as follows:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
3) Local cell is faulty
2-149
View the"Local Cell Status Parameters" interface. If the current status is faulty, it indicates that FS
board or RTR board is faulty or restarted. In this case, check if the following alarms are generated. If
yes, follow the suggestions on handling the related alarms:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
4) Baseband board is blocked
View the BPC board status. If the status is blocked, unblock it.
5) Baseband board is faulty
View the BPC board status. If the status is faulty, handle the alarm by referring to the following
suggestions:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
3.Alarm reason: Cell is blocked at NodeB side.
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management > Baseband Resource Pool. If
the cell status is blocked, unblock it.
4.Alarm reason: System information update fail.
The alarm is caused by the failure to update system messages, that is, system message broadcast
fails. Handle the alarm by referring to the suggestion for "Broadcast fail".
5.For other alarm causes, the system re-establishes the cell automatically. No human intervention
is required.
Probable Cause
Cell delete: The Bearer type of common transport channel is modified in NMS.
System Impact
The cell is unavailable and fails to provide services. Users fail to gain access through this cell.
2-150
Handling Suggestion
1.Baseband Resource Pool. Check if the values of Local Cell ID, Receiving Frequency Point, and
Transmitting Frequency Point in"Local Cell Basic Parameters" are consistent with those at RNC side.
If not, modify the RNC or Node B configurations to make them consistent.
2) On NMS fault management interface, check if Node B has generated "199084129 Board reboots
alarm". If yes, it indicates that the Node B has just been started or hardware has been just replaced
or added. In this case, wait for the Node B to finish powering on.
2.Alarm reason: Cell CGID is zero audit by NodeB.
1) Local cell is blocked
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management >Baseband Resource Pool. View
the Status in Local Cell Status Parameters. If the status is blocked, unblock it.
2) Node B is blocked or faulty
On the ground resource configuration interface, view Node B status. If the status is blocked, unblock
the Node B. If the status is faulty, it indicates that FS board may be faulty. In this case, check if related
alarms exist. If yes, follow the suggestions on handling the related alarms.
The related alarms are as follows:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
3) Local cell is faulty
View the"Local Cell Status Parameters" interface. If the current status is faulty, it indicates that FS
board or RTR board is faulty or restarted. In this case, check if the following alarms are generated. If
yes, follow the suggestions on handling the related alarms:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
4) Baseband board is blocked
View the BPC board status. If the status is blocked, unblock it.
5) Baseband board is faulty
View the BPC board status. If the status is faulty, handle the alarm by referring to the following
suggestions:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
3.Alarm reason: Cell is blocked at NodeB side.
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management > Baseband Resource Pool. If
the cell status is blocked, unblock it.
4.Alarm reason: System information update fail.
The alarm is caused by the failure to update system messages, that is, system message broadcast
fails. Handle the alarm by referring to the suggestion for "Broadcast fail".
2-151
5.For other alarm causes, the system re-establishes the cell automatically. No human intervention
is required.
Probable Cause
Cell delete: The transmission is break between RNC and Node B for a long time.
System Impact
The cell is unavailable and fails to provide services. Users fail to gain access through this cell.
Handling Suggestion
1.Baseband Resource Pool. Check if the values of Local Cell ID, Receiving Frequency Point, and
Transmitting Frequency Point in"Local Cell Basic Parameters" are consistent with those at RNC side.
If not, modify the RNC or Node B configurations to make them consistent.
2) On NMS fault management interface, check if Node B has generated "199084129 Board reboots
alarm". If yes, it indicates that the Node B has just been started or hardware has been just replaced
or added. In this case, wait for the Node B to finish powering on.
2.Alarm reason: Cell CGID is zero audit by NodeB.
1) Local cell is blocked
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management >Baseband Resource Pool. View
the Status in Local Cell Status Parameters. If the status is blocked, unblock it.
2) Node B is blocked or faulty
On the ground resource configuration interface, view Node B status. If the status is blocked, unblock
the Node B. If the status is faulty, it indicates that FS board may be faulty. In this case, check if related
alarms exist. If yes, follow the suggestions on handling the related alarms.
The related alarms are as follows:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
3) Local cell is faulty
2-152
View the"Local Cell Status Parameters" interface. If the current status is faulty, it indicates that FS
board or RTR board is faulty or restarted. In this case, check if the following alarms are generated. If
yes, follow the suggestions on handling the related alarms:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
4) Baseband board is blocked
View the BPC board status. If the status is blocked, unblock it.
5) Baseband board is faulty
View the BPC board status. If the status is faulty, handle the alarm by referring to the following
suggestions:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
3.Alarm reason: Cell is blocked at NodeB side.
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management > Baseband Resource Pool. If
the cell status is blocked, unblock it.
4.Alarm reason: System information update fail.
The alarm is caused by the failure to update system messages, that is, system message broadcast
fails. Handle the alarm by referring to the suggestion for "Broadcast fail".
5.For other alarm causes, the system re-establishes the cell automatically. No human intervention
is required.
Probable Cause
System Impact
The cell is unavailable and fails to provide services. Users fail to gain access through this cell.
2-153
Handling Suggestion
1.Baseband Resource Pool. Check if the values of Local Cell ID, Receiving Frequency Point, and
Transmitting Frequency Point in"Local Cell Basic Parameters" are consistent with those at RNC side.
If not, modify the RNC or Node B configurations to make them consistent.
2) On NMS fault management interface, check if Node B has generated "199084129 Board reboots
alarm". If yes, it indicates that the Node B has just been started or hardware has been just replaced
or added. In this case, wait for the Node B to finish powering on.
2.Alarm reason: Cell CGID is zero audit by NodeB.
1) Local cell is blocked
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management >Baseband Resource Pool. View
the Status in Local Cell Status Parameters. If the status is blocked, unblock it.
2) Node B is blocked or faulty
On the ground resource configuration interface, view Node B status. If the status is blocked, unblock
the Node B. If the status is faulty, it indicates that FS board may be faulty. In this case, check if related
alarms exist. If yes, follow the suggestions on handling the related alarms.
The related alarms are as follows:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
3) Local cell is faulty
View the"Local Cell Status Parameters" interface. If the current status is faulty, it indicates that FS
board or RTR board is faulty or restarted. In this case, check if the following alarms are generated. If
yes, follow the suggestions on handling the related alarms:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
4) Baseband board is blocked
View the BPC board status. If the status is blocked, unblock it.
5) Baseband board is faulty
View the BPC board status. If the status is faulty, handle the alarm by referring to the following
suggestions:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
3.Alarm reason: Cell is blocked at NodeB side.
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management > Baseband Resource Pool. If
the cell status is blocked, unblock it.
4.Alarm reason: System information update fail.
The alarm is caused by the failure to update system messages, that is, system message broadcast
fails. Handle the alarm by referring to the suggestion for "Broadcast fail".
2-154
5.For other alarm causes, the system re-establishes the cell automatically. No human intervention
is required.
Probable Cause
Cell delete: Established cell information is not exist in the audit response message.
System Impact
The cell is unavailable and fails to provide services. Users fail to gain access through this cell.
Handling Suggestion
1.Baseband Resource Pool. Check if the values of Local Cell ID, Receiving Frequency Point, and
Transmitting Frequency Point in"Local Cell Basic Parameters" are consistent with those at RNC side.
If not, modify the RNC or Node B configurations to make them consistent.
2) On NMS fault management interface, check if Node B has generated "199084129 Board reboots
alarm". If yes, it indicates that the Node B has just been started or hardware has been just replaced
or added. In this case, wait for the Node B to finish powering on.
2.Alarm reason: Cell CGID is zero audit by NodeB.
1) Local cell is blocked
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management >Baseband Resource Pool. View
the Status in Local Cell Status Parameters. If the status is blocked, unblock it.
2) Node B is blocked or faulty
On the ground resource configuration interface, view Node B status. If the status is blocked, unblock
the Node B. If the status is faulty, it indicates that FS board may be faulty. In this case, check if related
alarms exist. If yes, follow the suggestions on handling the related alarms.
The related alarms are as follows:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
3) Local cell is faulty
2-155
View the"Local Cell Status Parameters" interface. If the current status is faulty, it indicates that FS
board or RTR board is faulty or restarted. In this case, check if the following alarms are generated. If
yes, follow the suggestions on handling the related alarms:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
4) Baseband board is blocked
View the BPC board status. If the status is blocked, unblock it.
5) Baseband board is faulty
View the BPC board status. If the status is faulty, handle the alarm by referring to the following
suggestions:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
3.Alarm reason: Cell is blocked at NodeB side.
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management > Baseband Resource Pool. If
the cell status is blocked, unblock it.
4.Alarm reason: System information update fail.
The alarm is caused by the failure to update system messages, that is, system message broadcast
fails. Handle the alarm by referring to the suggestion for "Broadcast fail".
5.For other alarm causes, the system re-establishes the cell automatically. No human intervention
is required.
Probable Cause
System Impact
The cell is unavailable and fails to provide services. Users fail to gain access through this cell.
2-156
Handling Suggestion
1.Baseband Resource Pool. Check if the values of Local Cell ID, Receiving Frequency Point, and
Transmitting Frequency Point in"Local Cell Basic Parameters" are consistent with those at RNC side.
If not, modify the RNC or Node B configurations to make them consistent.
2) On NMS fault management interface, check if Node B has generated "199084129 Board reboots
alarm". If yes, it indicates that the Node B has just been started or hardware has been just replaced
or added. In this case, wait for the Node B to finish powering on.
2.Alarm reason: Cell CGID is zero audit by NodeB.
1) Local cell is blocked
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management >Baseband Resource Pool. View
the Status in Local Cell Status Parameters. If the status is blocked, unblock it.
2) Node B is blocked or faulty
On the ground resource configuration interface, view Node B status. If the status is blocked, unblock
the Node B. If the status is faulty, it indicates that FS board may be faulty. In this case, check if related
alarms exist. If yes, follow the suggestions on handling the related alarms.
The related alarms are as follows:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
3) Local cell is faulty
View the"Local Cell Status Parameters" interface. If the current status is faulty, it indicates that FS
board or RTR board is faulty or restarted. In this case, check if the following alarms are generated. If
yes, follow the suggestions on handling the related alarms:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
4) Baseband board is blocked
View the BPC board status. If the status is blocked, unblock it.
5) Baseband board is faulty
View the BPC board status. If the status is faulty, handle the alarm by referring to the following
suggestions:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
3.Alarm reason: Cell is blocked at NodeB side.
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management > Baseband Resource Pool. If
the cell status is blocked, unblock it.
4.Alarm reason: System information update fail.
The alarm is caused by the failure to update system messages, that is, system message broadcast
fails. Handle the alarm by referring to the suggestion for "Broadcast fail".
2-157
5.For other alarm causes, the system re-establishes the cell automatically. No human intervention
is required.
Probable Cause
System Impact
The cell is unavailable and fails to provide services. Users fail to gain access through this cell.
Handling Suggestion
1.Baseband Resource Pool. Check if the values of Local Cell ID, Receiving Frequency Point, and
Transmitting Frequency Point in"Local Cell Basic Parameters" are consistent with those at RNC side.
If not, modify the RNC or Node B configurations to make them consistent.
2) On NMS fault management interface, check if Node B has generated "199084129 Board reboots
alarm". If yes, it indicates that the Node B has just been started or hardware has been just replaced
or added. In this case, wait for the Node B to finish powering on.
2.Alarm reason: Cell CGID is zero audit by NodeB.
1) Local cell is blocked
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management >Baseband Resource Pool. View
the Status in Local Cell Status Parameters. If the status is blocked, unblock it.
2) Node B is blocked or faulty
On the ground resource configuration interface, view Node B status. If the status is blocked, unblock
the Node B. If the status is faulty, it indicates that FS board may be faulty. In this case, check if related
alarms exist. If yes, follow the suggestions on handling the related alarms.
The related alarms are as follows:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
3) Local cell is faulty
2-158
View the"Local Cell Status Parameters" interface. If the current status is faulty, it indicates that FS
board or RTR board is faulty or restarted. In this case, check if the following alarms are generated. If
yes, follow the suggestions on handling the related alarms:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
4) Baseband board is blocked
View the BPC board status. If the status is blocked, unblock it.
5) Baseband board is faulty
View the BPC board status. If the status is faulty, handle the alarm by referring to the following
suggestions:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
3.Alarm reason: Cell is blocked at NodeB side.
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management > Baseband Resource Pool. If
the cell status is blocked, unblock it.
4.Alarm reason: System information update fail.
The alarm is caused by the failure to update system messages, that is, system message broadcast
fails. Handle the alarm by referring to the suggestion for "Broadcast fail".
5.For other alarm causes, the system re-establishes the cell automatically. No human intervention
is required.
Probable Cause
System Impact
The cell is unavailable and fails to provide services. Users fail to gain access through this cell.
2-159
Handling Suggestion
1.Baseband Resource Pool. Check if the values of Local Cell ID, Receiving Frequency Point, and
Transmitting Frequency Point in"Local Cell Basic Parameters" are consistent with those at RNC side.
If not, modify the RNC or Node B configurations to make them consistent.
2) On NMS fault management interface, check if Node B has generated "199084129 Board reboots
alarm". If yes, it indicates that the Node B has just been started or hardware has been just replaced
or added. In this case, wait for the Node B to finish powering on.
2.Alarm reason: Cell CGID is zero audit by NodeB.
1) Local cell is blocked
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management >Baseband Resource Pool. View
the Status in Local Cell Status Parameters. If the status is blocked, unblock it.
2) Node B is blocked or faulty
On the ground resource configuration interface, view Node B status. If the status is blocked, unblock
the Node B. If the status is faulty, it indicates that FS board may be faulty. In this case, check if related
alarms exist. If yes, follow the suggestions on handling the related alarms.
The related alarms are as follows:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
3) Local cell is faulty
View the"Local Cell Status Parameters" interface. If the current status is faulty, it indicates that FS
board or RTR board is faulty or restarted. In this case, check if the following alarms are generated. If
yes, follow the suggestions on handling the related alarms:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
4) Baseband board is blocked
View the BPC board status. If the status is blocked, unblock it.
5) Baseband board is faulty
View the BPC board status. If the status is faulty, handle the alarm by referring to the following
suggestions:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
3.Alarm reason: Cell is blocked at NodeB side.
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management > Baseband Resource Pool. If
the cell status is blocked, unblock it.
4.Alarm reason: System information update fail.
The alarm is caused by the failure to update system messages, that is, system message broadcast
fails. Handle the alarm by referring to the suggestion for "Broadcast fail".
2-160
5.For other alarm causes, the system re-establishes the cell automatically. No human intervention
is required.
Probable Cause
System Impact
The cell is unavailable and fails to provide services. Users fail to gain access through this cell.
Handling Suggestion
1.Baseband Resource Pool. Check if the values of Local Cell ID, Receiving Frequency Point, and
Transmitting Frequency Point in"Local Cell Basic Parameters" are consistent with those at RNC side.
If not, modify the RNC or Node B configurations to make them consistent.
2) On NMS fault management interface, check if Node B has generated "199084129 Board reboots
alarm". If yes, it indicates that the Node B has just been started or hardware has been just replaced
or added. In this case, wait for the Node B to finish powering on.
2.Alarm reason: Cell CGID is zero audit by NodeB.
1) Local cell is blocked
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management >Baseband Resource Pool. View
the Status in Local Cell Status Parameters. If the status is blocked, unblock it.
2) Node B is blocked or faulty
On the ground resource configuration interface, view Node B status. If the status is blocked, unblock
the Node B. If the status is faulty, it indicates that FS board may be faulty. In this case, check if related
alarms exist. If yes, follow the suggestions on handling the related alarms.
The related alarms are as follows:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
3) Local cell is faulty
2-161
View the"Local Cell Status Parameters" interface. If the current status is faulty, it indicates that FS
board or RTR board is faulty or restarted. In this case, check if the following alarms are generated. If
yes, follow the suggestions on handling the related alarms:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
4) Baseband board is blocked
View the BPC board status. If the status is blocked, unblock it.
5) Baseband board is faulty
View the BPC board status. If the status is faulty, handle the alarm by referring to the following
suggestions:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
3.Alarm reason: Cell is blocked at NodeB side.
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management > Baseband Resource Pool. If
the cell status is blocked, unblock it.
4.Alarm reason: System information update fail.
The alarm is caused by the failure to update system messages, that is, system message broadcast
fails. Handle the alarm by referring to the suggestion for "Broadcast fail".
5.For other alarm causes, the system re-establishes the cell automatically. No human intervention
is required.
Probable Cause
System Impact
The cell is unavailable and fails to provide services. Users fail to gain access through this cell.
2-162
Handling Suggestion
1.Baseband Resource Pool. Check if the values of Local Cell ID, Receiving Frequency Point, and
Transmitting Frequency Point in"Local Cell Basic Parameters" are consistent with those at RNC side.
If not, modify the RNC or Node B configurations to make them consistent.
2) On NMS fault management interface, check if Node B has generated "199084129 Board reboots
alarm". If yes, it indicates that the Node B has just been started or hardware has been just replaced
or added. In this case, wait for the Node B to finish powering on.
2.Alarm reason: Cell CGID is zero audit by NodeB.
1) Local cell is blocked
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management >Baseband Resource Pool. View
the Status in Local Cell Status Parameters. If the status is blocked, unblock it.
2) Node B is blocked or faulty
On the ground resource configuration interface, view Node B status. If the status is blocked, unblock
the Node B. If the status is faulty, it indicates that FS board may be faulty. In this case, check if related
alarms exist. If yes, follow the suggestions on handling the related alarms.
The related alarms are as follows:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
3) Local cell is faulty
View the"Local Cell Status Parameters" interface. If the current status is faulty, it indicates that FS
board or RTR board is faulty or restarted. In this case, check if the following alarms are generated. If
yes, follow the suggestions on handling the related alarms:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
4) Baseband board is blocked
View the BPC board status. If the status is blocked, unblock it.
5) Baseband board is faulty
View the BPC board status. If the status is faulty, handle the alarm by referring to the following
suggestions:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
3.Alarm reason: Cell is blocked at NodeB side.
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management > Baseband Resource Pool. If
the cell status is blocked, unblock it.
4.Alarm reason: System information update fail.
The alarm is caused by the failure to update system messages, that is, system message broadcast
fails. Handle the alarm by referring to the suggestion for "Broadcast fail".
2-163
5.For other alarm causes, the system re-establishes the cell automatically. No human intervention
is required.
Probable Cause
System Impact
The cell is unavailable and fails to provide services. Users fail to gain access through this cell.
Handling Suggestion
1.Baseband Resource Pool. Check if the values of Local Cell ID, Receiving Frequency Point, and
Transmitting Frequency Point in"Local Cell Basic Parameters" are consistent with those at RNC side.
If not, modify the RNC or Node B configurations to make them consistent.
2) On NMS fault management interface, check if Node B has generated "199084129 Board reboots
alarm". If yes, it indicates that the Node B has just been started or hardware has been just replaced
or added. In this case, wait for the Node B to finish powering on.
2.Alarm reason: Cell CGID is zero audit by NodeB.
1) Local cell is blocked
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management >Baseband Resource Pool. View
the Status in Local Cell Status Parameters. If the status is blocked, unblock it.
2) Node B is blocked or faulty
On the ground resource configuration interface, view Node B status. If the status is blocked, unblock
the Node B. If the status is faulty, it indicates that FS board may be faulty. In this case, check if related
alarms exist. If yes, follow the suggestions on handling the related alarms.
The related alarms are as follows:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
3) Local cell is faulty
2-164
View the"Local Cell Status Parameters" interface. If the current status is faulty, it indicates that FS
board or RTR board is faulty or restarted. In this case, check if the following alarms are generated. If
yes, follow the suggestions on handling the related alarms:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
4) Baseband board is blocked
View the BPC board status. If the status is blocked, unblock it.
5) Baseband board is faulty
View the BPC board status. If the status is faulty, handle the alarm by referring to the following
suggestions:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
3.Alarm reason: Cell is blocked at NodeB side.
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management > Baseband Resource Pool. If
the cell status is blocked, unblock it.
4.Alarm reason: System information update fail.
The alarm is caused by the failure to update system messages, that is, system message broadcast
fails. Handle the alarm by referring to the suggestion for "Broadcast fail".
5.For other alarm causes, the system re-establishes the cell automatically. No human intervention
is required.
Probable Cause
System Impact
The cell is unavailable and fails to provide services. Users fail to gain access through this cell.
2-165
Handling Suggestion
1.Baseband Resource Pool. Check if the values of Local Cell ID, Receiving Frequency Point, and
Transmitting Frequency Point in"Local Cell Basic Parameters" are consistent with those at RNC side.
If not, modify the RNC or Node B configurations to make them consistent.
2) On NMS fault management interface, check if Node B has generated "199084129 Board reboots
alarm". If yes, it indicates that the Node B has just been started or hardware has been just replaced
or added. In this case, wait for the Node B to finish powering on.
2.Alarm reason: Cell CGID is zero audit by NodeB.
1) Local cell is blocked
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management >Baseband Resource Pool. View
the Status in Local Cell Status Parameters. If the status is blocked, unblock it.
2) Node B is blocked or faulty
On the ground resource configuration interface, view Node B status. If the status is blocked, unblock
the Node B. If the status is faulty, it indicates that FS board may be faulty. In this case, check if related
alarms exist. If yes, follow the suggestions on handling the related alarms.
The related alarms are as follows:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
3) Local cell is faulty
View the"Local Cell Status Parameters" interface. If the current status is faulty, it indicates that FS
board or RTR board is faulty or restarted. In this case, check if the following alarms are generated. If
yes, follow the suggestions on handling the related alarms:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
4) Baseband board is blocked
View the BPC board status. If the status is blocked, unblock it.
5) Baseband board is faulty
View the BPC board status. If the status is faulty, handle the alarm by referring to the following
suggestions:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
3.Alarm reason: Cell is blocked at NodeB side.
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management > Baseband Resource Pool. If
the cell status is blocked, unblock it.
4.Alarm reason: System information update fail.
The alarm is caused by the failure to update system messages, that is, system message broadcast
fails. Handle the alarm by referring to the suggestion for "Broadcast fail".
2-166
5.For other alarm causes, the system re-establishes the cell automatically. No human intervention
is required.
Probable Cause
System Impact
The cell is unavailable and fails to provide services. Users fail to gain access through this cell.
Handling Suggestion
1.Baseband Resource Pool. Check if the values of Local Cell ID, Receiving Frequency Point, and
Transmitting Frequency Point in"Local Cell Basic Parameters" are consistent with those at RNC side.
If not, modify the RNC or Node B configurations to make them consistent.
2) On NMS fault management interface, check if Node B has generated "199084129 Board reboots
alarm". If yes, it indicates that the Node B has just been started or hardware has been just replaced
or added. In this case, wait for the Node B to finish powering on.
2.Alarm reason: Cell CGID is zero audit by NodeB.
1) Local cell is blocked
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management >Baseband Resource Pool. View
the Status in Local Cell Status Parameters. If the status is blocked, unblock it.
2) Node B is blocked or faulty
On the ground resource configuration interface, view Node B status. If the status is blocked, unblock
the Node B. If the status is faulty, it indicates that FS board may be faulty. In this case, check if related
alarms exist. If yes, follow the suggestions on handling the related alarms.
The related alarms are as follows:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
3) Local cell is faulty
2-167
View the"Local Cell Status Parameters" interface. If the current status is faulty, it indicates that FS
board or RTR board is faulty or restarted. In this case, check if the following alarms are generated. If
yes, follow the suggestions on handling the related alarms:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
4) Baseband board is blocked
View the BPC board status. If the status is blocked, unblock it.
5) Baseband board is faulty
View the BPC board status. If the status is faulty, handle the alarm by referring to the following
suggestions:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
3.Alarm reason: Cell is blocked at NodeB side.
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management > Baseband Resource Pool. If
the cell status is blocked, unblock it.
4.Alarm reason: System information update fail.
The alarm is caused by the failure to update system messages, that is, system message broadcast
fails. Handle the alarm by referring to the suggestion for "Broadcast fail".
5.For other alarm causes, the system re-establishes the cell automatically. No human intervention
is required.
Probable Cause
Cell delete: Cell instance at CRM-setup status fail to receive setup response message form CRM
module.
System Impact
The cell is unavailable and fails to provide services. Users fail to gain access through this cell.
2-168
Handling Suggestion
1.Baseband Resource Pool. Check if the values of Local Cell ID, Receiving Frequency Point, and
Transmitting Frequency Point in"Local Cell Basic Parameters" are consistent with those at RNC side.
If not, modify the RNC or Node B configurations to make them consistent.
2) On NMS fault management interface, check if Node B has generated "199084129 Board reboots
alarm". If yes, it indicates that the Node B has just been started or hardware has been just replaced
or added. In this case, wait for the Node B to finish powering on.
2.Alarm reason: Cell CGID is zero audit by NodeB.
1) Local cell is blocked
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management >Baseband Resource Pool. View
the Status in Local Cell Status Parameters. If the status is blocked, unblock it.
2) Node B is blocked or faulty
On the ground resource configuration interface, view Node B status. If the status is blocked, unblock
the Node B. If the status is faulty, it indicates that FS board may be faulty. In this case, check if related
alarms exist. If yes, follow the suggestions on handling the related alarms.
The related alarms are as follows:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
3) Local cell is faulty
View the"Local Cell Status Parameters" interface. If the current status is faulty, it indicates that FS
board or RTR board is faulty or restarted. In this case, check if the following alarms are generated. If
yes, follow the suggestions on handling the related alarms:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
4) Baseband board is blocked
View the BPC board status. If the status is blocked, unblock it.
5) Baseband board is faulty
View the BPC board status. If the status is faulty, handle the alarm by referring to the following
suggestions:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
3.Alarm reason: Cell is blocked at NodeB side.
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management > Baseband Resource Pool. If
the cell status is blocked, unblock it.
4.Alarm reason: System information update fail.
The alarm is caused by the failure to update system messages, that is, system message broadcast
fails. Handle the alarm by referring to the suggestion for "Broadcast fail".
2-169
5.For other alarm causes, the system re-establishes the cell automatically. No human intervention
is required.
Probable Cause
System Impact
The cell is unavailable and fails to provide services. Users fail to gain access through this cell.
Handling Suggestion
1.Baseband Resource Pool. Check if the values of Local Cell ID, Receiving Frequency Point, and
Transmitting Frequency Point in"Local Cell Basic Parameters" are consistent with those at RNC side.
If not, modify the RNC or Node B configurations to make them consistent.
2) On NMS fault management interface, check if Node B has generated "199084129 Board reboots
alarm". If yes, it indicates that the Node B has just been started or hardware has been just replaced
or added. In this case, wait for the Node B to finish powering on.
2.Alarm reason: Cell CGID is zero audit by NodeB.
1) Local cell is blocked
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management >Baseband Resource Pool. View
the Status in Local Cell Status Parameters. If the status is blocked, unblock it.
2) Node B is blocked or faulty
On the ground resource configuration interface, view Node B status. If the status is blocked, unblock
the Node B. If the status is faulty, it indicates that FS board may be faulty. In this case, check if related
alarms exist. If yes, follow the suggestions on handling the related alarms.
The related alarms are as follows:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
3) Local cell is faulty
2-170
View the"Local Cell Status Parameters" interface. If the current status is faulty, it indicates that FS
board or RTR board is faulty or restarted. In this case, check if the following alarms are generated. If
yes, follow the suggestions on handling the related alarms:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
4) Baseband board is blocked
View the BPC board status. If the status is blocked, unblock it.
5) Baseband board is faulty
View the BPC board status. If the status is faulty, handle the alarm by referring to the following
suggestions:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
3.Alarm reason: Cell is blocked at NodeB side.
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management > Baseband Resource Pool. If
the cell status is blocked, unblock it.
4.Alarm reason: System information update fail.
The alarm is caused by the failure to update system messages, that is, system message broadcast
fails. Handle the alarm by referring to the suggestion for "Broadcast fail".
5.For other alarm causes, the system re-establishes the cell automatically. No human intervention
is required.
Probable Cause
System Impact
The cell is unavailable and fails to provide services. Users fail to gain access through this cell.
2-171
Handling Suggestion
1.Baseband Resource Pool. Check if the values of Local Cell ID, Receiving Frequency Point, and
Transmitting Frequency Point in"Local Cell Basic Parameters" are consistent with those at RNC side.
If not, modify the RNC or Node B configurations to make them consistent.
2) On NMS fault management interface, check if Node B has generated "199084129 Board reboots
alarm". If yes, it indicates that the Node B has just been started or hardware has been just replaced
or added. In this case, wait for the Node B to finish powering on.
2.Alarm reason: Cell CGID is zero audit by NodeB.
1) Local cell is blocked
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management >Baseband Resource Pool. View
the Status in Local Cell Status Parameters. If the status is blocked, unblock it.
2) Node B is blocked or faulty
On the ground resource configuration interface, view Node B status. If the status is blocked, unblock
the Node B. If the status is faulty, it indicates that FS board may be faulty. In this case, check if related
alarms exist. If yes, follow the suggestions on handling the related alarms.
The related alarms are as follows:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
3) Local cell is faulty
View the"Local Cell Status Parameters" interface. If the current status is faulty, it indicates that FS
board or RTR board is faulty or restarted. In this case, check if the following alarms are generated. If
yes, follow the suggestions on handling the related alarms:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
4) Baseband board is blocked
View the BPC board status. If the status is blocked, unblock it.
5) Baseband board is faulty
View the BPC board status. If the status is faulty, handle the alarm by referring to the following
suggestions:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
3.Alarm reason: Cell is blocked at NodeB side.
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management > Baseband Resource Pool. If
the cell status is blocked, unblock it.
4.Alarm reason: System information update fail.
The alarm is caused by the failure to update system messages, that is, system message broadcast
fails. Handle the alarm by referring to the suggestion for "Broadcast fail".
2-172
5.For other alarm causes, the system re-establishes the cell automatically. No human intervention
is required.
Probable Cause
Cell delete:Local Cell ID configured only at RNC side, not at Node B side
System Impact
The cell is unavailable and fails to provide services. Users fail to gain access through this cell.
Handling Suggestion
1.Baseband Resource Pool. Check if the values of Local Cell ID, Receiving Frequency Point, and
Transmitting Frequency Point in"Local Cell Basic Parameters" are consistent with those at RNC side.
If not, modify the RNC or Node B configurations to make them consistent.
2) On NMS fault management interface, check if Node B has generated "199084129 Board reboots
alarm". If yes, it indicates that the Node B has just been started or hardware has been just replaced
or added. In this case, wait for the Node B to finish powering on.
2.Alarm reason: Cell CGID is zero audit by NodeB.
1) Local cell is blocked
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management >Baseband Resource Pool. View
the Status in Local Cell Status Parameters. If the status is blocked, unblock it.
2) Node B is blocked or faulty
On the ground resource configuration interface, view Node B status. If the status is blocked, unblock
the Node B. If the status is faulty, it indicates that FS board may be faulty. In this case, check if related
alarms exist. If yes, follow the suggestions on handling the related alarms.
The related alarms are as follows:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
3) Local cell is faulty
2-173
View the"Local Cell Status Parameters" interface. If the current status is faulty, it indicates that FS
board or RTR board is faulty or restarted. In this case, check if the following alarms are generated. If
yes, follow the suggestions on handling the related alarms:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
4) Baseband board is blocked
View the BPC board status. If the status is blocked, unblock it.
5) Baseband board is faulty
View the BPC board status. If the status is faulty, handle the alarm by referring to the following
suggestions:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
3.Alarm reason: Cell is blocked at NodeB side.
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management > Baseband Resource Pool. If
the cell status is blocked, unblock it.
4.Alarm reason: System information update fail.
The alarm is caused by the failure to update system messages, that is, system message broadcast
fails. Handle the alarm by referring to the suggestion for "Broadcast fail".
5.For other alarm causes, the system re-establishes the cell automatically. No human intervention
is required.
Probable Cause
Cell delete: Cell Instance at CRM-setup status fails to write information in DBS.
System Impact
The cell is unavailable and fails to provide services. Users fail to gain access through this cell.
2-174
Handling Suggestion
1.Baseband Resource Pool. Check if the values of Local Cell ID, Receiving Frequency Point, and
Transmitting Frequency Point in"Local Cell Basic Parameters" are consistent with those at RNC side.
If not, modify the RNC or Node B configurations to make them consistent.
2) On NMS fault management interface, check if Node B has generated "199084129 Board reboots
alarm". If yes, it indicates that the Node B has just been started or hardware has been just replaced
or added. In this case, wait for the Node B to finish powering on.
2.Alarm reason: Cell CGID is zero audit by NodeB.
1) Local cell is blocked
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management >Baseband Resource Pool. View
the Status in Local Cell Status Parameters. If the status is blocked, unblock it.
2) Node B is blocked or faulty
On the ground resource configuration interface, view Node B status. If the status is blocked, unblock
the Node B. If the status is faulty, it indicates that FS board may be faulty. In this case, check if related
alarms exist. If yes, follow the suggestions on handling the related alarms.
The related alarms are as follows:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
3) Local cell is faulty
View the"Local Cell Status Parameters" interface. If the current status is faulty, it indicates that FS
board or RTR board is faulty or restarted. In this case, check if the following alarms are generated. If
yes, follow the suggestions on handling the related alarms:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
4) Baseband board is blocked
View the BPC board status. If the status is blocked, unblock it.
5) Baseband board is faulty
View the BPC board status. If the status is faulty, handle the alarm by referring to the following
suggestions:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
3.Alarm reason: Cell is blocked at NodeB side.
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management > Baseband Resource Pool. If
the cell status is blocked, unblock it.
4.Alarm reason: System information update fail.
The alarm is caused by the failure to update system messages, that is, system message broadcast
fails. Handle the alarm by referring to the suggestion for "Broadcast fail".
2-175
5.For other alarm causes, the system re-establishes the cell automatically. No human intervention
is required.
Probable Cause
System Impact
The cell is unavailable and fails to provide services. Users fail to gain access through this cell.
Handling Suggestion
1.Baseband Resource Pool. Check if the values of Local Cell ID, Receiving Frequency Point, and
Transmitting Frequency Point in"Local Cell Basic Parameters" are consistent with those at RNC side.
If not, modify the RNC or Node B configurations to make them consistent.
2) On NMS fault management interface, check if Node B has generated "199084129 Board reboots
alarm". If yes, it indicates that the Node B has just been started or hardware has been just replaced
or added. In this case, wait for the Node B to finish powering on.
2.Alarm reason: Cell CGID is zero audit by NodeB.
1) Local cell is blocked
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management >Baseband Resource Pool. View
the Status in Local Cell Status Parameters. If the status is blocked, unblock it.
2) Node B is blocked or faulty
On the ground resource configuration interface, view Node B status. If the status is blocked, unblock
the Node B. If the status is faulty, it indicates that FS board may be faulty. In this case, check if related
alarms exist. If yes, follow the suggestions on handling the related alarms.
The related alarms are as follows:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
3) Local cell is faulty
2-176
View the"Local Cell Status Parameters" interface. If the current status is faulty, it indicates that FS
board or RTR board is faulty or restarted. In this case, check if the following alarms are generated. If
yes, follow the suggestions on handling the related alarms:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
4) Baseband board is blocked
View the BPC board status. If the status is blocked, unblock it.
5) Baseband board is faulty
View the BPC board status. If the status is faulty, handle the alarm by referring to the following
suggestions:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
3.Alarm reason: Cell is blocked at NodeB side.
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management > Baseband Resource Pool. If
the cell status is blocked, unblock it.
4.Alarm reason: System information update fail.
The alarm is caused by the failure to update system messages, that is, system message broadcast
fails. Handle the alarm by referring to the suggestion for "Broadcast fail".
5.For other alarm causes, the system re-establishes the cell automatically. No human intervention
is required.
Probable Cause
System Impact
The cell is unavailable and fails to provide services. Users fail to gain access through this cell.
2-177
Handling Suggestion
1.Baseband Resource Pool. Check if the values of Local Cell ID, Receiving Frequency Point, and
Transmitting Frequency Point in"Local Cell Basic Parameters" are consistent with those at RNC side.
If not, modify the RNC or Node B configurations to make them consistent.
2) On NMS fault management interface, check if Node B has generated "199084129 Board reboots
alarm". If yes, it indicates that the Node B has just been started or hardware has been just replaced
or added. In this case, wait for the Node B to finish powering on.
2.Alarm reason: Cell CGID is zero audit by NodeB.
1) Local cell is blocked
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management >Baseband Resource Pool. View
the Status in Local Cell Status Parameters. If the status is blocked, unblock it.
2) Node B is blocked or faulty
On the ground resource configuration interface, view Node B status. If the status is blocked, unblock
the Node B. If the status is faulty, it indicates that FS board may be faulty. In this case, check if related
alarms exist. If yes, follow the suggestions on handling the related alarms.
The related alarms are as follows:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
3) Local cell is faulty
View the"Local Cell Status Parameters" interface. If the current status is faulty, it indicates that FS
board or RTR board is faulty or restarted. In this case, check if the following alarms are generated. If
yes, follow the suggestions on handling the related alarms:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
4) Baseband board is blocked
View the BPC board status. If the status is blocked, unblock it.
5) Baseband board is faulty
View the BPC board status. If the status is faulty, handle the alarm by referring to the following
suggestions:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
3.Alarm reason: Cell is blocked at NodeB side.
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management > Baseband Resource Pool. If
the cell status is blocked, unblock it.
4.Alarm reason: System information update fail.
The alarm is caused by the failure to update system messages, that is, system message broadcast
fails. Handle the alarm by referring to the suggestion for "Broadcast fail".
2-178
5.For other alarm causes, the system re-establishes the cell automatically. No human intervention
is required.
Probable Cause
Cell delete: Cell Instance at established status fails to write info in dbs.
System Impact
The cell is unavailable and fails to provide services. Users fail to gain access through this cell.
Handling Suggestion
1.Baseband Resource Pool. Check if the values of Local Cell ID, Receiving Frequency Point, and
Transmitting Frequency Point in"Local Cell Basic Parameters" are consistent with those at RNC side.
If not, modify the RNC or Node B configurations to make them consistent.
2) On NMS fault management interface, check if Node B has generated "199084129 Board reboots
alarm". If yes, it indicates that the Node B has just been started or hardware has been just replaced
or added. In this case, wait for the Node B to finish powering on.
2.Alarm reason: Cell CGID is zero audit by NodeB.
1) Local cell is blocked
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management >Baseband Resource Pool. View
the Status in Local Cell Status Parameters. If the status is blocked, unblock it.
2) Node B is blocked or faulty
On the ground resource configuration interface, view Node B status. If the status is blocked, unblock
the Node B. If the status is faulty, it indicates that FS board may be faulty. In this case, check if related
alarms exist. If yes, follow the suggestions on handling the related alarms.
The related alarms are as follows:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
3) Local cell is faulty
2-179
View the"Local Cell Status Parameters" interface. If the current status is faulty, it indicates that FS
board or RTR board is faulty or restarted. In this case, check if the following alarms are generated. If
yes, follow the suggestions on handling the related alarms:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
4) Baseband board is blocked
View the BPC board status. If the status is blocked, unblock it.
5) Baseband board is faulty
View the BPC board status. If the status is faulty, handle the alarm by referring to the following
suggestions:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
3.Alarm reason: Cell is blocked at NodeB side.
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management > Baseband Resource Pool. If
the cell status is blocked, unblock it.
4.Alarm reason: System information update fail.
The alarm is caused by the failure to update system messages, that is, system message broadcast
fails. Handle the alarm by referring to the suggestion for "Broadcast fail".
5.For other alarm causes, the system re-establishes the cell automatically. No human intervention
is required.
Probable Cause
Cell delete: Cell Instance at established status fails to read info from dbs.
System Impact
The cell is unavailable and fails to provide services. Users fail to gain access through this cell.
2-180
Handling Suggestion
1.Baseband Resource Pool. Check if the values of Local Cell ID, Receiving Frequency Point, and
Transmitting Frequency Point in"Local Cell Basic Parameters" are consistent with those at RNC side.
If not, modify the RNC or Node B configurations to make them consistent.
2) On NMS fault management interface, check if Node B has generated "199084129 Board reboots
alarm". If yes, it indicates that the Node B has just been started or hardware has been just replaced
or added. In this case, wait for the Node B to finish powering on.
2.Alarm reason: Cell CGID is zero audit by NodeB.
1) Local cell is blocked
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management >Baseband Resource Pool. View
the Status in Local Cell Status Parameters. If the status is blocked, unblock it.
2) Node B is blocked or faulty
On the ground resource configuration interface, view Node B status. If the status is blocked, unblock
the Node B. If the status is faulty, it indicates that FS board may be faulty. In this case, check if related
alarms exist. If yes, follow the suggestions on handling the related alarms.
The related alarms are as follows:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
3) Local cell is faulty
View the"Local Cell Status Parameters" interface. If the current status is faulty, it indicates that FS
board or RTR board is faulty or restarted. In this case, check if the following alarms are generated. If
yes, follow the suggestions on handling the related alarms:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
4) Baseband board is blocked
View the BPC board status. If the status is blocked, unblock it.
5) Baseband board is faulty
View the BPC board status. If the status is faulty, handle the alarm by referring to the following
suggestions:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
3.Alarm reason: Cell is blocked at NodeB side.
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management > Baseband Resource Pool. If
the cell status is blocked, unblock it.
4.Alarm reason: System information update fail.
The alarm is caused by the failure to update system messages, that is, system message broadcast
fails. Handle the alarm by referring to the suggestion for "Broadcast fail".
2-181
5.For other alarm causes, the system re-establishes the cell automatically. No human intervention
is required.
Probable Cause
System Impact
The cell is unavailable and fails to provide services. Users fail to gain access through this cell.
Handling Suggestion
1.Baseband Resource Pool. Check if the values of Local Cell ID, Receiving Frequency Point, and
Transmitting Frequency Point in"Local Cell Basic Parameters" are consistent with those at RNC side.
If not, modify the RNC or Node B configurations to make them consistent.
2) On NMS fault management interface, check if Node B has generated "199084129 Board reboots
alarm". If yes, it indicates that the Node B has just been started or hardware has been just replaced
or added. In this case, wait for the Node B to finish powering on.
2.Alarm reason: Cell CGID is zero audit by NodeB.
1) Local cell is blocked
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management >Baseband Resource Pool. View
the Status in Local Cell Status Parameters. If the status is blocked, unblock it.
2) Node B is blocked or faulty
On the ground resource configuration interface, view Node B status. If the status is blocked, unblock
the Node B. If the status is faulty, it indicates that FS board may be faulty. In this case, check if related
alarms exist. If yes, follow the suggestions on handling the related alarms.
The related alarms are as follows:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
3) Local cell is faulty
2-182
View the"Local Cell Status Parameters" interface. If the current status is faulty, it indicates that FS
board or RTR board is faulty or restarted. In this case, check if the following alarms are generated. If
yes, follow the suggestions on handling the related alarms:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
4) Baseband board is blocked
View the BPC board status. If the status is blocked, unblock it.
5) Baseband board is faulty
View the BPC board status. If the status is faulty, handle the alarm by referring to the following
suggestions:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
3.Alarm reason: Cell is blocked at NodeB side.
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management > Baseband Resource Pool. If
the cell status is blocked, unblock it.
4.Alarm reason: System information update fail.
The alarm is caused by the failure to update system messages, that is, system message broadcast
fails. Handle the alarm by referring to the suggestion for "Broadcast fail".
5.For other alarm causes, the system re-establishes the cell automatically. No human intervention
is required.
Probable Cause
Cell delete:Local Cell ID at RNC side is not consistent with which at Node B side
System Impact
The cell is unavailable and fails to provide services. Users fail to gain access through this cell.
2-183
Handling Suggestion
1.Baseband Resource Pool. Check if the values of Local Cell ID, Receiving Frequency Point, and
Transmitting Frequency Point in"Local Cell Basic Parameters" are consistent with those at RNC side.
If not, modify the RNC or Node B configurations to make them consistent.
2) On NMS fault management interface, check if Node B has generated "199084129 Board reboots
alarm". If yes, it indicates that the Node B has just been started or hardware has been just replaced
or added. In this case, wait for the Node B to finish powering on.
2.Alarm reason: Cell CGID is zero audit by NodeB.
1) Local cell is blocked
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management >Baseband Resource Pool. View
the Status in Local Cell Status Parameters. If the status is blocked, unblock it.
2) Node B is blocked or faulty
On the ground resource configuration interface, view Node B status. If the status is blocked, unblock
the Node B. If the status is faulty, it indicates that FS board may be faulty. In this case, check if related
alarms exist. If yes, follow the suggestions on handling the related alarms.
The related alarms are as follows:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
3) Local cell is faulty
View the"Local Cell Status Parameters" interface. If the current status is faulty, it indicates that FS
board or RTR board is faulty or restarted. In this case, check if the following alarms are generated. If
yes, follow the suggestions on handling the related alarms:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
4) Baseband board is blocked
View the BPC board status. If the status is blocked, unblock it.
5) Baseband board is faulty
View the BPC board status. If the status is faulty, handle the alarm by referring to the following
suggestions:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
3.Alarm reason: Cell is blocked at NodeB side.
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management > Baseband Resource Pool. If
the cell status is blocked, unblock it.
4.Alarm reason: System information update fail.
The alarm is caused by the failure to update system messages, that is, system message broadcast
fails. Handle the alarm by referring to the suggestion for "Broadcast fail".
2-184
5.For other alarm causes, the system re-establishes the cell automatically. No human intervention
is required.
Probable Cause
System Impact
The cell is unavailable and fails to provide services. Users fail to gain access through this cell.
Handling Suggestion
1.Baseband Resource Pool. Check if the values of Local Cell ID, Receiving Frequency Point, and
Transmitting Frequency Point in"Local Cell Basic Parameters" are consistent with those at RNC side.
If not, modify the RNC or Node B configurations to make them consistent.
2) On NMS fault management interface, check if Node B has generated "199084129 Board reboots
alarm". If yes, it indicates that the Node B has just been started or hardware has been just replaced
or added. In this case, wait for the Node B to finish powering on.
2.Alarm reason: Cell CGID is zero audit by NodeB.
1) Local cell is blocked
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management >Baseband Resource Pool. View
the Status in Local Cell Status Parameters. If the status is blocked, unblock it.
2) Node B is blocked or faulty
On the ground resource configuration interface, view Node B status. If the status is blocked, unblock
the Node B. If the status is faulty, it indicates that FS board may be faulty. In this case, check if related
alarms exist. If yes, follow the suggestions on handling the related alarms.
The related alarms are as follows:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
3) Local cell is faulty
2-185
View the"Local Cell Status Parameters" interface. If the current status is faulty, it indicates that FS
board or RTR board is faulty or restarted. In this case, check if the following alarms are generated. If
yes, follow the suggestions on handling the related alarms:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
4) Baseband board is blocked
View the BPC board status. If the status is blocked, unblock it.
5) Baseband board is faulty
View the BPC board status. If the status is faulty, handle the alarm by referring to the following
suggestions:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
3.Alarm reason: Cell is blocked at NodeB side.
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management > Baseband Resource Pool. If
the cell status is blocked, unblock it.
4.Alarm reason: System information update fail.
The alarm is caused by the failure to update system messages, that is, system message broadcast
fails. Handle the alarm by referring to the suggestion for "Broadcast fail".
5.For other alarm causes, the system re-establishes the cell automatically. No human intervention
is required.
Probable Cause
System Impact
The cell is unavailable and fails to provide services. Users fail to gain access through this cell.
2-186
Handling Suggestion
1.Baseband Resource Pool. Check if the values of Local Cell ID, Receiving Frequency Point, and
Transmitting Frequency Point in"Local Cell Basic Parameters" are consistent with those at RNC side.
If not, modify the RNC or Node B configurations to make them consistent.
2) On NMS fault management interface, check if Node B has generated "199084129 Board reboots
alarm". If yes, it indicates that the Node B has just been started or hardware has been just replaced
or added. In this case, wait for the Node B to finish powering on.
2.Alarm reason: Cell CGID is zero audit by NodeB.
1) Local cell is blocked
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management >Baseband Resource Pool. View
the Status in Local Cell Status Parameters. If the status is blocked, unblock it.
2) Node B is blocked or faulty
On the ground resource configuration interface, view Node B status. If the status is blocked, unblock
the Node B. If the status is faulty, it indicates that FS board may be faulty. In this case, check if related
alarms exist. If yes, follow the suggestions on handling the related alarms.
The related alarms are as follows:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
3) Local cell is faulty
View the"Local Cell Status Parameters" interface. If the current status is faulty, it indicates that FS
board or RTR board is faulty or restarted. In this case, check if the following alarms are generated. If
yes, follow the suggestions on handling the related alarms:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
4) Baseband board is blocked
View the BPC board status. If the status is blocked, unblock it.
5) Baseband board is faulty
View the BPC board status. If the status is faulty, handle the alarm by referring to the following
suggestions:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
3.Alarm reason: Cell is blocked at NodeB side.
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management > Baseband Resource Pool. If
the cell status is blocked, unblock it.
4.Alarm reason: System information update fail.
The alarm is caused by the failure to update system messages, that is, system message broadcast
fails. Handle the alarm by referring to the suggestion for "Broadcast fail".
2-187
5.For other alarm causes, the system re-establishes the cell automatically. No human intervention
is required.
Probable Cause
Cell delete:Cell PSCH at RNC side is not consistent with which at NodeB side
System Impact
The cell is unavailable and fails to provide services. Users fail to gain access through this cell.
Handling Suggestion
1.Baseband Resource Pool. Check if the values of Local Cell ID, Receiving Frequency Point, and
Transmitting Frequency Point in"Local Cell Basic Parameters" are consistent with those at RNC side.
If not, modify the RNC or Node B configurations to make them consistent.
2) On NMS fault management interface, check if Node B has generated "199084129 Board reboots
alarm". If yes, it indicates that the Node B has just been started or hardware has been just replaced
or added. In this case, wait for the Node B to finish powering on.
2.Alarm reason: Cell CGID is zero audit by NodeB.
1) Local cell is blocked
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management >Baseband Resource Pool. View
the Status in Local Cell Status Parameters. If the status is blocked, unblock it.
2) Node B is blocked or faulty
On the ground resource configuration interface, view Node B status. If the status is blocked, unblock
the Node B. If the status is faulty, it indicates that FS board may be faulty. In this case, check if related
alarms exist. If yes, follow the suggestions on handling the related alarms.
The related alarms are as follows:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
3) Local cell is faulty
2-188
View the"Local Cell Status Parameters" interface. If the current status is faulty, it indicates that FS
board or RTR board is faulty or restarted. In this case, check if the following alarms are generated. If
yes, follow the suggestions on handling the related alarms:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
4) Baseband board is blocked
View the BPC board status. If the status is blocked, unblock it.
5) Baseband board is faulty
View the BPC board status. If the status is faulty, handle the alarm by referring to the following
suggestions:
Application software monitoring alarm
Board communication link is interrupted.
Board parameter synchronization abnormity
Board reboots alarm
3.Alarm reason: Cell is blocked at NodeB side.
On NMS configuration management interface, select the cell to be viewed under Base Station Radio
Resource Management > WCDMA Radio Resource Management > Baseband Resource Pool. If
the cell status is blocked, unblock it.
4.Alarm reason: System information update fail.
The alarm is caused by the failure to update system messages, that is, system message broadcast
fails. Handle the alarm by referring to the suggestion for "Broadcast fail".
5.For other alarm causes, the system re-establishes the cell automatically. No human intervention
is required.
Probable Cause
Unknown
System Impact
The Node B is unavailable and fails to provide services. Users fail to gain access through this Node B.
2-189
Handling Suggestion
Probable Cause
System Impact
The Node B is unavailable and fails to provide services. Users fail to gain access through this Node B.
2-190
Handling Suggestion
Probable Cause
System Impact
The Node B is unavailable and fails to provide services. Users fail to gain access through this Node B.
2-191
Handling Suggestion
Probable Cause
System Impact
2-192
Handling Suggestion
On NMS fault management interface, view Details where Cause of failure is given. Locate the specific
handling suggestion which corresponds to the listed cause.
The handling suggestions that correspond to different causes are described below.
1.cause: incomplete local RNC data.
On NMS configuration management interface, check if “RNC ID”and "PLMN" is configured. If not,
add the configuration.
2.cause: Timer of Iu Inteface not config.
On NMS configuration management interface, check if Iu Timer is configured. If not, add the
configuration.
3.cause: GPS card info not config
On NMS configuration management interface, check if GPS card is configured. If not, add the
configuration.
4.cause: The signal point of adjacent office not config
On NMS configuration management interface, check if signal point of adjacent office is configured. If
not, add the configuration.
Probable Cause
System Impact
Handling Suggestion
Reduce the number of neighbour cells of local cell till the alarm is disappeared
2-193
Probable Cause
The minus of time on OMP and time from SNTP server over alarm limit
System Impact
Handling Suggestion
1. Inquire time difference alarm limit from backstage, judge if time difference alarm limit is too low
Y-> Reset the time difference alarm limit, wait dozens of seconds, check if the alarm is eliminated, if
alarm is restored, end, else go to "2".
N-> Go to "2".
2. check time on SNTP server and the system time, judge which time is more accurater
Time on SNTP server-> Enforce SNTP time synchronization from SNTP server, wait dozens of
seconds, check if the alarm is eliminated, if alarm is restored, end, else go to "3".
System time-> Check SNTP server organization, find out the reason of the inaccurate time, if cannot
solve, go to "3".
3. Please record the alarm information and contact ZTE Corporation
2-194
Probable Cause
There are too many alarms for this board, and the alarm pool is full of board alarms.
System Impact
Handling Suggestion
Probable Cause
1.There are some badly-touched boards in the system environment and the retransfer-ratio of control
plane increases.
2.The ethernet communication equipment is abnormal on board or switch board.
3.The node address of TIPC conflicts.
System Impact
Handling Suggestion
2-195
Probable Cause
1. The environment board is not connected to the switch board or the connection is wrong.
2. The environment board locates in a rack. The configured rack number is different from that where
DIP switch of the environment board locates.
System Impact
There is no impact on services. However, the system can not monitor the status of power supply
and environment situation.
Handling Suggestion
1. Reconnect the RS485 cable between the environment monitor board and switch board.
2. Modify the rack number configured for the environment monitor board to consistent with the rack
number switch set for the environment monitor board.
2-196
Probable Cause
System Impact
Handling Suggestion
1. Check the alarm management window for the CPU overloaded on the switch board at the shelf, or
local board. Perform recommended solution to process the alarm(s) if any.
2. Check the alarm management window for the alarms of inter-shelf media plane links abnormal.
Perform the recommended solution to process the alarm(s) if any.
3. Replace the board.
4. Change the slot of the board.
5. Replace the switch board in the same shelf.
Probable Cause
System Impact
The channel between media and control plane is abnormal, and it maybe cause the service quality
decline or the service may be wholly interrupted.
2-197
Handling Suggestion
Probable Cause
System Impact
Some resource in system is blocked and is unavailable, the services carried by the board are affected.
Handling Suggestion
2-198
Probable Cause
Far end IMA group clock mode sent by the far end through ICP cell does not match with the near-end
one. For example, ITC (Independent Transmit Clock) on the far end does not match with CTC
(Common Transmit Clock) on the near end.
System Impact
Handling Suggestion
1.Check if the clock mode on the near end matches with that on the far end.
Y->If it matches, please contact ZTE Corporation.
N->If not, modify the configuration. If the alarm is eliminated, finish the alarm handling. If not, please
contact ZTE Corporation.
Probable Cause
When a transmitting link is not connected to the far end IMA group like other links, this alarm appears.
System Impact
Handling Suggestion
1.Check if IMA chip works normally and each link can be connected to the far end IMA group normally.
Y->If the chip works normally and each link is connected to the far end IMA group successfully,please
contact ZTE Corporation for help.
N->If not, configure them again. If the alarm is eliminated, finish the alarm handling. If not, please
contact ZTE Corporation.
2-199
Probable Cause
System Impact
IMA link is down. If several links are available in the IMA group, bandwidth of the IMA group will be
affected, and the number of available upper-layer service access will decrease. Otherwise, all service
will not be interrupted if merely one link is available in the IMA group.
Handling Suggestion
On NMS fault management interface, view alarm Details where information of IMA chip ID, IMA group
ID, IMA link ID, and E1 index are given. Locate the faulty IMA link according to the given information.
1. Refer to user's networking plan to see if connection error exists.
2. On NMS fault management interface, check if E1-related alarm exists in the board. If so, refer to
the corresponding alarm handling suggestion.
Probable Cause
2-200
System Impact
IMA link is down. If several links are available in the IMA group, bandwidth of the IMA group will be
affected, and the number of available upper-layer service access will decrease. Otherwise, all service
will not be interrupted if merely one link is available in the IMA group.
Handling Suggestion
On NMS fault management interface, view alarm Details where information of IMA chip ID, IMA group
ID, IMA link ID, and E1 index are given. Locate the faulty IMA link according to the given information.
1. Check the RUN indicator of clock board. If the indicator is green and flashes slowly, operation of
the clock board must be normal. Otherwise, reset/replace the clock board.
2. On NMS fault management interface, check if clock-related alarm occurs in UIM/GUIM. If yes,
input clock source must be abnormal. Refer to the corresponding alarm handling suggestion.
3. On NMS fault management interface, check if E1-related alarm exists. If yes, refer to the
corresponding alarm handling suggestion.
Probable Cause
System Impact
IMA link is down. If several links are available in the IMA group, bandwidth of the IMA group will be
affected, and the number of available upper-layer service access will decrease. Otherwise, all service
will not be interrupted if merely one link is available in the IMA group.
Handling Suggestion
On NMS fault management interface, view alarm Details where information of IMA chip ID, IMA group
ID, IMA link ID, and E1 index are given. Locate the faulty IMA link according to the given information.
Check the working status of the relevant far end receiving link by referring to the opposite equipment
operation guide. If far end receiving link is not in active status, please activate the link.
2-201
Probable Cause
If a near-end link in receiving direction has faults,this alarm appears on the near end.
System Impact
IMA link is down. If several links are available in the IMA group, bandwidth of the IMA group will be
affected, and the number of available upper-layer service access will decrease. Otherwise, all service
will not be interrupted if merely one link is available in the IMA group.
Handling Suggestion
1.Check if IMA chip works normally and each link can be connected to the near IMA group normally.
Y->If the chip works normally and each link is connected to the near IMA group properly, please
contact ZTE Corporation for help.
N->If IMA chip works abnormally or there is a link which does not belong to near end IMA group,
handle this problem. If the alarm is eliminated, finish the alarm handling. If not, please contact ZTE
Corporation for help.
Probable Cause
When some receiving links can not be connected to the far end IMA group like other links, this
alarm appears.
2-202
System Impact
IMA link is down. If several links are available in the IMA group, bandwidth of the IMA group will be
affected, and the number of available upper-layer service access will decrease. Otherwise, all service
will not be interrupted if merely one link is available in the IMA group.
Handling Suggestion
1.Check receiving link connections on the both sides to see if each receiving link is connected to the
far end IMA group properly and if the anticipant local E1 link is connected to the corresponding E1
link on far end.
Y->If so, please contact ZTE Corporation for help.
N->If not, find the fault causes and handle the problem. If the alarm is eliminated, finish the alarm
handling. If not, please contact ZTE Corporation for help.
Probable Cause
System Impact
Handling Suggestion
1.Check whether the number of active links of an IMA group is smaller than the minimum number of
active links required for the IMA group to work normally.
Y->If so, please check the broken IMA links and make sure that the number of active links is not
smaller than the minimum number required. If alarm is restored, the troubleshooting completes,
otherwise contact ZTE Corporation for help.
N->If not,please contact ZTE Corporation for help.
2-203
Probable Cause
System Impact
Handling Suggestion
1.Make no manual intervention and wait for automatic system recovery. Check whether this alarm
disappears after 30 seconds.
Y->End.
N->Contact ZTE Corporation
Probable Cause
System Impact
2-204
Handling Suggestion
1. Check the local board for the Related Alarms. Perform the recommended solution to process
the possible alarms.
Related Alarms:
1286 Loss of clock when input to board
5646 Phase-lock loop unlock
2. Check the clock board for the Related Alarms. Perform the recommended solution to process
the possible alarms.
Related Alarms:
26133 Output clock lost
26129 Clock reference source lost (Level 1 alarm)
26128 Clock reference source lost (Level 2 alarm)
26127 Clock reference source lost (Level 3 alarm)
3. Open the Configuration Management window and check whether the EMSI has configured APS
while the active/standby board is configure.
How to check APS protection configuration: open the rack map on the Configuration Management
window, find the EMSI board, right click to pop up shortcut menu, and select Optical port APS
Protection.
4. Replace the board.
5. Replace the slot.
6. Replace the ETAS in the same shelf.
Probable Cause
1. The connection is wrong between the shelf management board and switch board in the same shelf.
2. The 485 communication is wrong between switch board and the rack configuration of the
environmental monitoring board.
System Impact
2-205
Handling Suggestion
Probable Cause
A critical event has occurred.An unrecoverable local failure condition has occurred.Local device's
receive pash has detected a fault.
System Impact
Handling Suggestion
1. Check the fiber Rx if connetivity is good or electric cable is loose。Put out the fiber or cable and
put in it。Observe if the alarm restore.
Yes-> alarm restore
No-> jump“2”\
2. Check peer device’s ethernet OAM function is enable。If it is disable,make peer device enable
ethernet OAM function. Observe if the alarm restore.
Yes->alarm restore
No->jump“3”
3. Replace the cable to peer port on the same device。Insure peer move the other port on the device.
Yes-> alarm restor
No->phone ZTE corporation
2-206
l Alarm Sub-code:0
l Description:Connectivity fault alarm
l Severity:Minor
l Alarm Type:Communications Alarm
Probable Cause
System Impact
Handling Suggestion
1. Observe the additional information of the alarm.There are five kinds of additional informations.
(1) receive remote rx fault indication signal,jump to "2"
(2) receive server layer's alarm indication signal,jump to "3"
(3) lost continuity from the remote MEP,jump to "4"
(4) recevie incorrect CCM frame,jump to "5"
(5) receive a CCM frame from other MD,jump to "6"
(6) receive server layer's lock signal,jump to "7"
2. Check if remote Mep's(Maintanence end point)"rx is unidirection. Check rx's link state, for
example,rx's fiber is loose.If rx's fiber is loose,then put in it.Sure the devices between localc and
remote mep if good and their port is up.Observer if alarm restore.
Yes->alarm restore,alarm process end.
No->jump to "8"
3. Check the link work state between the server layer's MEP. Sure the port of intermediate devices
is up. If some links of intermediate server layer's devices if fault.Restore the fault links(replace the
cable or put out and put in the port).Observe if the alarm restore.
Yes->alarm restore, alarm process end.
No->jump to "8"
4. Check network path matter between two MEP. Check if link ports of intermediate devices are up. If
intermediate server layer's network have fault link between MEP. Restore fault links(replace cable
or put up and put in port).Check local and remote MEP's bind port's packet statics can increase.
Observe if alarm can restore.
Yes->alarm restore, alarm process end.
No->jump to "8"
5. Check the whole network plane of Ethernet OAM(IEEE 802.1ag)administration. You inspect the
device's VLAN,MD,MA configuration. Check the remote MEP configuration belong to local MEP.
Check if it has incorrect configuration, CCM send interval is different from local CCM send interval, or
local MEP's MAC is different from remote MAC.Amend it to same. Observe if the alarm can restore.
Yes->alarm restore, alarm process end.
No->jump to "8"
2-207
6. Check the whole network plane of Ethernet OAM(IEEE 802.1ag)administration. You inspect the
device's VLAN,MD,MA configuration. Check the edge MEPs of the whole MD domain is are full close
in. Check if there are packets from other MD domains. Observe if the alarm can restore.
Yes->alarm restore, alarm process end.
No->jump to "8"
7. Check the 802.1ag configuration of the server layer's from which our device receive lock
signal.Check if the server layer's MEPs are doing administrator lock. If it is in administrator lock
state,then turn off it.Observe if the alarm restore.
Yes->alarm restore, alarm process end.
No->jump to "8"
8. We suggest that you adopt expert's advice to eliminate the alarm.
Yes->alarm restore, then phone ZTE to analyse the network.
No->phone ZTE.
Probable Cause
System Impact
Handling Suggestion
1. Check if physical trunk has faults. 2. Check if input ima clock work normally.
2-208
Probable Cause
System Impact
The board is blocked so that the services carried by the board are interrupted.
Handling Suggestion
Probable Cause
2-209
System Impact
The corresponding subsystem cannot receive or send messages.
Handling Suggestion
1.Check through Alarm Management whether there is any alarm prompting that the adjacent office
is inaccessible.
Y->Perform further handling according to the office inaccessible alarms if there are MTP3 office
inaccessible alarms or M3UA office inaccessible alarms.
N->Go to Step 2.
2.Check the local data configuration to see whether the subsystem is correctly configured in the local
office configuration and adjacent office configuration.
Y->Go to Step 3.
N->Configure the subsystem.
2.1 Check whether this alarm disappears after configuring the subsystem.
Y->End.
N->Go to Step 3.
3.Check the peer-end data configuration to see whether the subsysem is correctly configured in its
local office configuration and adjacent office configuration.
Y->Go to Step 4.
N->Ask the peer end to configure the subsystem.
3.1 Check whether this alarm disappears after the peer end has configured the subsystem.
Y->End.
N->Go to Step 4.
4.Note down detailed information.
4.1 Back up related local office configuration data and peer-end office configuration data.
4.2 Back up related local office and peer-end office history alarms and notifications, as well as
current alarms.
4.3 Contact ZTE Corporation and end the alarm handling procedure.
Probable Cause
1.Office and route configuration error.
2.Link broken.
2-210
System Impact
Handling Suggestion
1.Check whether the static route settings of the destination office are correct.
Y->Go to Step 2.
N->Configure or modify the related static route.
1.1 Check whether the office is accessible (this alarm disappears).
Y->End
N->Go to Step 2.
2.Query link status in the route table through Dynamic Management on the background to check
whether there are links available.
Y->Go to Step 4.
N->Go to Step 3.
3.Check alarms on the background to see whether there are alarms prompting that no link is available.
Y->Perform further handling according to the alarms prompting no link available.
N->Go to Step 4.
4.Note down detailed information.
4.1 Back up related local office configuration data and peer-end office configuration data.
4.2 Back up related local office and peer-end office history alarms and notifications, as well as
current alarms.
4.3 Contact ZTE Corporation and end the alarm handling procedure.
Probable Cause
System Impact
This alarm may render some offices inaccessible, or may result in the congestion of other links.
2-211
Handling Suggestion
1.Check whether there is new data configuration or the configuration has been changed.
Y->1.1 Check link configuration data, especially signaling point code (SPC), SLC and network type
(international or domestic) to see whether they accord with the peer end of the link.
Y->Go to Step 2.
N->Modify the configuration and go to Step 1.2.
1.2 Check whether this alarm disappears after modifying the configuration.
Y->End
N->Go to Step 2.
N->Go to Step 2.
2.Check whether there is any alarm for bottom layer transmission if the link configuration has not
been changed.
Y->Ask a transmission engineer to handle the problem.
N->Go to Step 3.
3.Perform physical link self-loop on the devices at the both ends of the link, and check whether
this alarm disappears.
Y->Check the bottom layer transmission and ask a transmission engineer to solve the problem.
N->Go to Step 4.
4.Note down detailed information.
4.1 Back up related local office configuration data and peer-end office configuration data.
4.2 Back up related local office and peer-end office history alarms and notifications, as well as
current alarms.
4.3 Contact ZTE Corporation and end the alarm handling procedure.
Probable Cause
System Impact
2-212
Handling Suggestion
1.Check whether the static route configuration of the destination cluster is correct.
Y->Go to Step 2 if the static route configuration of the destination cluster is correct.
N->Configure or modify related static route.
1.1 Check whether the cluster is accessible.
Y->End
N->Go to Step 2.
2.Query link status in the route table through Dynamic Management on the background to check
whether there are links available.
Y->Go to Step 4.
N->Go to Step 3.
3.Check alarms on the background to see whether there are alarms prompting no link available.
Y->Perform further handling according to the alarms prompting no link available.
N->Go to Step 4.
4.Note down detailed information.
4.1 Back up related local office configuration data and peer-end office configuration data.
4.2 Back up related local office and peer-end office history alarms and notifications, as well as
current alarms.
4.3 Contact ZTE Corporation and end the alarm handling procedure.
Probable Cause
System Impact
Reception and sending of messages from/to the relevant office fail. Access of new service under this
office fails, and abnormal release of the ongoing service occurs.
2-213
Handling Suggestion
Probable Cause
System Impact
Association interruption, data cannot be transmited, upper layer services will be impacted,
for example, signaling office is unreachable and other available association of an identical office
is blocked.
Handling Suggestion
2-214
Y->4
N->6
4. The association is blocked manually, check whether required to block the association
manually.
Y->End
N->5
5. Activate corresponding association by dynamic management tool, and check whether
the alarm is eliminated.
Y->End
N->6
6. Contact the ZTE office.
Probable Cause
1. Hardware fault, for example, external interfaces of local/remote devices are broken,
the intermediate switch device is broken, or the transmission channel is interrupted.
2. Bear network communication fault, for example, external interfaces of local/remote
devices are broken, the intermediate switch device is broken or the bear link is
interrupted.
3. Configuration fault, for example, routes or interface addresses of local/remote devices
change.
4. Device fault, for example, NE control panel channels of local or remote device are
interrupted.
System Impact
This channel is unavailable, all channel interruption will result in association interruption.SCTP will
shift transmission to another channel without impact on signaling transmission and service.
2-215
Handling Suggestion
1. Enter the protocol mode by IPSTACK, and check whether the physical link lost lots of
packages by PING and exit this mode by EXIT MODE.
Y->2
N->3
2. Troubleshooting the physical links, and check whether the alarm is eliminated.
Y->End
N->3
3. In the NM alarm management window, check whether the ALM-8393985 Abnormal
Control Plane Communication Between Board and Home ModuleALM-8393988
Abnormal Control Plane Communication Between Module and OMP alarms are
reported on the home module.
Y->5
N->4
4. Handle the fault according to related suggestions, and check whether the alarm is
eliminated.
Y->End
N->5
5. Check whether the remote device of the association is faulty, troubleshoot the remote
faults, and check whether the alarm is eliminated.
Y->End
N->6
6. Contact the ZTE office.
Probable Cause
Unknown
System Impact
The CCP transmission link is unavailable. Therefore, the CCP cannot be used during radio link
establishment. If Node B continues to select this CCP, RNC messages cannot reach Node B and the
current service is interrupted.
2-216
Handling Suggestion
Check if the Node B corresponding to the faulty CCP has generated associated alarms. Follow the
suggestions on handling the related alarms. The related alarms are as follows:
1.IP mode
According to the association link number, check if alarms related to association links exist through the
fault management interface. If yes, follow the suggestions on handling the related alarms:
The related alarms are as follows:
Association congested
Association link broken
2.ATM mode
1) Bottom layer transmission fault
Check if related alarms exist. If yes, follow the suggestions on handling the related alarms.
The related alarms are as follows:
SDH/SONET fault
Abnormal status in SDH/SONET
SDH/SONET: Excessive Error Code
High Error Rate of Optical Interface
2) PVC link break
Check if the related alarm exists. If yes, follow the suggestions on handling the related alarm.
The related alarm is as follows:
PVC Fault
Probable Cause
System Impact
The CCP transmission link is unavailable. Therefore, the CCP cannot be used during radio link
establishment. If Node B continues to select this CCP, RNC messages cannot reach Node B and the
current service is interrupted.
2-217
Handling Suggestion
Check if the Node B corresponding to the faulty CCP has generated associated alarms. Follow the
suggestions on handling the related alarms. The related alarms are as follows:
1.IP mode
According to the association link number, check if alarms related to association links exist through the
fault management interface. If yes, follow the suggestions on handling the related alarms:
The related alarms are as follows:
Association congested
Association link broken
2.ATM mode
1) Bottom layer transmission fault
Check if related alarms exist. If yes, follow the suggestions on handling the related alarms.
The related alarms are as follows:
SDH/SONET fault
Abnormal status in SDH/SONET
SDH/SONET: Excessive Error Code
High Error Rate of Optical Interface
2) PVC link break
Check if the related alarm exists. If yes, follow the suggestions on handling the related alarm.
The related alarm is as follows:
PVC Fault
Probable Cause
System Impact
The CCP transmission link is unavailable. Therefore, the CCP cannot be used during radio link
establishment. If Node B continues to select this CCP, RNC messages cannot reach Node B and the
current service is interrupted.
2-218
Handling Suggestion
Check if the Node B corresponding to the faulty CCP has generated associated alarms. Follow the
suggestions on handling the related alarms. The related alarms are as follows:
1.IP mode
According to the association link number, check if alarms related to association links exist through the
fault management interface. If yes, follow the suggestions on handling the related alarms:
The related alarms are as follows:
Association congested
Association link broken
2.ATM mode
1) Bottom layer transmission fault
Check if related alarms exist. If yes, follow the suggestions on handling the related alarms.
The related alarms are as follows:
SDH/SONET fault
Abnormal status in SDH/SONET
SDH/SONET: Excessive Error Code
High Error Rate of Optical Interface
2) PVC link break
Check if the related alarm exists. If yes, follow the suggestions on handling the related alarm.
The related alarm is as follows:
PVC Fault
Probable Cause
System Impact
The CCP transmission link is unavailable. Therefore, the CCP cannot be used during radio link
establishment. If Node B continues to select this CCP, RNC messages cannot reach Node B and the
current service is interrupted.
2-219
Handling Suggestion
Check if the Node B corresponding to the faulty CCP has generated associated alarms. Follow the
suggestions on handling the related alarms. The related alarms are as follows:
1.IP mode
According to the association link number, check if alarms related to association links exist through the
fault management interface. If yes, follow the suggestions on handling the related alarms:
The related alarms are as follows:
Association congested
Association link broken
2.ATM mode
1) Bottom layer transmission fault
Check if related alarms exist. If yes, follow the suggestions on handling the related alarms.
The related alarms are as follows:
SDH/SONET fault
Abnormal status in SDH/SONET
SDH/SONET: Excessive Error Code
High Error Rate of Optical Interface
2) PVC link break
Check if the related alarm exists. If yes, follow the suggestions on handling the related alarm.
The related alarm is as follows:
PVC Fault
Probable Cause
System Impact
2-220
Handling Suggestion
On NMS fault management interface, view Alarm Details where Alarm Reason is given. Locate the
specific alarm handling suggestion according to the given reason.
The handling suggestions that correspond to different reasons are described below.
1.CN Overload.
1) CN Overload. View CN NMS operation log to see if CN is in overload condition. If yes, no
handling is necessary.
2) Check if transmission-related/board alarm occurs in the board. If yes, refer to the corresponding
alarm handling suggestion.
Related alarms:
199066005 SCCP SSN is invalid
199066010 MTP3 office inaccessible
199066014 M3UA office inaccessible
2.CN unaccessible.
Check if transmission-related/board alarm occurs. If yes, refer to the corresponding alarm handling
suggestion.
Related alarms:
199066005 SCCP SSN is invalid
199066010 MTP3 office inaccessible
199066014 M3UA office inaccessible
Probable Cause
2-221
System Impact
Common Channel is unavailable, which falls into the following three cases.
1. If the SCCPCH carrying FACH is unavailable, UE-initiated CS/PS services will be down.
2. If the SCCPCH carrying PCH is unavailable, paging function will be unavailable in the system,
leading to failure of UE-initiated CS/PS services.
3. If the PRACH carrying RACH is unavailable, UE access to the cell will fail.
Handling Suggestion
Probable Cause
System Impact
2-222
Handling Suggestion
Probable Cause
System Impact
It may affect the path selection function in multi-path protection, and also affect the quality of service.
Handling Suggestion
Check and correct the configuration of IP domain in both RNC and NodeB.
2-223
Probable Cause
1.Boards are configured backup mode, but the slave board is offline.
2.The slave board is online, but the communication link between master and slave independent
boards is abnormal.
System Impact
The master board and the slave board can't communicate. When the master board works abnormally,
change over won't happen. It has no impact to the services.
Handling Suggestion
1. Make sure the board is configured backup mode, and the master and slave boards are firmly online.
2. Check the opposite board for the related alarms. If there are related alarms, perform the
recommended solution to process the possible alarms.
3. Replace the opposite board.
4. Change the slots of both the master and slave boards.
Probable Cause
System Impact
The board is blocked so that it can not provide functions. Furthermore, all services under the relevant
module become unavailable.
2-224
Handling Suggestion
Probable Cause
System Impact
Handling Suggestion
1Is there a alarminfo called "18501 EPU create HDLC channel failed"
Y->go to "2"
N->go to "7"
2.Observe the alarm information for a few minutes, check whether the alarm will be restored.
Y->alarm can be restored, end(link broken reason may be 2,3,4,5,6)
N->go to "3"
3.Check cable connection at both ends. If the cable is disconnected or connection is loose
Y-> unplug and plug the cable or replace the cable,if the alarm is restored after operation,end(link
broken reason:2) ,otherwise, go to "4".
2-225
N->go to "4"
4.Refer to user's networking plan to see if E1 cable connection is correct
Y-> connection refer to user's networking.if the alarm is restored after operation,end(link broken
reason:2) ,otherwise, go to "5".
N->go to "5"
5.On NMS configuration management interface (IPOverE1 configuration), check whether Interface E1
No. and time slot configuration of two sides is accord
Y-> modify congiguration,Ensure that the relevant configuration is consistent at both ends.if the alarm
is restored after operation,end(link broken reason:7) ,otherwise, go to "6".
N->go to "6"
6.On NMS configuration management interface, check whether configuration of relay board and
interface board connection is accord.
Y-> modify congiguration,Ensure the connection continuity of PPP port at both ends.if the alarm is
restored after operation,end(link broken reason:7) ,otherwise, go to "10".
N->go to "10"
7.Check if EPU board property is T1.
Y->go to "8"
N->go to "9"
8.Check if the timeslot of port is excess No.24
Y->modify the configuration,make sure timeslot is not overrun No.24,end(link broken reason:1)
,otherwise, go to "9".
N->go to "9"
9.Check if the E1 Num is excess max num.
Y->modify the E1 num,,end(link broken reason:1) ,otherwise, go to "10".
N->go to "10"
10.Contact ZTE corporation,use expert advice
2-226
Probable Cause
System Impact
BFD is used to test the accessibility to the opposite device and link quality. BFD interruption means
the link to the opposite device is disconnected, and all static routes which treat this opposite device
as the new-hop path will be disconnected or switched. If there is a standby path, then the system
will change over to this path, if not, the services are unavailable.
Handling Suggestion
1. Abundant data caused by the burst traffic or some configurations will result in BFD
disconnection in a flash, observe this alarm information for a while, and check whether
the alarm is eliminated.
Y->End
N->2
2. Check the indicators of the BFD session source address interface and destination
interface are on normally.
Y->4
N->3
3. Replace the network cables, or re-insert the link cables of the BFD session, wait for
30 secs, re-check the indicators of the BFD session source address interface and
destination interface, and check whether the alarm is eliminated.
Y->End
N->4
4. Enter the protocol mode by IPSTACK, and check network connection between BFD
source address and destination address by PING and exit this mode by EXIT MODE.
Y->6
N->5
5. Troubleshoot the network connection and check whether the alarm is eliminated.
Y->End
N->6
6. Contact the ZTE office.
2-227
Probable Cause
System Impact
All services on the path related to the BFD session will be switched to the slave path. Service
interruption will occur if slave path does not exist.
Handling Suggestion
1. Time different of both parties may result in unsuccessful BFD negotiation, observe
alarm information for a while, and check whether the alarm is eliminated.
Y->End
N->2
2. Check the indicators of the BFD session source address interface and destination
interface are on normally.
Y->4
N->3
3. Replace the network cables, or re-insert the link cables of the BFD session, wait for
30 secs, re-check the indicators of the BFD session source address interface and
destination interface, and check whether the alarm is eliminated.
Y->End
N->4
4. Enter the protocol mode by IPSTACK, and check network connection between BFD
source address and destination address by PING and exit this mode by EXIT MODE.
Y->6
N->5
5. Troubleshoot the network connection and check whether the alarm is eliminated.
Y->End
N->6
2-228
Probable Cause
1. The intermediate device drop packets which possibly causes the bearer network to be unavailable.
2. Some section of both sides environment's drop packets which also possibly cause the bearer
network to be unavailable.
System Impact
Handling Suggestion
1 Ping the address each other to sure if the link is break or loss packet badly
Y - >Goto 2.1
N - > please contact zte, End the alarm handling.
2 Use the PD trace function to detect through the Web Master:
2.1 Check the every part coording to each nexthop
2.1.1 the link between mp and interface board is broken,Goto 2.2
2.1.2 the link between interface board and intermediate equipment is broken, Goto 2.4
2.1.3 the link between intermediate equipment and other intermediate equipmentis broken, Goto 2.4
2.2 check to see if the routing configuration with wrong
Y - > Check to see if the route configuration is wrong
Y - > Change route configuration ,Goto 2.1.1
N - > Goto 2.3
2.2.1 This part is ok?
Y - > make sure the alarm is eliminated or not,goto 2.2.2
N - > Goto 2.3
2.2.2 Check if the alarm is eliminated
Y - > End the alarm handling.
N - > Goto 2.3
2.3 Check The port of interface board is down or not
Y - > Replace the cable,Goto 2.3.1
N - > please contact zte, End the alarm handling.
2-229
Probable Cause
1. The intermediate device drop packets which possibly causes the bearer network worst.
2. Some section of both sides environment's drop packets which also possibly cause the bearer
network worst.
System Impact
2-230
Handling Suggestion
1 Ping the address each other to sure if the link is break or loss packet badly
Y - >Goto 2.1
N - > please contact zte, End the alarm handling.
2 Use the PD trace function to detect through the Web Master:
2.1 Check the every part coording to each nexthop
2.1.1 the link between mp and interface board is broken,Goto 2.2
2.1.2 the link between interface board and intermediate equipment is broken, Goto 2.4
2.1.3 the link between intermediate equipment and other intermediate equipmentis broken, Goto 2.4
2.2 check to see if the routing configuration with wrong
Y - > Check to see if the route configuration is wrong
Y - > Change route configuration ,Goto 2.1.1
N - > Goto 2.3
2.2.1 This part is ok?
Y - > make sure the alarm is eliminated or not,goto 2.2.2
N - > Goto 2.3
2.2.2 Check if the alarm is eliminated
Y - > End the alarm handling.
N - > Goto 2.3
2.3 Check The port of interface board is down or not
Y - > Replace the cable,Goto 2.3.1
N - > please contact zte, End the alarm handling.
2.3.1 Check port of interface board again
Y - > Check if the alarm is eliminated ,goto 2.3.2
N - > please contact zte, End the alarm handling.
2.3.2 Check if the alarm is eliminated
Y - > End the alarm handling.
N - > Goto 2.4
2.4 Check intermediate equipment, such as eht configuration of switch to find if it has errors
Y - > Change configuration, Goto 2.4.1
N - > Goto 2.4.2
2.4.1 This part is ok?
Y - > make sure the alarm is eliminated or not,goto 2.4.2
N - > Goto 2.4.2
2.4.2 Replace the intermediate equipment,goto 2.4.3
2.4.3 Check if the alarm is eliminated
Y - > End the alarm handling.
N - > Please contact zte
2-231
Probable Cause
System Impact
IPD is used to test the accessibility to the opposite device and link quality. IPD interruption means
the link to the opposite device is disconnected, and all static routes which treat this opposite device
as the new-hop path will be disconnected or switched. If there is a standby path, then the system
will change over to this path, if not, the services are unavailable.
Handling Suggestion
1. Abundant data caused by the burst traffic or some configurations will result in IPD
disconnection in a flash, observe this alarm information for a period of time, and check whether
the alarm is eliminated.
Y->End
N->2
2. Check the indicators of the IPD session source address interface and destination
interface are normal.
Y->4
N->3
3. Replace the network cables, or re-insert the link cables of the IPD session, wait for
30 seconds, re-check the indicators of the IPD session source address interface and
destination interface, and check whether the alarm is eliminated.
Y->End
N->4
4. Enter the protocol mode by IPSTACK, and check network connection between IPD
source address and destination address by PING and exit this mode by EXIT MODE.
Y->6
N->5
5. Troubleshoot the network connection and check whether the alarm is eliminated.
2-232
Y->End
N->6
6. Contact the ZTE office.
Probable Cause
System Impact
This alarm may render some offices inaccessible, or may result in the congestion of other links.
Handling Suggestion
1.Check whether there is new data configuration or the configuration has been changed.
Y->1.1 Check link configuration data, especially the link's vpi,vci and the port to see whether they
accord with the peer end of the link.
Y->Go to Step 2.
N->Modify the configuration and go to Step 1.2.
1.2 Check whether this alarm disappears after modifying the configuration.
Y->End
N->Go to Step 2.
N->Go to Step 2.
2.Check whether there is any alarm for bottom layer transmission if the link configuration has not
been changed.
Y->Ask a transmission engineer to handle the problem.
N->Go to Step 3.
3.Perform physical link self-loop on the devices at the both ends of the link, and check whether
this alarm disappears.
Y->Check the bottom layer transmission and ask a transmission engineer to solve the problem.
N->Go to Step 4.
4.Note down detailed information.
4.1 Back up related local office configuration data and peer-end office configuration data.
2-233
4.2 Back up related local office and peer-end office history alarms and notifications, as well as
current alarms.
4.3 Contact ZTE Corporation and end the alarm handling procedure.
Probable Cause
System Impact
Handling Suggestion
2-234
Probable Cause
1.Heavy traffic
2.Uneven load among associations
3.Insufficient association resources
System Impact
Transmission delay, or even packet loss will occur. If congestion is not serious, service will not be
affected. Otherwise, call loss might occur, and access success rate of PS service might fall.
Handling Suggestion
1. Check network cable connection. Ensure that the network cable is tightly inserted.
2. Add association links to the office that is in service for the congested association.
3. If intermediate equipment exists between local end and opposite end, check the transmission
quality of intermediate equipment.
Probable Cause
System Impact
The traffic over the license threshold would cause packet loss and service quality decrease.
Handling Suggestion
Check if the whole thpoughput is over the provider's guaranteed bandwidth limit authorized by license.
2-235
l Alarm Sub-code:0
l Description:IU CS traffic over load alarm
l Severity:Minor
l Alarm Type:Qos Alarm
Probable Cause
System Impact
The traffic over the license threshold would cause user service access reject.
Handling Suggestion
Check if the whole thpoughput is over the provider's guaranteed bandwidth limit authorized by license.
Probable Cause
System Impact
The traffic over the license threshold would cause CS user service access reject or PS service
quality decrease.
Handling Suggestion
Check if the whole thpoughput is over the provider's guaranteed bandwidth limit authorized by license.
2-236
3-1
3-2
3-3
3-4
Probable Cause
Since frequency difference might exist between trunk line clock and local receive clock, the trunk
receive clock is not synchronous with the transmit clock.
System Impact
Momentary fault occurs to trunk data service or signaling channel. If fault occurs repeatedly, CS/PS
service might become unstable. Otherwise, service is not affected.
Handling Suggestion
Check the clock synchronization status at both sides. If the status is unsynchronized, check if
LOL-related (loss of lock) alarm occurs in clock board. If yes, refer to the corresponding alarm
handling suggestion.
Related alarms:
26127 Clock reference source lost (Level 3 alarm)
26128 Clock reference source lost (Level 2 alarm)
26129 Clock reference source lost (Level 1 alarm)
Probable Cause
System Impact
Handling Suggestion
Pull out the board for 5 seconds and insert it again after a full discharge. If the problem can still
not be solved, please contact ZTE Corporation.
3-5
Probable Cause
System Impact
Handling Suggestion
Probable Cause
System Impact
3-6
Handling Suggestion
Probable Cause
System Impact
None
Handling Suggestion
Probable Cause
System Impact
Powering failed
3-7
Handling Suggestion
Probable Cause
It is hardware system fault or the board changes over due to artificial operation.
System Impact
Handling Suggestion
1. Analyze the change over reason according to the additional information about the alarm. If it is
not because of the system fault but due to control of MML command at the background or caused
by non-active/standby change over, or the standby board does not exist physically, nothing would
be done for this alarm.
2. If it is because of the system fault, eliminate those alarms firstly.
3-8
Probable Cause
System Impact
The configured environment parameters fail to take effect. There is no impact on services.
Handling Suggestion
Probable Cause
PP2S (Pulse Per 2 Seconds) source has switched within system clock, GPS receiver sides and
1588 synchronize clock.
System Impact
The broadcast time is triggered by GPS-side PP2S, system-side PP2S or 1588-side PP2S.
Handling Suggestion
No need to handle.
3-9
Probable Cause
The port is configured as a master clock port in synchronous Ethernet, two master clock ports
is directly connected.
System Impact
If it is normal, then there is no impact; if it is network connecting mistake, then the port can not
synchronize to the connected master clock port.
Handling Suggestion
If users do not want the other side to recover clock from this SyncE port, it is normal.
otherwise, it maybe has a mistake on network
connecting. If it is normal, there is no need to handle; if it is network connecting mistake,there is need
to reconfigure the clock port or reconnect the port.
Probable Cause
System Impact
None
Handling Suggestion
No need to handle.
3-10
Probable Cause
When base is manually selected, if the previous base selection is still in process and operation result
is not yet to be given, the present manual base selection is shut down and this notification is declared.
System Impact
None
Handling Suggestion
Probable Cause
There is no valid reference of the clock board to be selected, because all references are invalid
or are not configured.
System Impact
System could not get the needed clock, which will cause processing abnormity related to the clock.
Handling Suggestion
3-11
Probable Cause
The selected reference is valid, but the phase-lock loop can not be lock status in a long time.
System Impact
System could not get the needed clock, which will cause processing abnormity related to the clock.
Handling Suggestion
Probable Cause
The clock board locks the other reference but not the selected reference.
System Impact
System could not get the needed clock, which will cause processing abnormity related to the clock.
Handling Suggestion
3-12
Probable Cause
System Impact
None
Handling Suggestion
No need to handle.
Probable Cause
Clock board is in preheat status,and does not check the reference and the work mode.So, it does
not response the manual selecting reference command.
System Impact
None
3-13
Handling Suggestion
Execute the manual selecting clock reference command again after the preheat status is over.
Probable Cause
Please refer to additional information of the notification for locating the cause that the version can not
be found.
System Impact
Handling Suggestion
1.Check the actual attributes of the board and configure the correct version for it. Then re-config the
board version to see if the fault is eliminated.
Y->End alarm handling.
N->Please contact ZTE Corporation.
3-14
Probable Cause
System Impact
Some board may not get needed version if OMP board change over after synchronization fail.
Handling Suggestion
1.Check whether there are the corresponding files on the hard disks of the active and the mate
boards if version synchronization fails.
N->Add the required version occurred check if the alarm still occurred, if there is no corresponding file.
Y->Ask the engineers from the R&D department to troubleshoot this problem, if there are
corresponding files.
Take different measures according to the error code type in the additional information.
(1)Version synchronization ends: it means the synchronization is completed normally, there is no
need to handle it.
(2)Mate board is not at position and the synchronization can not be performed.
(3)The file synchronization fails: It needs to add this version manually.
(4)Database records acquisition fails: Please contact ZTE Corporation.
Probable Cause
System Impact
Handling Suggestion
3-15
Probable Cause
System Impact
Handling Suggestion
Probable Cause
System Impact
3-16
Handling Suggestion
(1)Confirm if it is needed to change current boot type, and configure boot type if needed.
Probable Cause
System Impact
Handling Suggestion
Probable Cause
System Impact
3-17
Handling Suggestion
Probable Cause
System Impact
Handling Suggestion
Probable Cause
System Impact
3-18
Handling Suggestion
1.Check the additional information for this alarm, and look for the error patch package.
Probable Cause
Write back start and finish information.
System Impact
None
Handling Suggestion
Denote entering into write back version.
Probable Cause
Check version start and finish information.
System Impact
None
Handling Suggestion
Denote entering into check version.
3-19
Probable Cause
System Impact
None
Handling Suggestion
Probable Cause
System Impact
Handling Suggestion
3-20
Probable Cause
System Impact
Handling Suggestion
Probable Cause
System Impact
None
Handling Suggestion
No need to handle.
3-21
Probable Cause
System Impact
power on fail
Handling Suggestion
NA
Probable Cause
System Impact
After the system reboot, the board fails in power-on because of loading data failure.
3-22
Handling Suggestion
1. Lookup if there is an alarm of the disk's break, please change a new disk.
2. Lookup if the disk is full, please make records of the alarm information and contact ZTE Corporation.
3. Lookup if the db's memory(shm) is full, please make records of the alarm information and contact
ZTE Corporation.
4. Lookup if IO is busy,please wait for a minute and try again.
Probable Cause
1.compatible failed;
2.master pack failed;
3.slave up failed;
4.slave table overflow
System Impact
Handling Suggestion
3-23
Probable Cause
System Impact
Handling Suggestion
Probable Cause
System Impact
Handling Suggestion
3-24
Probable Cause
System Impact
Handling Suggestion
Probable Cause
System Impact
NA
Handling Suggestion
NA
3-25
Probable Cause
no mem
System Impact
NA
Handling Suggestion
NA
Probable Cause
1. no *.so file in version pkg 2. mismatch of *.so in pkg
System Impact
power on fail
Handling Suggestion
check files in version, if the .so file is exist and the version is wright
Probable Cause
get lock timeout
3-26
System Impact
NA
Handling Suggestion
Probable Cause
System Impact
NA
Handling Suggestion
NA
Probable Cause
3-27
System Impact
Handling Suggestion
1. Check the GT number if or not configured. If it isn't configured, please add, otherwise:
2. Collecting information and ask for support:
(1) Backup data of configuration about local and remote.
(2) Backup information about alarm of history,alarm of notice,alarm of current.
Probable Cause
System Impact
Handling Suggestion
1. Check NID is configured or not about appear in the alarm notice. If isn't configured, please add.
2. Collection information, ask for supporting.
(1) Backup data of configuration about local and remote.
(2) Backup information about alarm of history、alarm of notice、alarm of current.
3-28
Probable Cause
System Impact
Handling Suggestion
1. Check NID of configured right or not about appear in the alarm notice. If isn't right, please modify.
2. Collection information, ask for supporting.
(1) Backup data of configuration about local and remote.
(2) Backup information about alarm of history, alarm of notice, alarm of current.
Probable Cause
SCCP ANSI NID translating, the information of NID in the message is repeat, and it is the local NID.
System Impact
Handling Suggestion
3-29
Probable Cause
System Impact
Handling Suggestion
Probable Cause
SCCP ANSI NID translating, the route indication of NID is failed, the list of NID is too large.
System Impact
3-30
Handling Suggestion
Probable Cause
SCCP ANSI NID translating, the non-XUDT message use ISNI function.
System Impact
Handling Suggestion
Probable Cause
3-31
System Impact
A certain M3UA user under the corresponding office cannot receive or send messages.
Handling Suggestion
Probable Cause
System Impact
Handling Suggestion
3-32
Probable Cause
System Impact
Handling Suggestion
Probable Cause
System Impact
lack of memory
Handling Suggestion
3-33
Probable Cause
System Impact
Handling Suggestion
1. Check whether association interruption alarm occurs. If yes, refer to the corresponding alarm
handling suggestion.
Related alarm: 8417538 Association link broken
2. Activate the ASP in dynamic data management.
3. Check whether ASP operation is performed at the opposite end.
Probable Cause
AS Status is changed.
System Impact
Handling Suggestion
1. Check whether association interruption alarm occurs. If yes, refer to the corresponding alarm
handling suggestion.
Related alarm: 8417538 Association link broken
2. Activate ASP under the AS in dynamic data management.
3. Check whether ASP operation is performed at the opposite end.
3-34
Probable Cause
System Impact
Different errors have different influences upon the system, such as no influence, office inaccessible,
and service loss.
Handling Suggestion
1. Check AS configuration to see whether the configured traffic mode at both sides are consistent. If
no, modify configuration to keep consistency.
2. APP server AS ID configuration must meet the following requirements. If ASP is configured for
local end, SGP should be configured for Opposite end. Vice versa. If IPSP client is configured for
local end, IPSP server should be configured for opposite end. Vice Versa.
3. Activate the ASP in dynamic data management.
4. On NMS configuration management interface (AS configuration), check if routing context and
routing context ID are configured. Ensure that the routing contexts configured at both ends are
the same.
5. On NMS configuration management interface, check whether the local ASP in service for AS is
configured. If no, add the configuration.
6. Check the protocol versions used at both sides. Ensure that the protocol versions are the same.
3-35
Probable Cause
System Impact
None
Handling Suggestion
Probable Cause
System Impact
If several association links are available to the destination office, service will not be affected by
establishment failure of one association. In the case of heavy traffic, congestion of available
association(s) might occur, leading to upper layer call loss or increasing PS call access failures.
If merely one association link is available to the destination office, the office might become
inaccessible. Reception and sending of messages from/to the relevant office fail. Access of services
under this office fails.
3-36
Handling Suggestion
1. On NMS configuration management interface, check association configuration at local end and
opposite end. Checking items include local IP address, local port No., remote IP address, remote port
No., and application property of SCTP association. If the association at local end is configured as
client, the association at opposite end should be configured as server. Vice Versa.
2. At local end, check whether the associations configured with different protocol types have the
same local IP address and local port No.. If yes, perform configuration modification to differentiate the
local IP address and local port No. of these associations.
3. Check protocol stack configuration at both ends to see if interface board addresses are in the same
network segment. If no, modify configuration to put two addresses in the same network segment.
4. Ping the opposite-end interface board address to see if the network cable or other intermediate link
is faulty. Replace the cable if ping fails.
Probable Cause
System Impact
Usually, there is no effect to process, at worst condition, association breakdown and restart at once.
Handling Suggestion
1. Please contact related personnel on the remote end to find out why association breakdown.
2. Ensure that connector contact and cable connection are normal.
3-37
Probable Cause
System Impact
may result a office unaccessible ,or may result other association congested
Handling Suggestion
No need to handle.
Probable Cause
System Impact
none
Handling Suggestion
No need to handle.
3-38
l Notification Sub-code:0
l Description:One user of share association is out of service
l Severity:Major
Probable Cause
One user of share association is out of service
System Impact
The unestablished assoc will result in the status(down) of asp directly , and in some case the status of
As and office maybe not correct also.
Handling Suggestion
No need to handle.
Probable Cause
The config of association's stream is error or is not configured in SCTP layer yet
System Impact
The associated can't set up
Handling Suggestion
1. Please check streams: M2PA:2, M2UA/SUA/M3UA/IUA:2-17, other:1-17
2. Please check if the assoication is already configured in SCTP layer
3-39
Probable Cause
Dynamic memory application is failed
System Impact
None
Handling Suggestion
Enlarge memory capacity and then restart the board.
Probable Cause
The config of dynamic association is error
System Impact
The associated can't set up
Handling Suggestion
Please check the config of dynamic assoc:
1.The dynamic assoc can't config remote IP and PORT
2.The dynamic assoc can't config the client property
3.The dynamic assoc can't support the protocal
3-40
Probable Cause
System Impact
Handling Suggestion
Probable Cause
That MTMA get and parse configuration file is abnormal or configuration file is updated
System Impact
Handling Suggestion
3-41
Probable Cause
exception occurs when MTMS access database
System Impact
The MCS cann't work
Handling Suggestion
Check the OMP
Probable Cause
The board heartbeat was lost.
System Impact
Interfaces on this board are unavailable.
Handling Suggestion
1. Reinsert the board tightly, review whether this alarm still presents.
Y->go to "2".
N->End.
2. Turn off ENUM switch, review whether this alarm still presents.
Y->Please contact ZTE Corporation.
N->End.
3-42
l Severity:Minor
Probable Cause
1. The remote end reset this TCP connection through sending RST packet.
2. The remote end receives the TCP connection that is unavailable and responds by
sending RST packet.
System Impact
1. The TCP service discards received reset reports, and the service stays in monitoring
status.
2. There is no impact on the upper layer services.
Handling Suggestion
1. Enter the protocol mode by IPSTACK, and check whether the physical link lost lots of
packages by PING and exit this mode by EXIT MODE.
Y->2
N->3
2. Troubleshoot the physical connection, and check whether the alarm is eliminated.
Y->End
N->3
3. Contact the ZTE office.
Probable Cause
1. Hardware fault, for example, external interfaces of local/remote devices are broken,
the intermediate switch device is broken, or the transmission channel is interrupted.
2. Bearer network communication fault, such as external interfaces of local/opposite
device are faulty, physical intermediate device or route is faulty, or the bearer link is
faulty.
3. Configuration is improper, for example, the route or interface address of the local/opposite
device changes.
4. Device is faulty, for example, the NE control panel channel of local/opposite device is
disconnected.
3-43
System Impact
Handling Suggestion
1. Enter the protocol mode by IPSTACK, and check whether the physical link lost lots of
packages by PING and exit this mode by EXIT MODE.
Y->2
N->3
2. Troubleshoot the physical connection, and check whether the alarm is eliminated.
Y->End
N->3
3. In the NM alarm management window, check whether the ALM-8393985 Abnormal
Control Plane Communication Between Board and Home ModuleALM-8393988
Abnormal Control Plane Communication Between Module and OMP alarms are
reported on the home module.
Y->4
N->5
4. Handle the faults according to the alarm suggestions, and check whether the alarm is
eliminated.
Y->End
N->5
5. Contact the opposite device maintenance personnel to remove the NE fault. Check
whether the notification is removed.
Y->End
N->6
6. Contact the ZTE office.
Probable Cause
System Impact
TCP discards the received reports, which results in application layer communication failure.
3-44
Handling Suggestion
1. Observe both ends of the application layer and check whether MD5 is not configured.
Y->2
N->3
2. Set MD5 and check whether the notification is removed.
Y->End
N->3
3. Contact the ZTE office.
Probable Cause
The MD5 keys at both ends are not consistent with each other when the application layer
sends and receives packets.
System Impact
TCP discards the received reports, which results in application layer communication failure.
Handling Suggestion
1. Check whether the MD5 passwords at both ends are not consistent with each other.
Y->2
N->3
2. Set the same MD5 passwords at two ends and check whether the notification is
removed.
Y->End
N->3
3. Contact the ZTE office.
3-45
Probable Cause
System Impact
Handling Suggestion
1.Check whether the threshold of socket queue is too low through debug function in EPU.
Y->Set a large value. The troubleshooting completes.
N->It may be caused by abnormal upper layer service,Go to "2"
2.Make records of the alarm information and contact ZTE Corporation.
Probable Cause
System Impact
3-46
Handling Suggestion
1.Make no manual intervention and just wait the system to recover.Check whether the alarm
disappears after 2 minutes.
Y->End.
N->Contact ZTE.
Probable Cause
The peer IP address configuration and the local IP address configuration of PPP link is the same.
System Impact
Network communication will be interrupted.
Handling Suggestion
1. Check if the port is self-loop.
Y->cancel loopback
N->go to "2"
2. Check if the peer IP address configuration is same as the local IP address configuration of PPP link.
Y->reconfigure unrepeatable IP address
N->Please contact ZTE Corporation.
3-47
l Severity:Minor
Probable Cause
System Impact
Handling Suggestion
3-48
l Severity:Minor
Probable Cause
1.Because of disappear of error environment before, now HDLC create successfully now
System Impact
Handling Suggestion
NONE.
Probable Cause
System Impact
If the HDLC is the last available one in the UID,the service on the UID will be interrupted. If the HDLC
is not the last available one in the UID, the traffic on the UID will be reduced.
Handling Suggestion
1.Check the settings of HDLC channel to see whether the E1/TI of this HDLC and its time slots are
accordant with the peer end.
Y->Go to "2".
N->Modify HDLC settings and make it accordant with the peer end HDLC, and go to "2" if this alarm
still exists.
2.Check whether the physical connection is correct.
Y->Go to "3".
N->Change physical connection and make it accordant with the peer end, and go to "3" if this alarm
still exists.
3.Check whether the E1/T1 line is damaged.
Y->Change the E1/T1 line, and go to "4" if this alarm still exists.
3-49
N->Go to "4".
4.Note down the statistic data of messages received and sent from the HDLC, and contact ZTE.
Probable Cause
1.The port rate is larger than the limit of pyhsical port when creating atm port;
2.There is at least one atm pvc on the atmport when deleting atm port;
3.The port rate is less than the sum of the pvc rate on the atm port when modifing atm port;
System Impact
Can not config PVC on the port,ATM can not be work normally.
Handling Suggestion
Check the parameters of the port:1.The port rate isn't out of the range about the type.
2.The rate must be enough for the current pvc on the port when you modify the port rate.
3.Please confirm there is not pvc on the port.
Probable Cause
When the IMA group related operations (such as adding, deleting or modifying a group) initiated by
the oamback fail,this alarm appears. In general, the reason is that the group parameters are incorrect
when the operations are initiated.
3-50
System Impact
Handling Suggestion
1.Check whether the parameters related to the initiated operations are correct.
Y->If so, go to '2'.
N->If not, modify them and perform operations again. If the operations can be performed successfully,
finish the alarm handling. If not, go to '2'.
2. Check if the operation steps are legal.
Y->If so, please contact ZTE Corporation for help.
N->If not, perform the operations according to correct steps. If the operations can be performed
successfully, finish the alarm handling. If the operations fail, please contact ZTE Corporation for help.
Probable Cause
When the IMA link related operations (such as adding or deleting a ima link) initiated by the oamback
fail, this alarm appears. In general, the reason is that the link parameters are incorrect when the
operations are initiated.
System Impact
Handling Suggestion
1.Check whether the parameters related with the initiated operations are correct.
Y-> If so, go to '2'.
N-> If not, modify them and perform the operations again. If the operations can be performed
successfully, finish the alarm handling. If they can not be performed successfully, please go to '2'.
2.Check if the operation steps are legal.
Y->If so, please contact ZTE Corporation for help.
N->If not, perform the operations according to correct steps. If the operations can be performed
successfully, finish the alarm handling. If the operations fail, please contact ZTE Corporation for help.
3-51
Probable Cause
System Impact
During APS switching, the link is interrupted for 10 to 50 ms. Few packets loss might occur, but
service is not affected.
Handling Suggestion
Check operation and maintenance log to see if O&M personnel initiated manual APS switching
request/clearance. If yes, no handling is necessary. If no, check if the following alarms are declared
in the board. If such alarm exists, refer to the corresponding alarm handling suggestion.
3-52
Probable Cause
1. RPU fails to register.
2. Protocol stack fails to request for system configuration.
3. The control-plane communication is broken.
System Impact
The protocol process could not enter working state.
Handling Suggestion
1. Check whether the home module MP and the local board system control are normal
and whether their communication is normal.
Y->4
N->2
2. Plug this board and reset hardware, check whether the fault is eliminated.
Y->End
N->3
3. Replace the faulty board, and check whether the alarm is eliminated.
Y->End
N->4
4. Contact the ZTE office.
Probable Cause
Add UID or PPP route failed.
System Impact
Communication failed.
Handling Suggestion
1.Check whether the destination IP of new route has been used by other routes.
2.Check whether the route table is full.
3.Please contact ZTE Corporation.
3-53
Probable Cause
1. The IP address (including virtual addresses in the same network section) configured
for this gateway is same with that of other host in the network.
2. This is a loop in the networking.
3. VLAN is not divided or divided improperly.
System Impact
The device and alarm interface in the network share the same IP address, if you continue
to use this interface, its services will be unavailable and its connection will be connected and
disconnected intermittently. Meanwhile, ARP pf other communication devices will be
updated frequently.
Handling Suggestion
1. Check the port configuration to see if the same IP address has been configured.
Y->2
N->3
2. Modify a port IP address, and check whether the notification is eliminated.
Y->End
N->3
3. Contact the ZTE office.
3-54
Probable Cause
1. The MAC address of this network is the same with the other MAC address in the
associated network.
2. This is a loop in the networking.
3. VLAN is not divided or divided improperly.
System Impact
The lay-2 device will transfer MAC based on the target MAC, and port MAC influences
layer-2 MAC recording. In case of MAC address conflict, MAC recording will be influenced,
and the reports will be sent and received intermittently,
Handling Suggestion
1. Check whether the port has configured the same MAC address.
Y->2
N->3
2. Modify the MAC address of a port, and check whether the notification is eliminated.
Y->End
N->3
3. Contact the ZTE office.
Probable Cause
When adding a neighbor, the address of the neighbor mismatches with that of the interface.
System Impact
The dynamic routes needed to be from this neighbor can not be established.
3-55
Handling Suggestion
1.Check the address of interface to see whether it is in the same network segment with that of RIP
neighbor.
Y->If so, go to "3".
N->If not, go to "2".
2.Check if the configured neighbor address is the network number or broadcast address.
Y->If so, go to "3".
N->go to "4".
3.Reconfigure the neighbor address to finish the alarm handling.
4.Contact ZTE Corporation.
Probable Cause
System Impact
Handling Suggestion
1.Check if the authentication types on the two ends are consistent. If not, go to "2". Y-> If so, go to "3".
2.Modify authentication types on two ends as consistent ones. And Finish the alarm handling.
3.If the authentication types are consistent, check if the authentication keys are consistent, if so, go to
"4". If not, modify them as consistent ones. Finish the alarm handling.
4.Contact ZTE Corporation.
3-56
l Severity:Minor
Probable Cause
The version number of the interface on remote device is inconsistent with that on local device.
System Impact
Handling Suggestion
1.Check if the version number of the interface on remote device is inconsistent with that on local
device.
Y->Go to "3".
N->Go to "2".
2.Reconfigure it and finish the alarm handling.
3.Contact ZTE Corporation.
Probable Cause
System Impact
Handling Suggestion
1.Configure route aggregation to reduce the number of LSAs. Check if the alarm is eliminated.
Y->If so, finish the alarm handling.
N->Contact ZTE Corporation.
3-57
Probable Cause
System Impact
Handling Suggestion
1.To modify the relevant configuration of OSPF and make them being coordinated. Check if the
alarm is eliminated.
Y->If so, finish the alarm handling.
N->Contact ZTE Corporation.
Probable Cause
System Impact
3-58
Handling Suggestion
Probable Cause
System Impact
Handling Suggestion
3-59
Probable Cause
System Impact
Handling Suggestion
Probable Cause
System Impact
3-60
Handling Suggestion
1.Check routes on RPU to see if there are any needless interface addresses and static routes.
Y->If there are, delete the unwanted IP interface addresses or static routes, go to "2".
N->If IP address is not configured on the interface, go to "3".
2.Check if the alarm is eliminated.
Y->If so, finish the alarm handling.
N->If not, go to "3".
3.Reduce the quantity of its distributed route information through route aggregation on the peer router.
And check if the alarm is eliminated on the local.
Y->If so, finish the alarm handling.
N->If not, go to "4".
4.Record the detailed information.
1)Record IP address and static route information on the interface.
2)Record the dynamic route information. Contact ZTE Corporation.
Probable Cause
The default MAC of the port conflicts with a configured MAC of an intra-office port.
System Impact
The NE MAC addresses conflict, and these two ports cannot communicate with each other.
Handling Suggestion
1. Check whether the existing port MAC conflicts with the MAC you want to configure.
Y->2
N->3
2. Change to other MAC value, and check whether the notification is eliminated.
Y->End
N->3
3. Contact the ZTE office.
3-61
Probable Cause
Hello message authentication modes or keys configured on the routers of the two ends are
inconsistent.
System Impact
The report that fails in the Hello authentication is omitted and the local router can not synchronize
the link status with the corresponding router.
Handling Suggestion
1.Find out the peer-end router according to system id in the alarm message.
2.Execute the show running config command locally and remotely. Check the routers on the two ends
in the displayed device running configuration to see if the protocol authentication modes in ISIS
protocol stack instance configuration are consistent (MD5/TEXT).
Y->Go to "3".
N->Modify the protocol authentication modes on the routers of the two ends as the consistent ones
and perform the interconnection operations again. Finish the alarm handling.
3.Execute the show running config command locally and remotely. Check the routers on the two ends
in the displayed device running configuration to see if the protocol message authentication keys in
ISIS protocol instance configuration are consistent (MD5/TEXT).
Y->Please contact ZTE Corporation.
N->Modify the protocol authentication modes on the routers of the two ends as the consistent ones
and perform the interconnection operations again. Finish the alarm handling.
3-62
l Severity:Minor
Probable Cause
LSP message authentication modes or keys configured on the routers of the two ends are
inconsistent.
System Impact
The report that fails in the LSP authentication is omitted and the local router can not synchronize
the link status with the corresponding router.
Handling Suggestion
1.Find out the peer-end router according to system id in the alarm message.
2.Execute the show running config command locally and remotely. Check the routers on the two ends
in the displayed device running configuration to see if the protocol authentication modes in ISIS
protocol stack instance configuration are consistent (MD5/TEXT).
Y->Go to "3".
N->Modify the protocol authentication modes on the routers of the two ends as the consistent ones
and perform the interconnection operations again. Finish the alarm handling.
3.Execute the show running config command locally and remotely. Check the routers on the two ends
in the displayed device running configuration to see if the protocol message authentication keys in
ISIS protocol instance configuration are consistent (MD5/TEXT).
Y->Please contact ZTE Corporation.
N->Modify the protocol authentication modes on the routers of the two ends as the consistent ones
and perform the interconnection operations again. Finish the alarm handling.
Probable Cause
SNP message authentication modes or keys configured on the routers of the two ends are
inconsistent.
3-63
System Impact
The report that fails in the SNP authentication is omitted and the local router can not synchronize
the link status with the corresponding router.
Handling Suggestion
1.Find out the peer-end router according to system id in the alarm message.
2.Execute the show running config command locally and remotely. Check the routers on the two ends
in the displayed device running configuration to see if the protocol authentication modes in ISIS
protocol stack instance configuration are consistent (MD5/TEXT).
Y->Go to "3".
N->Modify the protocol authentication modes on the routers of the two ends as the consistent ones
and perform the interconnection operations again. Finish the alarm handling.
3.Execute the show running config command locally and remotely. Check the routers on the two ends
in the displayed device running configuration to see if the protocol message authentication keys in
ISIS protocol instance configuration are consistent (MD5/TEXT).
Y->Please contact ZTE Corporation.
N->Modify the protocol authentication modes on the routers of the two ends as the consistent ones
and perform the interconnection operations again. Finish the alarm handling.
Probable Cause
System Impact
Handling Suggestion
1.Check if the bottom link has communication problems and if there is any illegal system in the
network.
3-64
Probable Cause
In ISIS instance configuration under protocol stack configuration mode, System-id has wrong
configuration.
System Impact
ISIS Protocol-Neighbor can not set up between the Routers with system id conflicting.
Handling Suggestion
1.Check system id configuration in ISIS instance on the router by show running config command
for conflict.
Y->Modify system id configuration in the instance, go to "2".
N->Contact ZTE Corporation.
2.Check if the alarm is eliminated.
Y->Finish the alarm handling.
N->Please contact ZTE Corporation.
Probable Cause
Top resource insufficient.
System Impact
Top Resource of the board is not available.
3-65
Handling Suggestion
Probable Cause
The currently locked reference of the clock board has been changed.
System Impact
System could not get the needed clock, which will cause processing abnormity related to the clock.
Handling Suggestion
No need to handle.
Probable Cause
System Impact
System could not get the needed clock, which will cause processing abnormity related to the clock.
3-66
Handling Suggestion
No need to handle.
Probable Cause
System Impact
Handling Suggestion
1.Configure an IPv4 address for an interface (It is recommended to configured an IPv4 address for a
Loopback interface) , make it a Router ID, and then re-create an OSPF process. Check whether
the alarm disappears.
Y->End.
N->Contact ZTE.
Probable Cause
3-67
System Impact
Handling Suggestion
1.To modify the relevant configuration of OSPF and make them being coordinated. Check if the
alarm is eliminated.
Y->If so, finish the alarm handling.
N->Contact ZTE Corporation.
Probable Cause
The remote address of the first choice channel is not in the address list of the TCB
association.
System Impact
Handling Suggestion
1. At the remote end, execute the SHOW SCTPAC command to query the SCTP
association configuration and the local IP address configuration.
2. At the local association end, modify the remote IP address to the local IP address
obtained in step 1.
Y->End
N->3
3. Contact the ZTE office.
3-68
l Notification Sub-code:0
l Description:SCTP Change Nexthop
l Severity:Minor
Probable Cause
Due to a link problem, the retransmission occurred three time in the association, or the previously-fixed
next hop was done with a poor quality, which caused the SCTP next hop to switch,or the SCTP next
hop switched back when the originally allocated next hop was recovered.
System Impact
Handling Suggestion
The user can check the previous next hop link based on notifications to determine whether a problem
has occurred to any middle device.Compare the previous notifications to determine whether it is a
switch back after the link is recovered.
Probable Cause
System Impact
Handling Suggestion
1.Make no manual intervention and just wait the system to recover. Check whether the alarm
disappears after 2 minutes.
Y->End.
N->Contact ZTE.
3-69
Probable Cause
System Impact
Handling Suggestion
Probable Cause
System Impact
Handling Suggestion
1.Check whether the threshold of sctp queue is too low through debug function in EPU.
Y->Set a large value. The troubleshooting completes.
N->It may be caused by abnormal upper layer service,Go to "2"
2.Make records of the alarm information and contact ZTE Corporation.
3-70
Probable Cause
DNS server makes no response, so the link may be broken or the DNS server is down.
System Impact
Handling Suggestion
1.Use command Ping to check whether the link between the network element which the DNS client
belongs to and the DNS server is available.
Y->Go to "2".
N->Solve the physical link problem.
2.Check the status of DNS server to see whether it is listening at port 53.
Y->Contact ZTE.
N->Solve equipment problem.
Probable Cause
System Impact
3-71
Handling Suggestion
1. Check the fiber Rx if connetivity is good or electric cable is loose.Put out the fiber or cable and
put in it.Observe if the alarm restore.
Yes-> alarm restore
No-> jump "2"\
2. Replace the cable to peer port on the same device.Insure peer move the other port on the device.
Yes-> alarm restore
No-> phone ZTE corporation
Probable Cause
1. As the result of the parameter is wrong such as wrong configurations of source address and
destination address, the configured PD task fail to start.
2. Failed to start task because the task pool is full.
System Impact
Handling Suggestion
3-72
5. Change the configuration of the local IP address and peer IP address,and check whether or not
the PD task start successfully:
Y->End.
N->Go to step 3;
6. Change the configuration of the destination IP address,and check whether or not the PD task
start successfully:
Y->End;
N->Go to step 4;
7. Configure the route,and check whether or not the PD task start successfully:
Y->End.
N->Contact ZTE Corporation.
Probable Cause
System Impact
none
Handling Suggestion
NONE
3-73
Probable Cause
ATCA FRU Power Off.
System Impact
none
Handling Suggestion
NONE
Probable Cause
ATCA FRU Communication Lost.
System Impact
none
Handling Suggestion
Check IPMB bus.
Probable Cause
ATCA FRU Communication Regain.
3-74
System Impact
none
Handling Suggestion
NONE
Probable Cause
Heartbeat lost;CMM command;Panel reset-keypress;Hardware watchdog;Global reset
System Impact
Board reboot, board function invalid
Handling Suggestion
Check Payload
Probable Cause
BIOS Start-up Inform
System Impact
none
3-75
Handling Suggestion
Check BIOS
Probable Cause
BIOS Memory Inform
System Impact
none
Handling Suggestion
Check Memory
Probable Cause
Hardware or software may be abnormal.
System Impact
Board can't enter word status.
Handling Suggestion
Check board according to attached detail.
3-76
Probable Cause
System Impact
none
Handling Suggestion
Probable Cause
System Impact
3-77
Handling Suggestion
Probable Cause
System Impact
Handling Suggestion
No need to handle.
3-78
Probable Cause
System Impact
Handling Suggestion
Check whether the configuration of IP is conflict, or there are other users use this IP on the network
Probable Cause
1.PVCID is invalid;
2.The ingress connection and the egress connection is not in same board;
3.The VPI or VCI of the ingress connection is conflicting between the egress connection.
4.The traffic parameters is invalid;
5.The port number is invalid.
6. The service category has not accorded with traffic type.
System Impact
Handling Suggestion
3-79
Probable Cause
When the TC link-related operations (such as adding or deleting a tc link) initiated by the oamback
fail, this alarm appears. In general, the reason is that the tc link parameters are incorrect when
the operations are initiated.
System Impact
Handling Suggestion
1.Check whether the parameters related with the initiated operations are correct.
Y->If so, go to '2'.
N->If not, modify them and perform the operations again. If the operations can be performed
successfully, finish the alarm handling. If they can not be performed successfully, go to '2'.
2.Check if the operation steps are legal.
Y->If so, please contact ZTE Coroperaton for help.
N->If not, perform the operations according to correct steps. If the operations can be performed
successfully, finish the alarm handling. If the operations fail, please contact ZTE Corporation for help.
Probable Cause
3-80
System Impact
The services that have been established are released. Access of new service is denied. Service
access will be restored in 3 seconds.
Handling Suggestion
View alarm details on the NMS Alarm Management interface to check the alarm reason, which can
help you easily find the corresponding handling suggestions.
The handling suggestions for each alarm are as follows:
1.Alarm reason: The CN sends a RESET message.
1) Check the operation log of the NMS to see if any resetting is initiated. If yes, no handling is required.
2) Check if there is any of the following transmission-related alarms. If yes, follow the corresponding
suggestions to handle it:
199066005 SCCP subsystem unavailable
199066010 MTP3 office inaccessible.
199066014 M3UA office inaccessible.
2.Alarm reason: The signaling point of the CN-related office direction is inaccessible.
Check if there is any of the following transmission-related alarm. If yes, follow the corresponding
handling suggestions to handle it:
199066005 SCCP subsystem unavailable
199066010 MTP3 office inaccessible.
199066014 M3UA office inaccessible.
3.Alarm reason: Global reset operation is initiated by the NMS.
Check the operation log of the RNC NMS to see if there is any resetting. If yes, no handling is required.
Probable Cause
System Impact
3-81
Handling Suggestion
Check if transmission-related/board alarm occurs. If yes, refer to the corresponding alarm handling
suggestion.
Related alarms:
SCCP SSN is invalid
MTP3 office inaccessible
M3UA office inaccessible
Probable Cause
System Impact
Access of new service fails. Service access is restored to normal state in 3 seconds.
Handling Suggestion
3-82
Probable Cause
System Impact
No impact on service.
Handling Suggestion
Probable Cause
The CCP ID configured on the RNC side is different from that on the Node B side.
System Impact
Handling Suggestion
Click NE Information Configuration on the NMS Configuration Management interface. Select the
corresponding Node B and modify its CCP ID in Node B port configuration.
3-83
l Severity:Major
Probable Cause
System Impact
The cell is unavailable. UE access to the cell fails, and all cell services are down.
Handling Suggestion
On NMS fault management interface, view notification Details where Alarm Reason is given. Locate
the specific handling suggestion according to the given reason.
The handling suggestions that correspond to the reasons are described below.
1.Alarm reason: Get system information from database failed.
View notification Details where "bySIBType" information is given. For example, "SIB type=1" indicates
fetching failure of Sib1. Check if the Sib1-related parameter configuration is correct and if the
configuration exists in the cell.
The mapping relationship between SIB type and the configuration required to be checked is listed
below.
1) SIB type=1
On NMS configuration management interface (UE timers and constants information), check UE
timers and counters in idle and connected status.
2) SIB type=2
On NMS configuration management interface (UTRAN cell), check URA ID in UTRAN cell global
information.
3) SIB type=3
On NMS configuration management interface (cell selection and reselection), check cell
selection/reselection information parameters and cell access limit parameters.
4) SIB type=5
On NMS configuration management interface (UTRAN cell), check common transport channel
parameters in SCCPCH and RACH.
2.Alarm reason: Exceed system broadcast ability.
The notification might be caused by transmission fault. Check if transmission-related alarm exists in
the Node B that the cell belongs to. If yes, refer to the corresponding alarm handling suggestion.
1) IP Mode
Check if related alarm exists according to the given association ID.
Related alarms:
199066018 Association congested
199066019 Association link broken
2) ATM Mode
a. Bottom layer transmission fault.
Check if related alarm exists.
Related alarms:
3-84
SDH/SONET fault
Abnormal status in SDH/SONET
SDH/SONET: Excessive Error Code
High Error Rate of Optical Interface
b. PVC unavailable.
Check if related alarm exists.
Related alarm: PVC Fault
Probable Cause
System Impact
Common Channel is unavailable, which falls into the following three cases.
1. If the SCCPCH carrying FACH is unavailable, UE-initiated CS/PS services will be down.
2. If the SCCPCH carrying PCH is unavailable, paging function will be unavailable in the system,
leading to failure of UE-initiated CS/PS services.
3. If the PRACH carrying RACH is unavailable, UE access to the cell will fail.
Handling Suggestion
On NMS alarm management interface, view notification Details where Alarm Reason is given. Locate
the specific handling suggestion according to the given reason.
The handling suggestions that correspond to different reasons are described below.
1.Alarm reason: User plane resource unit initialization fail.
1) On NMS configuration management interface (NE information configuration), select the relevant
Node B. Check the correctness of parameter configuration on path configuration interface. Check if
forwarding bandwidth is configured.
2). On NMS configuration management interface (path group configuration), view path group
configuration. Check the correctness of parameter configuration.
2.Alarm reason: CCH setup fail at NodeB side.
3-85
On NMS configuration management interface (BS ground resource management), view IP parameter
configuration in IP and route management. Ensure that at least one "COS" is selected.
3.Alarm reason: CCH delete by OMCR.
Automatic processing is performed by the system. Common channel deletion is initiated by RNC. No
handling is necessary
4. Others.
Common channel will be automatically reestablished by the system. No handling is necessary.
Probable Cause
1. The RNC is connected with other Node B incorrectly, not the wanted Node B.
2. The radio resource data configured at RNC side and Node B side is inconsistent.
System Impact
Handling Suggestion
1、Check if the RNC is connected with Node B correctly on Iub interface. If not, please reconnect
RNC and Node B, and synchronize the configuration data to Node B.
2、Check if the radio resource data configured at RNC and Node B is consistent. If not, please
modify the radio resource data correctly, and synchronize the configuration data to RNC and Node B.
3-86
Probable Cause
System Impact
some neighbour cells are not broadcasted by SIB, and the cell re-selection procedure does not
work well.
Handling Suggestion
Probable Cause
MicroCode subsystem failed to get the table of configuration from database subsystem during the
power on procedure, or failed to update the table of configuration.
3-87
System Impact
The system impacts that correspond to different alarm causes are described below.
1. Failed to get the information of the reassemble board.
The configuration information is used to reassemble the fragments of IP packets inputted into the
equipment. Lacking the configuration information may cause processing failure of fragments of IP
packets. Service interruption might occur or service processing rate might slow down.
2. Failed to get the configuration of OMCB server.
Lacking the configuration information may paralyze OMCB function.
3. Failed to get the configuration of signal dispatch table.
Lacking the configuration information causes SCTP data transmission failure on the interface board.
The service related to SCTP Protocol on this board is down.
4. Failed to get the configuration of IP/UDP.
Lacking the configuration information may cause processing failure of IUPS service, or processing
failure of other data based on IP transmission.
5. Failed to get the configuration of L2 table.
Lacking the configuration information may cause communication failure within the equipment. All
services on the board might be down.
6. Failed to get the configuration of path information.
In the case of ATM interface board, lacking the configuration information may incur processing failure
of the AAL2 data based on ATM Adaptation Layer Protocol, leading to interruption of IUB/IUCS/IUR
services under this office.
In the case of IP interface board, lacking the configuration information may incur processing failure of
IP packet traffic control, leading to interruption of all services under this office.
7. Failed to get the configuration of pathgroup information.
In the case of ATM interface board, lacking the configuration information may incur processing failure
of the AAL2 data based on ATM Adaptation Layer Protocol, leading to interruption of IUB/IUCS/IUR
services under this office.
In the case of IP interface board, service is not affected.
Handling Suggestion
The operator should add the configuration or re-synchronize the configuration according to the
addition information of this report.
3-88
Probable Cause
There are too many configured route entries.The alarm is declared when the number of route entries
reaches 90% of the table capacity threshold.
System Impact
1.If the number of route entries does not exceed the RUB board route table capacity, service will
not be affected.
2.If the number of route entries exceeds the RUB board route table capacity, information of some
route entries will be lost.
1) If the missing route are the route to Node B or CN, UE service access to the board will fail.
2) If the missing route are the route to other RNC NE, access of Inter-RNC UE services to the board
will fail. Meanwhile, tick clock synchronization of the MBMS service between the relevant RNC NEs
will fail, degrading the MBMS service quality
3.If the number of route entries exceeds the RUB board route table capacity, the SLA diagnostic test
function from RNC to related NE will be disabled.
Handling Suggestion
1. On NMS configuration management interface (static route), delete the routes that are not in use.
2. On NMS configuration management interface (interface configuration), delete the port IP that is
no longer in use.
Probable Cause
Failed to assign DHCP Configuration to Client, may be one of the following causes:
1) OMCB Server Ip Configuration Absent
2) Peer Ip Address of PPP Link Absent
3) RNC Omcb Service Ip of Node Operation and Maintain Absent
4) Failed to Get Client DHCP Configuration from DBS
System Impact
DHCP Client can not get it's DHCP Configuration Information
3-89
Handling Suggestion
Probable Cause
System Impact
Handling Suggestion
Probable Cause
1. Clock Deviation between Slave and Host over threshold(default threshold 36sec/hr)
2. Clock crystal oscillator of Slave or Host is inaccurate
3-90
System Impact
Handling Suggestion
Block the Slave reported in the notification, and inform hardware manager
Probable Cause
System Impact
Handling Suggestion
Block the Slave reported in the notification, and inform hardware manager
3-91
Probable Cause
System Impact
Handling Suggestion
1.On NMS configuration management interface, check local IP address, remote IP address and TCP
connection mode. If the connection mode at local end is configured as client, the connection mode at
opposite end should be configured as server. Vice Versa.
2.On NMS configuration management interface, check protocol stack configuration at both ends. In
the case of direct connection, ensure that interface board addresses at both ends are in the same
network segment, and the next hop address is direct connect interface board address. In the case of
not direct connection, ensure that the next hop address is the intermediate equipment address.
3.Check the IP interface board for the Related Alarms. Perform the recommended solution to process
the possible alarms.
Related Alarms: 199066070 Board Offline or the CPU is in long period reset status
4.Telnet to the interface board. Set a destination IP and ping it. In the case of direct connection, ping
the direct connect interface board address. In the case of not direct connection, ping the intermediate
equipment. If response timeout, contact the equipment provider for solution.
5.Check the physical connection on IuBC interface. If the connection is loose or broken, unplug and
plug the cable or replace the cable. If port indicator is on, the physical link must be normal.
Probable Cause
Adjust the transmission path bandwidth to the low thehold can not radically improve packet loss
rate of this path.
3-92
System Impact
The packet loss rate higher than the reference value will depress the quality of service (QoS), even
lead to the access failure and service disconnection.
Handling Suggestion
Check the intermediate equipment between RNC and peer NE,make sure the intermediate
equipment runs normally .
Probable Cause
System Impact
IPBM can not recive the SLA acknowledge,the function of the band width adjust is useless.
Handling Suggestion
3-93
Probable Cause
System Impact
Either the LogService or the OMP cannot save the performance files. Performance data will be lost.
It has no impact on services.
Handling Suggestion
Check alarm details to find the Failure cause during saving performance file, and handle the alarm
accordingly.
1. If the Failure cause is "the space of OMP disk is less than 500M"Please delete unnecessary files
from the OMP disk to release enough space.
4. If the Failure cause is "The session ends abnormally and the performance file can not be saved", it
means the board time has been adjusted. In this case, no handling is required.
5. If the Failure cause is "PM files have already existed for over two hours.", the suggestion is given
for the alarm "199083028 Logservice is unavailable".
Probable Cause
System Impact
Handling Suggestion
3-94
Probable Cause
System Impact
Handling Suggestion
1.Check the IP interface board for the Related Alarms. Perform the recommended solution to process
the possible alarms.
Related Alarms: 198005379 Board Offline or the CPU is in long period reset status
2.TCheck the physical connection on IuBC interface. If the connection is loose or broken, unplug and
plug the cable or replace the cable. If port indicator is on, the physical link must be normal.
Probable Cause
System Impact
3-95
Handling Suggestion
Probable Cause
System Impact
If the bandwidth is lesser than configured bandwidth, lesser calls will be adopted in the relative
transport path.
Handling Suggestion
If the bandwidth of the inform is lesser than the configured bandwidth, it means that there is
something wrong with the transport path and it is more possible that fault is more possible at the
Nodeb side. If the bandwidth of the inform is equal to the configured bandwidth, it means the fault
has been recovered.
3-96
Probable Cause
Available bandWidth of transport path is less than occupied bandWidth. Probable causes for the
alarm include:
1.E1 link is broken.
2.Transmission quality of the transmission line is poor.
3.Intermediate equipment is faulty.
System Impact
The available bandwidth to destination is less than occupied bandwidth. Some services would be
released in this transport path selectively to avoid transport path congestion.
Handling Suggestion
Probable Cause
Available bandwidth of transport path group is less than occupied bandwidth. Probable causes
for the alarm include:
1.E1 link is broken.
2.Transmission quality of the transmission line is poor.
3.Intermediate equipment is faulty.
System Impact
The available bandwidth to destination is less than occupied bandwidth.So service rate on this
path group will be degraded.
Handling Suggestion
3-97
3-98