HLR Alarm Message Reference
HLR Alarm Message Reference
Version: V4.11.10
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: [email protected]
LEGAL INFORMATION
Copyright © 2011 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
I
2.26 M3UA Office Inaccessible (8400384) ............................................................... 2-21
2.27 SUA Subsystem Unavailable (8401152)........................................................... 2-22
2.28 SUA Office Inaccessible (8401153).................................................................. 2-24
2.29 Association Link Broken (8402690).................................................................. 2-25
2.30 PPP Link Broken (8407043) ............................................................................ 2-26
2.31 BFD Session Interrupted (8411392) ................................................................. 2-28
2.32 BFD Session Negotiation Failed (8411393) ...................................................... 2-30
2.33 Association Path Broken (8417537) ................................................................. 2-31
2.34 Bearer Network is Unavailable (8419073) ........................................................ 2-33
2.35 Bearer Network Get Worse (8419074) ............................................................. 2-34
2.36 Broadband Link Unavailable (8429568) ........................................................... 2-35
2.37 Link to Specified Node Broken (2534034688)................................................... 2-36
2.38 Link Broken Between NE and NM Server (2365981697) ................................... 2-36
2.39 Link Broken Between Alarm Box and NM Server (2365981698) ........................ 2-37
II
3.22 Internal Controlled Account Number and Password Already Expired
(2365980930)................................................................................................. 3-20
3.23 Internal Controlled Account Number and Password Do Not Meet Requirements
(2365980931)................................................................................................. 3-21
3.24 3 Consecutive Wrong Passwords During Login (2365980932)........................... 3-22
3.25 License File Illegal (2365981441) .................................................................... 3-23
3.26 License File Unavailable (2365981443) ........................................................... 3-24
3.27 Multiple License Files Exist (2365981444)........................................................ 3-24
3.28 Loaded License File Expires (2365981445)...................................................... 3-25
3.29 Create Agent Diary File Failed (2533521408) ................................................... 3-26
3.30 Failed to Upload Agent Diary (2533521409) ..................................................... 3-26
3.31 MMDB Tuple Check Failed (2533968405) ........................................................ 3-27
3.32 MMDB Page Check Failed (2533968406) ........................................................ 3-27
3.33 Service PDB Occupation Alarm (2534019079) ................................................. 3-28
3.34 DBIO Server Is Overload (2534029312)........................................................... 3-28
3.35 DBIO Modified Local Agent Password Fail (2534029313).................................. 3-29
3.36 User Capacity Beyond License Capacity (2534029320) .................................... 3-29
3.37 Auth Capacity Beyond AdminDomani Capacity (2534029321) ........................... 3-30
3.38 HLR Has Failed Over to Other HLRs, the Links to Other NEs Are Blocking
(2534031360)................................................................................................. 3-30
3.39 HLR Can Provide Service for Other NEs, the Links to Other NEs Are
Unblocked. The BOSS Request Has Been Permitted (2534031361) .................. 3-32
3.40 HLR Has Provided Services for Standby Subscriber from Now (2534031362) ..... 3-34
3.41 HLR Stops to Provide Service for Standby Subscriber from Now
(2534031363)................................................................................................. 3-36
3.42 Serious Error Found, HLR Try to Block All Link to Other NEs, the Operation
Has Failed (2534031364) ................................................................................ 3-37
3.43 UDS Node Has Received too Many Messages Within a Time (2534033667) ...... 3-39
3.44 The User Capacity of Each DSA Node in DSA Group Has Been Full
(2534033668)................................................................................................. 3-40
3.45 Capacity of User Table Is Full (2534033920) .................................................... 3-41
3.46 Capacity of HLR User DB Is Full (2534033922) ................................................ 3-42
3.47 Percentage of Free Space on Logical Structures Beneath (2534033923) ........... 3-42
3.48 Disk Full (2534034176)................................................................................... 3-43
3.49 Problem With Operations Read/Write on the Physical Structures of the
Database (2534034177).................................................................................. 3-43
3.50 Resume Failed Because The Capacity of Backup Node Is Undersize
(2534034432)................................................................................................. 3-44
3.51 UDS Synch Power On Fail (2534034433) ........................................................ 3-45
III
3.52 Resume Failed Because The Capacity of Slave Node Is Less Than The High
Water in The Master Node (2534034434)......................................................... 3-45
3.53 Schema Control Module Failed to Check Configure Data Compatibility
(2534034689)................................................................................................. 3-46
3.54 The DR Synchronize Requests Can't Be Sent to Backup HLR in Time
(2534035457)................................................................................................. 3-47
3.55 the Occupancy of System CPU is Above Fatal Level (2535082240)................... 3-48
3.56 the Occupancy of System CPU Is above Serious Level (2536130816) ............... 3-49
3.57 the Occupancy of System CPU Is above Common Level (2537179392)............. 3-50
IV
5.10 Loss of Clock When Input to Board (1286) ......................................................... 5-8
5.11 CPU Resets on a Board in the Same Shelf (1600) .............................................. 5-9
5.12 FLASH Device Initialize Failed (3073) .............................................................. 5-10
5.13 The Configuration Does Not Supported (5123) ................................................. 5-10
5.14 Board Config Information not Compatible (5200) ...............................................5-11
5.15 Packet Test of Internal Media Plane Is Abnormal (5396).................................... 5-12
5.16 Clock Board Work Mode Is Abnormal (5405) .................................................... 5-13
5.17 The Hard Disk Used-Rate Is over Threshold (5632) .......................................... 5-13
5.18 The Hard Disk Becomes Error or not Exist (5633)............................................. 5-14
5.19 Sub Card Abnormal (5645) ............................................................................. 5-14
5.20 Phase-Lock Loop Unlock (5646)...................................................................... 5-15
5.21 Error Packets of MAC Is Higher than the Specified Threshold (5666) ................. 5-16
5.22 Oscillator Status Abnormal (5670) ................................................................... 5-17
5.23 MAC Port Link Is Down (5760) ........................................................................ 5-17
5.24 The Speed Mode of the Port Doesn't Match with Settings (5761) ....................... 5-18
5.25 One Frequency of Clock Is All Lost when Input to Board (5768)......................... 5-19
5.26 The Master and Slave Mode of the Port Doesn't Match with Settings (5769)....... 5-20
5.27 The OMP Board Doesn't Have OMC Port (5770) .............................................. 5-20
5.28 The Duplex Mode of the Port Doesn't Match with Settings (5771) ...................... 5-21
5.29 Board Device Fault (5772) .............................................................................. 5-22
5.30 High CRC Error Rate at E1 Bottom Layer (5773) .............................................. 5-22
5.31 High FAS Error Rate at E1 Bottom Layer (5774) ............................................... 5-23
5.32 High EBIT Error Rate at E1 Bottom Layer (5775).............................................. 5-23
5.33 Subcard is Formatting Flash (5786) ................................................................. 5-24
5.34 Subcard Works in Genernal Error (5787) ......................................................... 5-24
5.35 Subcard Works in Critical Error (5788) ............................................................. 5-25
5.36 Subcard Works in Fatal Error (5789)................................................................ 5-26
5.37 Functional Epld Update Fail (5890).................................................................. 5-26
5.38 Inner Port Error (7169).................................................................................... 5-27
5.39 Media Status Abnormal (15360) ...................................................................... 5-27
5.40 Too Many Bad Frames Received (15618)......................................................... 5-28
5.41 The Fan Tray Is Off (23050) ............................................................................ 5-29
5.42 The PEM Is Off (23051) .................................................................................. 5-29
5.43 Abnormal Half-Fixed Connection Changes (25602) .......................................... 5-30
5.44 RACK Temperature Is Higher than High Threshold (25856)............................... 5-30
5.45 RACK Temperature Is Lower than Low Threshold (25857) ................................ 5-31
5.46 Room Temperature Is Higher than High Threshold (25858) ............................... 5-32
V
5.47 Room Temperature Is Lower than Low Threshold (25859)................................. 5-33
5.48 Voltage Is Higher than High Threshold (25860)................................................. 5-34
5.49 Voltage Is Lower than Low Threshold (25861) .................................................. 5-35
5.50 Humidity Is Higher than High Threshold (25862)............................................... 5-36
5.51 Humidity Is Lower than Low Threshold (25863) ................................................ 5-36
5.52 Fault in Fan Plug-In Box (25864) ..................................................................... 5-37
5.53 Rack Door Access Control Alarm (25865) ........................................................ 5-38
5.54 Smoke Alarm (25866) ..................................................................................... 5-39
5.55 Infrared Alarm (25867).................................................................................... 5-40
5.56 Lightning Alarm (25868).................................................................................. 5-41
5.57 Power Switch Alarm (25869) ........................................................................... 5-41
5.58 Power Type Configured Does Not Accord with Physical (25870)........................ 5-43
5.59 Clock Reference Source Lost (Level 3 Alarm) (26127) ...................................... 5-43
5.60 Clock Reference Source Lost (Level 2 Alarm) (26128) ...................................... 5-44
5.61 Clock Reference Source Lost (Level 1 Alarm) (26129) ...................................... 5-45
5.62 Output Clock Lost (26133) .............................................................................. 5-45
5.63 Velocity of fan is Lower Than Lower-critical Threshold (30734) .......................... 5-46
5.64 Velocity of fan is Lower Than Lower-non-critical Threshold (30745) ................... 5-46
5.65 Velocity of fan is Lower Than Lower-non-recoverable Threshold (30746) ........... 5-47
5.66 IPMB State Change (IPMB-A Enable \ IPMB-B Disable) (30812) ....................... 5-48
5.67 IPMB State Change (IPMB-A Disable\IPMB-B Enable) (30813) ......................... 5-48
5.68 STC Office Inaccessible (8402944).................................................................. 5-49
5.69 NM Server CPU Usage Rate Exceeds Criterion (2365981185) .......................... 5-49
5.70 NM Server Memory Usage Rate Exceeds Criterion (2365981186) ..................... 5-51
5.71 NM Server Hard Disk Usage Rate Exceeds Criterion(Level 1 Alarm)
(2365981187) ................................................................................................. 5-52
5.72 NM Server Hard Disk Usage Rate Exceeds Criterion(Level 2 Alarm)
(2365981188) ................................................................................................. 5-53
5.73 NM Server Hard Disk Usage Rate Exceeds Criterion(Level 3 Alarm)
(2365981189) ................................................................................................. 5-55
5.74 NM Server Hard Disk Usage Rate Exceeds Criterion(Level 4 Alarm)
(2365981190) ................................................................................................. 5-57
5.75 Directory Usage Rate Exceeds Criterion (Level 1 Alarm) (2365981191) ............. 5-58
5.76 Directory Usage Rate Exceeds Criterion (Level 2 Alarm) (2365981192) ............. 5-60
5.77 Directory Usage Rate Exceeds Criterion (Level 3 Alarm) (2365981193) ............. 5-62
5.78 Directory Usage Rate Exceeds Criterion (Level 4 Alarm) (2365981194) ............. 5-64
5.79 Link Between DBIO and HSMAPP Node Broken (2534029328)......................... 5-66
5.80 HSMAPP Node Status Error (2535069704) ...................................................... 5-66
VI
Chapter 6 Environment Alarms................................................................. 6-1
6.1 Temperature Is Lower Than Lower-non-critical Threshold (30721) ......................... 6-1
6.2 Temperature Is Lower Than Lower-critical Threshold (30722)................................ 6-2
6.3 Temperature Is Lower Than Lower-non-recoverable Threshold (30723) ................. 6-2
6.4 Temperature Is Higher Than Upper-non-critical Threshold (30724) ........................ 6-3
6.5 Temperature Is Higher Than Upper-critical Threshold (30725) ............................... 6-4
6.6 Temperature Is Higher Than Upper-non-recoverable Threshold (30726) ................ 6-5
6.7 Voltage Is Lower Than Lower-non-critical Threshold (30727)................................. 6-5
6.8 Voltage Is Lower Than Lower-critical Threshold (30728) ....................................... 6-6
6.9 Voltage Is Lower Than Lower-non-recoverable Threshold (30729)......................... 6-7
6.10 Voltage Is Higher Than Upper-non-critical Threshold (30730) .............................. 6-7
6.11 Voltage Is Higher Than Upper-critical Threshold (30731) ..................................... 6-8
6.12 Voltage Is Higher Than Upper-non-Recoverable Threshold (30732)..................... 6-9
6.13 Filter Tray Is Present for Too Long (Non-Recoverable) (30735)............................ 6-9
6.14 Filter Tray Is Present for Too Long (Critical) (30736) ......................................... 6-10
6.15 Filter Tray Is Present for Too Long (Non-Critical) (30737) .................................. 6-10
6.16 State Is Abnormal (30738) ...............................................................................6-11
Glossary .......................................................................................................... I
VII
VIII
About This Manual
Purpose
This manual introduces the alarms related to ZXUN USPP (HLR), including communication
alarms, processing error alarms, QoS alarms, equipment alarms and environment
alarms. In addition, the basic information and causes of each alarm, the impacts of each
corresponding fault on the system, and the handling method for each alarm are provided.
Intended Audience
This manual is intended for engineers and technicians who perform maintenance activities
on ZXUN USPP (HLR).
Chapter Summary
Chapter 1, Introduction to Alarms Introduces the concepts about alarm messages, alarm
functions and related information about this manual.
Chapter 2, Communication Alarms Introduces the causes, impact on the system, and handling
methods for communication alarms.
Chapter 3, Processing Error Alarms Introduces the causes, impact on the system, and handling
methods for processing error alarms.
Chapter 4, QoS Alarms Introduces the causes, impact on the system, and handling
methods for QoS alarms.
Chapter 5, Equipment Alarms Introduces the causes, impact on the system, and handling
methods for equipment alarms.
Chapter 6, Environment Alarms Introduces the causes, impact on the system, and handling
methods for environment alarms.
I
1. This device may not cause harmful interference.
2. This device must accept any interference received, including interference that may
cause undesired operation.
Changes or modifications not expressly approved by the party responsible for compliance
could void the user's authority to operate the equipment.
Conventions
ZTE documents employ the following typographical conventions.
Typeface Meaning
Bold Menus, menu options, function names, input fields, radio button names, check
boxes, drop-down lists, dialog box names, window names.
CAPS Keys on the keyboard and buttons on screens and company name.
II
Declaration of RoHS
Compliance
To minimize environmental impacts and take more responsibilities to the earth we live on,
this document shall serve as a formal declaration that ZXUN USPP (HLR) manufactured
by ZTE CORPORATION is in compliance with the Directive 2002/95/EC of the European
Parliament - RoHS (Restriction of Hazardous Substances) with respect to the following
substances:
l Lead (Pb)
l Mercury (Hg)
l Cadmium (Cd)
l Hexavalent Chromium (Cr (VI))
l PolyBrominated Biphenyls (PBBs)
l PolyBrominated Diphenyl Ethers (PBDEs)
I
II
Chapter 1
Introduction to Alarms
Table of Contents
Functions and Applications.........................................................................................1-1
Related Information ....................................................................................................1-2
Basic Concepts
l Alarm Message
Alarm messages are prompts provided upon the concurrence of problems or faults
during the running of each NE equipment.
Alarms persist till all corresponding problems or faults have been removed.
l Alarm Type
This manual introduces the following types of alarms:
à Communication alarms: alarms related to the information transmission process.
à Processing error alarms: alarms related to software and process errors.
An alarm code identifies an alarm message. The combination of an alarm code and
a system type can uniquely distinguish an alarm message from others in the alarm
system.
l System Type
1-1
System types indicate the locations where the alarm messages occur. The system
types involved in the alarm messages include:
à NE Alarm: alarms reported by network element.
à OMM System Alarm: alarms reported by the OMM system.
à Peripheral Node Alarm: alarms reported by the peripheral node.
l Alarm Level
Alarms can be divided into four levels in term of severities:
à The Critical level indicates that a service affecting condition has occurred and an
immediate corrective action is required.
à The Major level indicates that a service affecting condition has developed and an
urgent corrective action is required.
à The Minor level indicates the existence of a non-service affecting fault condition
and that corrective action should be taken in order to prevent a more serious (for
example, service affecting) fault.
à The Warning level indicates the detection of a potential or impending service
affecting fault, before any significant effects have been felt. Action should be
taken to further diagnose (if necessary) and correct the problem in order to
prevent it from becoming a more serious service affecting fault.
If the alarm level of an alarm is not known, that means the alarm is used as a threshold
alarm, whose level dynamically varies.
1-2
1-3
1-4
2-1
Causes
l Boards are badly connected in the environment. As a result, retransmission of control
plane messages is increased.
l An Ethernet communication device works improperly on the board or switching board.
l Addresses of TIPC nodes conflict.
Handling
Record the current alarm information and contact ZTE.
2-2
Causes
l The connection between the switching board and the environment monitoring board
is unavailable, or the connection cable is faulty.
l The rack No. configured for the rack where the switching board resides is inconsistent
with the rack No. set on the DIP switches of the environment monitoring board.
Handling
1. Reconnect the 485 cable between the environment monitoring board and the switching
board.
2. Ensure that the rack No. configured for the rack where the switching board resides is
consistent with the rack No. set on the DIP switches of the environment monitoring
board.
Cause
The packet loss rate of the RAWMAC channel internal the board exceeds the preset
threshold (5% by default).
Note:
2-3
Handling
1. On the Fault Management view of NMS, check whether a relevant alarm is reported
on the switching board in the same shelf.
l Yes: Handle the problem according to the handling suggestions of the relevant
alarm.
l No: Go to step 2.
2. Replace the board with the alarm, and observe whether the alarm disappears.
l Yes: End.
l No: Go to step 3.
3. Replace the switching board in the same shelf, and observe whether the alarm
disappears.
l Yes: End.
l No: Go to step 4.
4. Plug the faulty board in another slot, and observe whether the alarm disappears.
l Yes: End.
l No: Contact ZTE.
Causes
l The process for reporting the sub-unit status runs improperly.
l The device corresponding to the sub-unit works improperly.
Handling
1. Restart the board. Check whether the alarm disappears.
l Yes: End.
l No: Go to Step 2.
2. Replace the faulty board. Check whether the alarm disappears.
l Yes: End.
l No: Contact ZTE.
2-4
Cause
The status of the AS to the office has changed.
Handling
1. Check whether SIO location data has been configured for the user.
l Yes: Go to Step 3.
l No: Go to Step 2.
2. Configure the user's SIO location data, and then check whether the alarm disappears.
l Yes: End.
l No: Go to Step 3.
3. Check whether the AS is active.
l Yes: Go to Step 5.
l No: Go to Step 4.
4. Activate the AS, and then check whether the alarm disappears.
l Yes: End.
l No: Go to Step 5.
5. Contact ZTE.
Causes
l Local processor is faulty.
l The local MTP3 and the local M2PA fail to communicate.
l The peer-end processor is faulty.
2-5
Handling
1. For the peer-end processor faults, contact the peer end to solve it. For the local
processor faults, check whether the home SMP module of the M2PA link works
properly.
l Yes: Go to Step 3.
l No: Go to Step 2.
2. Switch the data processing blade where the SMP module is positioned over and reset
it. Check whether the alarm disappears.
l Yes: End.
l No: Go to Step 3.
3. Record the following information and contact ZTE.
l Configuration data of the local office and peer-end office.
l History alarms, history notifications, and current alarms of the local office and
peer-end office.
Cause
Sctp failed to create a link.
Handling
1. Just wait until the system automatically recovers. After 30 seconds, observe whether
the alarm disappears.
l Yes: End.
l No: Go to Step 2.
2-6
2. Handle the alarm according to 2.29 Association Link Broken (8402690). If the alarm
still exists, go to step 3.
3. Record the following information and contact ZTE.
l Configuration data of the local office and peer-end office.
l History alarms, history notifications, and current alarms of the local office and
peer-end office.
Cause
The remote-end IMA clock transmitting mode sent by the remote end through an ICP cell
does not match the near-end IMA clock transmitting mode. For example, the remote-end
clock transmitting mode ITC does not match the near-end clock transmitting mode CTC.
Handling
Check whether the near-end clock mode matches the remote-end clock mode.
l Yes: Contact ZTE.
l No: Modify the clock modes to make them match each other, and check whether the
alarm disappears.
à Yes: End.
à No: Contact ZTE.
2-7
Cause
A transmitting link in the IMA group fails to connect the remote-end IMA group as other
links.
Handling
Check whether the IMA chip works properly and whether each link connects the
remote-end IMA group.
l Yes: Contact ZTE.
l No: Perform configurations to make sure that the chip and all links work properly, and
check whether the alarm disappears.
à Yes: End.
à No: Contact ZTE.
Cause
The E1/T1 link has physical faults.
Handling
1. Check whether the E1/T1 link is correctly connected according to the network
construction plan.
l Yes: Go to Step 2.
l No: Go to Step 3.
2. Rectify the connection and observe whether the alarm disappears.
l Yes: End.
2-8
l No: Go to Step 3.
3. In the alarm management view of NMS, check whether any E1/T1 link alarm exists on
the board.
l Yes: Handle the alarm according to the handling suggestions of the related
alarms. If the alarm still exists, go to Step 4.
l No: Go to Step 4.
4. Contact ZTE.
Causes
l Access clock is abnormal.
l The link transmission quality is bad.
Handling
1. Check whether the clock indicators on the SWI2 board are in normal working status.
l Yes: Go to Step 2.
l Yes: Go to Step 3.
2. Check whether the clock access source is proper.
l Yes: Go to Step 4.
l No: Handle the alarms according to the alarm handling suggestions on the Fault
Management view of NMS. If the alarm still exists, go to Step 4.
3. Restart or replace SWI2 to check whether the alarm disappears.
l Yes: End.
l Yes: Go to Step 2.
4. Check whether there are any alarms for the E1/T1 link on the Fault Management view
of NMS.
l Yes: Handle the alarm according to relevant alarm handling suggestions.
l No: Contact ZTE.
2-9
Causes
l IMA link on remote end is not in activated status.
l The receiving direction of the remote link is faulty.
Handling
1. Check whether the receiving link on remote end is activated.
l Yes: Go to Step 3.
l No: Go to Step 2.
2. Activate the link and check whether the alarm disappears.
l Yes: End.
l No: Go to Step 3.
3. Contact ZTE.
Cause
The near-end receiving link fails.
2-10
Handling
Check whether the IMA chip works properly and whether each link connects the near-end
IMA group.
l Yes: Contact ZTE.
l No: Identify and solve the problem. Check whether the alarm disappears.
à Yes: End.
à No: Contact ZTE.
Cause
A receiving link in the IMA group fails to connect the remote-end IMA group as other links.
Handling
Check whether each receiving link connects the remote-end IMA group, and whether the
required near-end E1/T1 link connects the corresponding remote-end E1/T1 link.
l Yes: Contact ZTE.
l No: Identify and solve the problem. Check whether the alarm disappears.
à Yes: End.
à No: Contact ZTE.
2-11
Cause
All links of the IMA group fail.
Handling
1. Check whether the number of active links in the IMA group is less than the minimum
number of active links required for normal work of the IMA group.
l Yes: Go to step 2.
l No: Go to step 3.
2. Check and recover the faulty links that are not in active status in the IMA group. Make
sure that the number of active links in the IMA group is not less than the required
minimum number of active links. Check whether the alarm disappears.
l Yes: End.
l No: Go to step 3.
3. Contact ZTE.
Cause
An irrecoverable local fault has occurred with a user-defined critical event, or a fault has
occurred in the link receiving direction.
2-12
Handling
1. Check whether the Ethernet OAM function is enabled at the peer end.
l Yes: Go to Step 3.
l No: Go to Step 2.
2. Enable the Ethernet OAM function at the peer end, and then check whether the alarm
disappears.
l Yes: End.
l No: Go to Step 3.
3. Check whether the receive end of the fiber is in poor contact or the network cable on
the electric interface is loosely connected.
l Yes: Go to Step 4.
l No: Go to Step 5.
4. Unplug and plug the fiber or network cable, and then check whether the alarm
disappears.
l Yes: End.
l No: Go to Step 5.
5. Remove the network cable, insert it into an equivalent port with the same configurations
on the same device, and then check whether the alarm disappears.
l Yes: End.
l No: Go to Step 6.
6. Contact ZTE.
Cause
The physical trunk line or the clock is abnormal on the TC link.
Handling
1. Check whether the physical trunk line works properly.
2. Check whether the access clock works properly.
2-13
Causes
l The board is configured in the database but not powered on.
l The board is powered on but the control plane link to its home MP is broken.
Handling
1. Check whether the switch board in the same shelf and the switch board of the shelf
where the module of the board is positioned work improperly.
l Yes: Go to Step 3.
l No: Go to Step 2.
2. Restore the above boards to normal working status, and observe whether the alarm
disappears.
l Yes: End.
l No: Go to Step 3.
3. Check whether the board is successfully powered on.
l Yes: Go to Step 5.
l No: Go to Step 4.
4. Successfully switch on the board and observe whether the alarm disappears.
l Yes: End.
l No: Go to Step 5.
5. Contact ZTE.
2-14
Causes
l The MP board is configured in the database but not powered on.
l The MP board is powered on but the control plane link to the OMP is broken.
Handling
1. Check whether the switch board in the same shelf and the switch board where OMP
is positioned work improperly.
l Yes: Go to Step 3.
l No: Go to Step 2.
2. Restore the above boards to normal working status, and observe whether the alarm
disappears.
l Yes: End.
l No: Go to Step 5.
3. Check whether the board is successfully powered on.
l Yes: Go to Step 5.
l No: Go to Step 4.
4. Successfully switch on the board and observe whether the alarm disappears.
l Yes: End.
l No: Go to Step 5.
5. Contact ZTE.
2-15
Causes
l The peer-end subsystem exits the service, and the peer end blocks the local
subsystem of the peer end or other factors at the peer end cause the subsystem to
be unavailable.
l The peer-end signaling point is unreachable.
l The peer-end MTP3 or M3UA user configurations do not include SCCP users.
l The local end blocks the related subsystem.
l The configuration data at the local end includes the configuration data of the peer-end
subsystem. However, the peer end does not have local subsystem configuration
information.
l The subsystem test message initiated by the local end is not sent to the peer end
normally, or the peer end does not normally process the subsystem test message
initiated by the local end.
Handling
1. On the Fault Management view of NMS, check whether there is any alarm prompting
this adjacent office inaccessible.
l Yes: If there are alarms prompting inaccessible MTP3 office or M3UA office,
handle the alarms by following the alarm handling suggestions in 2.24 MTP3
Office Inaccessible (8400128) or 2.26 M3UA Office Inaccessible (8400384).
l No: Go to Step 2.
2. Check the local data configuration to see whether the SSN is correctly configured in
local office configuration and adjacent office configuration.
l Yes: Go to Step 4.
l No: Go to Step 3.
3. Configure the SSN and check whether the alarm disappears after configuring the SSN.
l Yes: End.
l No: Go to Step 4.
4. Check the peer-end data configuration to see whether the SSN is correctly configured
in its local office configuration and adjacent office configuration.
l Yes: Go to Step 6.
l No: Go to Step 5.
5. Contact the peer-end personnel to configure the SSN and check whether the alarm
disappears.
l Yes: End.
l No: Go to Step 6.
6. Back up the following data and contact ZTE.
l Configuration data related to local office and peer-end office.
2-16
l History alarms, current alarms, and notifications that are related to the local office
and peer-end office.
Causes
l The traffic is heavy.
l The loads on links are uneven.
l The link resource is insufficient.
Handling
1. Make no manual intervention and just wait until the system recovers. After 30 seconds,
check whether the alarm disappears.
l Yes: End.
l No: Go to Step 2.
2. Check whether the system has heavy traffic.
l Yes: Go to Step 3.
l No: Go to Step 6.
3. Check whether the link resource is sufficient.
l Yes: Go to Step 4.
l No: Go to Step 5.
4. Query performance statistic data to check whether load is evenly shared among links.
l Yes: Go to Step 1.
l No: Go to Step 6.
5. Add new links and check whether the alarm disappears.
l Yes: End.
l No: Go to Step 4.
6. Back up the following data and then contact ZTE.
l Configuration data related to local office and peer-end office.
l History alarms, current alarms, and notifications that are related to the local office
and peer-end office.
2-17
Causes
l Heavy traffic at the peer end.
l Uneven load among links.
l Insufficient link resource.
Handling
1. Make no manual intervention and just wait until the system recovers. Check whether
the alarm disappears 30 seconds later.
l Yes: End.
l No: Go to Step 2.
2. Check whether the system is busy in processing current services.
l Yes: Go to Step 3.
l No: Go to Step 6.
3. Check whether there are sufficient link resources.
l Yes: Go to Step 4.
l No: Go to Step 5.
4. Check whether the loads are evenly shared among links.
l Yes: Go to Step 1.
l No: Go to Step 6.
5. Add new links and check whether this alarm disappears.
l Yes: End.
l No: Go to Step 4.
6. Record the following information and contact ZTE.
l Configuration data of the local office and peer-end office.
l History alarms, history notifications, and current alarms of the local office and
peer-end office.
2-18
Causes
l The link is physically broken.
l Link test is failed.
l The universal processing blade is restarted.
Handling
1. Check whether there is new data configuration or the configuration has been changed.
l Yes: Go to Step 2.
l No: Go to Step 4.
2. 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.
l Yes: Go to Step 4.
l No: Go to Step 3.
3. Modify link data configuration and then check whether the alarm disappears.
l Yes: End.
l No: Go to Step 4.
4. Check whether there is any alarm for bottom layer transmission if the link configuration
has not been changed.
l Yes: Contact a transmission engineer to handle the problem.
l No: Go to Step 5.
5. Perform physical link self-loop on the devices at the two ends of the link, and check
whether the alarm disappears.
l Yes: Check the bottom layer transmission and ask a transmission engineer to
solve the problem.
l No: Go to Step 6.
6. Record the following information and contact ZTE.
l Configuration data of the local office and peer-end office.
l History alarms, history notifications, and current alarms of the local office and
peer-end office.
2-19
Causes
l The office or route configuration is incorrect.
l The link is broken.
Handling
1. Check whether the static route settings of the destination office are correct.
l Yes: Go to Step 3.
l No: Go to Step 2.
2. Configure or modify related static route. Check whether the alarm disappears.
l Yes: End.
l No: Go to Step 3.
3. Query the status of the link in the route list through the back-end dynamic management
to check whether any link is available.
l Yes: Go to Step 5.
l No: Go to Step 4.
4. Check alarms on the NMS to see whether there are alarms prompting no link available.
l Yes: Handle the alarms by following the alarm handling suggestions in 2.23 MTP3
Link Unavailable (8400129).
l No: Go to Step 5.
5. Record the following information and contact ZTE.
l Configuration data of the local office and peer-end office.
l History alarms, history notifications, and current alarms of the local office and
peer-end office.
2-20
Causes
l The cluster and route configuration is incorrect.
l The link is broken.
Handling
1. Check whether the static route configuration of the cluster is correct.
l Yes: Go to Step 3.
l No: Go to Step 2.
2. Configure or modify related static route. Check whether the cluster is accessible.
l Yes: End.
l No: Go to Step 3.
3. Query the link status in the route table through the dynamic management on NMS to
check whether there are available links.
l Yes: Go to Step 5.
l No: Go to Step 4.
4. Check alarms on the NMS to see whether there are alarms prompting that there are
no available MTP3 links.
l Yes: Handle the alarms by following the alarm handling suggestions in 2.23 MTP3
Link Unavailable (8400129).
l No: Go to Step 5.
5. Back up the following data and contact ZTE.
l Configuration data related to local office and peer-end office.
l History alarms, current alarms, and notifications that are related to the local office
and peer-end office.
Causes
l The association link is released or the AS has not entered serving state, which causes
office inaccessibility.
2-21
l The peer office of the association link reports DUNA (destination signaling point is
unavailable) so that the office is unconnectable.
Handling
1. Check the configuration data to see whether SIO location of the office is configured.
l Yes: Go to Step 3.
l No: Go to Step 2.
2. Configure the SIO location data and check whether the alarm disappears.
l Yes: End.
l No: Go to Step 3.
3. Check the data configuration to see whether the AS corresponding to the SIO location
of the office is activated.
l Yes: Go to Step 6.
l No: Go to Step 4.
4. Check whether ASPs on this AS are activated.
l Yes: If there are ASPs activated on this AS and the number of them exceeds the
necessary number, go to Step 7.
l No: If there is no ASP activated on this AS or the number of activated ASPs does
not reach the necessary number, go to Step 5.
5. Check whether the association of ASP is activated.
l Yes: If the association corresponding to the ASP is activated but the ASP is not
activated, go to Step 6.
l No: If the association corresponding to the ASP is not activated, perform further
handling according to the alarm for association unavailable.
6. Deactivate and then activate the associations serving the office, and check whether
the alarm disappears.
l Yes: End.
l No: Go to Step 7.
7. Back up the following data and contact ZTE.
l Configuration data related to local office and peer office.
l History alarms, current alarms, and notifications that are related to the local office
and peer office.
2-22
Causes
l A signaling point subsystem exits the services.
l The association or AS is not in serving state, which causes signaling point
inaccessibility.
l SSN location AS is not configured.
Handling
1. On the Fault Management view of NMS, check whether there are corresponding
alarms for adjacent office inaccessibility.
l Yes: If there are alarms for SUA office inaccessibility, handle the alarms by
following the alarm handling suggestions in 2.28 SUA Office Inaccessible
(8401153).
l No: Go to Step 2.
2. Check configuration data of the local office to see whether the corresponding
subsystem is configured in local office configuration and adjacent office configuration.
l Yes: Go to Step 4.
l No: Go to Step 3.
3. Configure the subsystem and check whether the alarm disappears.
l Yes: End.
l No: Go to Step 4.
4. Check configuration data of the peer-end adjacent office to see whether the
corresponding subsystem is configured in Local Office Configuration and Adjacent
Office Configuration.
l Yes: Go to Step 6.
l No: Go to Step 5.
5. Contact the personnel of the peer-end office to configure the data. Check whether the
alarm disappears after the peer-end configuring the subsystem.
l Yes: End.
l No: Go to Step 6.
6. Record the following information and contact ZTE.
l Configuration data of the local office and peer-end office.
l History alarms, history notifications, and current alarms of the local office and
peer-end office.
2-23
Causes
l The association or AS is not in serving state, which causes signaling point
inaccessible.
l No SSN location AS to all the subsystems of the office is configured.
Handling
1. Check configuration data to see whether SSN location of the office is configured.
l Yes: Go to Step 3.
l No: Go to Step 2.
2. Configure the SSN location data and check whether the alarm disappears.
l Yes: End.
l No: Go to Step 3.
3. Check the data configuration to see whether the AS corresponding to the SSN location
of the office is activated.
l Yes: Go to Step 6.
l No: Go to Step 4.
4. Check whether ASPs on this AS are activated.
l Yes: If there are ASPs activated on this AS and the number of them exceeds the
necessary number, go to Step 7.
l No: If there is no ASP activated on this AS or the number of activated ASPs does
not reach the necessary number, go to Step 5.
5. Check whether the association of ASP is activated.
l Yes: If the association corresponding to the ASP is activated but the ASP is not
activated, go to Step 6.
l No: If the association corresponding to the ASP is not activated, perform further
handling according to the alarm for association unavailable.
6. Deactivate and then activate the associations serving the office, and check whether
the alarm disappears.
l Yes: End.
l No: Go to Step 7.
7. Record the following information and contact ZTE.
l Configuration data of the local office and peer-end office.
2-24
l History alarms, history notifications, and current alarms of the local office and
peer-end office.
Causes
l The association link is manually released.
l All paths specified in association link configuration are interrupted, or the maximum
retransmission count of the association link is greater than the protocol attribute
configured for the association link.
l Other causes excluding association deletion cause the association interruption. For
specific causes, see additional information of the alarm.
Handling
1. On the Terminal or MML Terminal view of NMS, run the SHOW SCTP command
according to the association link number indicated in the additional alarm information
to check whether the association link configuration is correct. Check whether the
configured local port number, peer port number, IP addresses, and other items are
consistent on both ends, and whether the configured association client and server are
matched.
l Yes: Go to Step 3.
l No: Go to Step 2.
Note:
2-25
2. Run the SET SCTP command to modify the configuration data, synchronize the data,
and then check whether the alarm disappears.
l Yes: End.
l No: Go to Step 3.
3. Check the alarm cause in the additional alarm information, so as to determine whether
the association link is manually blocked.
l Yes: Activate the association link by running ACT LNK command.
l No: Go to Step 4.
4. Check whether there is bottom layer transmission alarm.
l Yes: Forward the problem to a transmission engineer for further handling.
l No: Go to Step 5.
5. Record the following information and contact ZTE.
l Configuration data of the local office and peer-end office.
l History alarms, history notifications, and current alarms of the local office and
peer-end office.
Causes
l The physical link is broken or the link transmission quality degrades.
l A PPP port is created or modified.
l The active board is powered on or the standby board is successfully switched to the
active board.
l Modification of PPP link parameters causes link re-negotiation.
l The peer end of the link initiates negotiation again.
l The ports configured at both ends of the link are not consistent.
2-26
Handling
1. Wait a while and then check whether the system automatically recovers.
l Yes: End.
l No: Go to Step 2.
2. Check the PPP port number in the alarm information. Check whether the cable
between the devices at both ends is disconnected or loose.
l Yes: Go to Step 3.
l No: Go to Step 4.
3. Unplug and plug the cables, or replace the cables. Check whether the alarm
disappears.
l Yes: End.
l No: Go to Step 4.
4. According to your network construction plan, check whether the E1/T1 cable is
incorrectly connected.
l Yes: Go to Step 5.
l No: Go to Step 6.
5. Re-connect the cable according to the network construction plan. Check whether the
alarm disappears.
l Yes: End.
l No: Go to Step 6.
6. Check whether the configuration of the E1/T1 interface is inconsistent with the
configuration of the peer-end equipment connected by the physical cable.
l Yes: Go to Step 7.
l No: Go to Step 8.
7. Modify the configuration to make sure consistency between both ends. Check whether
the alarm disappears.
l Yes: End.
l No: Go to Step 8.
8. Check whether the connection relationship of the PPP ports at both ends is consistent.
l Yes: Go to Step 10.
l No: Go to Step 9.
9. Modify the configuration to make sure that the connection relations of the PPP ports
at both ends is consistent. Observe whether the alarm disappears.
l Yes: End.
l No: Go to Step 10.
10. Contact ZTE.
2-27
Cause
l The BFD session is deleted at the peer end.
l The software for running the BFD session is faulty.
l The physical link where the BFD session runs is faulty.
l The device interface where the BFD session runs is faulty.
l There is congestion or packet loss on the link where the BFD session runs.
Handling
1. Observe the alarm for some time and check whether the alarm automatically
disappears.
l Yes: No handling is required (BFD negotiation failure at the beginning may be
caused by the difference of the time configured at both ends. To further analyze
the fault, go to Step 11).
l No: Go to Step 2.
2. Check whether the physical connection indicators at both the source address interface
and the destination address interface of the BFD session are on.
l Yes: Go to Step 4.
l No: Go to Step 3.
3. Replace the network cable, or check all the network cables on the link where the
BFD session runs and plug them in place. Wait about 30 seconds. And again check
whether the physical connection indicators at both the source address interface and
the destination address interface of the BFD session are on, and whether the alarm
disappears.
l Yes: End.
l No: Go to Step 4.
4. On the Terminal or MML Terminal view of NMS, run the SHOW IP INTERFACE BRIE
F command to check whether the source and destination interfaces of the BFD session
are up.
2-28
l Yes: Go to Step 5.
l No: Go to Step 12.
5. Check the packet transceiving performance statistics of the device where the BFD
session runs by using the performance statistics tool. Check whether the packet flow
between devices is too large and causes congestion or packet loss (there may be
malicious attacks).
l Yes: Go to Step 6.
l No: Go to Step 7.
6. Configure a packet filter policy (according to the actual networking and service
features) on the device to filter out useless packets. Wait about 30 seconds to check
whether the alarm disappears.
l Yes: End.
l No: Go to Step 7.
7. On the Terminal or MML Terminal view of NMS, run the PING command to check
whether the source and destination addresses of the BFD session can be successfully
connected using the ping command from each other.
l Yes: Go to Step 8.
l No: Go to Step 13.
8. Run the corresponding command at the peer end to check whether there is a session
corresponding to the BFD session at the local end.
l Yes: Go to Step 10.
l No: Go to Step 9.
9. Run the corresponding command at the peer end to configure the corresponding BFD
session. wait about 30 seconds to check whether the alarm disappears.
l Yes: End.
l No: Go to Step 10.
10. Check whether the BFD-related configurations were once modified.
l Yes: Go to Step 11.
l No: Go to Step 13.
11. On the Terminal or MML Terminal view of NMS, run the SHOW BFD GLOBAL PROP
command to check whether the BFD session parameter configurations and the BFD
session global configurations are correct according to the BFD configuration manual.
If authentication is configured, the authentication database configurations at both ends
must be consistent. If multiple hops are used, multiple hops should be configured at
both ends. And the BFD global attributes need to be set to Enable.
l Yes: Go to Step 13.
l No: Go to Step 12.
12. Modify incorrect BFD parameters according to the BFD configuration manual. wait
about 30 seconds to check whether the alarm disappears.
l Yes: End.
l No: Go to Step 13.
13. Contact ZTE.
2-29
Causes
l The BFD session is not configured on the peer-end device.
l BFD configurations are incorrect.
l The physical link where the BFD session runs is faulty.
l The device interface where the BFD session runs is faulty.
l There is congestion or packet loss on the link where the BFD session runs.
Handling
1. Observe the alarm for some time and check whether the alarm automatically
disappears.
l Yes: No handling is required (BFD negotiation failure at the beginning may be
caused by the difference of the time configured at both ends. To further analyze
the fault, go to Step 11).
l No: Go to Step 2.
2. Run the corresponding command at the peer end to check whether there is a session
corresponding to the BFD session at the local end.
l Yes: Go to Step 4.
l No: Go to Step 3.
3. Run the corresponding command at the peer end to configure the corresponding BFD
session. wait about 30 seconds to check whether the alarm disappears.
l Yes: End.
l No: Go to Step 4.
4. Run the SHOW BFD GLOBAL PROP command in the Terminal or MML Terminal
view of NMS to check whether the BFD session parameter configurations and the BFD
session global configurations are correct according to the BFD configuration manual.
If authentication is configured, the authentication database configurations at both ends
must be consistent. If multiple hops are used, multiple hops should be configured at
both ends. And the BFD global attributes need to be set to Enable.
2-30
l Yes: Go to Step 6.
l No: Go to Step 5.
5. Modify incorrect BFD parameters according to the BFD configuration manual. wait
about 30 seconds to check whether the alarm disappears.
l Yes: End.
l No: Go to Step 6.
6. Check whether the physical connection indicators at both the source address interface
and the destination address interface of the BFD session are on.
l Yes: Go to Step 8.
l No: Go to Step 7.
7. Replace the network cable, or check all the network cables on the link where the
BFD session runs and plug them in place. wait about 30 seconds. And again check
whether the physical connection indicators at both the source address interface and
the destination address interface of the BFD session are on, and whether the alarm
disappears.
l Yes: End.
l No: Go to Step 8.
8. Run the SHOW IP INTERFACE BRIEF command in the Terminal or MML Terminal
view of NMS to check whether the source and destination interfaces of the BFD session
are up.
l Yes: Go to Step 9.
l No: Go to Step 11.
9. Check the packet transceiving performance statistics of the device where the BFD
session runs by using the performance statistics tool. Check whether the packet flow
between devices is too large and causes congestion or packet loss (there may be
malicious attacks).
l Yes: Go to Step 10.
l No: Go to Step 11.
10. Configure a packet filter policy (according to the actual networking and service
features) on the device to filter out useless packets. wait about 30 seconds to check
whether the alarm disappears.
l Yes: End.
l No: Go to Step 11.
11. Contact ZTE.
2-31
Causes
l Hardware faults. For example, the external interface of the local or peer device on the
connection is down, the intermediate switching device is down, or the transmission
line is faulty.
l Bearer network communication failure. For example, the external interface of the local
or peer device is faulty, the intermediate device is faulty physically, the route is faulty,
or the bearer link is faulty.
l Configuration errors. For example, the route or interface address of the local or peer
device has changed.
l Device faults. For example, the control plane path inside the NE of the local or peer
device is interrupted.
Handling
1. Check whether there is serious loss of packets on the physical link (by using command
ping).
l Yes: Go to Step 2.
l No: Go to Step 3.
2. Solve the physical link problem, and check whether the alarm disappears.
l Yes: End.
l No: Go to Step 3.
3. On the Fault Management view of NMS, check whether there is any alarm for broken
control-plane link on the module which this association belongs to.
l Yes: Go to Step 6.
l No: Go to Step 4.
4. Check whether the peer-end device of the association link is faulty.
l Yes: Go to Step 5.
l No: Go to Step 6.
5. Check whether the alarm disappears after confirming that the peer-end device is
normal.
l Yes: End.
l No: Go to Step 6.
6. Contact ZTE.
2-32
Causes
l Packets are discarded by intermediate devices, and as a result the bearer network
may be unavailable.
l Packets are discarded in a certain network segment, and as a result the bearer
network may also be unavailable.
Handling
1. Ping the address of the other end from each end to check whether packets are
consecutively discarded.
l Yes: Go to Step 2.
l No: Go to Step 10.
2. On the Terminal or MML Terminal view of NMS, run the Trace command to check
and remove the fault of the bearer network with reference to the following table.
2-33
Causes
l Packet loss occurs on any intermediate device.
l Packet loss occurs on a section of environment between both ends.
Handling
1. Check whether any intermediate device is faulty:
l Yes: Go to Step 4.
l No: Go to Step 2.
2. Check whether network ports of the board work properly:
l Yes: Contact ZTE.
l No: Go to Step 3.
3. Check whether any hardware reason causes failure of network ports:
l Yes: Go to Step 4.
l No: Contact ZTE.
4. Replace the faulty device and check whether the link is normal:
l Yes: End.
2-34
l No: Go to Step 2.
Causes
l The bottom-layer physical transmission fails.
l The link initiated by the peer end is broken.
l Too many protocol-unmatched messages or error packets are received.
Handling
1. Check whether the link data is newly configured or already modified.
l Yes: Go to Step 2.
l No: Go to Step 4.
2. Check the configuration of link data is consistent, especially the VPI and VCI of both
ends and the connecting ports.
l Yes: Go to Step 4.
l No: Go to Step 3.
3. Modify the configuration and check whether the alarm disappears.
l Yes: End.
l No: Go to Step 4.
4. Check whether the bottom-layer transmission incurs any alarm.
l Yes: Deliver this problem to transmission engineers for handling.
l No: Go to Step 5.
5. Perform physical self-loop operations on the DDF for the devices at both ends of the
link. Check whether the link self-loop alarm disappears.
l Yes: Check the bottom-layer transmission and deliver the problem to transmission
engineers for handling.
l No: Go to Step 6.
6. Record the detailed information and contact ZTE.
l Back up related configuration data of the local and peer offices.
l Back up related history alarms, history notifications, and current alarms of the
local and peer offices.
2-35
Cause
The physical link is disconnected.
Handling
Check the physical link to the specified node.
Cause
The OMM server detects that all the links between the node and the OMM server are
abnormal.
Handling
1. Check whether the physical connection between the disconnected node and the OMM
server is normal.
l Yes: Go to Step 3.
l No: Go to Step 2.
2-36
2. Check whether the alarm disappears after confirming that the physical connection is
normal.
l Yes: End.
l No: Go to Step 3.
3. On the Terminal or MML Terminal view of NMS, run the SHOW OMPLNKSTAT
command to check whether the IP address and port of the node configured on the
OMM server have been occupied.
l Yes: Go to Step 4.
l No: Go to Step 5.
4. On the Terminal or MML Terminal view of NMS, run the SET OMP command to
recreate OMM socket links, and then delete the wrongly configured link using the
DELETE OMSLINK command. After that, check whether the alarm disappears.
l Yes: End.
l No: Go to Step 5.
5. Contact ZTE.
Cause
The communication link between the alarm box and the OMM server is broken.
Handling
1. Check whether the physical connection between the disconnected node and the OMM
server is normal.
l Yes: Go to Step 3.
l No: Go to Step 2.
2. Check whether the alarm disappears after confirming that the physical connection is
normal.
l Yes: End.
l No: Go to Step 3.
3. On the Terminal or MML Terminal view of NMS, run the SHOW ALARMBOX
command to check whether the service-end monitoring port configured on the OMM
2-37
server is occupied, whether the alarm box address is consistent with that set on the
OMM server, and whether the alarm box address is not occupied.
l Yes: Go to Step 4.
l No: Go to Step 5.
4. On the Terminal or MML Terminal view of NMS, run the SET ALARMBOX command
to modify the alarm box port settings, and then check whether the alarm disappears.
l Yes: End.
l No: Go to Step 5.
5. Determine whether this alarm needs to be temporarily ignored.
l Yes: Go to Step 6.
l No: Go to Step 7.
6. On the Terminal or MML Terminal view of NMS, run the SET ALARMBOX command
to set Status to NO in the alarm settings of the OMM server, and then check whether
the alarm disappears.
l Yes: End.
l No: Go to Step 7.
7. Contact ZTE.
2-38
3-1
Cause
The following factors may result in an excessively high CPU rate:
l Data has been synchronized and saved.
l The version has been upgraded and it is necessary to save the upgraded version.
l The board has been restarted. It needs to be initialized, obtain data, and synchronize
data before entering the working status again.
3-2
Handling
l A board where the OMP or other module is deployed
1. Make sure whether data synchronization, saving and version upgrade operations
are performed, or the device is restarted before the alarm.
à Yes: Go to Step 2.
à No: Go to Step 3.
2. Wait 2 to 3 minutes to check whether the alarm disappears.
à Yes: End.
à No: Go to Step 3.
3. Confirm the board with an excessively high CPU rate according to the physical
location of the alarm information, and determine whether the high CPU rate is
caused by exceptions according to the three processes with the highest CPU rate
as indicated in the alarm information.
à Yes: Go to Step 7.
à No: Go to Step 4.
4. On the Terminal or MML Terminal view of NMS, run the SHOW CPUTHR
command to check the CPU rate threshold information and determine whether
the alarm is caused because the threshold value is too small.
à Yes: Go to Step 5.
à No: Go to Step 6.
5. Run the SET CPUTHR command under the guidance of ZTE technical support
personnel to reset the CPU rate threshold, and then check whether the alarm
disappears.
à Yes: End.
à No: Go to Step 6.
6. Contact ZTE technical support personnel to adjust the service structure and
migrate some of the services on the boards with an excessively high CPU rate to
other boards, and then check whether the alarm disappears.
à Yes: End.
à No: Go to Step 7.
3-3
7. Contact ZTE.
l A board where the CMM module is deployed.
1. Make sure whether data synchronization, saving and version upgrade operations
are performed, or the device is restarted before the alarm.
à Yes: Go to Step 2.
à No: Go to Step 3.
2. Wait 2 to 3 minutes, and then check whether the alarm disappears.
à Yes: End.
à No: Go to Step 3.
3. The board processing capability does not meet the requirements. Contact ZTE
technical support personnel in time to reduce the system capacity or add boards.
Causes
The configuration of system bureau is changed.
Handling
Restart the system, wait 30 seconds, check if the alarm is eliminated.
l Yes: End.
l No: Record the alarm information and contact ZTE.
3-4
l Alarm description: The data set through OMP itself is conflicting with the data set
through CMM.
Causes
l A slot is set to the OMP on the CMM, but the slot is not set to the OMP in the OMP
database.
l A slot is not set to the OMP on the CMM, but the slot is set to OMP in the OMP
database.
Handling
Re-configure the physical address of the OMP on the OMP, or re-configure data on the
CMM according to the physical address configured on the OMP. Restart the OMP.
l Yes: End.
l No: Contact ZTE.
Cause
The version information returned by the version server is incomplete.
Handling
Check the version server logs to find the missing version, and then add and activate the
version.
3-5
Cause
The system fails to download a version from the version server.
Handling
1. Check the logs of the board to find the version that failed to be downloaded, and then
check whether there is the version file on the version server.
l Yes: Go to Step 3.
l No: Go to Step 2.
2. Add the version file, download the version again, and then check whether the alarm
disappears.
l Yes: End.
l No: Go to Step 3.
3. Check whether the communications are normal.
l Yes: Go to Step 4.
l No: Ensure that the communications are normal.
4. Contact ZTE.
Cause
A process fails to be started.
3-6
Handling
Check the logs of the board, and then handle the alarm according to the error code
indicating the process start failure.
Cause
The local continuity check times out.
Handling
1. Activate the peer-end CC or the peer end sends data, make the local end receive user
signal or CC signal, and observe whether the alarm disappears.
l Yes: End.
l No: Go to Step 2.
2. Deactivate the local CC and observe whether the alarm disappears.
l Yes: End.
l No: Go to Step 3.
3. Delete PVC and check whether the alarm disappears.
l Yes: End.
l No: Go to Step 4.
4. Contact ZTE.
3-7
Cause
Since the group parameters configured in the near-end IMA group does not match with
that configured in the remote IMA group and the IMA configuration parameters sent by the
remote end through ICP cells are rejected. The system comes into Config_Aborted status.
Handling
1. Check whether the IMA group parameters configured on both the near end and remote
end are correct and match with each other.
l Yes: Go to Step 3.
l No: Go to Step 2.
2. Modify the IMA group parameters, and check whether the alarm disappears.
l Yes: End.
l No: Go to Step 3.
3. Contact ZTE.
Causes
l The database does not respond to the configuration requests from the EPU or RPU.
l The database responds with incorrect contents.
l The information sent by the EPU or RPU to the database is lost.
l The communication fails at the control plane.
3-8
Handling
1. Check whether the RPU is restarting when the EPU registers to the RPU.
l Yes: No need to handle it.
l No: Go to Step 2.
2. Check whether system control of this board and the MP of the configuration provider
is normal, and whether the communication with them is normal.
l Yes: Go to Step 5.
l No: Go to Step 3.
3. Remove and then insert the board to perform hardware reset. Check whether the
alarm disappears.
l Yes: End.
l No: Go to Step 4.
4. Replace the faulty board. Check whether the alarm disappears.
l Yes: End.
l No: Go to Step 5.
5. Contact ZTE.
Cause
The board has too many alarm messages. As a result, the alarm pool for storing alarm
messages is full.
Handling
1. On the Fault Management view of NMS, check whether there are plenty of alarms
about the board.
l Yes: Go to Step 2.
l No: Go to Step 3.
3-9
2. Remove all other alarms except for the alarm according to the suggestions on board
alarm handling, wait about three to five minutes, and then check whether the alarm
disappears.
l Yes: End.
l No: Go to Step 3.
3. Contact ZTE.
Cause
Connection check is not enabled after the command for disabling connection check is run.
Handling
Log in to the board and run the ppenableconncheck command to check the connection.
Cause
The local Ethernet port is in loopback state because the Ethernet OAM loopback function
is enabled at the peer end.
3-10
Handling
1. Check the Ethernet OAM configurations at the peer end, and determine whether the
Ethernet OAM loopback function is enabled at the peer end.
l Yes: Go to Step 2.
l No: Go to Step 3.
2. Disable the Ethernet OAM loopback function at the peer end after the loopback test is
over, and then check whether the alarm disappears.
l Yes: End.
l No: Go to Step 3.
3. Contact ZTE.
Cause
l The NTP server time is inaccurate. As a result, the time deviation from the system
time in the foreground exceeds the set alarm threshold.
l The NTP server time has been adjusted. As a result, the time deviation from the
system time in the foreground exceeds the set alarm threshold.
l The crystal oscillator of the OMP or CMM cannot maintain high precision.
Handling
1. If the alarm occurs on the CMM, open the Terminal or MML Terminal view of NMS,
and run the SET ENTPCFG command to change the clock synchronization Error
Threshold(ms) of the CMM to 0 to cancel such alarms.
2. If the alarm occurs on the OMP, open the Terminal or MML Terminal view of
NMS and run the SET SNTP command to change the clock synchronization Error
Threshold(ms) of the OMP to 0 to cancel such alarms.
3. Check whether the NTP server time is accurate.
l Yes: On the Terminal or MML Terminal view of NMS, run the SYN SNTPTIME
command to initiate forced clock synchronization.
l No: Go to Step 4.
4. Adjust the NTP server time, so that the NTP server time is accurate.
3-11
5. Check whether the NTP server time was once adjusted near the time of alarm
occurrence.
l Yes: The alarm is normal. If the alarm still exists after a clock synchronization
interval, go to Step 7.
l No: Go to Step 5.
6. Reset the clock synchronization interval of the foreground system, ensuring that it is
shorter than the current clock synchronization interval. After a clock synchronization
interval, and then check whether the alarm disappears.
l Yes: End.
l No: Go to Step 7.
7. Contact ZTE.
Cause
The system fails to request time information from the SNTP server.
Handling
1. Check whether the configurations of the SNTP server are correct and whether the
SNTP server works properly.
l Yes: Go to Step 3.
l No: Go to Step 2.
2. Reconfigure correct SNTP server information, perform a forced synchronization
operation, and then check whether the alarm disappears.
l Yes: End.
l No: Go to Step 3.
3. Record the alarm information, and contact ZTE.
3-12
Causes
l Services are busy.
l Link loads are not homogeneous.
l The quality of bottom-layer physical transmission is poor.
l The link bandwidth is insufficiently configured.
Handling
1. Wait 30 seconds until the system automatically recovers. Check whether the alarm
disappears.
l Yes: End.
l No: Go to Step 2.
2. Check whether the current service is busy.
l Yes: Go to Step 3.
l No: Go to Step 6.
3. Check whether the link configuration is sufficient.
l Yes: Go to Step 4.
l No: Go to Step 5.
4. Check whether link loads are homogeneous.
l Yes: Go to Step 1.
l No: Go to Step 7.
5. Add the link configuration. Check whether the alarm disappears.
l Yes: End.
l No: Go to Step 4.
6. If the link configuration is not modified, check whether the bottom-layer transmission
incurs any alarm.
l Yes: Deliver this problem to transmission engineers for handling.
l No: Go to Step 7.
7. Record the following information and contact ZTE.
l Configuration data of the local office and peer-end office.
l History alarms, history notifications, and current alarms of the local office and
peer-end office.
3-13
Causes
l Services are busy.
l Link loads are not homogeneous.
l The quality of bottom-layer physical transmission is poor.
l The link bandwidth is insufficiently configured.
Handling
1. Wait 30 seconds until the system automatically recovers. Check whether the alarm
disappears.
l Yes: End.
l No: Go to Step 2.
2. Check whether the current service is busy.
l Yes: Go to Step 3.
l No: Go to Step 6.
3. Check whether the link configuration is sufficient.
l Yes: Go to Step 4.
l No: Go to Step 5.
4. Check whether link loads are homogeneous.
l Yes: Go to Step 1.
l No: Go to Step 7.
5. Add the link configuration. Check whether the alarm disappears.
l Yes: End.
l No: Go to Step 4.
6. If the link configuration is not modified, check whether the bottom-layer transmission
incurs any alarm.
l Yes: Deliver this problem to transmission engineers for handling.
l No: Go to Step 7.
7. Record the following information and contact ZTE.
l Configuration data of the local office and peer-end office.
3-14
l History alarms, history notifications, and current alarms of the local office and
peer-end office.
Causes
l Heavy traffic.
l Uneven load among links.
l Insufficient link resource.
Handling
1. Make no manual intervention and just wait until the system recovers. 30 seconds later,
check whether the alarm disappears.
l Yes: End.
l No: Go to Step 2.
2. Check whether the system has heavy traffic.
l Yes: Go to Step 3.
l No: Go to Step 6.
3. Check whether the link resource is sufficient.
l Yes: Go to Step 4.
l No: Go to Step 5.
4. Query performance statistic data to check whether load is evenly shared among links.
l Yes: Go to Step 1.
l No: Go to Step 6.
5. Add new links and check whether the alarm disappears.
l Yes: End.
l No: Go to Step 4.
6. Record the following information and contact ZTE.
l Configuration data of the local office and peer-end office.
l History alarms, history notifications, and current alarms of the local office and
peer-end office.
3-15
Cause
The sending load on the MTP3 link exceeds the threshold of sending flow control.
Handling
1. Wait 30 seconds until the system automatically recovers. Check whether the alarm
disappears.
l Yes: End.
l No: Go to Step 2.
2. Check whether the current service is busy.
l Yes: Go to Step 3.
l No: Go to Step 6.
3. Check whether the link configuration is sufficient.
l Yes: Go to Step 4.
l No: Go to Step 5.
4. Check whether loads are homogeneous on the link.
l Yes: Go to Step 1.
l No: Go to Step 6.
5. Add link configuration. Check whether the alarm disappears.
l Yes: End.
l No: Go to Step 4.
6. Record the following information and contact ZTE.
l Configuration data of the local office and peer-end office.
l History alarms, history notifications, and current alarms of the local office and
peer-end office.
3-16
Cause
Too many NE alarms exist. The number of NE alarms exceeds the threshold of the NE
alarm pool.
Handling
1. On the Fault Management view of NMS, check whether there are plenty of NE alarms.
l Yes: Go to Step 2.
l No: Go to Step 3.
2. Remove all other alarms except for the alarm according to the suggestions on NE
alarm handling, wait about three to five minutes, and then check whether the alarm
disappears.
l Yes: End.
l No: Go to Step 3.
3. Contact ZTE.
Cause
The board has too many alarm messages. As a result, the alarm pool for storing alarm
messages is full.
3-17
Handling
1. On the Fault Management view of NMS check whether there are plenty of alarms
about the board.
l Yes: Go to Step 2.
l No: Go to Step 3.
2. Remove all other alarms except for the alarm according to the suggestions on board
alarm handling, wait about three to five minutes, and then check whether the alarm
disappears.
l Yes: End.
l No: Go to Step 3.
3. Contact ZTE.
Cause
The function of password expiry alert is enabled in the inner account password policy,
and the value of Days Before The Password Is Invalid is not 0. The time since the
administrator's last modification of an inner account password reaches the time for
password expiry alert.
Note:
The Password Valid Day of an inner account can be queried with the SHOW ACCOUNT
INFO command in the Terminal or MML Terminal view of NMS.
3-18
Handling
1. On the Terminal or MML Terminal view of NMS, run the SHOW PASSWDTACTIC
command to check whether Need To Send Alarm When Invalid is set to Yes in the
inner account password policy of the system.
l Yes: Go to Step 2.
l No: Go to Step 9.
2. Confirm whether it is necessary to set a password expiry alert policy. For example,
it is recommended that a password expiry alert policy be set in a public network
environment.
l Yes: Go to Step 4.
l No: Go to Step 3.
3. On the Terminal or MML Terminal view of NMS, run the SET PASSWDTACTIC
command to change the settings of Need To Send Alarm When Invalid to No, and
then check whether the alarm disappears.
l Yes: End.
l No: Go to Step 7.
4. Confirm whether to send the alert only at the time of password expiry.
l Yes: Go to Step 5.
l No: Go to Step 6.
5. On the Terminal or MML Terminal view of NMS, run the SET ACCOUNTPASSWD
command to change the value of Days Before The Password Is Invalid to 0, and
then check whether the alarm disappears.
l Yes: End.
l No: Go to Step 6.
6. Check whether it is the first time to change the inner account password.
l Yes: Go to Step 7.
l No: Go to Step 8.
Caution!
The SET ACCOUNTPASSWD command is dangerous. Do not perform any other
OMM operations while changing the inner account password with this command.
7. On the Terminal or MML Terminal view of NMS, run the SET ACCOUNTPASSWD
command to change the inner account password (the initial password is the account
name), wait about 30 seconds, and then check whether the alarm disappears.
l Yes: End.
l No: Go to Step 9.
8. On the Terminal or MML Terminal view of NMS, run the SET ACCOUNTPASSWD
command to change the inner account password, wait about 30 seconds, and then
check whether the alarm disappears.
l Yes: End.
l No: Go to Step 9.
3-19
9. Contact ZTE.
Cause
The function of password expiry alert is enabled in the inner account password policy, and
the administrator does not change the inner account password within the validity period of
the password.
Handling
1. On the Terminal or MML Terminal view of NMS, run the SHOW PASSWDTACTIC
command to check whether Need To Send Alarm When Invalid is set to Yes in the
inner account password policy of the system.
l Yes: Go to Step 2.
l No: Go to Step 7.
2. Confirm whether it is necessary to set a password expiry alert policy. For example,
it is recommended that a password expiry alert policy be set in a public network
environment.
l Yes: Go to Step 4.
l No: Go to Step 3.
3. On the Terminal or MML Terminal view of NMS, run the SET PASSWDTACTIC
command to change the settings of Need To Send Alarm When Invalid to No, and
then check whether the alarm disappears.
l Yes: End.
l No: Go to Step 7.
4. Check whether it is the first time to change the inner account password.
l Yes: Go to Step 5.
l No: Go to Step 6.
5.
3-20
Caution!
The SET ACCOUNTPASSWD command is dangerous. Do not perform any other
OMM operations while changing the inner account password with this command.
On the Terminal or MML Terminal view of NMS, run the SET ACCOUNTPASSWD
command to change the inner account password (the initial password is the account
name), wait about 30 seconds, and then check whether the alarm disappears.
l Yes: End.
l No: Go to Step 7.
6. On the Terminal or MML Terminal view of NMS, run the SET ACCOUNTPASSWD
command to change the inner account password, wait about 30 seconds, and then
check whether the alarm disappears.
l Yes: End.
l No: Go to Step 7.
7. Contact ZTE.
Causes
l The password of an inner account is shorter than the Min Length Of The Password
specified in the inner account password policy.
l The password of an inner account is longer than the Max Length Of The Password
specified in the inner account password policy.
l A password complexity policy is enabled in the inner account password policy, but
the password of an inner account does not meet the requirements of the password
complexity policy.
l The password of an inner account is the same as an old password of Password
Repeat Count set in the inner account password policy.
3-21
Handling
1. On the Terminal or MML Terminal view of NMS, run the SHOW PASSWDTACTIC
command to check the settings of Min Length Of The Password, Max Length Of
The Password, Weak Password Check, and Password Repeat Count in the inner
account password policy of the system, and confirm whether the settings meet the
password policy requirements.
l Yes: Go to Step 3.
l No: Go to Step 2.
Caution!
The SET ACCOUNTPASSWD command is dangerous. Do not perform any other
OMM operations while changing the inner account password with this command.
2. On the Terminal or MML Terminal view of NMS, run the SET ACCOUNTPASSWD
command to modify the inner account password (the initial password is the account
name if it is the first time to modify the password), enter an inner account password
meeting the password policy requirements, and then check whether the alarm
disappears.
l Yes: End.
l No: Go to Step 3.
3. Contact ZTE.
Cause
The user-input password is wrong for three consecutive times.
3-22
Handling
1. Check the user name and login IP address indicated in the alarm information, and then
determine whether any illegal user is waging malicious attacks to the system.
l Yes: Go to Step 2.
l No: Go to Step 3.
2. Set a complex password to prevent the account information from being disclosed and
to periodically change the password.
3. Log in using the correct user password.
Cause
This alarm is reported when you restart the NMS or load a License file that is illegal. A
License file is illegal in the following conditions:
l The user information in the License file is inconsistent with the License file name
(excluding the suffix).
l The MAC address in the License file cannot match with any of the MAC addresses of
the network adapters on the current NMS server.
l The text format of the License file is illegal, and the License file is not generated by
the license tool.
Handling
1. Contact ZTE technical support personnel to make a new License file.
3-23
Cause
There is no license file in the $ZXHOME/$NE/server/conf/license directory.
Note:
The license file is suffixed with ".lic" or ".LCS".
Handling
1. Contact ZTE to purchase a license file.
2. Place the new license file into the $ZXHOME/$NE/server/conf/license directory,
restart the NMS or load the license file, and then check whether the alarm disappears.
l Yes: End.
l No: Go to Step 3.
3. Contact ZTE.
3-24
Cause
There are multiple license files in the $ZXHOME/$NE/server/conf/license directory.
Note:
A license file is suffixed with ".lic" or ".LCS".
Handling
1. Delete the excessive license files in the $ZXHOME/$NE/server/conf/license
directory on the NMS server, so that there is only one license file in the directory.
2. Restart the NMS or reload the license file, and then check whether the alarm
disappears.
l Yes: End.
l No: Go to Step 3.
3. Contact ZTE.
Cause
If a user attempts to log in from a client to the NMS after the license file loaded into the
NMS expires, this alarm is triggered. This alarm will also be triggered at 5:00 pm on the
next day after the license file loaded into the system expires.
3-25
Handling
1. Contact ZTE technical support personnel to update the license file.
2. Place the new license file into the $ZXHOME/$NE/server/conf/license directory,
restart the NMS or load the license file, and then check whether the alarm disappears.
l Yes: End.
l No: Go to Step 3.
3. Contact ZTE.
Causes
l The agent log database connection fails.
l SQLite connection processing is abnormal.
Handling
Check whether the agent log database is normal.
Causes
l The user fails to log in to the FTP/SFTP server.
l The FTP/SFTP server connection fails.
l The FTP/SFTP server user has no the required permission.
l The communications with the server fail.
l The server hard disk space is insufficient.
3-26
Handling
Check whether the agent log server is available.
Cause
A physical memory maybe unusable.
Handling
Replace the physical memory.
Cause
A physical memory may be unusable.
Handling
Replace physical memories.
3-27
Cause
l The services are busy.
l Some NEs cannot be connected.
l Some links get congested.
Handling
Check the link status or configuration.
Cause
Uncertain cause.
Handling
No handling is needed.
3-28
Cause
DBIO failed to update the configuration memory DB.
Handling
It can make agent password difference between OMM and DBIO. To solve this problem,
you should send agent configuration data to DBIO from OMM Client.
Cause
The number of subscribers exceeds the administration domain capacity.
Handling
Expand capacity to increase the subscriber capacity.
3-29
Cause
The number of users exceeds the administrative domain capacity.
Handling
l Expand the user capacity of the administrative domain.
l Delete certain users from the administrative domain.
Causes
l A major fault occurs on the active ZXUN USPP (HLR) in DRSync disaster recovery
mode. The device cannot continue normal operation and has disconnected from the
network automatically. The fault may be caused by the following factors:
à Eighty percent of the service processing modules in the active ZXUN USPP (HLR)
are not powered on or are exceptional. They cannot process most of the signaling
service requests.
3-30
Handling
1. Run the SHOW DR STATE command in the Terminal or MML Terminal view of NMS
of the standby ZXUN USPP (HLR), and check whether the standby ZXUN USPP (HLR)
is in Take Overed status.
l Yes: The standby ZXUN USPP (HLR) is in takeover status, and it can process
service requests from signaling links and process transactions. ZXUN USPP
(HLR) runs in standby mode without impacting services.
l No: Go to Step 2.
Caution!
The next step is risky. Contact ZTE technical support personnel for confirmation
before operation.
2. On the Terminal or MML Terminal view of NMS of the standby ZXUN USPP (HLR)
(if there are multiple standby ZXUN USPP (HLR)s, select the one with the same
number as that queried with the SHOW DR STATE command on the OMM of the
active ZXUN USPP (HLR)), run the TAKE OVER command to initiate the takeover of
the standby ZXUN USPP (HLR) immediately, and set the ZXUN USPP (HLR) to the
standby working mode.
3-31
3. The standby working mode is a temporary running status of the ZXUN USPP (HLR).
It is necessary to check the fault of the active ZXUN USPP (HLR) immediately and
contact ZTE technical support personnel to assist in fault troubleshooting of the active
ZXUN USPP (HLR).
Caution!
The next step is risky. Contact ZTE technical support personnel for confirmation before
operation.
4. After the fault is cleared from the active ZXUN USPP (HLR), run the RECLAIM
command on the Terminal or MML Terminal view of NMS of the active ZXUN USPP
(HLR) to conduct manual reclamation. Check whether the reclamation operation
succeeds.
l Yes: Go to Step 5.
l No: The external signaling link fault is not cleared completely. It is necessary to
clear the fault completely before performing reclamation operation.
5. On the Terminal or MML Terminal view of NMS of the active ZXUN USPP (HLR), run
the SHOW DR STATE command to check whether the active ZXUN USPP (HLR) is
in Not Fail Overed status. Make sure the device runs in active mode.
Caution!
The next step is risky. Contact ZTE technical support personnel for confirmation before
operation.
6. On the Terminal or MML Terminal view of NMS of the standby ZXUN USPP (HLR) (if
there are multiple standby ZXUN USPP (HLR)s, select the one with the same number
as that queried with the SHOW DR STATE command on the OMM of the active ZXUN
USPP (HLR)), run the GIVE BACK command to manually give back the standby ZXUN
USPP (HLR) and stop the standby ZXUN USPP (HLR).
3.39 HLR Can Provide Service for Other NEs, the Links
to Other NEs Are Unblocked. The BOSS Request
Has Been Permitted (2534031361)
Alarm Information
l Alarm code: 2534031361
l System type: NE alarm
3-32
Cause
In DRSync disaster recovery mode, run the RECLAIM command on the Terminal or MML
Terminal view of NMS to manually instruct the surveillance center to reclaim the active
ZXUN USPP (HLR). The active ZXUN USPP (HLR) responds to the manual reclamation
request of the operator and the reclamation operation succeeds.
Handling
1. On the Terminal or MML Terminal view of NMS of the standby ZXUN USPP (HLR),
run the SHOW DR STATE command to check whether the standby ZXUN USPP (HLR)
is in Not Take Overed status.
l Yes: The standby ZXUN USPP (HLR) is disabled, and the ZXUN USPP (HLR)
device runs in active mode.
l No: Go to Step 2.
Caution!
The next step is risky. Contact ZTE technical support personnel for confirmation
before operation.
2. If the standby ZXUN USPP (HLR) is in Take Overed status, it indicates the active
and standby ZXUN USPP (HLR)s are running. It is necessary to run the GIVE BACK
command on the Terminal or MML Terminal view of NMS of the standby ZXUN USPP
(HLR) (if there are multiple standby ZXUN USPP (HLR)s, select the one with the same
number as that queried with the SHOW DR STATE command on the OMM of the active
ZXUN USPP (HLR)) to give back the standby ZXUN USPP (HLR) back and stop the
standby ZXUN USPP (HLR).
3. Check whether there is any other exception on the active ZXUN USPP (HLR) and
whether all the faults are cleared. If there is an abnormal alarm, contact ZTE.
3-33
Causes
l In DRSync disaster recovery mode, run the TAKE OVER command in the Terminal
or MML Terminal view of NMS to manually instruct the surveillance center to initiate
the takeover of the standby ZXUN USPP (HLR). The standby ZXUN USPP (HLR)
responds to the manual takeover request of the operator and the takeover operation
succeeds.
l In DRSync disaster recovery mode, the external signaling link of the active ZXUN
USPP (HLR) is faulty, and service request messages cannot be sent to the signaling
service processing board of the active ZXUN USPP (HLR). The external NE enables
the standby route mode to send service request messages to the standby ZXUN
USPP (HLR). The standby ZXUN USPP (HLR) not yet taken over detects that the
service message flow reaches the preset threshold within the preset time, and
then automatically triggers takeover to ensure the success of the signaling service
requests.
Handling
1. On the Terminal or MML Terminal view of NMS of the active ZXUN USPP (HLR), run
the SHOW DR STATE command to check whether the active ZXUN USPP (HLR) is
in Fail Overed status.
l Yes: The active ZXUN USPP (HLR) is in Fail Overed status, all the external
signaling links are disconnected, all signaling service requests are forwarded
to the standby office for processing, transaction operations are disabled, and
3-34
transaction requests are forwarded to the standby office for processing. The
ZXUN USPP (HLR) runs in standby mode without impacting services.
l No: Go to Step 2.
Caution!
The next step is risky. Contact ZTE technical support personnel for confirmation before
operation.
2. On the Terminal or MML Terminal view of NMS of the active ZXUN USPP (HLR),
run the FAIL OVER command to manually fail over the active ZXUN USPP (HLR)
immediately, and set the ZXUN USPP (HLR) to standby mode.
3. The standby mode is a temporary running status of the ZXUN USPP (HLR). It is
necessary to check the fault of the active ZXUN USPP (HLR) immediately and contact
ZTE technical support personnel to assist in fault troubleshooting of the active ZXUN
USPP (HLR).
Caution!
The next step is risky. Contact ZTE technical support personnel for confirmation before
operation.
4. After the fault is cleared from the active ZXUN USPP (HLR), run the RECLAIM
command on the Terminal or MML Terminal view of NMS of the active ZXUN USPP
(HLR) to conduct manual reclamation. Check whether the reclamation operation
succeeds.
l Yes: Go to Step 5.
l No: The external signaling link fault is not cleared completely. It is necessary to
clear the fault completely before performing reclamation operation.
5. On the Terminal or MML Terminal view of NMS of the active ZXUN USPP (HLR), run
the SHOW DR STATE command to check whether the active ZXUN USPP (HLR) is
in Not Fail Overed status. Make sure the device runs in active mode.
Caution!
The next step is risky. Contact ZTE technical support personnel for confirmation before
operation.
6. On the Terminal or MML Terminal view of NMS of the standby ZXUN USPP (HLR) (if
there are multiple standby ZXUN USPP (HLR)s, select the one with the same number
3-35
as that queried with the SHOW DR STATE command on the OMM of the active ZXUN
USPP (HLR)), run the GIVE BACK command to manually give back the standby ZXUN
USPP (HLR) and stop the standby ZXUN USPP (HLR).
Cause
In DRSync disaster recovery mode, run the GIVE BACK command in the Terminal or
MML Terminal view of NMS to manually instruct the surveillance center to switch back
the standby ZXUN USPP (HLR). The active ZXUN USPP (HLR) responds to the manual
giveback request of the operator and the switchback operation succeeds.
Handling
1. On the Terminal or MML Terminal view of NMS of the active ZXUN USPP (HLR), run
the SHOW DR STATE command to check whether the active ZXUN USPP (HLR) is
in Not Fail Overed status.
l Yes: The active ZXUN USPP (HLR) is normal and can process service signaling
requests and transaction data. The ZXUN USPP (HLR) device is running in active
mode, and everything is normal.
l No: Go to Step 2.
2. Check whether the active ZXUN USPP (HLR) is abnormal and whether all the faults
are cleared. If there is an abnormal alarm, contact ZTE technical support personnel
immediately for help.
3-36
Caution!
The next step is risky. Contact ZTE technical support personnel for confirmation before
operation.
3. After the fault is cleared from the active ZXUN USPP (HLR), run the RECLAIM
command on the Terminal or MML Terminal view of NMS of the active ZXUN
USPP (HLR) to manually reclaim the active ZXUN USPP (HLR). Check whether the
reclamation operation succeeds.
l Yes: End.
l No: Go to Step 3.
4. If the active ZXUN USPP (HLR) is still in Fail Overed status, initiate the takeover of
the standby ZXUN USPP (HLR), and restore the ZXUN USPP (HLR) to the standby
working mode to ensure normal service and transaction.
5. The standby working mode is a temporary running status of the ZXUN USPP (HLR).
Contact ZTE immediately.
Cause
A major fault occurs on the active ZXUN USPP (HLR) in DRSync disaster recovery mode.
The device cannot continue normal operation. It attempts to automatically disconnect from
the network, but it fails to disconnect and is still running. The major fault may be caused
by the following:
l Eighty percent of the service processing modules in the active ZXUN USPP (HLR)
are not powered on or are exceptional. They cannot process most of the signaling
service requests.
l Database operations of eighty percent of the service processing modules in the active
ZXUN USPP (HLR) fail, and the failure count reaches the preset threshold within the
preset time.
3-37
l Service message sending of eighty percent of the service processing modules in the
active ZXUN USPP (HLR) fails, and the failure count reaches the preset threshold
within the preset time.
Handling
Caution!
The next step is risky. Contact ZTE technical support personnel for confirmation before
operation.
1. To ensure normal service and transaction, it is necessary to set the ZXUN USPP (HLR)
to standby mode.
a. On the Terminal or MML Terminal view of NMS of the active ZXUN USPP (HLR),
run the FAIL OVER command to manually switch the active ZXUN USPP (HLR)
to the failover status.
b. On the Terminal or MML Terminal view of NMS of the standby ZXUN USPP (HLR)
(if there are multiple standby ZXUN USPP (HLR)s, select the one with the same
number as that queried with the SHOW DR STATE command on the OMM of the
active ZXUN USPP (HLR)), run the TAKE OVER command to manually switch
the standby ZXUN USPP (HLR) to the takeover status.
2. The standby working mode is a temporary running status of ZXUN USPP (HLR). It is
necessary to check the fault of the active ZXUN USPP (HLR) immediately and contact
ZTE technical support personnel to assist in major fault troubleshooting of the active
ZXUN USPP (HLR).
3-38
Caution!
The next step is risky. Contact ZTE technical support personnel for confirmation before
operation.
3. After all major faults are cleared from the active ZXUN USPP (HLR), run the
RECLAIM command on the Terminal or MML Terminal view of NMS of the active
ZXUN USPP (HLR) to conduct manual reclamation. Check whether the reclamation
operation succeeds.
l Yes: Go to Step 4.
l No: The external signaling link fault is not cleared completely. It is necessary to
clear the fault completely before performing reclamation operation.
4. Run the SHOW DR STATE command on the Terminal or MML Terminal view of NMS
of the active ZXUN USPP (HLR) to check whether the active ZXUN USPP (HLR) is in
Not Fail Overed status.
Caution!
The next step is risky. Contact ZTE technical support personnel for confirmation before
operation.
5. Run the GIVE BACK command on the Terminal or MML Terminal view of NMS of the
standby ZXUN USPP (HLR) (if there are multiple standby ZXUN USPP (HLR)s, select
the one with the same number as that queried with the SHOW DR STATE command
on the OMM of the active ZXUN USPP (HLR)) to manually give back the standby
ZXUN USPP (HLR).
Cause
The DSA node has received too many LDAP or DSP request messages within a unit of
time.
3-39
Handling
1. Log in to the EMS client and open the MML Terminal view. Execute the SHOW DSA
NODEOPT command under the Global Equipment Configuration to check whether
the value of The Max Number of Received Message Per Second (that is, MAXMSG)
is much less than the recommended value 2000.
l Yes: Set The Max Number of Received Message Per Second to the
recommended value and transfer the changed table to validate the setting. Then
check whether the alarm disappears.
à Yes: End.
à No: Go to Step 2.
l No: Go to Step 2.
2. Log in to the EMS client and open the MML Terminal view. Execute the SHOW DS
ANODE STATUS command to check whether other DSA nodes in the DSA cluster of
the DSA node with alarms are off-line or faulty.
l Yes: Change the status of the other DSAs to online status or eliminate the faults
on the other DSAs so that the other DSAs can share the service load.
l No: Go to Step 3.
3. Check whether the TCP connections between the DSA with the alarm and the other
nodes in the cluster are normal.
l Yes: Contact ZTE.
l No: After eliminating the link faults, check whether the alarm disappears.
à Yes: End.
à No: Contact ZTE.
Cause
The number of the user lists of all DSAs in the DSA group will reach the upper limit.
3-40
Handling
Expand the capacity of the user list and restart DSA.
Cause
The current capacity of the subscriber table reaches the upper limit of the configured
capacity.
Handling
1. On the Performance Management view of the NMS, create a measurement job
to query the total current subscriber capacity in the system. On the License
Management view of the NMS, query the upper limit of the subscriber capacity
specified by the License, and check whether the value of the current subscriber
capacity is close or equals to the upper limit of the subscriber capacity specified by
the License.
l Yes: Contact ZTE to expand the capacity.
l No: Go to Step 2.
2. On the Performance Management view of NMS, create a measurement job to query
the current subscriber capacity of each administration domain. On the MML Terminal
or Terminal view of the NMS, check the setting of the subscriber capacity by running
the SHOW VHLRCAP command to see if the set value is close or equals to the current
subscriber capacity of the administration domain.
l Yes: Modify the setting of the administration domain capacity and then
synchronize the data. After that, check whether the alarm disappears.
à Yes: End.
à No: Go to Step 3.
l No: Go to Step 3.
3-41
3. Check the capacity of each DSA cluster involved in each DSA group to see if it reaches
the upper limit of the configured capacity.
l Yes: Contact ZTE to combine DSA groups or add more DSAs.
l No: Go to Step 4.
4. Check whether the configuration of the subscriber table capacity proportion is rational.
If it is not proper, the table could be full.
l Yes: Modify the configuration and then synchronize the data. Then check whether
the alarm disappears.
l No: Contact ZTE.
Cause
The user database is full.
Handling
Expand the database capacity.
Cause
The user table capacity is to reach the configured upper limit.
3-42
Handling
Expand the user table capacity, and then restart the DSA.
Cause
Insufficient disk space.
Handling
1. Check the backup data directory of the DST to see if the backup data are not deleted
in time so that the disk space is insufficient.
l Yes: Manually delete the backup data that were generated a long time ago and
re-create the scheduled data backup task to shorten the backup data reservation
duration.
l No: Go to Step 2.
2. Check whether the disk has faulty tracks.
l Yes: Change the hard disk.
l No: Contact ZTE.
3-43
Causes
l The physical storage is faulty, for example, the disk is damaged or the hardware ages.
l The operating system is faulty, and thus files cannot be read or written.
Handling
1. Run the fsck command to check whether the disk is faulty. Contact ZTE technical
support personnel to replace the disk if the disk is faulty.
2. It is maybe the operating system is faulty, contact ZTE.
Cause
The online recovery standby node has too less a table capacity.
Handling
1. Modify the configuration of the table capacity. Then synchronize the data and check
whether the alarm disappears.
l Yes: End.
l No: Go to Step 2.
2. Contact ZTE.
3-44
Cause
The asynchronous duplication standby node has too less a table capacity.
Handling
1. Modify the configuration of the table capacity and synchronize the data. Check
whether the alarm disappears.
l Yes: End.
l No: Go to Step 2.
2. Contact ZTE.
Cause
The online recovery standby node has too less a table capacity.
3-45
Handling
1. Modify the configuration of the table capacity to be higher than the higher level of
the active node at least. Then synchronize the data and check whether the alarm
disappears.
l Yes: End.
l No: Go to Step 2.
2. Contact ZTE.
Cause
Key configuration data are changed, which changes the node role and the service types
and capabilities provided by the node. Configuration data that may have been modified
are as follows:
l DSA node ID. For example, the original node ID is 111 and then it is changed to 121.
The node reports this alarm when the changed configuration data are sent to the node.
l DSA node type. For example, the original node type is DSA and then it is changed to
SAVE. The node reports this alarm when the changed configuration data are sent to
the node.
l Home DSA cluster of the DSA node. For example, the original cluster to which the
node belongs is cluster 1 and then it is changed to cluster 2. The node reports this
alarm when the changed configuration data are sent to the node.
l Storage node associated with the DSA node. For example, the original associated
storage node is 180 and then it is changed to 181. The node reports this alarm when
the changed configuration data are sent to the node.
l Home DSA type of the DSA node. For example, the original home DSA type is IDSA
and then it is changed to PDSA. The node reports this alarm when the changed
configuration data are sent to the node.
3-46
l Home DSA application type of the DSA node. For example, the original application
type is WCDMA NE and then other NE types are added. The node reports this alarm
when the changed configuration data are sent to the node.
l DSA node storage type. For example, the original storage type is dump and then it is
changed to another type. The node reports this alarm when the changed configuration
data are sent to the node.
l Associated DSA cluster of the storage node. For example, the original number of
associated clusters is 5, and then other clusters are added to associate with the
storage node. The node reports this alarm when the changed configuration data
are sent to the node. Or, the number of associated clusters does not change but
the associated cluster IDs change. The node reports this alarm when the changed
configuration data are sent to the node.
Note:
Such an alarm is generated normally at the early stage of office deployment. Key
configurations should not be modified during normal operation. Therefore, such an alarm
will not occur.
Handling
Contact ZTE technical support personnel to confirm whether the configuration data are
modified properly.
3-47
Cause
The link between DRSync and the disaster-tolerant HLR may ever be interrupted, which
causes that the disaster-tolerance synchronization request is delayed. Additionally,
DRSync may have a performance bottleneck.
Handling
Check whether the network connection between DRSync and the disaster-tolerant office
is interrupted, and check the performance of DRSync. If there is performance bottleneck,
add more DRSync modules.
Causes
The CPU overload of the system has reached the highest level configured on the MML
Terminal or Terminal view of the NMS (run the SHOW LOADLEV command to query the
overload level). CPU overload is caused by the following:
l Too many processes are started in the system, resulting in CPU overload.
l The traffic is too large, or some nodes in the cluster are abnormal.
l Too many signaling tracing or failure observation views are opened in the OMM.
l There is virus in the machine.
l There is device hardware problem.
3-48
Handling
1. On the MML Terminal or Terminal view of the NMS, run the SHOW LOADLEV
command , and check whether the CPU rate of the fatal load level is set properly.
l Yes: Go to Step 2.
l No: Reset the parameter value.
2. Check whether there are too many processes running in the system. For the Windows
operating system, choose Task Manager > Performance to check the settings. For
the Linux operating system, run the top command to check the CPU occupancy.
l Yes: Disable unnecessary processes to release the CPU.
l No: Go to Step 3.
3. Check whether the traffic is too large.
l Yes: Contact ZTE for system expansion, and add DSA nodes to implement load
sharing.
l No: Go to Step 4.
4. Check whether the DSA nodes in the cluster are running normally.
l Yes: Go to Step 5.
l No: Contact ZTE technical support personnel to solve the problem.
5. Check whether too many signaling tracing and failure observation windows are
opened.
l Yes: Close signaling tracing and failure observation windows.
l No: Go to Step 6.
6. Check whether there is any virus in the computer.
l Yes: Use anti-virus tools to kill viruses.
l No: Go to Step 7.
7. Check whether the hardware is faulty, and contact ZTE technical support personnel to
solve the problem.
Cause
The CPU load is above the critical alarm level and lower than the fatal alarm level.
3-49
Handling
1. Wait until the alarm disappears automatically. If it has not disappeared for a long time,
go to Step 2.
2. On the Fault Management view of NMS, perform alarm synchronization or clear the
alarm manually. Then check whether the system still reports this alarm.
l Yes: Contact ZTE.
l No: End.
Cause
The CPU load is above the minor alarm level and lower then the critical alarm level.
Handling
1. Wait until the alarm disappears automatically. If it has not disappeared for a long time,
go to Step 2.
2. On the Fault Management view of the NMS, perform alarm synchronization and clear
the alarm manually. Then check whether the system still reports this alarm.
l Yes: Contact ZTE to expand the capacity.
l No: End.
3-50
Causes
l Bottom-layer link has bad transmission quality, which leads to association congestion.
l Heavy traffic.
l Uneven load among associations.
l Insufficient association resources.
4-1
Handling
1. Make no manual intervention and just wait until the system recovers. Check whether
the alarm disappears after 30 seconds.
l Yes: End.
l No: Go to Step 2.
2. Check whether network cable is well connected. Ensure the network cable is securely
inserted and observe whether the alarm disappears.
l Yes: End.
l No: Go to Step 3.
3. Check whether the system has a heavy traffic.
l Yes: Go to Step 4.
l No: Go to Step 7.
4. Check whether there are sufficient association resources.
l Yes: Go to Step 5.
l No: Go to Step 6.
5. Check whether load are evenly shared among associations.
l Yes: Go to Step 1.
l No: Go to Step 7.
6. Add new associations and check whether this alarm disappears.
l Yes: End.
l No: Go to Step 5.
7. Record the following information and contact ZTE.
l Configuration data of the local office and peer-end office.
l History alarms, history notifications, and current alarms of the local office and
peer-end office.
Cause
At least one association of the office is in congestion status.
4-2
Handling
1. Make no manual intervention and just wait until the system recovers. Check whether
the alarm disappears 30 seconds later.
l Yes: End.
l No: Go to Step 2.
2. Check whether the system has heavy traffic.
l Yes: Go to Step 3.
l No: Go to Step 5.
3. Check whether there are sufficient association resources.
l Yes: Go to Step 4.
l No: Add new associations and check whether the alarm disappears.
à Yes: End.
à No: Go to Step 5.
4. Check whether there is association congestion.
l Yes: Troubleshoot association congestion by following the 4.1 Association
Congested (8402688) alarm handling suggestions.
l No: Go to Step 5.
5. Back up the following data and contact ZTE.
l Configuration data related to local office and peer-end office.
l History alarms, current alarms, and notifications that are related to the local office
and peer-end office.
Cause
An object for QoS alarm monitoring is uniquely determined by the threshold ID of the
measurement task and the measurement object ID associated with the threshold. For
a specific monitored object, if the counter value or index value detected at the data report
time point exceeds the set monitoring threshold of the critical level, a level-1 performance
QoS alarm is triggered.
4-3
Note:
l Task threshold
Task thresholds are a set of performance QoS thresholds set for a specific
measurement task, including the thresholds of four levels: critical, major, minor, and
warning. They must be associated with a certain counter or counter-based indexes.
l Measurement object ID
If the measurement task involves measurement objects, the task thresholds must be
associated with one or multiple of the measurement objects. Otherwise, the task
thresholds need not be associated with any measurement object.
l Data report time point
When the time granularity of a measurement task is up, the service node in the
foreground reports statistical data.
Handling
1. On the MML Terminal or Terminal view of the NMS, run the SHOW PMMONITOR
command with the additional alarm information to check whether the corresponding
performance threshold is properly set.
l Yes: Go to Step 3.
l No: Go to Step 2.
2. On the MML Terminal or Terminal view of the NMS, run the SET PMMONITOR
command to modify the threshold value (do not modify it unless really necessary),
and then check whether the alarm disappears.
l Yes: End.
l No: Go to Step 4.
3. Check the service running status based on the specific counter or index type, remove
the service fault, and then check whether the alarm disappears.
l Yes: End.
l No: Go to Step 4.
4. Contact ZTE.
4-4
Cause
An object for QoS alarm monitoring is uniquely determined by the threshold ID of the
measurement task and the measurement object ID associated with the threshold. For
a specific monitored object, if the counter value or index value detected at the data report
time point exceeds the set monitoring threshold of the major level, a level-2 performance
QoS alarm is triggered.
Note:
l Task threshold
Task thresholds are a set of performance QoS thresholds set for a specific
measurement task, including the thresholds of four levels: critical, major, minor, and
warning. They must be associated with a certain counter or counter-based indexes.
l Measurement object ID
If the measurement task involves measurement objects, the task thresholds must be
associated with one or multiple of the measurement objects. Otherwise, the task
thresholds need not be associated with any measurement object.
l Data report time point
When the time granularity of a measurement task is up, the service node in the
foreground reports statistical data.
Handling
1. On the MML Terminal or Terminal view of the NMS, run the SHOW PMMONITOR
command with the additional alarm information to check whether the corresponding
performance threshold is properly set.
l Yes: Go to Step 3.
l No: Go to Step 2.
2. On the MML Terminal or Terminal view of the NMS, run the SET PMMONITOR
command to modify the threshold value (do not modify it unless really necessary),
and then check whether the alarm disappears.
l Yes: End.
l No: Go to Step 4.
4-5
3. Check the service running status based on the specific counter or index type, remove
the service fault, and then check whether the alarm disappears.
l Yes: End.
l No: Go to Step 4.
4. Contact ZTE.
Cause
An object for QoS alarm monitoring is uniquely determined by the threshold ID of the
measurement task and the measurement object ID associated with the threshold. For
a specific monitored object, if the counter value or index value detected at the data report
time point exceeds the set monitoring threshold of the minor level, a level-3 performance
QoS alarm is triggered.
Note:
l Task threshold
Task thresholds are a set of performance QoS thresholds set for a specific
measurement task, including the thresholds of four levels: critical, major, minor, and
warning. They must be associated with a certain counter or counter-based indexes.
l Measurement object ID
If the measurement task involves measurement objects, the task thresholds must be
associated with one or multiple of the measurement objects. Otherwise, the task
thresholds need not be associated with any measurement object.
4-6
Handling
1. On the MML Terminal or Terminal view of the NMS, run the SHOW PMMONITOR
command with the additional alarm information to check whether the corresponding
performance threshold is properly set.
l Yes: Go to Step 3.
l No: Go to Step 2.
2. On the MML Terminal or Terminal view of the NMS, run the SET PMMONITOR
command to modify the threshold value (do not modify it unless really necessary),
and then check whether the alarm disappears.
l Yes: End.
l No: Go to Step 4.
3. Check the service running status based on the specific counter or index type, remove
the service fault, and then check whether the alarm disappears.
l Yes: End.
l No: Go to Step 4.
4. Contact ZTE.
Cause
An object for QoS alarm monitoring is uniquely determined by the threshold ID of the
measurement task and the measurement object ID associated with the threshold. For
a specific monitored object, if the counter value or index value detected at the data report
time point exceeds the set monitoring threshold of the warning level, a level-4 performance
QoS alarm is triggered.
4-7
Note:
l Task threshold
Task thresholds are a set of performance QoS thresholds set for a specific
measurement task, including the thresholds of four levels: critical, major, minor, and
warning. They must be associated with a certain counter or counter-based indexes.
l Measurement object ID
If the measurement task involves measurement objects, the task thresholds must be
associated with one or multiple of the measurement objects. Otherwise, the task
thresholds need not be associated with any measurement object.
l Data report time point
When the time granularity of a measurement task is up, the service node in the
foreground reports statistical data.
Handling
1. On the MML Terminal or Terminal view of the NMS, run the SHOW PMMONITOR
command with the additional alarm information to check whether the corresponding
performance threshold is properly set.
l Yes: Go to Step 3.
l No: Go to Step 2.
2. On the MML Terminal or Terminal view of the NMS, run the SET PMMONITOR
command to modify the threshold value (do not modify it unless really necessary),
and then check whether the alarm disappears.
l Yes: End.
l No: Go to Step 4.
3. Check the service running status based on the specific counter or index type, remove
the service fault, and then check whether the alarm disappears.
l Yes: End.
l No: Go to Step 4.
4. Contact ZTE.
4-8
Cause
The alarm is reported when the traffic gets overloaded, and is cleared up when the traffic
load gets normal.
Handling
Reduce the traffic.
Cause
The alarm is reported when the traffic gets overloaded, and is cleared up when the traffic
load gets normal.
Handling
Reduce the traffic.
4-9
Cause
The alarm is reported when the traffic gets overloaded, and is cleared up when the traffic
load gets normal.
Handling
Reduce the traffic.
Cause
The alarm is reported when the traffic gets overloaded, and is cleared up when the traffic
load gets normal.
Handling
Reduce the traffic.
4-10
l Alarm description: SMP report SHLR NNI interface level 4 overload alarm.
Cause
The alarm is reported when the traffic gets overloaded, and is cleared up when the traffic
load gets normal.
Handling
Reduce the traffic.
Cause
The alarm is reported when the traffic gets overloaded, and is cleared up when the traffic
load gets normal.
Handling
Reduce the traffic.
4-11
Cause
The alarm is reported when the traffic gets overloaded, and is cleared up when the traffic
load gets normal.
Handling
Reduce the traffic.
Cause
The alarm is reported when the traffic gets overloaded, and is cleared up when the traffic
load gets normal.
Handling
Reduce the traffic.
4-12
Cause
The alarm is reported when the traffic gets overloaded, and is cleared up when the traffic
load gets normal.
Handling
Reduce the traffic.
Cause
The alarm is reported when the traffic gets overloaded, and is cleared up when the traffic
load gets normal.
Handling
Reduce the traffic.
4-13
Cause
The alarm is reported when the traffic gets overloaded, and is cleared up when the traffic
load gets normal.
Handling
Reduce the traffic.
4-14
5-1
5-2
Cause
The NMS link is broken.
Handling
Check whether the link is connected.
Causes
l The two ends are not connected to the same ground.
l The clock is not synchronous.
l The transmission device is faulty
Handling
1. Check whether the cable impedance matches the local device, and whether the type
of rear card jumper is consistent with the DIP switch of the board (cable type).
l Yes: Go to Step 3.
l No: Go to Step 2.
2. Reset the DIP switch of the board or the rear card jumper. Check whether the alarm
disappears.
5-3
l Yes: End.
l No: Go to Step 3.
3. Check whether grounding signals are reliable between the devices at both ends by
using a multimeter.
l Yes: Go to Step 5.
l No: Go to Step 4.
4. Make sure the grounding signals are reliable between both devices. Check whether
the alarm disappears.
l Yes: End.
l No: Go to Step 5.
5. Check whether the clock subcard on the switching board works in tracing state (the
tracing/capturing state light indicator marked with T/C corresponding to the clock
subcard on the switching board keeps on always).
l Yes: Go to Step 6.
l No: Check the clock reference and make sure that clock reference is locked. Then
go to Step 6.
6. Check whether the clock reference is consistent between the NEs or nodes at both
ends.
l Yes: Go to Step 8.
l No: Go to Step 7.
7. Modify the clock reference to make sure that it is consistent between the NEs or nodes
at both ends. Check whether the alarm disappears.
l Yes: End.
l No: Go to Step 8.
8. Ask for the maintenance personnel of transmission devices to check whether
transmission devices are faulty. Identify the fault source through level-by-level
physical loopback tests. If the alarm still remains, contact ZTE.
Cause
l No E1/T1 line is connected on the DDF or an E1/T1 line is incorrectly connected.
l The E1/T1 line is disconnected.
l An upstream equipment work improperly.
5-4
Handling
1. Make sure that the E1/T1 line is correctly connected on the DDF. Check whether the
alarm disappears.
l Yes: End.
l No: Go to Step 2.
2. Perform self-loop for the E1/T1 line on the local end. Check whether the alarm
disappears.
l Yes: Contact the upstream device maintenance personnel to check the upstream
device and handle the alarm.
l No: Go to Step 3.
3. Replace the board and end alarm handling.
Cause
An upstream device is faulty.
Handling
Contact the upstream device maintenance personnel to check and clear the E1/T1 link
alarms on the upstream device. If the alarm remains, contact ZTE.
Cause
The frame format is inconsistent.
5-5
Handling
1. Check whether the frame format is consistent between both ends.
l Yes: Contact ZTE.
l No: Go to Step 2.
2. Make sure that the frame format is consistent between both ends. Check whether the
alarm disappears.
l Yes: End.
l No: Contact ZTE.
Causes
l Transmitting signals of the local device are faulty.
l Any intermediate transmission device is faulty.
l All faults that may cause LOS, AIS, or LOF on the peer end.
Handling
At least one alarm is reported on the peer device among LOS, AIS, and LOF. Therefore,
check and record alarms reported on the peer device. Check whether any intermediate
transmission device on the trunk link fails.
l Yes: Contact transmission engineer to handle the problem.
l No: Contact ZTE.
5-6
Cause
Device A sends a CSU link establishment code to device B, and device B creates loopback
on the trunk link for CSU tests. This alarm will not be reported if the trunk link is not used
for CSU loopback tests.
Handling
Perform diagnosis tests and send a command for canceling CSU loopback from device A
to device B.
Cause
The cell header HEC is damaged, and thus cells cannot be delineated from physical
layer frames. In general, this alarm is triggered by a bottom-layer fault, or simply caused
because the local equipment and the peer equipment handle the cell HEC in different
ways.
Handling
1. Check whether other physical layer alarms exist.
l Yes: Go to Step 2.
l No: Go to Step 3.
2. Check whether the alarm disappears after confirming that there are no other physical
alarms.
l Yes: End.
l No: Go to Step 3.
5-7
3. Unplug and plug the board to perform a hardware reset, and then check whether the
alarm disappears.
l Yes: End.
l No: Go to Step 4.
4. Contact ZTE.
Cause
When a board is reset, the SETS chip and constant-temperature crystal oscillator should
be fully preheated.
Handling
This is normal after a board is powered on. Make sure that preheating of the clock board
terminates before clock performance tests.
Causes
l The boards are not securely positioned in the slots.
l The clock wire is not connected.
l One of the clock boards in the same shelf is faulty.
l The board goes faulty.
5-8
Handling
1. Check whether the two switch boards of the shelf have proper clock. If one of them is
proper, no handling is needed.
l Yes: Go to Step 2.
l No: Replace the board and check whether the alarm disappears.
à Yes: End.
à No: Go to Step 2.
2. Check whether the clock input line of this shelf is well connected.
l Yes: Go to Step 4.
l No: Go to Step 3.
3. Insert the clock input wire in position and observe whether the alarm disappears.
l Yes: End.
l No: Go to Step 4.
4. Contact ZTE.
Cause
The board is abnormal or reset through a man-machine command.
Handling
1. Check whether the board is reset through a man-machine command.
l Yes: The alarm is normal and does not require any handing.
l No: Go to Step 2.
2. Remove the board fault, and then check whether the alarm disappears.
l Yes: End.
l No: Go to Step 3.
3. Contact ZTE.
5-9
Cause
The FLASH of the board is damaged.
Handling
1. Confirm that there is a standby board that can be used for replacement.
l Yes: Go to Step 2.
l No: Go to Step 3.
2. Replace the board and then check whether the alarm disappears.
l Yes: End
l No: Go to Step 3.
3. Contact ZTE.
Cause
Configuration data is incorrect.
5-10
Handling
1. Check the additional alarm information to determine which configuration item is
incorrect.
2. Check whether this configuration item is available on Physical Configuration of the
Terminal view.
l Yes: Go to Step 3.
l No: Contact ZTE.
3. Modify the configuration item to another value. Check whether the alarm disappears.
l Yes: End.
l No: Contact ZTE.
Cause
The obtained board configuration information is incompatible with the board type.
Handling
1. Check whether the board configuration information matches with the board.
l Yes: Go to Step 3.
l No: Go to Step 2.
2. Modify the board configuration information, or replace the board with a matching board,
and then check whether the alarm disappears.
l Yes: End.
l No: Go to Step 3.
3. Contact ZTE.
5-11
Cause
The loss rate of the media-plane packets internal the board exceeds the preset threshold
(5% by default).
Note:
This alarm rarely occurs.
Handling
1. On the Fault Management view of NMS, check whether an alarm related to CPU
overload is reported on the switching board, co-shelf switching board, or the board.
l Yes: Handle the problem according to the handling suggestions of the alarm.
l No Go to Step 2.
2. On the Fault Management view of NMS, check whether an alarm is reported to prompt
abnormal inter-shelf media plane links.
l Yes: Handle the problem according to the handling suggestions of the alarm.
l No Go to Step 3.
3. Replace the board and observe whether the alarm disappears.
l Yes: End.
l No Go to Step 4.
4. Plug the board in another slot and observe whether the alarm disappears.
l Yes: End.
l No Go to Step 5.
5. Replace the co-shelf switching board and observe whether the alarm disappears.
l Yes: End.
l No Contact ZTE.
5-12
Causes
l No reference source is available.
l The clock distribution line is incorrect or self-loop exists.
l A stratum-2 clock locks a stratum-3 clock.
Handling
1. Check whether the clock reference is correctly connected.
l Yes: Replace the board and go to Step 2.
l No: Correctly connect the clock reference and go to Step 2.
2. Check whether the alarm disappears.
l Yes: End.
l No: Contact ZTE.
Cause
The used capacity of the hard disk exceeds the alarm threshold.
Handling
Check whether the used capacity of hard disk is too high.
5-13
l Yes: Sort out the space of hard disk to make sure that the used capacity is lower than
the threshold.
l No: Contact ZTE.
Cause
The hard disk is damaged or fails to be detected by the system.
Handling
1. Check whether the user-enabled hard disk exists.
l Yes: Go to Step 2.
l No: Go to Step 3.
2. Repair or replace the hard disk, and then check whether the alarm disappears.
l Yes: End.
l No: Go to Step 4.
3. Insert a hard disk, and then check whether the alarm disappears.
l Yes: End.
l No: Go to Step 4.
4. Contact ZTE.
Cause
The subcard is abnormal or the subcard Flash memory is being formatted.
5-14
Handling
1. Check whether the Flash memory is being formatted.
l Yes: Go to Step 2.
l No: Go to Step 3.
2. Check whether the alarm disappears after the formatting is over.
l Yes: End.
l No: Go to Step 3.
3. Check whether the subcard is faulty.
l Yes: Go to Step 4.
l No: Go to Step 5.
4. Replace the subcard, and then check whether the alarm disappears.
l Yes: End.
l No: Go to Step 5.
5. Contact ZTE.
Causes
l The clock extracting reference is switched. In specific, the interface board disables
clock output when an optical interface fails, thus causing input changes to the clock
board. Or the NMS sets another optical interface to extract the clock.
l The input of the clock board changes, thus causing output changes.
l Hardware failure occurs on the phase-lock loop.
Handling
1. On the Fault Management view of NMS, check whether a relevant clock alarm is
reported.
5-15
l Yes: Handle the problem according to the handling suggestions of the relevant
alarm.
l No: Go to Step 2.
2. On the Fault Management view of NMS, check whether a relevant alarm is reported
on the optical interface that extracts the clock.
l Yes: Handle the problem according to the handling suggestions of the relevant
alarm.
l No: Go to Step 3.
3. Check NMS operation and maintenance logs. Check whether an operator of changing
the loop clock extracting reference exists.
l Yes: This alarm is a normal phenomenon and cannot be neglected.
l No: Go to Step 4.
4. Switch the clock board (that is, the switching board). Check whether the alarm
disappears.
l Yes: End.
l No: Go to Step 5.
5. Replace the board. Check whether the alarm disappears.
l Yes: End.
l No: Contact ZTE.
Cause
The packet error rate of the MAC port exceeds the threshold.
Handling
1. Check whether the local port is correctly connected with the peer port.
l Yes: Go to Step 2.
l No: Check the physical cable. If it is damaged, replace it with a good one. Check
whether the alarm disappears.
à Yes: End.
5-16
à No: Go to Step 2.
2. Replace the local board or the peer interface. Check whether the alarm disappears.
l Yes: End.
l No: Go to Step 3.
3. Replace the peer board or the local interface. Check whether the alarm disappears.
l Yes: End.
l No: Contact ZTE.
Cause
The crystal oscillator stops working or frequency deviation occurs.
Handling
Replace the board. Check whether the alarm disappears.
l Yes: End.
l No: Contact ZTE.
Cause
The MAC port link is broken.
5-17
Handling
1. Check whether the link works properly.
l Yes: Go to Step 2.
l No: Solve the link problem. Check whether the alarm disappears.
à Yes: End.
à No: Go to Step 2.
2. Check whether the port mode is reasonably configured.
l Yes: Go to Step 3.
l No: Modify the port mode. Check whether the alarm disappears.
à Yes: End.
à No: Go to Step 3.
3. Contact ZTE.
Cause
The chip performance is not successfully configured on the local or peer end. As a result,
the setting of working mode of the external port does not take effect, and the port fails to
work in the configured speed mode.
Handling
1. Check whether the speed mode of the peer end is correctly configured to match the
local end.
l Yes: Go to Step 2.
l No: Modify the speed mode of the peer end to make it match the local end. Check
whether the alarm disappears.
5-18
à Yes: End.
à No: Go to Step 2.
2. Check whether the speed mode of the local end is correctly configured.
l Yes: Contact ZTE.
l No: Modify the speed mode of the local end. Check whether the alarm disappears.
à Yes: End.
à No: Contact ZTE.
Causes
l The board is not tightly inserted in the slot.
l Two clock boards in the same shelf have no output signals.
l The clock board fails.
l The clock line fails.
l The board fails.
Handling
1. Check whether the clock board and clock line work properly in the local shelf.
l Yes: Got to Step 2.
l No: Solve the clock board and clock line problem. Check whether the alarm
disappears.
à Yes: End.
5-19
Cause
The master/slave mode does not match the configuration.
Handling
1. Check whether the master/slave mode of the peer end is correctly configured to match
the local end.
l Yes: Go to Step 2.
l No: Modify the master/slave mode of the peer end to make it match the local end.
Check whether the alarm disappears.
à Yes: End.
à No: Go to Step 2.
2. Check whether the master/slave mode of the local end is correctly configured.
l Yes: Contact ZTE.
l No: Modify the master/slave mode of the local end. Check whether the alarm
disappears.
à Yes: End.
à No: Contact ZTE.
5-20
Cause
l The rear card has incorrect model or is not well inserted.
l The board does not support the OMC port.
Handling
1. Check the rear card to make sure that it has correct model and is correctly inserted.
2. Check the board hardware to make sure it supports the OMC port.
Cause
The chip performance is not successfully configured on the local or peer end. As a result,
the setting of working mode of the external port does not take effect, and the port fails to
work in the configured duplex mode.
Handling
1. Check whether the duplex mode of the peer end is correctly configured to match the
local end.
l Yes: Go to Step 2.
l No: Modify the duplex mode of the peer end to make it match the local end. Check
whether the alarm disappears.
à Yes: End.
à No: Go to Step 2.
2. Check whether the duplex mode of the local end is correctly configured.
l Yes: Contact ZTE.
5-21
l No: Modify the duplex mode of the local end. Check whether the alarm
disappears.
à Yes: End.
à No: Contact ZTE.
Cause
Exceptions occur when the board register is read or written. Possibly the board hardware
is faulty.
Handling
Replace the board.
Cause
The E1/T1 link or the uplink equipment has faults.
5-22
Handling
1. Check whether the local trunk link fails with an alarm. If yes, rectify the original fault.
Check whether the alarm disappears.
l Yes: End.
l No: Go to Step 2.
2. Check whether any other device fails on the uplink trunk link. If yes, rectify the fault.
Check whether the alarm disappears.
l Yes: End.
l No: Contact ZTE.
Cause
The E1/T1 link or the uplink equipment has faults.
Handling
1. Check whether the local trunk link fails with an alarm. If yes, rectify the original fault.
Check whether the alarm disappears.
l Yes: End.
l No: Go to Step 2.
2. Check whether any other device fails on the uplink trunk link. If yes, rectify the fault.
Check whether the alarm disappears.
l Yes: End.
l No: Contact ZTE.
5-23
Cause
The E1/T1 link or the uplink equipment is faulty.
Handling
At least CRC error codes exist on the peer device; therefore, check and record alarms
reported on the peer device. Check whether any intermediate transmission device on the
trunk link fails.
l Yes: Contact transmission engineers to handle problem.
l No: Contact ZTE.
Cause
The subcard is formatting the Flash memory.
Handling
Check whether the Flash memory of the subcard is being formatted.
l Yes: Wait until the formatting ends. The alarm disappears.
l No: Contact ZTE.
5-24
Cause
The subcard status is abnormal.
Handling
1. Check whether the subcard is faulty.
l Yes: Go to Step 2.
l No: Go to Step 3.
2. Replace the subcard, and then check whether the alarm disappears.
l Yes: End.
l No: Go to Step 3.
3. Contact ZTE.
Cause
The subcard status is abnormal.
Handling
1. Check whether the subcard is faulty.
l Yes: Go to Step 2.
l No: Go to Step 3.
2. Replace the subcard, and then check whether the alarm disappears.
l Yes: End.
l No: Go to Step 3.
3. Contact ZTE.
5-25
Cause
The subcard status is abnormal.
Handling
1. Check whether the subcard is faulty.
l Yes: Go to Step 2.
l No: Go to Step 3.
2. Replace the subcard, and then check whether the alarm disappears.
l Yes: End.
l No: Go to Step 3.
3. Contact ZTE.
Cause
Upgrading the functional EPLD fails.
Handling
1. Check whether the switching boards in the same shelf as the board and the switching
board co-existing in the shelf where OMP is plugged work properly.
5-26
l Yes: Go to Step 2.
l No: Restore the preceding board to normal working status.
à Yes: Go to Step 2.
à No: Contact ZTE.
2. Upgrade the EPLD again. Check whether a new EPLD version runs on the preceding
board.
l Yes: End.
l No: Contact ZTE.
Causes
l The duplex mode of an internal port for connecting other intra-shelf slots on the
switching board is abnormal and cannot be self-healed.
l The speed mode of an internal port for connecting other intra-shelf slots on the
switching board is abnormal and cannot be self-healed.
l The duplex mode of a network interface on the PP board is abnormal and cannot be
self-healed.
l The speed mode of a network interface on the PP board is abnormal and cannot be
self-healed.
Handling
Restart the board with the alarm.
5-27
Cause
The network processing components such as the media-plane processor kernel, the
micro-engine, or APP650/APP100 run improperly or cannot be continuously kept
activated.
Handling
Because this problem is mostly caused by failure of board hardware, replace the board if
this alarm is repeatedly reported.
Cause
Within a period of time, the number of bad frames received by the media plane interface
exceeds the threshold. The reason is that components are faulty or the connection of
fibers and network cables is broken.
Handling
Check the connection of fibers and network cables. If the alarm is repeatedly reported,
replace the board.
5-28
Causes
l The fan is unplugged.
l There is something wrong with the IPMB line between the CMM and the fan.
Handling
1. Check whether the fan is in position.
l Yes: If the alarm still exists after a period of time, contact ZTE.
l No: Go to Step 2.
2. Insert the fan tray into the shelf and then check whether the alarm disappears.
l Yes: End.
l No: Contact ZTE.
Causes
l The PEM is unplugged.
l There is something wrong with the IPMB line between the CMM and the PEM.
5-29
Handling
1. Check whether the power supply is connected to the shelf.
l Yes: If the alarm still exists after a period of time, contact ZTE.
l No: Go to Step 2.
2. Insert the PEM and then check whether the alarm disappears.
l Yes: End.
l No: Contact ZTE.
Causes
l Line clock of the shelf where the board lies jitters abnormally.
l Hardware failure occurs on the switching chip of the board.
Handling
1. Check whether the chip clock is normal.
l Yes: Go to Step 2.
l No: Ensure that the chip clock is proper and observe whether the alarm
disappears.
à Yes: End.
à No: Go to Step 2.
2. Replace the connection chip or board and observe whether the alarm disappears.
l Yes: End.
l No: Contact ZTE.
5-30
Cause
l The threshold is unreasonably set.
l The real rack temperature is too high.
Handling
1. On the MML Terminal or Terminal view of the NMS, run the SHOW ENVIOR
command to check whether the higher temperature threshold of the rack is reasonably
set.
l Yes: Go to Step 3.
l No: Go to Step 2.
2. Run the SET ENVIOR command to modify the higher temperature threshold of the
rack, and synchronize the data, then check whether the alarm disappears.
l Yes: End.
l No: Go to Step 3.
3. Decrease the rack temperature, and then check whether the alarm disappears.
l Yes: End.
l No: Go to Step 4.
Causes
l The preset rack temperature threshold is unreasonable.
l The real temperature is too low.
5-31
Handling
1. On the MML Terminal or Terminal view of the NMS, run the SHOW ENVIOR
command to check whether the configured lower threshold of the rack temperature
is reasonable.
l Yes: Go to Step 2.
l No: Go to Step 3.
2. Modify the lower threshold of the rack temperature using the SET ENVIOR command,
and synchronize the data, then check whether the alarm disappears.
l Yes: End.
l No: Go to Step 3.
3. Increase the rack temperature and observe whether the alarm disappears.
l Yes: End.
l No: Contact ZTE.
Cause
l The threshold is unreasonably set.
l The real temperature in the equipment room is too high.
5-32
Handling
1. On the MML Terminal or Terminal view of the NMS, run the SHOW ENVIOR
command to check whether the higher temperature threshold for the equipment room
is reasonably set.
l Yes: Go to Step 3.
l No: Go to Step 2.
2. Run the SET ENVIOR command to modify the higher temperature threshold for the
equipment room, and synchronize the data, then check whether the alarm disappears.
l Yes: End.
l No: Go to Step 3.
3. Lower the equipment room temperature, and check whether the alarm disappears.
l Yes: End.
l No: Contact ZTE.
Causes
l The equipment room temperature threshold is unreasonably set.
l The temperature in the equipment room is lower than the preset lower threshold.
l The temperature sensor of the equipment room is wrongly connected.
Handling
1. On the Terminal view of NMS, run the SHOW ENVIOR command to check whether
the lower temperature threshold for the equipment room is reasonably set on the NMS.
l Yes: Go to Step 3.
l No: Go to Step 2.
2. Run the SET ENVIOR command to modify the lower temperature threshold for the
equipment room, and synchronize the data, then check whether the alarm disappears.
5-33
l Yes: End.
l No: Go to Step 3.
3. Increase the equipment room temperature, and then check whether the alarm
disappears.
l Yes: End.
l No: Go to Step 4.
4. Check whether the sensor is correctly connected.
l Yes: Contact ZTE.
l No: Go to Step 5.
5. Properly connect the sensor, and then check whether the alarm disappears.
l Yes: End.
l No: Contact ZTE.
Cause
l The threshold is unreasonably set.
l The actual voltage is too high.
Handling
1. On the MML Terminal or Terminal view of the NMS, run the SHOW ENVIOR
command to check whether the high-voltage alarm threshold is reasonably set.
l Yes: Go to Step 3.
l No: Go to Step 2.
2. Run the SET ENVIOR command to modify the high-voltage alarm threshold (57 for
48 V power as the higher threshold and 72 for 60 V power as the higher threshold are
suggested), synchronize the data, and then check whether the alarm disappears.
l Yes: End.
l No: Go to Step 3.
5-34
3. Determine which line of voltage is higher than the high-voltage alarm threshold
according to the voltage index indicated in the detailed alarm information, lower the
voltage of the line, and then check whether the alarm disappears.
l Yes: End.
l No: Contact ZTE.
Causes
l The voltage of a line is lower than the lower limit of the alarm threshold.
l The input of a line of voltage is disconnected.
Handling
1. On the MML Terminal or Terminal view of the NMS, run the SHOW ENVIOR
command to check whether the low-voltage alarm threshold is reasonably set.
l Yes: Go to Step 3.
l No: Go to Step 2.
2. Run the SET ENVIOR command to modify the low-voltage alarm threshold ( 40 for
48 V power as the lower threshold and 50 for 60 V power as the lower threshold are
suggested), synchronize the data, and then check whether the alarm disappears.
l Yes: End.
l No: Go to Step 3.
3. Determine which line of voltage is lower than the low-voltage alarm threshold according
to the voltage index indicated in the detailed alarm information, raise the voltage of the
line, and then check whether the alarm disappears.
l Yes: End.
l No: Go to Step 4.
4. Check whether the input power voltage is normal.
l Yes: Contact ZTE.
l No: Go to Step 5.
5-35
5. Connect the power with a normal voltage, and then check whether the alarm
disappears.
l Yes: End.
l No: Contact ZTE.
Cause
l The threshold is unreasonably set.
l The real humidity is too high.
Handling
1. On the MML Terminal or Terminal view of the NMS, run the SHOW ENVIOR
command to check whether the equipment room humidity threshold is reasonably set.
l Yes: Go to Step 3.
l No: Go to Step 2.
2. Run the SET ENVIOR command to modify the equipment room humidity threshold (to
90), and synchronize the data, then check whether the alarm disappears.
l Yes: End.
l No: Go to Step 3.
3. Lower the equipment room humidity, and check whether the alarm disappears.
l Yes: End.
l No: Contact ZTE.
5-36
Causes
l The equipment room humidity threshold is unreasonably set.
l The humidity in equipment room is lower than the lower limit of the alarm threshold.
l The humidity sensor of the equipment room is wrongly connected.
Handling
1. On the MML Terminal or Terminal view of the NMS, run the SHOW ENVIOR
command to check whether the low-humidity threshold is reasonably set.
l Yes: Go to Step 3.
l No: Go to Step 2.
2. Run the SHOW ENVIOR command to modify the equipment room low-humidity
threshold, synchronize the data to the foreground, and then check whether the alarm
disappears.
l Yes: End.
l No: Go to Step 3.
3. Raise the rack humidity, and then check whether the alarm disappears.
l Yes: End.
l No: Go to Step 4.
4. Check whether the sensor is correctly connected.
l Yes: Contact ZTE.
l No: Go to Step 5.
5. Properly connect the sensor, and then check whether the alarm disappears.
l Yes: End.
l No: Contact ZTE.
Causes
l The fan shelf is loosely inserted.
5-37
Handling
1. Check whether the fan shelf and its power line are connected securely (indicators are
normal).
l Yes: Go to Step 3.
l No: Go to Step 2.
2. Secure the fan shelf and connect the power line, and then check whether the alarm
disappears.
l Yes: End.
l No: Go to Step 3.
3. Replace the fan shelf with a good one and check whether the alarm disappears.
l Yes: End.
l No: Go to Step 4.
4. Check whether the sensor is correctly connected.
l Yes: Contact ZTE.
l No: Go to Step 5.
5. Properly connect the sensor, and then check whether the alarm disappears.
l Yes: End.
l No: Contact ZTE.
Causes
l The related rack door is not closed.
l The rack door access control sensor is wrongly connected.
l The rack door access controller is wrongly connected.
5-38
Handling
1. Check whether the rack door is properly closed.
l Yes: Go to Step 3.
l No: Go to Step 2.
2. Properly close the rack door, and then check whether the alarm disappears.
l Yes: End.
l No: Go to Step 3.
3. Check whether the rack door access controller is correctly connected.
l Yes: Go to Step 5.
l No: Go to Step 4.
4. Properly connect the rack door access controller, close the rack door, and then check
whether the alarm disappears.
l Yes: End.
l No: Go to Step 5.
5. Check whether the sensor is correctly connected.
l Yes: Go to Step 7.
l No: Go to Step 6.
6. Properly connect the sensor, and then check whether the alarm disappears.
l Yes: End.
l No: Go to Step 7.
7. Contact ZTE.
Causes
l The smoke detector detects smoke.
l The smoke sensor is wrongly connected.
Handling
Check whether there is smoke in the equipment room.
l Yes: Dispel the smoke, and check whether the alarm disappears.
à Yes: End.
5-39
Causes
l There is heat source approaching, including animals and human beings.
l The infrared sensor settings are incorrect.
l The sensor is faulty.
l The sensor is wrongly connected.
Handling
1. Check whether there is creature around the infrared sensor.
l Yes: Go to Step 2.
l No: Go to Step 3.
2. Keep the creature away from the sensor, and then check whether the alarm
disappears.
l Yes: End.
l No: Go to Step 3.
3. Check whether the infrared sensor is correctly set.
l Yes: Go to Step 5.
l No: Go to Step 4.
4. Properly set the infrared sensor, and then check whether the alarm disappears.
l Yes: End.
l No: Go to Step 5.
5. Check whether the infrared sensor is faulty.
l Yes: Go to Step 6.
l No: Go to Step 7.
6. Replace the infrared sensor, and then check whether the alarm disappears.
l Yes: End.
5-40
l No: Go to Step 7.
7. Check whether the infrared sensor is correctly connected.
l Yes: Go to Step 9.
l No: Go to Step 8.
8. Properly connect the infrared sensor, and then check whether the alarm disappears.
l Yes: End.
l No: Go to Step 9.
9. Contact ZTE.
Causes
l The equipment room is influenced by thunder strike in bad weather.
l The lightning protection sensor is wrongly connected.
Handling
1. Check whether there is lightning hazard.
l Yes: Go to Step 2.
l No: Go to Step 3.
2. Take protection measures, and check whether the alarm disappears.
l Yes: End.
l No: Go to Step 3.
3. Check whether the sensor is correctly connected.
l Yes: Go to Step 4.
l No: Reconnect the sensor.
4. Contact ZTE.
5-41
Causes
l This air switch is not switched on, but the configuration on the NMS needs to enable
the air switch detection.
l The air switch sensor is wrongly connected.
Handling
l If you use the shelf:
1. Check whether the air switch is switched on, and whether the ALM indicator is
normal.
à Yes: Go to Step 3.
à No: Go to Step 2.
2. Switch on the air switch, and then check whether the alarm disappears.
à Yes: End.
à No: Go to Step 3.
3. Check whether the sensor is working properly.
à Yes: Go to Step 5.
à No: Go to Step 4.
4. Correctly connect the sensor, confirm that the sensor works properly, and then
check whether the alarm disappears.
à Yes: End.
à No: Go to Step 5.
5. Contact ZTE.
l If you do not use the shelf:
1. On the MML Terminal or Terminal view of the NMS, run the SHOW ENVIOR
command to check whether the air switch is shielded.
à Yes: Go to Step 3.
à No: Go to Step 2.
2. Run the SET ENVIOR command to change the switch to NO, and then check
whether the alarm disappears.
à Yes: End.
5-42
à No: Go to Step 3.
3. Contact ZTE.
Cause
The device type configured in the database is not consistent with the board hardware.
Handling
1. According to the additional alarm information, check the configuration on the NMS to
see whether the configuration information is consistent with the board hardware.
l Yes: Go to Step 2.
l No: Modify the configuration according to the hardware and power on the board
again. The alarm disappears.
2. Contact ZTE.
Cause
The duration in which the input reference is in invalid status is less than 10 minutes.
Possible causes include:
l The clock reference input is abnormal.
5-43
Handling
1. Check whether the corresponding clock reference is correctly led in.
l Yes: Replace the board, and then go to Step 2.
l No: Correctly lead in the clock reference and go to Step 2.
2. Check whether the alarm disappears.
l Yes: End.
l No: Contact ZTE.
Cause
The duration in which the input reference is in invalid status is larger than 10 minutes less
than 24 hours. Possible causes include:
l The clock reference input is abnormal.
l The configured clock reference does not exist.
Handling
1. Check whether the corresponding clock reference is correctly led in.
l Yes: Replace the board, and then go to Step 2.
l No: Correctly lead in this clock reference, and then go to Step 2.
2. Check whether this alarm disappears.
l Yes: End.
5-44
Cause
The duration in which the input reference is in invalid status is larger than 24 minutes.
Possible causes include:
l The clock reference input is abnormal.
l The configured clock reference does not exist.
Handling
1. Check whether the corresponding clock reference is correctly led in.
l Yes: Replace the board, and then go to Step 2.
l No: Correctly lead in this clock reference, and then go to Step 2.
2. Check whether this alarm disappears.
l Yes: End.
l No: Contact ZTE.
Cause
There are hardware faults in the board.
5-45
Handling
Replace the board, and check whether the alarm disappears.
l Yes: End.
l No: Contact ZTE.
Causes
l A major mechanical fan fault has occurred.
l The fan voltage is abnormal.
Handling
1. Wait until the alarm disappears. If the alarm still exists after a period, go to Step 2.
2. Check whether there is something absorbed into the fan device.
l Yes: Remove it from the fan device.
l No: Record the alarm and contact ZTE.
5-46
Causes
l A minor mechanical fan fault has occurred.
l The fan voltage is a little bit abnormal.
Handling
1. Wait until the alarm disappears. If the alarm still exists after a long period, go to Step
2.
2. Check whether there is something absorbed into the fan device.
l Yes: Remove it from the fan device.
l No: Record the alarm and contact ZTE.
Causes
l A fatal mechanical fan fault has occurred.
l The fan voltage is extremely abnormal.
Handling
Replace the fan, and then check whether the alarm disappears.
l Yes: Clear all foreign substances from the fan, so that the fan works properly.
l No: Record the abnormality, and then contact ZTE.
5-47
Cause
The IPMB-A is enabled and the IPMB-B is disabled.
Handling
Contact ZTE.
Cause
The IPMB-A is disabled and the IPMB-B is enabled.
Handling
Contact ZTE.
5-48
Cause
No SCTP association to the office is available.
Handling
1. Check whether there are any alarms for disconnected associations.
l Yes: Handle the alarm according to the handling suggestions in 2.29 Association
Link Broken (8402690).
l No: Go to Step 2.
2. On the MML Terminal or Terminal view of the NMS, check whether related association
is configured for the office.
l Yes: Go to Step 4.
l No: Go to Step 3.
3. Add the association configuration of the office and check whether the alarm
disappears.
l Yes: End.
l No: Go to Step 4.
4. Record the following information and contact ZTE.
l Configuration data of the local office and peer-end office.
l History alarms, history notifications, and current alarms of the local office and
peer-end office.
5-49
Cause
Of the CPU resource monitoring parameters, Switch is set to Close. If the OMM server
CPU utilization detected at a monitoring time point exceeds the set CPU utilization
threshold for N consecutive times (N = Consecutive CPU utilization out-of-limit alarm
threshold), this alarm is triggered.
Note:
When the CPU utilization is lower than 1%, the monitoring process returns a CPU utilization
of 1%. In other cases, the monitoring process directly returns the integer of the calculated
CPU utilization (instead of rounding up or down the CPU utilization. For example, the
monitoring process returns 6% if the calculation result of the current CPU utilization is
6.3% or 6.9%.
Monitoring time point: If Switch among the CPU resource monitoring parameters is set
to Open when the running environment monitoring thread is started, a CPU resource
monitoring timer is triggered. This timer will be triggered again at an interval (user-specified
monitoring period), and the system will read a new monitoring period (that is, changes to
the monitoring period do not take effect in real time but the monitoring period is updated at
the monitoring time point only). Monitoring is performed each time the monitoring timer is
triggered. Therefore, alarm recovery does not take effect in real time and the alarm of the
corresponding level is recovered only when the CPU utilization detected at the monitoring
time point is lower than the set threshold.
Handling
1. Run the top command on the NMS server to find the COMMAND in the rows where
the value of %CPU is large and check whether the processes are expected ones.
l Yes: Go to Step 2.
l No: Go to Step 3.
2. Kill the processes with high CPU utilization as required, or open the MML Terminal or
Terminal view of the NMS and run the SET CPUPARA command to change Switch
to Close, and then check whether the alarm disappears.
l Yes: End.
l No: Go to Step 4.
3. Confirm whether the processes are normal, take proper actions to remove faults, and
then check whether the alarm disappears.
l Yes: End.
l No: Go to Step 4.
4. Contact ZTE.
5-50
Cause
Of the memory resource monitoring parameters, Switch is set to Open. If the OMM server
memory utilization detected at the monitoring time point exceeds the set memory utilization
threshold for N consecutive times (N = Consecutive memory utilization out-of-limit alarm
threshold), this alarm is triggered.
Note:
When the memory utilization is lower than 1%, the monitoring process returns a memory
utilization of 1%. In other cases, the monitoring process directly returns the integer of the
calculated memory utilization (instead of rounding up or down the memory utilization. For
example, the monitoring process returns 6% if the calculation result of the current memory
utilization is 6.3% or 6.9%.
Monitoring time point: If Switch among the memory resource monitoring parameters is set
to Open when the running environment monitoring thread is started, a memory resource
monitoring timer is triggered. This timer will be triggered again at an interval (user-specified
monitoring period), and the system will read a new monitoring period (that is, changes to
the monitoring period do not take effect in real time but the monitoring period is updated
at the monitoring time point only). Monitoring is performed each time the monitoring timer
is triggered. Therefore, alarm recovery does not take effect in real time and the alarm
of the corresponding level is recovered only when the memory utilization detected at the
monitoring time point is lower than the set threshold.
Handling
1. Run the top command on the NMS server to find the COMMAND in the rows where
the value of %MEM is large and check whether the processes are expected ones.
l Yes: Go to Step 2.
l No: Go to Step 3.
5-51
2. Kill the processes with high memory utilization as required, or open the MML Terminal
or Terminal view of the NMS and run the SET MEMPARA command to change Switch
to Close, and then check whether the alarm disappears.
l Yes: End.
l No: Go to Step 4.
3. Confirm whether the processes are normal, take proper actions to remove faults, and
then check whether the alarm disappears.
l Yes: End.
l No: Go to Step 4.
4. Contact ZTE.
Cause
Of the global hard disk monitoring parameters, Switch is set to Open. For a specific
partition, Monitor Type is set to Absolute Value Monitor(M) or Percentage Monitor(%)
whereas Threshold-Critical is set to a non-0 value. If the hard disk utilization detected at
the monitoring time point exceeds the set monitoring threshold of the critical level, a level-1
alarm about the hard disk utilization of the partition is triggered.
Note:
Hardware partitions are monitored on the CGSL system.
Monitoring time point: If Switch among the global hard disk monitoring parameters is set
to Open when the running environment monitoring thread is started, a hard disk resource
monitoring timer is triggered. This timer will be triggered again at an interval (user-specified
monitoring period), and the system will read a new monitoring period (that is, changes to
the monitoring period do not take effect in real time but the monitoring period is updated
at the monitoring time point only). Monitoring is performed each time the monitoring timer
is triggered. Therefore, alarm recovery does not take effect in real time and the alarm of
the corresponding level is recovered only when the hard disk utilization detected at the
monitoring time point is lower than the set threshold.
5-52
Handling
1. On the MML Terminal or Terminal view of the NMS, run the SHOW HDPARA
command to check whether Switch among the global hard disk monitoring parameters
is set to Open and whether the monitoring period is reasonably set.
l Yes: Go to Step 2.
l No: Go to Step 7.
2. Check whether to enable hard disk monitoring.
l Yes: Go to Step 4.
l No: Go to Step 3.
3. On the MML Terminal or Terminal view of the NMS, run the SET HDPARA command
to change Switch among the global hard disk monitoring parameters to Close (it is
not recommended that hard disk monitoring be disabled), and then check whether the
alarm disappears.
l Yes: End.
l No: Go to Step 7.
4. On the MML Terminal or Terminal view of the NMS, run the SHOW PARTITIONPAR
A command to check whether Threshold-Critical is properly set among the hard disk
partition monitoring parameters.
l Yes: Go to Step 6.
l No: Go to Step 5.
5. On the MML Terminal or Terminal view of the NMS, run the SET PARTITIONPARA
command to change the settings of Threshold-Critical to a reasonable value, and
then check whether the alarm disappears.
l Yes: End.
l No: Go to Step 6.
6. Clear the files on the hard disk according to the alarm information and actual needs to
evacuate a sufficient space and ensure that the directory utilization is lower than the
monitoring threshold of the corresponding alarm level, and then check whether the
alarm disappears.
l Yes: End.
l No: Go to Step 7.
7. Contact ZTE.
5-53
Cause
Of the global hard disk monitoring parameters, Switch is set to Open. For a specific
partition, Monitor Type is set to Absolute Value Monitor(M) or Percentage Monitor(%)
whereas Threshold-Major is set to a non-0 value. If the hard disk utilization detected at
the monitoring time point exceeds the set monitoring threshold of the major level, a level-2
alarm about the hard disk utilization of the partition is triggered.
Note:
Hardware partitions are monitored on the CGSL system.
Monitoring time point: If Switch among the global hard disk monitoring parameters is set
to Open when the running environment monitoring thread is started, a hard disk resource
monitoring timer is triggered. This timer will be triggered again at an interval (user-specified
monitoring period), and the system will read a new monitoring period (that is, changes to
the monitoring period do not take effect in real time but the monitoring period is updated
at the monitoring time point only). Monitoring is performed each time the monitoring timer
is triggered. Therefore, alarm recovery does not take effect in real time and the alarm of
the corresponding level is recovered only when the hard disk utilization detected at the
monitoring time point is lower than the set threshold.
Handling
1. On the MML Terminal or Terminal view of the NMS, run the SHOW HDPARA
command to check whether Switch among the global hard disk monitoring parameters
is set to Open and whether the monitoring period is reasonably set.
l Yes: Go to Step 2.
l No: Go to Step 7.
2. Determine whether to enable hard disk monitoring.
l Yes: Go to Step 4.
l No: Go to Step 3.
3. On the MML Terminal or Terminal view of the NMS, run the SET HDPARA command
to change Switch among the global hard disk monitoring parameters to Close (it is
not recommended that hard disk monitoring be disabled), and then check whether the
alarm disappears.
l Yes: End.
5-54
l No: Go to Step 7.
4. On the MML Terminal or Terminal view of the NMS, run the SHOW PARTITIONPA
RA command to check whether Threshold-Major is properly set among the hard disk
partition monitoring parameters.
l Yes: Go to Step 6.
l No: Go to Step 5.
5. On the MML Terminal or Terminal view of the NMS, run the SET PARTITIONPARA
command to change the settings of Threshold-Major to a reasonable value, and then
check whether the alarm disappears.
l Yes: End.
l No: Go to Step 6.
6. Clear the files on the hard disk according to the alarm information and actual needs to
evacuate a sufficient space and ensure that the directory utilization is lower than the
monitoring threshold of the corresponding alarm level, and then check whether the
alarm disappears.
l Yes: End.
l No: Go to Step 7.
7. Contact ZTE.
Cause
Of the global hard disk monitoring parameters, Switch is set to Open. For a specific
partition, Monitor Type is set to Absolute Value Monitor(M) or ercentage Monitor(%)
whereas Threshold-Minor is set to a non-0 value. If the hard disk utilization detected
at the monitoring time point exceeds the set monitoring threshold of the minor level but
does not reach the monitoring thresholds of the major and critical levels (the value 0 is not
compared), a level-3 alarm about the hard disk utilization of the partition is triggered.
5-55
Note:
Hardware partitions are monitored on the CGSL system.
Monitoring time point: If Switch among the global hard disk monitoring parameters is set
to Open when the running environment monitoring thread is started, a hard disk resource
monitoring timer is triggered. This timer will be triggered again at an interval (user-specified
monitoring period), and the system will read a new monitoring period (that is, changes to
the monitoring period do not take effect in real time but the monitoring period is updated
at the monitoring time point only). Monitoring is performed each time the monitoring timer
is triggered. Therefore, alarm recovery does not take effect in real time and the alarm of
the corresponding level is recovered only when the hard disk utilization detected at the
monitoring time point is lower than the set threshold.
Handling
1. On the MML Terminal or Terminal view of the NMS, run the SHOW HDPARA
command to check whether Switch among the global hard disk monitoring parameters
is set to Open and whether the monitoring period is reasonably set.
l Yes: Go to Step 2.
l No: Go to Step 7.
2. Determine whether to enable hard disk monitoring.
l Yes: Go to Step 4.
l No: Go to Step 3.
3. On the MML Terminal or Terminal view of the NMS, run the SET HDPARA command
to change Switch among the global hard disk monitoring parameters to Open (it is
not recommended that hard disk monitoring be disabled), and then check whether the
alarm disappears.
l Yes: End.
l No: Go to Step 7.
4. On the MML Terminal or Terminal view of the NMS, run the SHOW PARTITIONPA
RA command to check whether Threshold-Minor is properly set among the hard disk
partition monitoring parameters.
l Yes: Go to Step 6.
l No: Go to Step 5.
5. On the MML Terminal or Terminal view of the NMS, run the SET PARTITIONPARA
command to change the settings of Threshold-Minor to a reasonable value, and then
check whether the alarm disappears.
l Yes: End.
l No: Go to Step 6.
5-56
6. Clear the files on the hard disk according to the alarm information and actual needs to
evacuate a sufficient space and ensure that the directory utilization is lower than the
monitoring threshold of the corresponding alarm level, and then check whether the
alarm disappears.
l Yes: End.
l No: Go to Step 7.
7. Contact ZTE.
Cause
Of the global hard disk monitoring parameters, Switch is set to Open. For a specific
partition, Monitor Type is set to Absolute Value Monitor(M) or Percentage Monitor(%)
whereas Threshold-Warning is set to a non-0 value. If the hard disk utilization detected at
a monitoring time point exceeds the set monitoring threshold of the warning level but does
not reach the monitoring thresholds of the minor, major, and critical levels (the value 0 is
not compared), a level-4 alarm about the hard disk utilization of the partition is triggered.
Note:
Hardware partitions are monitored on the CGSL system.
Monitoring time point: If Switch among the global hard disk monitoring parameters is set
to Open when the running environment monitoring thread is started, a hard disk resource
monitoring timer is triggered. This timer will be triggered again at an interval (user-specified
monitoring period), and the system will read a new monitoring period (that is, changes to
the monitoring period do not take effect in real time but the monitoring period is updated
at the monitoring time point only). Monitoring is performed each time the monitoring timer
is triggered. Therefore, alarm recovery does not take effect in real time and the alarm of
the corresponding level is recovered only when the hard disk utilization detected at the
monitoring time point is lower than the set threshold.
5-57
Handling
1. On the MML Terminal or Terminal view of the NMS, run the SHOW HDPARA
command to check whether Switch among the global hard disk monitoring parameters
is set to Open and whether the monitoring period is reasonably set.
l Yes: Go to Step 2.
l No: Go to Step 7.
2. Check whether to enable hard disk monitoring.
l Yes: Go to Step 4.
l No: Go to Step 3.
3. On the MML Terminal or Terminal view of the NMS, run the SET HDPARA command
to change Switch among the global hard disk monitoring parameters to Close (it is
not recommended that hard disk monitoring be disabled), and then check whether the
alarm disappears.
l Yes: End.
l No: Go to Step 7.
4. On the MML Terminal or Terminal view of the NMS, run the SHOW PARTITIONP
ARA command to check whether Threshold-Warning is properly set among the hard
disk partition monitoring parameters.
l Yes: Go to Step 6.
l No: Go to Step 5.
5. On the MML Terminal or Terminal view of the NMS, run the SET PARTITIONPARA
command to change the settings of Threshold-Warning to a reasonable value, and
then check whether the alarm disappears.
l Yes: End.
l No: Go to Step 6.
6. Clear the files on the hard disk according to the alarm information and actual needs to
evacuate a sufficient space and ensure that the directory utilization is lower than the
monitoring threshold of the corresponding alarm level, and then check whether the
alarm disappears.
l Yes: End.
l No: Go to Step 7.
7. Contact ZTE.
5-58
Cause
A monitored object in directory resource monitoring parameter configuration is uniquely
determined by Directory Description, File Type, and Is Include Sub-Directory. For a
specific object, Switch is set to Open whereas Threshold-Critical(M) is set to a non-0
value. When the file size detected at the monitoring time point exceeds the set monitoring
threshold of the critical level, a level-1 alarm about the directory utilization of the object is
triggered.
Note:
l File size
The file size refers to the total size of files of the specified file type in the set Directory
Description. If the file type is "*", all types of files are monitored. If Is Include
Sub-Directory is set to Yes, all files in this directory and all its subdirectories are
monitored. Otherwise, only the files in the directory are monitored.
l Monitoring time point
If Switch is set to Open for an object when the running environment monitoring
thread is started, a directory resource monitoring timer is triggered. This timer will be
triggered again at an interval (user-specified monitoring period), and the system will
read a new monitoring period (that is, changes to the monitoring period do not take
effect in real time but the monitoring period is updated at the monitoring time point
only). Monitoring is performed each time the monitoring timer is triggered. Therefore,
alarm recovery does not take effect in real time and the alarm of the corresponding
level is recovered only when the directory utilization detected at the monitoring time
point is lower than the set threshold.
Handling
1. On the MML Terminal or Terminal view of the NMS, run the SHOW DIRPARA
command to check whether Switch is set to Open for the corresponding directory
indicated in the alarm information and whether the monitoring period is properly set.
l Yes: Go to Step 2.
l No: Go to Step 7.
2. Determine whether to enable monitoring for the directory.
l Yes: Go to Step 4.
l No: Go to Step 3.
5-59
3. On the MML Terminal or Terminal view of the NMS, run the SET DIRPARA command
to change the settings of SWITCH to Close for the corresponding directory indicated
in the alarm information (it is not commended that directory monitoring be disabled),
and then check whether the alarm disappears.
l Yes: End.
l No: Go to Step 7.
4. On the MML Terminal or Terminal view of the NMS, run the SHOW DIRPARA
command to check whether Threshold-Critical(M) is properly set.
l Yes: Go to Step 6.
l No: Go to Step 5.
5. On the MML Terminal or Terminal view of the NMS, run the SET DIRPARA command
to change the settings of Threshold-Critical(M) to a reasonable value, and then check
whether the alarm disappears.
l Yes: End.
l No: Go to Step 6.
6. Clear the files on the hard disk according to the alarm information and actual needs to
evacuate a sufficient space and ensure that the directory utilization is lower than the
monitoring threshold of the corresponding alarm level, and then check whether the
alarm disappears.
l Yes: End.
l No: Go to Step 7.
7. Contact ZTE.
Cause
A monitored object in directory resource monitoring parameter configuration is uniquely
determined by Directory Description, File Type, and Is Include Sub-Directory. For a
specific object, Switch is set to Open whereas Threshold-Major(M) is set to a non-0
value. When the file size detected at the monitoring time point exceeds the set monitoring
threshold of the major level but does not exceed the monitoring thresholds of the critical
level (the value 0 is not compared), a level-2 alarm about the directory utilization of the
object is triggered.
5-60
Note:
l File size
The file size refers to the total size of files of the specified file type in the set Directory
Description. If the file type is "*", all types of files are monitored. If Is Include
Sub-Directory is set to Yes, all files in this directory and all its subdirectories are
monitored. Otherwise, only the files in the directory are monitored.
l Monitoring time point
If Switch is set to Open for an object when the running environment monitoring
thread is started, a directory resource monitoring timer is triggered. This timer will be
triggered again at an interval (user-specified monitoring period), and the system will
read a new monitoring period (that is, changes to the monitoring period do not take
effect in real time but the monitoring period is updated at the monitoring time point
only). Monitoring is performed each time the monitoring timer is triggered. Therefore,
alarm recovery does not take effect in real time and the alarm of the corresponding
level is recovered only when the directory utilization detected at the monitoring time
point does not reach the set threshold.
Handling
1. On the MML Terminal or Terminal view of the NMS, run the SHOW DIRPARA
command to check whether Switch is set to Open for the corresponding directory
indicated in the alarm information and whether the monitoring period is properly set.
l Yes: Go to Step 2.
l No: Go to Step 7.
2. Determine whether to enable monitoring for the directory.
l Yes: Go to Step 4.
l No: Go to Step 3.
3. On the MML Terminal or Terminal view of the NMS, run the SET DIRPARA command
to change the settings of Switch to Close for the corresponding directory indicated in
the alarm information (it is not commended that hard disk monitoring be disabled), and
then check whether the alarm disappears.
l Yes: End.
l No: Go to Step 7.
4. On the MML Terminal or Terminal view of the NMS, run the SHOW DIRPARA
command to check whether Threshold-Major(M) is properly set.
l Yes: Go to Step 6.
l No: Go to Step 5.
5-61
5. On the MML Terminal or Terminal view of the NMS, run the SET DIRPARA command
to change the settings of Threshold-Major(M) to a reasonable value, and then check
whether the alarm disappears.
l Yes: End.
l No: Go to Step 6.
6. Clear the files on the hard disk according to the alarm information and actual needs to
evacuate a sufficient space and ensure that the directory utilization is lower than the
monitoring threshold of the corresponding alarm level, and then check whether the
alarm disappears.
l Yes: End.
l No: Go to Step 7.
7. Contact ZTE.
Cause
A monitored object in directory resource monitoring parameter configuration is uniquely
determined by Directory Description, File Type, and Is Include Sub-Directory. For a
specific object, Switch is set to Open whereas Threshold-Minor(M) is set to a non-0
value. When the file size detected at the monitoring time point exceeds the set monitoring
threshold of the minor level but does not exceed the monitoring thresholds of the major and
critical levels (the value 0 is not compared), a level-3 alarm about the directory utilization
of the object is triggered.
5-62
Note:
l File size
The file size refers to the total size of files of the specified file type in the set Directory
Description. If the file type is "*", all types of files are monitored. If Is Include
Sub-Directory is set to Yes, all files in this directory and all its subdirectories are
monitored. Otherwise, only the files in the directory are monitored.
l Monitoring time point
If Switch is set to Open for an object when the running environment monitoring
thread is started, a directory resource monitoring timer is triggered. This timer will be
triggered again at an interval (user-specified monitoring period), and the system will
read a new monitoring period (that is, changes to the monitoring period do not take
effect in real time but the monitoring period is updated at the monitoring time point
only). Monitoring is performed each time the monitoring timer is triggered. Therefore,
alarm recovery does not take effect in real time and the alarm of the corresponding
level is recovered only when the directory utilization detected at the monitoring time
point does not reach the set threshold.
Handling
1. On the Terminal or MML Terminal view of the NMS, run the SHOW DIRPARA
command to check whether Switch is set to Open for the corresponding directory
indicated in the alarm information and whether the monitoring period is properly set.
l Yes: Go to Step 2.
l No: Go to Step 7.
2. Determine whether to enable monitoring for the directory.
l Yes: Go to Step 4.
l No: Go to Step 3.
3. On the Terminal or MML Terminal view of the NMS, run the SET DIRPARA command
to change the settings of Switch to Close for the corresponding directory indicated in
the alarm information (it is not commended that hard disk monitoring be disabled), and
then check whether the alarm disappears.
l Yes: End.
l No: Go to Step 7.
4. On the Terminal or MML Terminal view of the NMS, run the SHOW DIRPARA
command to check whether Threshold-Minor(M) is properly set.
l Yes: Go to Step 6.
l No: Go to Step 5.
5-63
5. On the Terminal or MML Terminal view of the NMS, run the SET DIRPARA command
to change the settings of Threshold-Minor(M) to a reasonable value, and then check
whether the alarm disappears.
l Yes: End.
l No: Go to Step 6.
6. Clear the files on the hard disk according to the alarm information and actual needs to
evacuate a sufficient space and ensure that the directory utilization is lower than the
monitoring threshold of the corresponding alarm level, and then check whether the
alarm disappears.
l Yes: End.
l No: Go to Step 7.
7. Contact ZTE.
Cause
A monitored object in directory resource monitoring parameter configuration is uniquely
determined by Directory Description, File Type, and Is Include Sub-Directory. For a
specific object, Switch is set to Open whereas Threshold-Warning(M) is set to a non-0
value. When the file size detected at the monitoring time point exceeds the set monitoring
threshold of the warning level but does not exceed the monitoring thresholds of the minor,
major, and critical levels (the value 0 is not compared), a level-4 alarm about the directory
utilization of the object is triggered.
5-64
Note:
l File size
The file size refers to the total size of files of the specified file type in the set Directory
Description. If the file type is "*", all types of files are monitored. If Is Include
Sub-Directory is set to Yes, all files in this directory and all its subdirectories are
monitored. Otherwise, only the files in the directory are monitored.
l Monitoring time point
If Switch is set to Open for an object when the running environment monitoring
thread is started, a directory resource monitoring timer is triggered. This timer will be
triggered again at an interval (user-specified monitoring period), and the system will
read a new monitoring period (that is, changes to the monitoring period do not take
effect in real time but the monitoring period is updated at the monitoring time point
only). Monitoring is performed each time the monitoring timer is triggered. Therefore,
alarm recovery does not take effect in real time and the alarm of the corresponding
level is recovered only when the directory utilization detected at the monitoring time
point does not reach the set threshold.
Handling
1. On the Terminal or MML Terminal view of the NMS, run the SHOW DIRPARA
command to check whether Switch is set to Open for the corresponding directory
indicated in the alarm information and whether the monitoring period is properly set.
l Yes: Go to Step 2.
l No: Go to Step 7.
2. Determine whether to enable monitoring for the directory.
l Yes: Go to Step 4.
l No: Go to Step 3.
3. On the Terminal or MML Terminal view of the NMS, run the SET DIRPARA command
to change the settings of Switch to Close for the corresponding directory indicated in
the alarm information (it is not commended that hard disk monitoring be disabled), and
then check whether the alarm disappears.
l Yes: End.
l No: Go to Step 7.
4. On the Terminal or MML Terminal view of the NMS, run the SHOW DIRPARA
command to check whether Threshold-Minor(M) is properly set.
l Yes: Go to Step 6.
l No: Go to Step 5.
5-65
5. On the Terminal or MML Terminal view of the NMS, run the SET DIRPARA command
to change the settings of Threshold-Minor(M) to a reasonable value, and then check
whether the alarm disappears.
l Yes: End.
l No: Go to Step 6.
6. Clear the files on the hard disk according to the alarm information and actual needs to
evacuate a sufficient space and ensure that the directory utilization is lower than the
monitoring threshold of the corresponding alarm level, and then check whether the
alarm disappears.
l Yes: End.
l No: Go to Step 7.
7. Contact ZTE.
Cause
The link between the modules DBIO and HSMAPP is interrupted.
Handling
The network is abnormal. Check the network connection between DBIO and HSMAPP.
5-66
Cause
The HSMAPP module is in abnormal status and alarms are generated.
Handling
HSMAPP is abnormal. Check the status of HSMAPP.
5-67
5-68
Cause
The environmental temperature is lower than the normal value.
6-1
Handling
1. Wait until the alarm disappears. If the alarm still exists after a long period, go to Step
2.
2. Check whether the environmental temperature of the equipment room is low.
l Yes: Adjust the temperature of the equipment room to the normal value range.
l No: Record the alarm and contact ZTE.
Cause
The environmental temperature is too low.
Handling
1. Wait until the alarm disappears. If the alarm still exists after a long period, go to Step
2.
2. Check whether the environmental temperature of the equipment room is quite low.
l Yes: Adjust the temperature of the equipment room to the normal value range.
l No: Record the alarm and contact ZTE.
6-2
Cause
The environmental temperature is extremely low.
Handling
Take off the device from the shelf, and contact ZTE.
Causes
l The environmental temperature is higher than the normal value.
l The velocity of the fan is lower than the normal value.
l The filter tray is dusty.
Handling
1. Wait until the alarm disappears. After a period, check whether the alarm disappears.
l Yes: End.
l No: Go to Step 2.
2. Check whether the temperature of the equipment room is high.
l Yes: Go to Step 3.
l No: Go to Step 4.
3. Reduce the temperature in the equipment room. After a period, check whether the
alarm disappears.
l Yes: End.
l No: Go to Step 4.
4. Check whether the velocity of the fan is low
l Yes: Go to Step 5.
l No: Go to Step 6.
5. Increase the velocity of the fan. After a period, check whether the alarm disappears.
6-3
l Yes: End.
l No: Go to Step 6.
6. Check whether the filter tray is dusty.
l Yes: Go to Step 7.
l No: Go to Step 8.
7. Clean the filter tray. After a period, check whether the alarm disappears.
l Yes: End.
l No: Go to Step 8.
8. Record the alarm and contact ZTE.
Causes
l The environmental temperature is too high.
l The velocity of the fan is too low.
l The filter tray is very dusty.
Handling
1. Wait until the alarm disappears. After a period, check whether the alarm disappears.
l Yes: End.
l No: Go to Step 2.
2. Check whether the temperature of the equipment room is too high.
l Yes: Go to Step 3.
l No: Go to Step 4.
3. Reduce the temperature in the equipment room. After a period, check whether the
alarm disappears.
l Yes: End.
l No: Go to Step 4.
4. Check whether the velocity of the fan is too low
l Yes: Go to Step 5.
l No: Go to Step 6.
5. Increase the velocity of the fan. After a period, check whether the alarm disappears.
6-4
l Yes: End.
l No: Go to Step 6.
6. Check whether the filter tray is too dusty.
l Yes: Go to Step 7.
l No: Go to Step 8.
7. Clean the filter tray. After a period, check whether the alarm disappears.
l Yes: End.
l No: Go to Step 8.
8. Record the alarm and contact ZTE.
Causes
l The environmental temperature is extremely high.
l The velocity of the fan is extremely low.
l The filter tray is extremely dusty.
Handling
1. Wait two minutes, and then check whether the alarm disappears.
l Yes: End.
l No: Go to Step 2.
2. Take off the device from the shelf, and contact ZTE.
6-5
Causes
l The voltage fluctuates.
l The resistance is invalid.
l The equipment payload fluctuates.
l The voltage deviates because of the improper temperature of the shelf’s environment.
Handling
1. Wait until the alarm disappears. If the alarm still exists after a long period, go to Step
2.
2. Check whether the power supply of the equipment room is abnormal.
l Yes: Contact the power supply engineer.
l No: Record the alarm and contact ZTE.
Causes
l The voltage fluctuates.
l The resistance is invalid.
l The equipment payload fluctuates.
l The voltage deviates because of the improper temperature of the shelf’s environment.
Handling
1. Wait until the alarm disappears. If the alarm still exists after a long period, go to Step
2.
2. Check whether the power supply of the equipment room is abnormal.
6-6
Causes
l The voltage fluctuates.
l The resistance is invalid.
l The equipment payload fluctuates.
l The voltage deviates because of the improper temperature of the shelf’s environment.
Handling
Take off the device from the shelf, and contact ZTE.
Causes
l The voltage fluctuates.
l The resistance is invalid.
l The equipment payload fluctuates.
l The voltage deviates because of the improper temperature of the shelf’s environment.
6-7
Handling
1. Wait until the alarm disappears. If the alarm still exists after a long period, go to Step
2.
2. Check for abnormality of the power supply of the equipment room.
l Yes: Contact the power supply engineer.
l No: Record the alarm and contact ZTE.
Causes
l The voltage fluctuates.
l The resistance is invalid.
l The equipment payload fluctuates.
l The voltage deviates because of the improper temperature of the shelf’s environment.
Handling
1. Wait until the alarm disappears. If the alarm still exists after a long period, go to Step
2.
2. Check whether the power supply of the equipment room is abnormal
l Yes: Contact the power supply engineer.
l No: Record the alarm and contact ZTE.
6-8
Causes
l The voltage fluctuates.
l The resistance is invalid.
l The equipment payload fluctuates.
l The voltage deviates because of the improper temperature of the shelf’s environment.
Handling
Take off the device from the shelf, and contact ZTE.
Cause
The filter tray has not been cleaned or changed for too long a time.
Handling
Change or clean the filter tray immediately.
6-9
Cause
The filter tray has not been cleaned or changed for quite a long time.
Handling
Take off the filter tray and change it.
Cause
The filter tray has not been cleaned or changed for a relatively long time.
Handling
Take off the filter tray and change it or clean it.
6-10
Causes
l The voltage of the voltage regulating circuit is too high.
l The voltage regulating circuit is out of work.
l The switch of the power supply is turned on.
l The battery is too low.
Handling
1. Check whether the air switch of the power supply is on.
l Yes: Go to Step 2.
l No: Go to Step 3.
2. Switch off the air switch for power and check whether the alarm disappears.
l Yes: End.
l No: Go to Step 3.
3. Check whether the power supply of the equipment room is normal.
l Yes: Go to Step 5.
l No: Go to Step 4.
4. Make sure the power supply of the equipment room is normal and check whether the
alarm disappears.
l Yes: End.
l No: Go to Step 5.
5. Check whether the battery has too low capacity.
l Yes: Go to Step 6.
l No: Go to Step 7.
6. Replace the battery and check whether the alarm disappears.
l Yes: End.
l No: Go to Step 7.
7. Record the alarm and contact ZTE.
6-11
6-12
CSU
- Control and Storage Unit
DB
- DataBase
DBIO
- DataBase Input & Output
DDF
- Digital Distribution Frame
DSA
- Directory System Agent
DSP
- Directory System Protocol
DST
- Data Storage Transfer
EMS
- Network Element Management System
EPLD
- Erasable Programmable Logic Device
I
ZXUN USPP HLR Alarm Message Reference
EPU
- Epilogue Process Unit
FAS
- Frame Alignment Signal
HEC
- Header Error Check
HLR
- Home Location Register
ICP
- Internet Content Provider
IMA
- Inverse Multiplexing over ATM
IP
- Internet Protocol
LDAP
- Lightweight Directory Access Protocol
LIF
- Loss of IMA Frame
LODS
- Link Out of Delay Synchronization defect
M2PA
- MTP2-User Peer-to-Peer Adaptation Layer Protocol
M3UA
- MTP3-User Adaptation layer protocol
MP
- Main Processor
MTP2
- Message Transfer Part layer 2
MTP3
- Message Transfer Part layer 3
NE
- Network Element
NMS
- Network element Management System
NTP
- Network Time Protocol
OAM
- Operation, Administration and Maintenance
II
Glossary
OMC
- Operation & Maintenance Center
OMM
- Operation & Maintenance Module
OMP
- Operation & Maintenance Processor
PEM
- Power Entry Module
PP
- Peripheral Processor
PPP
- Point to Point Protocol
PS
- Packet Switched
PVC
- Permanent Virtual Channel
QoS
- Quality of Service
RDI
- Remote Defect Indication
RPU
- Router Process Unit
SCCP
- Signaling Connection Control Part
SCTP
- Stream Control Transmission Protocol
SETS
- Synchronous Equipment Timing Source
SIO
- Service Information Octet
SLC
- Signaling Link Code
SNTP
- Simple Network Time Protocol
SSCOP
- Service Specific Connection Oriented Protocol
SSN
- Sub-System Number
III
ZXUN USPP HLR Alarm Message Reference
STC
- Signaling Transport Converter
SUA
- SCCP User Adaptation
TC
- Trunk Circuit
TIPC
- Transparent Interprocess Communication
UDS
- Universal Directory Server
VCI
- Virtual Channel Identifier
VPI
- Virtual Path Identifier
ZTE
- Zhongxing Telecommunications Equipment
IV