Professional Documents
Culture Documents
System
V100R010
Issue 16
Date 2016-12-31
and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd.
All other trademarks and trade names mentioned in this document are the property of their respective
holders.
Notice
The purchased products, services and features are stipulated by the contract made between Huawei and the
customer. All or part of the products, services and features described in this document may not be within the
purchase scope or the usage scope. Unless otherwise specified in the contract, all statements, information,
and recommendations in this document are provided "AS IS" without warranties, guarantees or
representations of any kind, either express or implied.
The information in this document is subject to change without notice. Every effort has been made in the
preparation of this document to ensure accuracy of the contents, but all statements, information, and
recommendations in this document do not constitute a warranty of any kind, express or implied.
Website: http://www.huawei.com
Email: support@huawei.com
Related Versions
The following table lists the product versions related to this document.
Intended Audience
This document describes the alarms and performance events of the OptiX OSN equipment in
terms of generation principles, classification list, and handling methods.
Symbol Conventions
The symbols that may be found in this document are defined as follows.
Symbol Description
Symbol Description
GUI Conventions
The GUI conventions that may be found in this document are defined as follows.
Convention Description
Change History
Updates between document issues are cumulative. Therefore, the latest document issue
contains all updates made in previous issues.
l Adds the PWD_ENCRYPT_RISK alarm in "Alarm List P" in "Alarm List in the
Alphabetical Order".
l Adds the PWD_ENCRYPT_RISK alarm for the GSCC board of the system control,
cross-connect, and line board in "Board Alarm List".
l Revises the parameters of the POWER_ABNORMAL and LSR_WILL_DIE alarms in
"Common Alarm Handling".
l Revises the related information of the SECU_ALM alarm in "Other Alarm Handling".
l Adds the Delayed frames, Late collisions, Single Collision Frames, and Multiple
Collision Frames performance events for N1EMS4 board in "Statistics of RMON
extended performance" in "Board Performance Event List".
l Adds the Delayed frames, Late collisions, Single Collision Frames, and Multiple
Collision Frames performance events in "Statistics of RMON extended performance".
Contents
5 Performance Threshold.............................................................................................................. 52
6 Alarm List......................................................................................................................................53
6.1 Alarm List in the Alphabetical Order........................................................................................................................... 54
6.1.1 Alarm List A.............................................................................................................................................................. 54
6.1.2 Alarm List B.............................................................................................................................................................. 55
6.1.3 Alarm List C.............................................................................................................................................................. 56
6.1.4 Alarm List D.............................................................................................................................................................. 57
6.1.5 Alarm List E.............................................................................................................................................................. 58
6.1.6 Alarm List F...............................................................................................................................................................59
6.1.7 Alarm List H.............................................................................................................................................................. 60
6.1.8 Alarm List I............................................................................................................................................................... 60
6.1.9 Alarm List J............................................................................................................................................................... 61
6.1.10 Alarm List K............................................................................................................................................................ 61
6.1.11 Alarm List L.............................................................................................................................................................61
6.1.12 Alarm List M........................................................................................................................................................... 64
6.1.13 Alarm List N............................................................................................................................................................ 65
6.1.14 Alarm List O............................................................................................................................................................ 66
6.1.15 Alarm List P.............................................................................................................................................................67
6.1.16 Alarm List R............................................................................................................................................................ 68
6.1.17 Alarm List S.............................................................................................................................................................70
6.1.18 Alarm List T............................................................................................................................................................ 72
6.1.19 Alarm List U............................................................................................................................................................ 74
6.1.20 Alarm List V............................................................................................................................................................ 74
6.1.21 Alarm List W........................................................................................................................................................... 75
6.2 Board Alarm List.......................................................................................................................................................... 76
6.2.1 BA2............................................................................................................................................................................76
6.2.2 N1BPA....................................................................................................................................................................... 76
6.2.3 N2BPA....................................................................................................................................................................... 76
6.2.4 CAU...........................................................................................................................................................................77
6.2.5 COA...........................................................................................................................................................................77
6.2.6 N1ADL4.................................................................................................................................................................... 77
6.2.7 N1ADQ1....................................................................................................................................................................78
6.2.8 N1DX1.......................................................................................................................................................................79
6.2.9 N1DXA......................................................................................................................................................................79
6.2.10 N1EFS0................................................................................................................................................................... 80
6.2.11 N1EFS0A.................................................................................................................................................................81
6.2.12 N1EFS4................................................................................................................................................................... 81
6.2.13 N1EFT8................................................................................................................................................................... 82
6.2.14 N1EFT8A................................................................................................................................................................ 83
6.2.15 N1EGS4...................................................................................................................................................................84
6.2.16 N1EGT2...................................................................................................................................................................85
6.2.17 N1EMS2.................................................................................................................................................................. 85
6.2.18 N1EMS4.................................................................................................................................................................. 86
6.2.19 N1EFP0................................................................................................................................................................... 88
6.2.20 N1IDL4....................................................................................................................................................................89
6.2.21 N1IDL4A.................................................................................................................................................................90
6.2.22 N1IDQ1................................................................................................................................................................... 91
6.2.23 N1IDQ1A................................................................................................................................................................ 92
6.2.24 N1IFSD1..................................................................................................................................................................93
6.2.25 N1LWX....................................................................................................................................................................93
6.2.26 N1MST4.................................................................................................................................................................. 94
6.2.27 N1PD3..................................................................................................................................................................... 94
6.2.28 N1PL3......................................................................................................................................................................95
6.2.29 N1PL3A...................................................................................................................................................................95
6.2.30 N1PQ1..................................................................................................................................................................... 96
6.2.31 N1PQM....................................................................................................................................................................96
6.2.32 N1RPC01.................................................................................................................................................................97
6.2.33 N1RPC02.................................................................................................................................................................97
6.2.34 N1SEP..................................................................................................................................................................... 97
6.2.35 N1SEP1................................................................................................................................................................... 98
6.2.36 N1SF16.................................................................................................................................................................... 99
6.2.37 N1SL1....................................................................................................................................................................100
6.2.38 N1SL1A.................................................................................................................................................................101
6.2.39 N1SL4....................................................................................................................................................................102
6.2.40 N1SL4A.................................................................................................................................................................103
6.2.41 N1SL16..................................................................................................................................................................103
6.2.42 N1SL16A...............................................................................................................................................................104
6.2.43 N1SLD4.................................................................................................................................................................105
6.2.44 N1SLD4A.............................................................................................................................................................. 106
6.2.45 N1SLQ1.................................................................................................................................................................107
6.2.46 N1SLQ1A.............................................................................................................................................................. 108
6.2.47 N1SLQ4.................................................................................................................................................................109
6.2.48 N1SLQ4A.............................................................................................................................................................. 110
6.2.49 N1SLT1..................................................................................................................................................................110
6.2.50 N1SPQ4................................................................................................................................................................. 111
6.2.51 N2EFS0..................................................................................................................................................................112
6.2.52 N2EFS4..................................................................................................................................................................113
6.2.53 N2EFT8................................................................................................................................................................. 114
6.2.54 N2EFT8A...............................................................................................................................................................114
6.2.55 N2EGR2.................................................................................................................................................................115
6.2.56 N2EGS2................................................................................................................................................................. 116
6.2.57 N2EGT2.................................................................................................................................................................117
6.2.58 N2EMR0................................................................................................................................................................117
6.2.59 N2PD3................................................................................................................................................................... 118
6.2.60 N2PL3....................................................................................................................................................................119
6.2.61 N2PL3A................................................................................................................................................................. 119
6.2.62 N2PQ1................................................................................................................................................................... 120
6.2.63 N2PQ3................................................................................................................................................................... 121
6.2.64 N2SL1....................................................................................................................................................................121
6.2.65 N2SL4....................................................................................................................................................................122
6.2.66 N2SL16..................................................................................................................................................................123
6.2.67 N2SL16A...............................................................................................................................................................124
6.2.68 N2SLD4.................................................................................................................................................................126
6.2.69 N2SLO1.................................................................................................................................................................127
6.2.70 N2SLQ1.................................................................................................................................................................128
6.2.71 N2SLQ4.................................................................................................................................................................129
6.2.72 N2SPQ4................................................................................................................................................................. 130
6.2.73 N3EFS4................................................................................................................................................................. 131
6.2.74 N3EGS2.................................................................................................................................................................131
6.2.75 N3EGS4.................................................................................................................................................................132
6.2.76 N3SL16..................................................................................................................................................................133
6.2.77 N3SL16A...............................................................................................................................................................135
6.2.78 N3SLQ41...............................................................................................................................................................136
6.2.79 N3SLO1.................................................................................................................................................................137
6.2.80 N4EFS0................................................................................................................................................................. 138
6.2.81 N4EGS4.................................................................................................................................................................139
6.2.82 N4SLD64...............................................................................................................................................................140
6.2.83 N5EFS0................................................................................................................................................................. 141
6.2.84 ODU.......................................................................................................................................................................142
6.2.85 Q2CXL1................................................................................................................................................................ 142
6.2.86 Q2CXL4................................................................................................................................................................ 144
6.2.87 Q2CXL16.............................................................................................................................................................. 146
6.2.88 Q3CXL1................................................................................................................................................................ 148
6.2.89 Q3CXL4................................................................................................................................................................ 150
6.2.90 Q3CXL16.............................................................................................................................................................. 152
6.2.91 Q5CXLLN............................................................................................................................................................. 154
6.2.92 Q5CXLQ41........................................................................................................................................................... 157
6.2.93 R1AMU................................................................................................................................................................. 160
6.2.94 R1AUX.................................................................................................................................................................. 160
6.2.95 R2AUX.................................................................................................................................................................. 161
6.2.96 R1CXLLN............................................................................................................................................................. 161
6.2.97 R1CXLD41............................................................................................................................................................163
6.2.98 R1CXLQ41............................................................................................................................................................165
6.2.99 R1EFT4................................................................................................................................................................. 167
6.2.100 R1EOW............................................................................................................................................................... 168
6.2.101 R1FAN.................................................................................................................................................................168
9.21 APS_MANUAL_STOP............................................................................................................................................525
9.22 AU_CMM.................................................................................................................................................................526
9.23 B3_EXC_VC3.......................................................................................................................................................... 527
9.24 B3_EXC_VC4.......................................................................................................................................................... 530
9.25 B3_SD_VC3............................................................................................................................................................. 531
9.26 B3_SD_VC4............................................................................................................................................................. 533
9.27 BD_NOT_INSTALLED...........................................................................................................................................534
9.28 BD_AT_LOWPOWER.............................................................................................................................................535
9.29 BDID_ERROR......................................................................................................................................................... 536
9.30 BEFFEC_SD............................................................................................................................................................ 538
9.31 BIP8_ECC................................................................................................................................................................ 539
9.32 BIOS_STATUS.........................................................................................................................................................540
9.33 BOOTROM_BAD....................................................................................................................................................542
9.34 C2_PDI..................................................................................................................................................................... 543
9.35 C2_VCAIS................................................................................................................................................................545
9.36 C4_R_LAISD........................................................................................................................................................... 547
9.37 C4_T_LAISD........................................................................................................................................................... 548
9.38 CC_LOC................................................................................................................................................................... 550
9.39 CFCARD_FULL...................................................................................................................................................... 553
9.40 CFCARD_FAILED.................................................................................................................................................. 554
9.41 CFCARD_OFFLINE................................................................................................................................................555
9.42 CFCARD_W_R_DISABLED.................................................................................................................................. 556
9.43 CFGBD_FAIL.......................................................................................................................................................... 556
9.44 CHCS........................................................................................................................................................................558
9.45 CHIP_ABN...............................................................................................................................................................559
9.46 CHIP_FAIL...............................................................................................................................................................560
9.47 CLK_NO_TRACE_MODE......................................................................................................................................563
9.48 COOL_CUR_OVER................................................................................................................................................ 564
9.49 CRC4_ERR_OVER..................................................................................................................................................565
9.50 CRC6_ERR_OVER..................................................................................................................................................567
9.51 CTS........................................................................................................................................................................... 568
9.52 DBMS_ERROR........................................................................................................................................................569
9.53 DBMS_PROTECT_MODE..................................................................................................................................... 570
9.54 DCC_CHAN_LACK................................................................................................................................................571
9.55 DCD..........................................................................................................................................................................573
9.56 DDN_AIS................................................................................................................................................................. 574
9.57 DDN_ALOS............................................................................................................................................................. 575
9.58 DDN_CRC4_ERR_OVER....................................................................................................................................... 577
9.59 DDN_LFA................................................................................................................................................................ 578
9.60 DDN_LMFA.............................................................................................................................................................580
9.61 DDN_LOOP_ALM.................................................................................................................................................. 581
9.62 DDN_RFA................................................................................................................................................................ 583
9.63 DDN_RMFA.............................................................................................................................................................584
9.64 DLAG_PROTECT_FAIL.........................................................................................................................................585
9.65 DOWN_T1_AIS....................................................................................................................................................... 587
9.66 DS3_IDLE................................................................................................................................................................ 589
9.67 DSR.......................................................................................................................................................................... 591
9.68 DTR.......................................................................................................................................................................... 592
9.69 E1_LOC....................................................................................................................................................................593
9.70 ETH_NO_FLOW..................................................................................................................................................... 595
9.71 ETHOAM_DISCOVER_FAIL.................................................................................................................................596
9.72 ETHOAM_RMT_CRIT_FAULT............................................................................................................................. 598
9.73 ETHOAM_RMT_LOOP.......................................................................................................................................... 599
9.74 ETHOAM_RMT_SD............................................................................................................................................... 601
9.75 ETHOAM_SELF_LOOP......................................................................................................................................... 602
9.76 ETHOAM_VCG_SELF_LOOP............................................................................................................................... 603
9.77 EX_ETHOAM_CC_LOS......................................................................................................................................... 605
9.78 EX_ETHOAM_MPID_CNFLCT............................................................................................................................ 607
9.79 EXT_LOS................................................................................................................................................................. 609
9.80 EXT_TIME_LOC.....................................................................................................................................................611
9.81 FEC_LOF................................................................................................................................................................. 612
9.82 FEC_OOF................................................................................................................................................................. 613
9.83 FLOW_OVER.......................................................................................................................................................... 614
9.84 FPGA_ABN..............................................................................................................................................................616
9.85 FSELECT_STG........................................................................................................................................................617
9.86 FUSE_ALARM........................................................................................................................................................ 618
9.87 HARD_ERR............................................................................................................................................................. 620
9.88 HP_CROSSTR......................................................................................................................................................... 621
9.89 HP_REI.....................................................................................................................................................................623
9.90 IN_PWR_FAIL.........................................................................................................................................................624
9.91 K1_K2_M................................................................................................................................................................. 626
9.92 K2_M........................................................................................................................................................................627
9.93 LAN_LOC................................................................................................................................................................ 628
9.94 LASER_MOD_ERR................................................................................................................................................ 629
9.95 LASER_SHUT......................................................................................................................................................... 630
9.96 LCAS_BAND_DECREASED................................................................................................................................. 631
9.97 LCAS_FOPR............................................................................................................................................................ 633
9.98 LCAS_FOPT............................................................................................................................................................ 634
9.99 LCAS_PLCR............................................................................................................................................................ 635
9.100 LCAS_PLCT.......................................................................................................................................................... 637
9.101 LCAS_TLCR..........................................................................................................................................................639
9.102 LCAS_TLCT.......................................................................................................................................................... 640
9.103 LCD........................................................................................................................................................................ 642
9.104 LCS_DAYS_OF_GRACE......................................................................................................................................644
10.2.40 N1SL16................................................................................................................................................................973
10.2.41 N1SL16A.............................................................................................................................................................974
10.2.42 N1SLD4...............................................................................................................................................................974
10.2.43 N1SLD4A............................................................................................................................................................ 975
10.2.44 N1SLQ1...............................................................................................................................................................976
10.2.45 N1SLQ1A............................................................................................................................................................ 976
10.2.46 N1SLQ4...............................................................................................................................................................977
10.2.47 N1SLQ4A............................................................................................................................................................ 977
10.2.48 N1SLT1................................................................................................................................................................978
10.2.49 N1SPQ4............................................................................................................................................................... 979
10.2.50 N2EFS0............................................................................................................................................................... 979
10.2.51 N2EFS4............................................................................................................................................................... 980
10.2.52 N2EFT8............................................................................................................................................................... 982
10.2.53 N2EFT8A............................................................................................................................................................ 983
10.2.54 N2EGR2.............................................................................................................................................................. 984
10.2.55 N2EGS2...............................................................................................................................................................988
10.2.56 N2EGT2...............................................................................................................................................................989
10.2.57 N2EMR0..............................................................................................................................................................991
10.2.58 N2PD3................................................................................................................................................................. 994
10.2.59 N2PL3..................................................................................................................................................................995
10.2.60 N2PL3A...............................................................................................................................................................995
10.2.61 N2PQ1................................................................................................................................................................. 996
10.2.62 N2PQ3................................................................................................................................................................. 996
10.2.63 N2SL1..................................................................................................................................................................997
10.2.64 N2SL4..................................................................................................................................................................997
10.2.65 N2SL16................................................................................................................................................................998
10.2.66 N2SL16A.............................................................................................................................................................998
10.2.67 N2SLD4...............................................................................................................................................................999
10.2.68 N2SLO1.............................................................................................................................................................1000
10.2.69 N2SLQ1.............................................................................................................................................................1000
10.2.70 N2SLQ4.............................................................................................................................................................1001
10.2.71 N2SPQ4............................................................................................................................................................. 1002
10.2.72 N3EFS4............................................................................................................................................................. 1002
10.2.73 N3EGS2.............................................................................................................................................................1004
10.2.74 N3EGS4.............................................................................................................................................................1005
10.2.75 N3SL16..............................................................................................................................................................1007
10.2.76 N3SL16A...........................................................................................................................................................1007
10.2.77 N3SLQ41...........................................................................................................................................................1008
10.2.78 N4SLD64...........................................................................................................................................................1008
10.2.79 N4EFS0............................................................................................................................................................. 1009
10.2.80 N4EGS4.............................................................................................................................................................1010
10.2.81 N5EFS0............................................................................................................................................................. 1012
10.2.82 ODU...................................................................................................................................................................1013
10.2.83 Q2CXL1............................................................................................................................................................ 1014
10.2.84 Q2CXL4............................................................................................................................................................ 1015
10.2.85 Q2CXL16.......................................................................................................................................................... 1015
10.2.86 Q3CXL1............................................................................................................................................................ 1016
10.2.87 Q3CXL4............................................................................................................................................................ 1017
10.2.88 Q3CXL16.......................................................................................................................................................... 1018
10.2.89 Q5CXLLN......................................................................................................................................................... 1019
10.2.90 Q5CXLQ41....................................................................................................................................................... 1019
10.2.91 R1CXLLN......................................................................................................................................................... 1020
10.2.92 R1CXLD41........................................................................................................................................................1021
10.2.93 R1CXLQ41........................................................................................................................................................1022
10.2.94 R1EFT4............................................................................................................................................................. 1023
10.2.95 R1PD1............................................................................................................................................................... 1024
10.2.96 R1PL1................................................................................................................................................................ 1025
10.2.97 R1SL1................................................................................................................................................................ 1025
10.2.98 R1SL4................................................................................................................................................................ 1025
10.2.99 R1SLD4............................................................................................................................................................. 1026
10.2.100 R1SLQ1........................................................................................................................................................... 1027
10.2.101 R2CXLLN....................................................................................................................................................... 1027
10.2.102 R2CXLQ41......................................................................................................................................................1028
10.2.103 R2PD1............................................................................................................................................................. 1029
10.2.104 R3PD1............................................................................................................................................................. 1029
10.2.105 R3SL1.............................................................................................................................................................. 1030
10.2.106 R3SL4.............................................................................................................................................................. 1030
10.2.107 R3SLD4........................................................................................................................................................... 1031
10.2.108 R3SLQ1........................................................................................................................................................... 1032
11.2.6 CRC4_ERR..........................................................................................................................................................1047
11.2.7 DDN_CRC4_ERR............................................................................................................................................... 1049
11.2.8 E1_LCV_SDH..................................................................................................................................................... 1050
11.2.9 E1_LES_SDH......................................................................................................................................................1051
11.2.10 E1_LSES_SDH..................................................................................................................................................1052
11.2.11 E3_LCV_SDH................................................................................................................................................... 1053
11.2.12 E3_LES_SDH....................................................................................................................................................1054
11.2.13 E3_LSES_SDH..................................................................................................................................................1056
11.2.14 EDTMP..............................................................................................................................................................1057
11.2.15 EDRPL...............................................................................................................................................................1058
11.2.16 EDTPL............................................................................................................................................................... 1059
11.2.17 ENVTMP........................................................................................................................................................... 1060
11.2.18 FEC_AFT_COR_ER......................................................................................................................................... 1061
11.2.19 FEC_BEF_COR_ER......................................................................................................................................... 1062
11.2.20 FEC_COR_0BIT_CNT..................................................................................................................................... 1063
11.2.21 FEC_COR_1BIT_CNT..................................................................................................................................... 1063
11.2.22 FEC_COR_BYTE_CNT................................................................................................................................... 1064
11.2.23 FEC_UNCOR_BLOCK_CNT...........................................................................................................................1065
11.2.24 HPBBE...............................................................................................................................................................1066
11.2.25 HPCSES.............................................................................................................................................................1067
11.2.26 HPES..................................................................................................................................................................1068
11.2.27 HPFEBBE..........................................................................................................................................................1069
11.2.28 HPFEES............................................................................................................................................................. 1070
11.2.29 HPFECSES........................................................................................................................................................ 1071
11.2.30 HPFESES...........................................................................................................................................................1072
11.2.31 HPFEUAS..........................................................................................................................................................1074
11.2.32 HPSES............................................................................................................................................................... 1075
11.2.33 HPUAS.............................................................................................................................................................. 1076
11.2.34 LPBBE............................................................................................................................................................... 1077
11.2.35 LPCSES............................................................................................................................................................. 1079
11.2.36 LPES.................................................................................................................................................................. 1081
11.2.37 LPFEBBE.......................................................................................................................................................... 1082
11.2.38 LPFECSES.........................................................................................................................................................1084
11.2.39 LPFEES............................................................................................................................................................. 1085
11.2.40 LPFESES........................................................................................................................................................... 1086
11.2.41 LPFEUAS.......................................................................................................................................................... 1088
11.2.42 LPSES................................................................................................................................................................1089
11.2.43 LSBISA..............................................................................................................................................................1091
11.2.44 LPUAS...............................................................................................................................................................1092
11.2.45 LSCLC............................................................................................................................................................... 1093
11.2.46 LSIOP................................................................................................................................................................ 1094
11.2.47 LSOOP...............................................................................................................................................................1096
11.2.48 LSTMP...............................................................................................................................................................1097
11.2.49 MSBBE..............................................................................................................................................................1098
11.2.50 MSCSES............................................................................................................................................................ 1099
11.2.51 MSES................................................................................................................................................................. 1100
11.2.52 MSFEBBE......................................................................................................................................................... 1101
11.2.53 MSFECSES........................................................................................................................................................1102
11.2.54 MSFEES............................................................................................................................................................ 1103
11.2.55 MSFESES.......................................................................................................................................................... 1104
11.2.56 MSFEUAS......................................................................................................................................................... 1105
11.2.57 MSSES...............................................................................................................................................................1107
11.2.58 MSUAS..............................................................................................................................................................1108
11.2.59 ODU2PMBIP8...................................................................................................................................................1109
11.2.60 OSPITMPMIN................................................................................................................................................... 1110
11.2.61 OSPITMPMAX..................................................................................................................................................1111
11.2.62 OSPITMPCUR...................................................................................................................................................1112
11.2.63 OSPICCVMIN................................................................................................................................................... 1112
11.2.64 OSPICCVMAX................................................................................................................................................. 1113
11.2.65 OSPICCVCUR...................................................................................................................................................1114
11.2.66 OTU2SMBIP8................................................................................................................................................... 1115
11.2.67 RSBBE............................................................................................................................................................... 1116
11.2.68 RSCSES............................................................................................................................................................. 1117
11.2.69 RSES.................................................................................................................................................................. 1118
11.2.70 RSOFS............................................................................................................................................................... 1120
11.2.71 RSOOF...............................................................................................................................................................1121
11.2.72 RSSES................................................................................................................................................................1122
11.2.73 RSUAS...............................................................................................................................................................1123
11.2.74 RPLMIN............................................................................................................................................................ 1124
11.2.75 RPLMAX...........................................................................................................................................................1125
11.2.76 RPLCUR............................................................................................................................................................ 1125
11.2.77 T1_LCV_SDH................................................................................................................................................... 1126
11.2.78 T1_LES_SDH.................................................................................................................................................... 1127
11.2.79 T1_LSES_SDH..................................................................................................................................................1129
11.2.80 T3_LCV_SDH................................................................................................................................................... 1130
11.2.81 T3_LES_SDH.................................................................................................................................................... 1131
11.2.82 T3_LSES_SDH..................................................................................................................................................1132
11.2.83 TPLMIN.............................................................................................................................................................1133
11.2.84 TPLMAX........................................................................................................................................................... 1134
11.2.85 TPLCUR............................................................................................................................................................ 1135
11.2.86 TLBMIN............................................................................................................................................................ 1136
11.2.87 TLBMAX...........................................................................................................................................................1137
11.2.88 TLBCUR............................................................................................................................................................1138
11.2.89 TUPJCHIGH......................................................................................................................................................1139
11.2.90 TUPJCLOW.......................................................................................................................................................1140
11.2.91 TUPJCNEW.......................................................................................................................................................1141
11.2.92 WCV.................................................................................................................................................................. 1142
11.2.93 XCSTMP............................................................................................................................................................1143
11.3 Performance Threshold-Crossing Event Clearing of RMON................................................................................. 1144
11.3.1 AlignmentErrors.................................................................................................................................................. 1145
11.3.2 InBadOcts............................................................................................................................................................ 1146
11.3.3 OutBadOcts..........................................................................................................................................................1148
11.3.4 Collisions............................................................................................................................................................. 1149
11.3.5 Deferred Transmissions....................................................................................................................................... 1151
11.3.6 DropEvent............................................................................................................................................................ 1152
11.3.7 FCSErrors............................................................................................................................................................ 1154
11.3.8 Fragments.............................................................................................................................................................1156
11.3.9 Jabbers..................................................................................................................................................................1157
11.3.10 Late Collisions................................................................................................................................................... 1159
11.3.11 OversizePkts.......................................................................................................................................................1160
11.3.12 UndersizePkts.................................................................................................................................................... 1162
11.3.13 Sperbadaddrpkt.................................................................................................................................................. 1164
11.3.14 SperbadctlFcspkt................................................................................................................................................1165
11.3.15 SperbadDataFcspkt............................................................................................................................................ 1166
11.3.16 SperbadFcspkt....................................................................................................................................................1167
11.3.17 SperbadHecpkt...................................................................................................................................................1168
11.3.18 SperbadParitypkt................................................................................................................................................1169
11.3.19 Spercontainedpkt................................................................................................................................................1170
11.3.20 Spereredsnds...................................................................................................................................................... 1171
11.3.21 SperPmdabortpkt................................................................................................................................................1171
11.3.22 SperScffers......................................................................................................................................................... 1172
11.3.23 SperSelfSrcupkt................................................................................................................................................. 1173
11.3.24 SperSvlrdsnds.................................................................................................................................................... 1174
11.3.25 Spertlpkt.............................................................................................................................................................1175
11.3.26 Spertspkt............................................................................................................................................................ 1176
11.3.27 SperTtlExppkt.................................................................................................................................................... 1177
11.3.28 SperUasnds........................................................................................................................................................ 1178
11.4 Performance Event Clearing of Microwave........................................................................................................... 1179
11.4.1 RSL...................................................................................................................................................................... 1179
11.4.2 TSL...................................................................................................................................................................... 1180
A Glossary....................................................................................................................................1200
This topic describes the generation principles and detection mechanism of certain signal flows
in the SDH higher-order and lower-order services. In addition, this topic describes the
suppression relations between alarm signals.
1.1 Overview
There are sufficient overhead bytes in the SDH frame, which are the regenerator section
overheads, multiplex section overheads, and path overheads. These overhead bytes carry
alarm and performance information. According to the information, the SDH system can
perform in-service monitoring of alarms and bit errors. With an understanding of the alarm
generation and detection principles, you can quickly locate faults.
1.2 Generation and Detection of Alarms and Performance Events in the SDH Higher Order
Signal Flow
The principle for locating fault is "line first, then tributary; higher order first, then lower
order".
1.3 Generation and Detection of Alarms and Performance Events in the SDH Lower Order
Signal Flow
PDH services at different rates use different path overhead bytes. Thus, the alarm signal
generation modes vary accordingly. This section describes the signal flow and the procedure
for handling each overhead byte by each module.
1.4 Suppression Correlation Between SDH Alarms
The equipment supports the alarm suppression function so that you can quickly locate the root
fault. This function involves the intra-board alarm suppression and the inter-board alarm
suppression. In terms of these two types of alarm suppressions, this section describes the
suppression relations among SDH alarms.
1.1 Overview
There are sufficient overhead bytes in the SDH frame, which are the regenerator section
overheads, multiplex section overheads, and path overheads. These overhead bytes carry
alarm and performance information. According to the information, the SDH system can
perform in-service monitoring of alarms and bit errors. With an understanding of the alarm
generation and detection principles, you can quickly locate faults.
Figure 1-1 shows the SDH alarm signal flow.
unit
PDH port
PDH port
unit
PDH port
PDH port
Alarm Description
Alarm Indication Signal The all "1"s signal that is inserted into the lower level circuit
(AIS) indicates that the signal is unavailable. The common AIS
alarms include the MS_AIS alarm, the AU_AIS alarm, the
TU_AIS alarm, and the other AIS alarms that are generated in
the E1/T1 signals.
Remote Defect Indication This alarm indicates that the opposite NE has detected the loss
(RDI) of signal (LOS), AIS, or trace identifier mismatch (TIM)
alarm. When the opposite NE detects these alarms, an RDI
alarm is sent to the local NE.
The MS_RDI, HP_RDI and LP_RDI alarms are common RDI
alarms.
NOTE
If an alarm is generated on an NE, it may not indicate that the NE is faulty. The alarm can be generated
due to a fault at the opposite NE or due to other factors.
For example, the R_LOS alarm is generated due to a fiber cut, or the HP_LOM alarm at the local NE is
generated due to the failure of the cross-connect board at the opposite NE.
l Network-wide alarm monitoring and remote alarm notification enable the U2000 to
notify maintenance engineers of network exceptions in a timely manner so that the
engineers can rectify faults quickly.
l Alarm/Event relevance analysis, alarm masking, alarm filtering, alarm suppression,
automatic alarm reporting, alarm reversion, and maintenance experience databases
improve the effectiveness and efficiency of alarm handling.
l Alarm synchronization ensures the reliability of alarms.
In the alarm reporting process, an alarm goes through the following procedures before it is
stored by the NMS:
The alarm/event relevance function identifies root alarms and correlatives alarms, allowing
the maintenance personnel to focus on root alarms in troubleshooting and therefore improving
the troubleshooting efficiency.
The alarm/event relevance function provides alarm relevance on NEs, alarm relevance on the
NMS, and user-defined alarm relevance.
Alarm Suppression
The NMS provides the alarm suppression function. If this function is enabled for an alarm,
the NE does not report the alarm.
Alarm Masking
This function masks minor alarms to avoid unnecessary alarm information.
During the maintenance, testing or deployment of an NE, numerous alarms may be reported
and there is no need to care about them. In this case, the alarm masking function can be used
to mask the alarms so that the NMS does not display or store the alarm information.
Figure 1-2 provides the differences between alarm suppression and alarm masking.
l If alarm suppression is enabled for an alarm, the NE does not report the alarm.
l If alarm masking is enabled for an alarm, the NE still reports the alarm but the NMS
discards the alarm information.
NMS NMS
The NMS does The NMS cannot
not receive the receive the
masked alarms. suppressed
alarms.
Alarm Filtering
To avoid redundant alarm information, alarm filtering can be enabled for a specific NE on the
NMS. The NMS filters the alarm information based on alarm name, object, severity, status,
type, latest report time, clear time and other conditions. This function improves alarm
browsing efficiency without affecting NE-side alarm reporting. The filtering conditions which
users are concerned about can be added to alarm filtering templates. Selecting an alarm
filtering template allows multiple required conditions to be applied at a time.
If alarm filtering is enabled for an alarm, the NMS discards the relevant alarm information; if
alarm filtering is disabled for an alarm, the NMS receives and records the relevant alarm
information.
Alarm Reversion
In the case of a port for which services are not activated, the alarm reversion function can be
used to prevent relevant alarm information from being generated and thus to prevent
interferences from the generated alarms. When the alarm reversion function is enabled, you
can set the alarm status of this port to be opposite to the actual status. That is, an alarm is
reported when no alarm occurs and no alarm is reported when alarms occur.
There are three modes of alarm reversion: non-revertive, auto-revertive, and manual-revertive
mode.
l Non-revertive: This is the normal alarm monitoring state, and is the default alarm mode.
In this mode, the alarm reversion function cannot be enabled for a port.
l Auto-revertive: In this mode, the alarm reversion function can be enabled only on a port
that reports alarms. After the alarm reversion function is enabled, the port enters the
alarm revertive mode, and does not report alarms. When the current alarms are cleared,
the port automatically exits the revertive mode, and the alarm state reported by the port is
restored to be the actual alarm state.
l Manual-revertive: In this mode, the alarm reversion function can be enabled on a port,
regardless of whether any alarms exist on this port.
When the alarm reversion function is enabled on a port, the alarm state reported by
the port is inconsistent with the actual alarm state.
When the manual-revertive mode is disabled, the alarm reversion mode is restored
to be the non-revertive mode. The alarm state reported by the port is consistent with
the actual alarm state.
The precautions for setting the alarm reversion function are as follows:
l The alarm state of the board, including the state of the alarm indicators on the board,
remains unchanged, which indicates the running state of the equipment.
l The alarm reversion function is realized by the NE software. The alarm data on the NE
and on the NMS is the same, which indicates the alarm state after the alarms are
reversed.
Alarm/Event Redefine
The U2000 can redefine attributes of all alarms or events, such as level, name, and type, to
locate and maintain alarms more effectively. For example, you can decrease the severities of
the alarms/events that do not require attention and increase the severities of the alarms/events
that require attention.
The redefinition of alarm/event names takes effect for all NEs. It cannot take effect for only
the specified NEs. The redefinition of types and severities can take effect for either the
specified NEs or all NEs.
Therefore, this section focuses only on the alarms and performance events generated between
the SDH interface and the cross-connect unit during maintenance. This section describes the
signal flow and the procedure for handling each overhead byte by each module.
Figure 1-3 shows the signal flow between the SDH interface and the cross-connect unit.
Figure 1-3 Alarm signals generated between the SDH interface and the cross-connect unit
Frame synchronizer and MS overhead Pointer processor and
RS overhead processor processor HP overhead processor
(RST) (MST) (MSA, HPT)
optical B2-Err.
HP-TIM Cross-
B2
J1
HP-UNEQ "1" connect
port BI Err. MS-REI C2
HP-SLM
B1 M1 C2
unit
HP-LOM
MS-RDI H4
K2 B3 Err.
B3
HP-REI
G1
G1 HP-RDI
Based on the positions of the various overhead byte processing in the STM-N frame, the
overhead bytes are classified into four modules:
l Regenerator section overheads
l Multiplex section overheads
l Higher order path overheads
l Lower order path overheads
If a fault occurs in the first two modules, it affects all the higher order paths. If a fault occurs
in the overhead bytes of a higher order path, however, it affects only this higher order path
and its lower order paths.
The following sections describe the signal flow and the processing of each overhead byte.
If the B1 byte restored from an STM-N signal is not consistent with the BIP-8 computing
result of the preceding STM-N frame, a B1 bit error is reported.
If the number of B1 bit errors exceeds the threshold 10-3 (which is the default value), a
B1_EXC alarm occurs.
When 10 SESs appear consecutively in the RS (for example, when the errored blocks reach
30% in one second), the RSUAT EVENT performance event occurs. At the same time, bytes
such as F1, D1-D3 and E1 that are not related to the alarms and performance events are
transmitted to the SCC module and the overhead module.
l Higher order path bit interleaved parity code (path BIP-8) byte (B3)
l Path status byte (G1)
l Multiframe indicator byte (H4)
The alarm signal flow is as follows:
l Detecting the H1 and H2 bytes
The pointer processor interprets and justifies the pointer on the basis of the H1 and H2
bytes in each AU-4. It achieves frequency and phase alignment. The pointer processor
also locates each VC-4 and transmits them to the corresponding higher order path
overhead processor.
NOTE
In the case of the Huawei OptiX Metro and OSN series equipment, you can use the NMS to set
whether the all "1"s signal is inserted when the HP_TIM, HP_UNEQ, or HP_SLM alarm occurs.
By default, the all "1"s signal is not inserted.
Currently, the tributary unit group (TUG) is adopted as the payload structure in China.
The preset C2 value that corresponds to the TUG structure is "02".
If the B3 byte restored from the HPOH is not consistent with the BIP-8 computing result
of the VC-4 signal of the preceding frame, B3 bit errors are reported.
In the STM-N lower order SDH interface board, the TU-12 signal extracted from VC-4s
requires the H4 byte to indicate the frame number of the current multiframe in which the
current TU-12 is placed. If the H4 byte detected is illegal, an HP_LOM alarm is
reported, and an all "1"s signal and the normal H4 byte is inserted.
If bit 5 of the G1 byte is "1", an HP_RDI alarm is reported. The value of bits 1-4 of the
G1 byte determines if an HP_REI alarm is reported. If the value of bits 1-4 of the G1
byte is 1-8, an HP_REI alarm is reported.
When B3 detects SES for 10 consecutive seconds, an HPUAT EVENT performance
event occurs.
Other overhead bytes such as the F3, K3 and N1 are reserved for future use.
Finally, the NxSTM-1 payloads are transmitted to the cross-connect unit for the cross
connection of the higher order path and the lower order path.
The higher order path overhead processor generates N higher order path overhead bytes,
which are transmitted to the pointer processor with the NxSTM-1 payloads.
The setting of higher order path overhead bytes such as the J1, C2, B3, G1, F2, F3 and N1 can
be completed along the upstream direction.
If B3 bit errors are detected in the downstream signal, bits 1-4 of the G1 byte are set to the
number of the detected error blocks (ranging from 1 to 8), and an HP_REI alarm is reported to
the transmit end.
The pointer processor generates NxAU-4 pointers, and adapts the VC-4 into an AU-4 (H1 and
H2 bytes). The NxAU-4s are then multiplexed into an STM-N signal by using the
multiplexing processor and are transmitted to the MSOH processor.
If an R_LOS, an R_LOF or an MS_AIS alarm is detected in the downstream signal flow, bits
6-8 of the K2 byte are set to "110". An MS_RDI alarm is reported to the transmit end through
the K2 byte.
If B2 bit errors are detected in the downstream signal flow, an MS_REI alarm is reported to
the remote end through the M1 byte.
After being scrambled by the frame synchronizer and scrambler, the STM-N electrical signal
is converted into an STM-N optical signal by the E/O module and then sent out of the optical
interface.
NOTE
This topic considers the PDH digital signals based on the E1, E3, and E4 signals in the European
standard as an example in the description.
This section describes the processing of the signal flow (for E1 services) between PDH
interfaces and the cross-connect unit, and the generation of alarms.
Figure 1-4 Generation of alarms between the E1 interface and the cross-connect unit
HPA , LPT LPA PPI
E1AIS "1'' T-ALOS
Cross- V5
LP-SLM
connect V5
LP-UNEQ
unit LP-TIM
J2
TU-LOP LP-TFIFO E1
V1, V2
V1, V2 TU-AIS port
H4 HP-LOM
LP-RDI
V5
E1AIS
"1''
BIP-2
V5
LP-REI
V5
LP-RFIFO
As shown in Figure 1-4, the lower order part is divided into the following functional modules
based on different features of the overhead byte processing:
l Higher order path adaptation (HPA)
l Lower order path termination (LPT)
l Lower order path adaptation (LPA)
l PDH physical interface (PPI)
The VC-4 signal from the cross-connect unit is transmitted to the HPA.
The HPA demaps the VC-4 into VC-12s. The pointers of all VC-12s are decoded to provide
the frame offset information in the unit of bytes between the VC-4 and the VC-12.
When the NE clock at the TU-12 assembler differs from the local reference clock, continuous
pointer justification is required. The positive TU pointer justification (TUPJCHIGH) and the
negative TU pointer justification (TUPJCLOW) are detected in the downlink signal flow.
If wrong H4 multiframe byte sequence is detected in the downlink direction, the HP_LOM
alarm is reported.
If the lower order pointer byte V1 or V2 is all "1"s, a TU_AIS alarm is reported. If the value
of V1 or V2 is illegal, a TU_LOP alarm is reported. If either of these two alarms occur, all
"1"s signal is inserted into the next functional block.
In addition, if a TU_AIS alarm is generated, the AIS signal is inserted in the downstream
data, and at the same time an LP_RDI is reported. Set bit 8 of the V5 byte to "1" to generate
an LP_RDI.
The VC-12 signal is transmitted to the LPT unit for V5 byte processing.
If bits 5-7 of the V5 byte in the downlink signal flow are detected to be "000", the lower order
paths are not equipped (LP_UNEQ), and the AIS signal is inserted into the lower level circuit.
If a signal label mismatch occurs, an LP_SLM alarm is reported.
The path RDI information in bit 8 of the V5 byte is terminated, and an LP_RDI is reported.
Error monitoring bits 1 and 2 of the V5 byte are detected and the BIP-2 for the VC-12 is
calculated. The BIP-2 value that is calculated for the current frame is compared with bits 1
and 2 of the V5 byte recovered from the next frame.
An LPBBE is reported if they are not the same. Meanwhile, bit 3 of the V5 byte is restored. If
it is "1", BIP-2 errors occur at the remote end and an LPFEBBE is reported at the remote end.
NOTE
NOTE
Different Path Overhead Bytes for Alarm and Performance Event Monitoring
The path overhead bytes that are used in the E3 and E4 electrical signal interface boards are
B3, J1, C2 and G1.
The B3 byte uses the even BIP-8 code for error monitoring. The function of the B3 byte is the
same as that of bits 1-2 of the V5 byte.
G1 byte b1 b2 b3 b4 b5 b6 b7 b8
R_LOS
The higher level alarms above the arrow can suppress the lower level alarms below the arrow.
Thus, pay attention to higher level alarms when locating faults.
R_LOC
R_LOF
MS_AIS
AU_LOP
HP_LOM
AU_AIS
A B means A suppresses B
If an alarm above the arrow is generated at the service source, and the alarm below the arrow
is generated at the service sink, the alarm above the arrow suppresses the alarm below the
arrow. In this case, you can focus on the alarms at the service source during troubleshooting.
X X
L L L L
C C
U U U U
S S
V5 returned
The HP_LOM alarm causes the change of the V5 byte. The changed V5 byte may trigger the
BIP_EXC and LP_UNEQ alarms after it is transmitted to NE B and then trigger the LP_RFI,
LP_RDI, and LP_REI alarms after it is returned to NE A.
To facilitate troubleshooting in this case, you need to enable the end-to-end alarm correlation
analysis function on the NMS to suppress the HP_LOM-derived alarms in line with the
specified alarm correlation rules.
The OptiX OSN equipment provides multiple types of Ethernet processing boards to support
different Ethernet services. For different Ethernet services, alarm detection methods are
slightly different because the processing modules are different. This topic describes the alarm
detection principle of each type of Ethernet boards.
Uplink
Donwlink
NOTE
The functions supported by different modules may be different from each other.
Encapsulation Module
This module supports the GFP, LAPS, and HDLC encapsulation modes. It also encapsulates
and decapsulates data.
Mapping Module
In the uplink direction, this module maps encapsulated HDLC/LAPS/GFP packets into VC-
trunks and multiplexes the VC-trunks into VC-4s to map Ethernet frames into SDH frames.
In the downlink direction, this module maps SDH frames into Ethernet frames.
The Ethernet board inspects whether a module is exceptional. If yes, the module directly
reports an exception alarm to the NE. This topic describes the principles of generating and
detecting alarms of each unit of the transparent transmission board by module.
Figure 2-2 shows the positions of alarms in the transparent transmission board.
LCAS_PLCT
LCAS_TLCR
TU alalrm indication at
the VC-3/VC-12 level
BIP BER
NOTE
For alarms supported by specific boards, see 6.2 Board Alarm List.
BD_STATUS
LASER_MOD_ERR The board software detects whether the optical module type is
matched and then decides whether to report the alarm
according to the detection result.
NOTE
For EFT8 boards, the hardware logic checks the laser type of the
optical interface board.
ALM_GFP_dLFD The internal chip of the board aligns GFP frames. If an error
occurs during frame alignment, the board reports the alarm
to the NE for display.
FCS_ERR The internal chip of the board performs FCS check on GFP
frames. If an error occurs during FCS check, the board
reports the alarm to the NE for display.
LCAS_FOPR The alarm is reported when the LCAS module detects that
the protocol is invalid in the receiving direction of the
LCAS.
LCAS_FOPT The alarm is reported when the LCAS module detects that
the protocol is invalid in the transmitting direction of the
LCAS.
Table 2-6 lists certain SDH alarms reported by the mapping module.
Figure 2-4 shows the functional modules of the Ethernet switching board.
Uplink
Donwlink
NOTE
The functions supported by different modules may be different from each other.
l Port enabling
l P/PE property of a port
l Port encapsulation format
l Default VLAN value of a port
l Tag-Aware/Tag-Access property of a port
l Enabling of packet entry detection
Encapsulation Module
This module supports the GFP, LAPS, and HDLC encapsulation modes. It also encapsulates
and decapsulates data.
Mapping Module
In the uplink direction, this module maps encapsulated HDLC/LAPS/GFP packets into VC-
trunks and multiplexes the VC-trunks into VC-4s to map Ethernet frames into SDH frames.
In the downlink direction, this module maps SDH frames into Ethernet frames.
NOTE
For alarms supported by specific boards, see 6.2 Board Alarm List.
ETHOAM_DISCOVER_F The alarm is reported to the NE for display when the OAM
AIL upper-layer protocol detects the negotiation failure between
the Ethernet port and the peer equipment.
LAG_FAIL The board software detects whether the primary port of the
aggregation group is invalid according to the configured
LAG, and decides whether to report the alarm to the NE for
display according to the detection result.
TPS_ALM The TPS protocol of the board detects the TPS switching
status. Whether to report the alarm to the NE for display
depends on the detection result.
ALM_GFP_dLFD The internal chip of the board aligns GFP frames. If an error
occurs during frame alignment, the board reports the alarm to
the NE for display.
FCS_ERR The internal chip of the board performs FCS check on GFP
frames. If an exception occurs during FCS check, the board
reports the alarm to the NE for display.
LCAS_FOPR The alarm is reported when the LCAS module detects that
the protocol is invalid in the receiving direction of the
LCAS.
LCAS_FOPT The alarm is reported when the LCAS module detects that
the protocol is invalid in the transmitting direction of the
LCAS.
VCAT_LOM_VC12 The board software detects the multiple frame indictor field
VCAT_LOM_VC3 (MFI) in the timeslots at different levels, and decides
whether to report the alarm to the NE according to the
VCAT_LOM_VC4 detection result.
Table 2-11 lists certain SDH alarms reported by the mapping module.
T_LOS
Figure 2-7 shows the functional modules of the Ethernet RPR board.
Uplink
Donwlink
NOTE
The functions supported by different modules may be different from each other.
l Port enabling
l P/PE property of a port
l Port encapsulation format
l Default VLAN value of a port
l Tag-Aware/Tag-Access property of a port
l Enabling of packet entry detection
l Working mode of a port
l Flow control
l Maximum packet length on a port
l Loopback on ports
Encapsulation Module
This module supports the GFP encapsulation mode. It also encapsulates and decapsulates
data.
Mapping Module
In the uplink direction, this module maps encapsulated GFP packets into VC-trunks and
multiplexes the VC-trunks into the VC-4s to map Ethernet frames into SDH frames.
In the downlink direction, this module maps SDH frames into Ethernet frames.
BIP BER
NOTE
For alarms supported by specific boards, see 6.2 Board Alarm List.
LAG_FAIL The board software detects whether the primary port of the
aggregation group is invalid according to the configured
LAG, and decides whether to report the alarm to the NE for
display according to the detection result.
RPR_PS_CHANGE The internal chip of the board aligns GFP frames. If an error
occurs during frame alignment, the board reports the alarm to
the NE for display.
RPR_NB_INCONSIS The internal chip of the board performs FCS check on GFP
frames. If an exception occurs during FCS check, the board
reports the alarm to the NE for display.
RPR_PM_INCONSIS The RPR protocol detects whether all stations have the same
RPR protection mode in the RPR topology database.
Whether to report the alarm to the NE for display depends on
the detection result.
RPR_SUM_A0_EXCEE The RPR protocol detects whether the total reserved loop
D bandwidth exceeds the total loop bandwidth. Whether to
report the alarm to the NE for display depends on the
detection result.
RPR_ECHO_DLOC In the OAM module, the RPR protocol detects whether the
local node receives the corresponding response frame within
the specified time after transmitting an ECHO request frame.
Whether to report the alarm to the NE for display depends on
the detection result.
RPR_STATIONS_EXCE The RPR protocol detects whether the stations on the ring in
ED the RPR topology database exceed the allowed maximum.
Whether to report the alarm to the NE for display depends on
the detection result.
ALM_GFP_dLFD The internal chip of the board aligns GFP frames. If an error
occurs during frame alignment, the board reports the alarm to
the NE for display.
FCS_ERR The internal chip of the board performs FCS check on GFP
frames. If an error occurs during FCS check, the board
reports the alarm to the NE for display.
LCAS_FOPR The alarm is reported when the LCAS module detects that
the protocol is invalid in the receiving direction of the
LCAS.
LCAS_FOPT The alarm is reported when the LCAS module detects that
the protocol is invalid in the transmitting direction of the
LCAS.
Table 2-17 lists certain SDH alarms reported by the mapping module.
T_LOS
ALM_GFP_dLF l Bit error ratio Bit errors, losses of pointers, and AIS signals in a
D (BER)-related path may cause BIP BER alarms, pointer-related
alarms: alarms, and TU_AIS alarms on the SDH layer. At
BIP_EXC and the same time, the generic framing procedure
BIP_SD (GFP) state machine may fail to locate GFP
l Pointer-related frames correctly.
alarms:
TU_LOP_VC
12 and
TU_LOP_VC
3
l Path-related
AIS alarms:
TU_AIS_VC1
2 and
TU_AIS_VC3
LCAS_BAND_D l BIP BER The SDH BER alarm, UNEQ alarm, and pointer-
ECREASED l UNEQ related alarm on the SDH layer may invalidate
path timeslots. Hence, the path timeslots become
l AIS unavailable. Upon the successful negotiation, the
l LOP LCAS protocol reports a bandwidth decrease
alarm.
l When specific trigger conditions are not met, relevant alarms cannot be reported.
l When the trigger conditions of multiple alarms are detected, certain alarms need to be
masked to avoid misleading the alarm handling. If certain alarms are not masked, many
similar alarms are reported at the same time.
The performance events of an SDH network include bit errors and jitter. Jitter can result in
pointer justification on the equipment. Thus, it is the key factor that influences the
transmission quality of the SDH network.
Generation Mechanism
The SDH system adopts bit interleaved parity (BIP) to detect bit errors. The BIP is performed
on the BIP matrix of the RS, MS, higher order path, and lower order path using the B1, B2,
B3 and V5 bytes respectively.
The B1 byte is used for error monitoring in the regenerator section. This function is
performed by using a bit interleaved parity 8 (BIP-8) code with even parity. The working
mechanism of the B1 byte is as follows:
1. At the transmit end, the BIP-8 is computed for all the scrambled bytes of the current
frame (frame N) and the result is placed in the B1 byte of the next frame (frame N+1) to
be scrambled.
2. At the receive end, the BIP-8 is computed for all bits of the current frame (frame N-1) to
be descrambled and the result is compared with the value of the B1 byte of the next
descrambled frame (frame N).
3. If the two values are different, exclusive-OR operation is conducted on them. The
number of "1"s in the result is the number of errored blocks in the frame during the
transmission.
The B2 byte is used for error monitoring in the multiplex section, and the working mechanism
is similar to the working mechanism of the B1 byte. The B1 byte monitors the errors that
occur in the entire STM-N frame during the transmission. One STM-N frame has only one B1
byte. The B2 byte monitors the errors that occur in every STM-1 frame of the STM-N frame.
The STM-N frame contains Nx3 B2 bytes. Every three B2 bytes correspond to one STM-1
frame. For example, there are three B2 bytes for one STM-1 frame. The working mechanism
of the B2 bytes is as follows:
1. At the transmit end, the BIP-24 is computed for all bits of the previous STM-1 frame
except the RSOH, and the result is stored in the B2 bytes of the current frame to be
scrambled.
2. At the receive end, the BIP-24 is computed for all bits of the current descrambled STM-1
frame except the RSOH, and exclusive-OR operation is conducted between the parity
result and the B2 bytes in the next descrambled STM-1 frame.
3. The number of "1"s in the result of the exclusive-OR operation is the number of errored
blocks that occur in this STM-1 frame within the STM-N frame during the transmission.
A maximum of 24 errored blocks can be detected.
The B3 byte is used to monitor the bit errors of the VC-4 or the 140 Mbit/s signal within the
STM-N frame during the transmission. The monitoring mechanism of the B3 byte is similar
to that of the B1 and B2 bytes; however, it is used to perform the BIP-8 parity for the VC-4
frame.
The V5 byte performs the functions of error monitoring, signal label and VC-12 path status.
Bits 1-2 are used to perform the BIP-2 monitoring of bit errors in the VC-12 within the STM-
N frame. If the receive end detects errored blocks, the number of such blocks are displayed in
the performance events at the local end. At the same time, bit 3 of the V5 byte reports the
lower order path remote error indication (LP_REI) to the transmit end, and the corresponding
number of errored blocks are displayed in the performance events at the transmit end.
B1
B2
B3
V5
The B1, B2, B3 and V5 bit errors are respectively monitored between these terminations.
Figure 3-1 shows that bit errors that occur in the lower order path cannot be detected in the
higher order path, MS and RS. If bit errors occur in the regenerator section, the bit errors are
triggered in the MS, higher order path and lower order path.
Generally, higher order bit errors can trigger lower order bit errors. If the B1 bit error occurs,
the B2, B3 and V5 bit errors are generated. On the contrary, if the V5 bit error occurs, B3, B2
and B1 bit errors are not necessarily generated.
When the SDH system detects errors, it reports the error performance events or alarms, and
notifies the remote end of error detection through overhead bytes.
Terms
Table 3-1 lists the relevant terms.
BBE Background block error. It indicates an errored block occurring outside the
period of UAT and SES.
Term Description
FEBBE Far end background block error. It indicates that a BBE event is detected at the
far end.
ES Errored second. It indicates a certain second that is detected with one or more
errored blocks.
FEES Far end errored second. It indicates that an ES event is detected at the far end.
SES Severely errored second. It indicates a certain second, which contains more
than 30% errored blocks or at least one serious disturbance period (SDP). The
SDP is a period of at least four consecutive blocks or 1 ms (taking the longer
one) where the error ratios of all the consecutive blocks are more than or equal
to 10-2 or a loss of signal occurs.
FESES Far end severely errored second. It indicates an SES event that is detected at
the far end.
CSES Consecutive severely errored second. It indicates the SES events that occur
consecutively, but last less than 10 seconds.
FECSES Far end consecutive severely errored second. It indicates a CSES event that is
detected at the far end.
UAS Unavailable second. A period of 10 consecutive seconds during which the bit
error ratio per second of the digital signal in either of the transmission
directions of a transmission system is inferior to 10-3. These 10 seconds are
considered to be part of the unavailable time.
If the bit If the bit If the bit errors If the bit errors
errors errors exceed exceed the exceed the
exceed the the threshold threshold at the threshold at the
threshold at at the local local station, the local station, the
the local station, the local station opposite station
station, the opposite reports the alarm. reports the alarm.
local station station
reports the reports the
relevant relevant
event. event.
If the B1 byte recovered from the STM-N signal is not consistent with the BIP-8 computing
result of the previous STM-N frame, the B1 bit error occurs.
If the B2 byte recovered from the STM-N signal is not consistent with the BIP-24 computing
result of the previous STM-N frame (all bits expect the RSOH), the B2 bit error occurs.
If the B3 byte recovered from the HPOH is not consistent with BIP-8 computing result of the
VC-4 signal of the previous frame, the B3 bit error occurs.
If bit 1 and bit 2 of the V5 byte that is restored from the LPOH are different from the BIP-2
calculating result of the VC-12 signal in the previous frame, the BIP errors are reported.
If B1, B2 and B3 bit errors exceed the 10-6 threshold, alarms such as the B1_SD, B2_SD,
B3_SD occur. If B1, B2 and B3 bit errors exceed the 10-3 threshold, alarms such as the
B1_EXC, B2_EXC and B3_EXC occur.
When B1 detects 10 consecutive SESs in the RS, it indicates that an RSUAT event occurs.
When B2 detects 10 consecutive SESs in the MS, it indicates that an MSUAT event occurs.
9 rows
VC-4
H1 YY H2 1* 1* H3 H3 H3
AU- 4 PTR 1 9
When the network is synchronous, the pointer is used to perform phase alignment among the
synchronous signals. If the NEs work under the same clock, the signals that are transmitted
from various NEs to a certain NE have the same clock frequency. Thus, rate adaptation is not
necessary. Transiently, the rate may be either a little higher or lower. In this case, phase
alignment is required.
When the network is not synchronous, the NEs work at different frequencies, and the pointer
is used for frequency justification. Pointer justification is also required to tolerate the
frequency jitter and wander in the network.
If the frame rate of the VC is different from that of the AUG, information is stuffed in the H3
bytes of the AU pointer area. The idle bytes are stuffed with pseudo-random information and
are inserted before the VC to decrease or increase the frame rate of the VC. At the same time,
the pointer value is dropped or raised to decrease or increase the frame rate of the VC. Thus,
negative and positive pointer justifications are generated. See Table 3-3.
State Byte Numbering and Content of the Fourth Row in the Rate
Name STM-1 Frame Relatio
n
7 8 9 10 11 12
NOTE
"Information" corresponds to the VC frame rate, and "Container" corresponds to the AU encapsulation
rate.
All the NEs in the SDH network are generally well synchronized, and pointer justification
seldom occurs. Actual performance monitoring for pointer justification of the network proves
that AU pointer justification and TU pointer justification seldom occurs.
It is difficult to guarantee that all the NEs are well synchronized all the time during long-term
network operation. If one or several NEs are not synchronized, even for a very short time, a
great amount of pointer justifications could occur. Consecutive positive or negative pointer
justification adjusts the phase forward or backward to realize the frequency justification.
An Ethernet service performance event is used to count the packets transmitted and received
and the transmission quality of Ethernet services.
The data board counts the packets transmitted and received on each Ethernet port. In the case
of certain data boards (such as the RPR board), the packets can be transmitted and received on
the VCTRUNK port. The statistical items include the times of losing packets and the number
of bytes in bad packets transmitted and received.
The board monitors the performance. For most data boards, the chip supports data statistics.
For example, in the case of the 15-minute performance, the board detects a spare performance
register and clears the data in the register at the beginning of each period, and then counts the
performance events. At the end of a period, the statistics performance data is refreshed and
then stored in the register.
Data boards read the number of packets entering a port and report it to the platform. Then the
platform detects whether the statistical value exceeds the preset performance event threshold.
l If the statistical value does not exceed the threshold within a period of time, the platform
directly reports the RMON statistical value to the NE.
l If the statistical value exceeds the threshold within a period of time, the platform reports
an RMON threshold-crossing event to the NE.
Figure 4-1 shows the performance reporting flow.
Whether to No
enable the performance End
monitoring?
Yes
No
Whether to
enable the automatic
reporting?
Yes
5 Performance Threshold
The user can set the performance threshold to mask the performance events that vary within
the normal range. In this way, the user can focus on the performance events that are severely
degraded.
Threshold, also called tolerance, indicates the extreme performance value for the transport
network to operate normally. The performance threshold is used to determine whether the
equipment is working normally. If a performance specification crosses the expected
performance threshold, this indicates a performance degrade trend. In this case, the user
should highly regard and handle the performance.
Normally, some margin should be reserved to set the performance threshold, and thus to find
out problems beforehand.
6 Alarm List
6.2.1 BA2
BD_STATUS LOCK_CUR_FAIL PUM_BCM_ALM
6.2.2 N1BPA
BD_STATUS LOCK_CUR_FAIL PUM_BCM_ALM
6.2.3 N2BPA
BD_STATUS LOCK_CUR_FAIL PUM_BCM_ALM
6.2.4 CAU
FUSE_ALARM MDL_ALARM PWR_MAJ_ALM
TEMP_ALARM BD_STATUS
6.2.5 COA
BD_STATUS IN_PWR_FAIL OUT_PWR_ABN
6.2.6 N1ADL4
AU_AIS AU_LOP B1_EXC
TEM_LA TF TU_AIS_VC3
PATCH_NOT_CONFIRM SWDL_PKG_NOBDSOFT
6.2.7 N1ADQ1
AU_AIS AU_LOP B1_EXC
TF TU_AIS_VC3 TU_LOP_VC3
SWDL_PKG_NOBDSOFT
6.2.8 N1DX1
BD_STATUS BDID_ERROR BIP_EXC
SWDL_PKG_NOBDSOFT SYNC_C_LOS
6.2.9 N1DXA
BD_STATUS BDID_ERROR BIP_EXC
SYNC_C_LOS
6.2.10 N1EFS0
ALM_GFP_dLFD AU_AIS B3_EXC_VC3
6.2.11 N1EFS0A
ALM_GFP_dLFD ALM_GFP_dCSF B3_EXC_VC3
TEMP_OVER TD T_LOSEX
TF TPS_ALM TR_LOC
6.2.12 N1EFS4
ALM_GFP_dLFD AU_AIS B3_EXC_VC3
6.2.13 N1EFT8
ALM_GFP_dLFD B3_EXC_VC3 B3_SD_VC3
PATCHFILE_NOTEXIST ETH_NO_FLOW
6.2.14 N1EFT8A
ALM_GFP_dLFD B3_EXC_VC3 B3_SD_VC3
ETH_NO_FLOW SWDL_PKG_NOBDSOFT
6.2.15 N1EGS4
ALM_GFP_dCSF ALM_GFP_dLFD ETHOAM_RMT_SD
TD ETHOAM_DISCOVER_FAIL ETHOAM_RMT_CRIT_FA
ULT
TU_AIS TEMP_OVER TF
ETH_CFM_RDI
6.2.16 N1EGT2
ALM_GFP_dLFD AU_AIS AU_LOP
6.2.17 N1EMS2
ALM_GFP_dCSF ALM_GFP_dLFD B3_EXC_VC3
T_LOSEX TD TEMP_OVER
TF TR_LOC TU_AIS_VC12
6.2.18 N1EMS4
B3_SD_VC4 ALM_GFP_dCSF ALM_GFP_dLFD
PATCHFILE_NOTEXIST TD TEMP_OVER
TF TU_AIS TU_AIS_VC3
6.2.19 N1EFP0
ALM_GFP_dCSF ALM_GFP_dLFD BD_STATUS
TD TEMP_ALARM TF
RMFA FLOW_OVER
6.2.20 N1IDL4
ALM_E1AIS ALM_IMA_LIF ALM_IMA_LINK_LCD
TF TU_AIS TU_LOP
SWDL_PKG_NOB
DSOFT
6.2.21 N1IDL4A
ALM_E1AIS ALM_IMA_LIF ALM_IMA_LINK_LCD
TF TU_AIS TU_LOP
T_LOSEX
6.2.22 N1IDQ1
ALM_E1AIS ALM_IMA_LIF ALM_IMA_LINK_LCD
TF TU_AIS TU_LOP
SWDL_PKG_NOB
DSOFT
6.2.23 N1IDQ1A
ALM_E1AIS ALM_IMA_LIF ALM_IMA_LINK_LCD
TF TU_AIS TU_LOP
T_LOSEX
6.2.24 N1IFSD1
AU_AIS AU_LOP B1_EXC
SWDL_PKG_NOBDSOF
T
6.2.25 N1LWX
BD_STATUS BDID_ERROR CFGBD_FAIL
PS PORT_MODULE_OFFLIN POWER_ABNORMAL
E
SPEED_OVER T_LOC TD
TF TEMP_ALARM TEST_STATUS
W_R_FAIL
6.2.26 N1MST4
AU_AIS AU_CMM AU_LOP
TF TR_LOC PATCH_NOT_CONFIRM
6.2.27 N1PD3
A_LOC B3_EXC B3_SD
PATCH_ERR PATCH_NOT_CONFIRM
6.2.28 N1PL3
A_LOC B3_EXC B3_SD
6.2.29 N1PL3A
A_LOC B3_EXC B3_SD
6.2.30 N1PQ1
BD_STATUS BIP_EXC BIP_SD
6.2.31 N1PQM
BIP_EXC BD_STATUS BIP_SD
6.2.32 N1RPC01
AD_CHECK_FAIL BD_STATUS FAN_FAIL
6.2.33 N1RPC02
AD_CHECK_FAIL BD_STATUS FAN_FAIL
6.2.34 N1SEP
AU_AIS AU_CMM AU_LOP
TR_LOC TF W_R_FAIL
PS PATCH_ERR ALM_ALS
MOD_TYPE_MISMATCH TIME_NOT_SUPPORT
6.2.35 N1SEP1
AU_AIS AU_CMM AU_LOP
PATCH_ERR PATCH_NOT_CONFIRM PS
6.2.36 N1SF16
ALM_ALS AU_AIS AU_CMM
TF TEM_LA TC_UNEQ
SWDL_PKG_NOBDSOFT PS PATCH_NOT_CONFIRM
6.2.37 N1SL1
ALM_ALS AU_AIS AU_CMM
TF TEM_LA T_LOSEX
TIME_NOT_SUPPORT PS PATCH_ERR
SWDL_PKG_NOBDSOFT
6.2.38 N1SL1A
ALM_ALS AU_AIS AU_CMM
TF TEM_LA T_LOSEX
TIME_NOT_SUPPORT PS PATCH_ERR
SWDL_PKG_NOBDSOFT
6.2.39 N1SL4
ALM_ALS AU_AIS AU_CMM
TF TEM_LA T_LOSEX
TIME_NOT_SUPPORT PS PATCH_ERR
MOD_TYPE_MISMATCH SWDL_PKG_NOBDSOFT
6.2.40 N1SL4A
ALM_ALS AU_AIS AU_CMM
TF TEM_LA T_LOSEX
TIME_NOT_SUPPORT PS PATCH_ERR
MOD_TYPE_MISMATCH SWDL_PKG_NOBDSOFT
6.2.41 N1SL16
ALM_ALS AU_AIS AU_CMM
TF TEM_LA T_LOSEX
MOD_TYPE_MISMATCH PS PATCH_ERR
SWDL_PKG_NOBDSOFT
6.2.42 N1SL16A
ALM_ALS AU_AIS AU_CMM
TF TEM_LA T_LOSEX
MOD_TYPE_MISMATCH PS PATCH_ERR
SWDL_PKG_NOBDSOFT
6.2.43 N1SLD4
ALM_ALS AU_AIS AU_CMM
TF TEM_LA T_LOSEX
TIME_NOT_SUPPORT PS PATCH_ERR
MOD_TYPE_MISMATCH SWDL_PKG_NOBDSOFT
6.2.44 N1SLD4A
ALM_ALS AU_AIS AU_CMM
TF TEM_LA T_LOSEX
TIME_NOT_SUPPORT PS PATCH_ERR
MOD_TYPE_MISMATCH SWDL_PKG_NOBDSOFT
6.2.45 N1SLQ1
ALM_ALS AU_AIS AU_CMM
TF TEM_LA T_LOSEX
TIME_NOT_SUPPORT PS PATCH_ERR
MOD_TYPE_MISMATCH SWDL_PKG_NOBDSOFT
6.2.46 N1SLQ1A
ALM_ALS AU_AIS AU_CMM
TF TEM_LA T_LOSEX
TIME_NOT_SUPPORT PS PATCH_ERR
MOD_TYPE_MISMATCH SWDL_PKG_NOBDSOFT
6.2.47 N1SLQ4
ALM_ALS AU_AIS AU_CMM
TF TEM_LA T_LOSEX
PATCH_ERR PS TU_LOP_VC3
TIME_NOT_SUPPORT SWDL_PKG_NOBDSOFT
6.2.48 N1SLQ4A
ALM_ALS AU_AIS AU_CMM
TF TEM_LA T_LOSEX
PATCH_ERR PS TU_LOP_VC3
TIME_NOT_SUPPORT SWDL_PKG_NOBDSOFT
6.2.49 N1SLT1
ALM_ALS AU_AIS AU_CMM
TF TEM_LA T_LOSEX
SWDL_PKG_NOBDSOFT PATCH_NOT_CONFIRM PS
6.2.50 N1SPQ4
AU_AIS AU_LOP B1_EXC
PATCH_NOT_CONFIRM SWDL_PKG_NOBDSOFT
6.2.51 N2EFS0
ALM_GFP_dLFD AU_AIS B3_EXC_VC3
6.2.52 N2EFS4
ALM_GFP_dLFD AU_AIS B3_EXC_VC3
SWDL_PKG_NOBDSOF
T
6.2.53 N2EFT8
ALM_GFP_dLFD B3_EXC_VC3 B3_SD_VC3
EX_ETHOAM_MPID_CNF VCTRUNK_NO_FLOW
LCT
6.2.54 N2EFT8A
LP_RDI_VC12 LP_RDI_VC3 LP_REI_VC12
ETHOAM_DISCOVER_FAI ETHOAM_SELF_LOOP
L
6.2.55 N2EGR2
AU_AIS AU_LOP B3_EXC_VC3
LPT_RFI SWDL_PKG_NOBDSOFT
6.2.56 N2EGS2
ALM_GFP_dLFD AU_AIS B3_EXC_VC3
SWDL_PKG_NOBDSOF
T
6.2.57 N2EGT2
ALM_GFP_dLFD AU_AIS AU_LOP
OUT_PWR_LOW T_LOSEX TD
TEMP_OVER TF TR_LOC
6.2.58 N2EMR0
AU_AIS AU_LOP B3_EXC_VC3
ETH_NO_FLOW SWDL_PKG_NOBDSOFT
6.2.59 N2PD3
BD_STATUS B3_EXC B3_SD
P_FFM
6.2.60 N2PL3
B3_EXC B3_SD BD_STATUS
P_FFM
6.2.61 N2PL3A
BD_STATUS B3_EXC B3_SD
PATCH_NOT_CONFIRM
6.2.62 N2PQ1
B3_EXC B3_SD BD_STATUS
PATCH_NOT_CONFIRM PATCHFILE_NOTEXIST
6.2.63 N2PQ3
BD_STATUS B3_EXC B3_SD
P_FFM
6.2.64 N2SL1
ALM_ALS ALM_AU3AIS ALM_AU3B3OVER
TU_AIS_VC12 TF TEM_LA
PS
6.2.65 N2SL4
ALM_ALS ALM_AU3AIS ALM_AU3B3OVER
TU_AIS_VC12 TF TEM_LA
MOD_TYPE_MISMATCH PS
6.2.66 N2SL16
ALM_ALS ALM_AU3AIS ALM_AU3B3OVER
TU_AIS_VC12 TF TEM_LA
MOD_TYPE_MISMATCH PS
6.2.67 N2SL16A
ALM_ALS ALM_AU3AIS ALM_AU3B3OVER
TU_AIS_VC12 TF TEM_LA
MOD_TYPE_MISMATCH PS
6.2.68 N2SLD4
ALM_ALS ALM_AU3AIS ALM_AU3B3OVER
TU_AIS_VC12 TF TEM_LA
MOD_TYPE_MISMATCH PS
6.2.69 N2SLO1
ALM_ALS ALM_AU3AIS ALM_AU3B3OVER
TR_LOC TEM_HA TF
PS TU_LOP_VC3 PATCH_NOT_CONFIRM
6.2.70 N2SLQ1
ALM_ALS ALM_AU3AIS ALM_AU3B3OVER
TU_AIS_VC12 TF TEM_LA
MOD_TYPE_MISMATCH PS
6.2.71 N2SLQ4
ALM_ALS ALM_AU3AIS ALM_AU3B3OVER
TU_AIS_VC12 TF TEM_LA
MOD_TYPE_MISMATCH PS
6.2.72 N2SPQ4
AU_AIS AU_LOP B1_EXC
PATCH_NOT_CONFIRM PS SWDL_PKG_NOBDSOFT
6.2.73 N3EFS4
ALM_GFP_dCSF ALM_GFP_dLFD B3_EXC_VC3
VCAT_SQM_VC3 VCTRUNK_NO_FLOW
6.2.74 N3EGS2
ALM_GFP_dLFD B3_EXC_VC3 B3_SD_VC3
TD TEMP_OVER TF
VCAT_SQM_VC3 VCTRUNK_NO_FLOW
6.2.75 N3EGS4
ALM_GFP_dCSF ALM_GFP_dLFD ETHOAM_RMT_SD
TD ETHOAM_DISCOVER_F ETHOAM_RMT_CRIT_FAU
AIL LT
TU_AIS TEMP_OVER TF
SWDL_PKG_NOBDSOF
T
6.2.76 N3SL16
ALM_ALS ALM_AU3AIS ALM_AU3B3OVER
TC_UNEQ TU_AIS_VC12 TF
PATCH_ERR TIME_NOT_SUPPORT PS
6.2.77 N3SL16A
ALM_ALS ALM_AU3AIS ALM_AU3B3OVER
TC_UNEQ TU_AIS_VC12 TF
PATCH_ERR TIME_NOT_SUPPORT PS
6.2.78 N3SLQ41
ALM_ALS ALM_AU3AIS ALM_AU3B3OVER
TC_INCAIS POWER_ABNORMAL PS
TF TC_RDI TC_REI
6.2.79 N3SLO1
ALM_ALS ALM_AU3AIS ALM_AU3B3OVER
PS SLAVE_WORKING POWER_ABNORMAL
TR_LOC TU_LOP_VC3 TF
6.2.80 N4EFS0
ALM_GFP_dLFD AU_AIS B3_EXC_VC3
TF SUM_INPWR_LOW SUBCARD_ABN
VCAT_LOA TPS_ALM TD
PATCHFILE_NOTEXIST SWDL_PKG_NOBDSO
FT
6.2.81 N4EGS4
ALM_GFP_dCSF ALM_GFP_dLFD AU_AIS
TD TEMP_OVER TF
6.2.82 N4SLD64
ALM_ALS AU_AIS AU_CMM
R_OOF R_LOF PS
TU_AIS_VC3 TR_LOC TF
TU_LOP_VC3
6.2.83 N5EFS0
ALM_GFP_dCSF ALM_GFP_dLFD B3_EXC_VC3
TD TEMP_OVER TF
6.2.84 ODU
BD_STATUS CONFIG_NOSUPPORT HARD_BAD
6.2.85 Q2CXL1
ECXL
APS_FAIL APS_INDI BD_STATUS
RPS_INDI SERVCHIP_ABN
GSCC
APS_MANUAL_STOP BD_AT_LOWPOWER BD_NOT_INSTALLED
Q1SL1
ALM_ALS AU_AIS AU_CMM
R_OOF TF TEM_LA
T_LOSEX PS TR_LOC
6.2.86 Q2CXL4
ECXL
APS_FAIL APS_INDI BD_STATUS
RPS_INDI SERVCHIP_ABN
GSCC
APS_MANUAL_STOP BD_AT_LOWPOWER BD_NOT_INSTALLED
Q1SL4
ALM_ALS AU_AIS AU_CMM
R_OOF TF TEM_LA
T_LOSEX PS TR_LOC
6.2.87 Q2CXL16
ECXL
APS_FAIL APS_INDI BD_STATUS
RPS_INDI SERVCHIP_ABN
GSCC
APS_MANUAL_STOP BD_AT_LOWPOWER BD_NOT_INSTALLED
Q1SL16
ALM_ALS AU_AIS AU_CMM
R_OOF TF TEM_LA
T_LOSEX PS TR_LOC
6.2.88 Q3CXL1
ECXL
APS_FAIL APS_INDI BD_STATUS
RPS_INDI SERVCHIP_ABN
GSCC
APS_MANUAL_STOP BD_AT_LOWPOWER BD_NOT_INSTALLED
Q1SL1
ALM_ALS AU_AIS AU_CMM
R_OOF TF TEM_LA
T_LOSEX PS TR_LOC
6.2.89 Q3CXL4
ECXL
APS_FAIL APS_INDI BD_STATUS
RPS_INDI SERVCHIP_ABN
GSCC
APS_MANUAL_STOP BD_AT_LOWPOWER BD_NOT_INSTALLED
Q1SL4
ALM_ALS AU_AIS AU_CMM
R_OOF TF TEM_LA
T_LOSEX PS TR_LOC
6.2.90 Q3CXL16
ECXL
APS_FAIL APS_INDI BD_STATUS
RPS_INDI SERVCHIP_ABN
GSCC
APS_MANUAL_STOP BD_AT_LOWPOWER BD_NOT_INSTALLED
Q1SL16
ALM_ALS AU_AIS AU_CMM
R_OOF TF TEM_LA
T_LOSEX PS TR_LOC
6.2.91 Q5CXLLN
RPS_INDI SERVCHIP_ABN
TIME_NOT_SUPPORT SERVCHIP_ABN
GSCC
APS_MANUAL_STOP BD_AT_LOWPOWER BD_NOT_INSTALLED
Q2SLN
R_LOS R_LOF R_LOF
PS B3_EXC_VC3 TU_AIS_VC3
TIME_NOT_SUPPORT
6.2.92 Q5CXLQ41
RPS_INDI SERVCHIP_ABN
TIME_NOT_SUPPORT SERVCHIP_ABN
GSCC
APS_MANUAL_STOP BD_AT_LOWPOWER BD_NOT_INSTALLED
Q2SLQ41
R_LOS R_LOF R_LOF
PS B3_EXC_VC3 TU_AIS_VC3
TIME_NOT_SUPPORT
6.2.93 R1AMU
ALM_HANGUP BD_STATUS CHIP_ABN
6.2.94 R1AUX
BD_STATUS FPGA_ABN HARD_BAD
SWDL_PKG_NOBDSOFT
6.2.95 R2AUX
BD_STATUS FPGA_ABN HARD_BAD
SWDL_PKG_NOBDSOFT
6.2.96 R1CXLLN
RCXL
APS_FAIL APS_INDI BD_STATUS
RPS_INDI
GSCC
APS_MANUAL_STOP BD_AT_LOWPOWER BD_NOT_INSTALLED
R1SLN
ALM_ALS AU_AIS AU_LOP
TC_UNEQ TF TC_TIM
TU_AIS_VC12 PS TR_LOC
6.2.97 R1CXLD41
RCXL
APS_FAIL APS_INDI BD_STATUS
RPS_INDI
GSCC
APS_MANUAL_STOP BD_AT_LOWPOWER BD_NOT_INSTALLED
R1SLD41
ALM_ALS AU_AIS AU_LOP
TC_UNEQ TF TC_TIM
TU_AIS_VC12 PS TR_LOC
6.2.98 R1CXLQ41
RCXL
APS_FAIL APS_INDI BD_STATUS
RPS_INDI
GSCC
APS_MANUAL_STOP BD_AT_LOWPOWER BD_NOT_INSTALLED
R1SLQ41
ALM_ALS AU_AIS AU_LOP
TC_UNEQ TF TC_TIM
TU_AIS_VC12 PS TR_LOC
6.2.99 R1EFT4
ALM_GFP_dLFD B3_EXC_VC3 B3_SD_VC3
W_R_FAIL ETH_NO_FLOW
6.2.100 R1EOW
ALM_HANGUP BD_STATUS CHIP_ABN
6.2.101 R1FAN
BD_STATUS FAN_FAIL
6.2.102 R1PD1
BD_STATUS BIP_EXC BIP_SD
PS T_ALOS SPARE_PATH_ALM
SWDL_PKG_NOBDSOF
T
6.2.103 R1PIU
BD_STATUS POWER_ABNORMAL
6.2.104 R1PIUA
BD_STATUS POWER_ABNORMAL
6.2.105 R1PIUB
BD_STATUS POWER_ABNORMAL
6.2.106 R1PIUC
BD_STATUS POWER_ABNORMAL
6.2.107 R1PL1
BIP_EXC BD_STATUS BIP_SD
PS SLAVE_WORKING SPARE_PATH_ALM
6.2.108 R1SL1
ALM_ALS AU_AIS AU_CMM
TEM_LA TEST_STATUS TF
LOOP_ALM PS SWDL_PKG_NOBDSOFT
MOD_TYPE_MISMATCH
6.2.109 R1SL4
ALM_ALS AU_AIS AU_CMM
POWER_ABNORMAL R_LOC TF
TR_LOC TU_AIS_VC12 PS
MOD_TYPE_MISMATCH
6.2.110 R1SLD4
ALM_ALS AU_AIS AU_CMM
POWER_ABNORMAL R_LOC TF
TR_LOC TU_AIS_VC12 PS
MOD_TYPE_MISMATCH
6.2.111 R1SLQ1
ALM_ALS AU_AIS AU_CMM
POWER_ABNORMAL R_LOC TF
TR_LOC TU_AIS_VC12 PS
MOD_TYPE_MISMATCH
6.2.112 R2CXLLN
RPS_INDI
TIME_NOT_SUPPORT SERVCHIP_ABN
GSCC
APS_MANUAL_STOP BD_AT_LOWPOWER BD_NOT_INSTALLED
R2SLN
ALM_ALS ALM_AU3AIS ALM_AU3B3OVER
R_LOF PS TC_EXC
TF TEMP_OVER TU_LOP_VC3
6.2.113 R2CXLQ41
RPS_INDI
TIME_NOT_SUPPORT SERVCHIP_ABN
GSCC
APS_MANUAL_STOP BD_AT_LOWPOWER BD_NOT_INSTALLED
R2SLQ41
ALM_ALS ALM_AU3AIS ALM_AU3B3OVER
R_LOF PS TC_EXC
TF TEMP_OVER TU_LOP_VC3
6.2.114 R2PD1
B3_EXC B3_SD BD_STATUS
PATCH_NOT_CONFIRM SWDL_PKG_NOBDSOFT
6.2.115 R3PD1
B3_EXC B3_SD BD_STATUS
SWDL_PKG_NOBDSOFT
6.2.116 R3SL1
ALM_ALS ALM_AU3AIS ALM_AU3B3OVER
R_LOF PS TC_EXC
TF TEMP_OVER TU_LOP_VC3
W_R_FAIL
6.2.117 R3SL4
ALM_ALS ALM_AU3AIS ALM_AU3B3OVER
R_LOF PS TC_EXC
TF TEMP_OVER TU_LOP_VC3
W_R_FAIL
6.2.118 R3SLD4
ALM_ALS ALM_AU3AIS ALM_AU3B3OVER
R_LOF PS TC_EXC
TF TEMP_OVER TU_LOP_VC3
W_R_FAIL
6.2.119 R3SLQ1
ALM_ALS ALM_AU3AIS ALM_AU3B3OVER
R_LOF PS TC_EXC
TF TEMP_OVER TU_LOP_VC3
W_R_FAIL
This topic introduces the common methods used for handling alarms.
l Handle the root alarms first and then the non-root alarms.
According to the relation of common alarms, handle the root alarms caused by a fault or
an abnormal event first. Then, handle the non-root alarms caused by the root alarms.
l Check the NMS first and then the NE; check the external factors and then the
internal factors.
On the NMS, remotely check and analyze the alarms and performance events on the
equipment. Then, check the configuration and operations on the NE. Afterwards, check
the links between NEs. Finally, check the hardware of the NE on site.
l Check the common causes and then the special causes.
According to the experience in handling alarms and the information about other alarms,
check the common causes of the alarms, and then the special causes.
l Check the software first and then the hardware.
If the alarm is caused by the fault of the equipment, reset the board to rectify the
software fault and then replace the board to rectify the hardware fault.
l Operation environment
In the telecommunications room, the temperature and humidity do not meet the
requirements for long-time and short-time operations. For example, the environment is
not clean or the ventilation is poor.
l Voltage of power supply
The voltage of power supply is not the DC that supports the normal operation of the
equipment. The voltage fluctuates sharply and is more than 20% of the normal value.
l Grounding
The grounding resistance of the equipment is higher than 1 ohm. Hence, the equipment
can be easily damaged by lightening.
l Heat dissipation
The heat dissipation of the equipment is poor. For example, the exhaust vents are
blocked, the air filter is dirty, and the fans work abnormally.
For specific requirements on the operation environment, see "Operation Environment
Requirements" in the Installation Reference.
Precautions
NOTICE
The operations of reseating a board and performing a cold reset mentioned in this document
cause service interruptions. If the services are not protected, implement the operations with
caution.
NOTICE
Performing a self-loop for the first VC-4 path may affect the ECC communication. Thus, try
to avoid looping back the service of the first VC-4 path. If the loopback method cannot be
used to locate the fault, modify the configuration or use the substitution method to locate the
fault.
All the fault locating methods have advantages and disadvantages. The maintenance
personnel should use various methods to handle the alarm. For common fault handling
methods, see "Common Methods of Locating Faults" in the Troubleshooting.
NOTE
l The alarm parameters listed in this document are those displayed on the NMS. When you browse an
alarm on the NMS, select the alarm. In the Alarm Details field, the related parameters of the alarm
are displayed.
l If the methods provided in this document cannot clear the alarm, contact Huawei technical support
engineers to handle the alarm.
7.1 ALM_GFP_dCSF
7.2 ALM_GFP_dLFD
7.3 APS_FAIL
7.4 APS_INDI
7.5 AU_AIS
7.6 AU_LOP
7.7 B1_SD
7.8 B2_SD
7.9 B3_SD
7.10 B3_EXC
7.11 BIP_SD
7.12 B1_EXC
7.13 B2_EXC
7.14 BIP_EXC
7.15 BD_STATUS
7.16 BUS_ERR
7.17 COMMUN_FAIL
7.18 DOWN_E1_AIS
7.19 ETH_LOS
7.20 ETH_CFM_LOC
7.21 ETH_CFM_MISMERGE
7.22 ETH_CFM_RDI
7.23 ETH_CFM_UNEXPERI
7.24 EXT_SYNC_LOS
7.25 FAN_FAIL
7.26 FCS_ERR
7.27 HARD_BAD
7.28 HP_LOM
7.29 HP_RDI
7.30 HP_SLM
7.31 HP_TIM
7.32 HP_UNEQ
7.33 HSC_UNAVAIL
7.34 IN_PWR_ABN
7.35 IN_PWR_HIGH
7.36 IN_PWR_LOW
7.37 J0_MM
7.38 LAG_FAIL
7.39 LAG_PORT_FAIL
7.40 LINK_ERR
7.41 LP_RDI
7.42 LP_UNEQ
7.43 LPT_INEFFECT
7.44 LPT_RFI
7.45 LSR_WILL_DIE
7.46 LTI
7.47 MS_AIS
7.48 MS_RDI
7.49 OOL
7.50 P_LOS
7.51 POWER_ABNORMAL
7.52 POWER_FAIL
7.53 R_LOF
7.54 R_OOF
7.55 R_LOS
7.56 SLAVE_WORKING
7.57 SYN_BAD
7.58 SUBCARD_ABN
7.59 TEMP_ALARM
7.60 TEMP_OVER
7.61 TF
7.62 T_LOSEX
7.63 TU_AIS
7.64 TU_LOP
7.65 UP_E1_AIS
7.66 W_R_FAIL
7.1 ALM_GFP_dCSF
Description
The ALM_GFP_dCSF is an alarm indicating the loss of GFP client signal. When the source
end cannot receive the client signal, it sends the management frame to the sink end. When the
sink end receives the management frame, the ALM_GFP_dCSF alarm is reported.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 2, Parameter 3 Indicates the number of the VCTRUNK where the alarm occurs.
Parameter 2: 0x00
Parameter 3: 0x01-0x40 (1-64)
If this section does not describe the common fault symptom or if the actual fault symptom is not
contained in the description of the common fault symptom, handle the ALM_GFP_dCSF alarm by
following the steps provided in Handling Procedure.
Table 7-1 lists the common fault symptoms of the ALM_GFP_dLFD alarm.
A board at the source end reports an alarm (such Cause 1: The physical link at the source
as ETH_LOS or LINK_ERR) indicating the end is faulty, or the optical/electrical
signals are lost. signals are lost.
A board at the source end reports an alarm (such Cause 2: The interface module at the
as the LSR_NO_FITED alarm) associated with source end is incorrect. For example, the
an optical module. optical module is absent or does not
match, the interface is faulty, or the
board is faulty.
Possible Causes
The possible causes of the ALM_GFP_dCSF alarm are as follows:
l Cause 1: The physical link at the source end is faulty, or the optical/electrical signals are
lost.
Inter- X X Inter-
E L SDH L E
connected Ethernet C C Ethernet connected
U U network U U
equipment network S S network equipment
l Cause 2: The interface module at the source end is incorrect. For example, the optical
module is absent or does not match, the interface is faulty, or the board is faulty.
Inter- X X Inter-
E L SDH L E
connected Ethernet C C Ethernet connected
U U network U U
equipment network S S network equipment
ALM_GFP_dCSF
Inter- X X
E L SDH L E Inter-
connected Ethernet C C Ethernet
U U network U U connected
equipment network S S network
equipment
Procedure
Step 1 Check the alarm on the NMS. Determine the board and port that report the alarm according to
the alarm parameters. For details, see Viewing the Current Alarms in the Supporting Tasks.
Step 2 Cause 1: The physical link at the source end is faulty, or the optical/electrical signals are lost.
1. Check whether the physical link at the source end of the VCTRUNK where the uplink
service is configured is normal. As shown in Figure 7-1, perform the following
operations according to the port type of the Ethernet unit on NE1.
If... Then...
The port of the Ethernet unit is an optical port Go to the next step.
The port of the Ethernet unit is an electrical port Go to Step Step 2.7.
2. Check whether the bending radius of the fiber jumper is within the specified range. If the
bending radius is less than 6 cm, spool the fiber jumper again. Check whether the alarm
is cleared.
3. Check the fiber between the optical port on the Etherenet board at the source end is
connected correctly to the interconnected equipment. If the connection is incorrect,
connect the optical port on the Etherenet board at the source end to the corresponding
port of the interconnected equipment according to the actual network.
4. Check whether the fiber connector is connected properly.
If... Then...
The fiber connector is loose Connect the fiber connector properly. Check whether
the alarm is cleared. If the alarm persists, go to the
next step.
If... Then...
5. Check whether the fiber connector is dirty. For details, see Checking the Optical Fiber
Connector in the Supporting Tasks.
If... Then...
The fiber Clean the optical connector immediately. For details on how to
connector is dirty clean the fiber connectors, see the Supporting Task.
Using the Fiber Cleaner to Clean the Optical Fiber Connector
Using the Lens Tissue to Clean the Optical Fiber Connector
Using the Dust-Free Cotton Bar to Clean the Optical Fiber
Adapter
Check whether the alarm is cleared. If the alarm persists, go to
the next step.
6. Check whether the cable is pressed, damaged, peeled off, aged, or cut. If the fiber is
faulty, replace the fiber. Check whether the alarm is cleared. If the alarm persists, go to
Step Step 3.
7. Check the fiber between the electrical port on the Ethernet board at the source end is
connected correctly to the interconnected equipment. If the connection is incorrect,
connect the electrical port on the Ethernet board at the source end to the corresponding
port of the interconnected equipment according to the actual network. Check whether the
alarm is cleared.
8. If the alarm persists, check whether the cable is grounded properly, and check whether
the cable and its connector are damaged. If the cable is faulty, replace the cable. Check
whether the alarm is cleared. If the alarm persists, go to Step Step 3.2.
Step 3 Cause 2: The interface module at the source end is incorrect. For example, the optical module
is absent or does not match, the interface is faulty, or the board is faulty.
1. As shown in Figure 7-2, check whether the interface module at the source end works
normally.
If... Then...
A board at the source end reports an Clear the alarm immediately. Check
alarm (such as LASER_MOD_ERR whether the ALM_GFP_dCSF alarm is
alarm) associated with an optical module cleared. If the alarm persists, go to the
next step.
2. Replace the corresponding board at the source end. If the board supports the pluggable
optical module, replace the pluggable optical module. For details, see Replacing a
Pluggable Optical Module in the Parts Replacement. Otherwise, replace the faulty board.
For details, see Replacing Boards Onsite in the Supporting Tasks.
3. Check whether the alarm is cleared. If the alarm persists, go to Step Step 4.
Step 4 Cause 2: The board that reports the alarm is faulty.
1. Replace the board that reports the alarm. For details, see Replacing an Ethernet Board in
the Parts Replacement.
2. Check whether the alarm is cleared. If the alarm persists, contact Huawei technical
support engineers to handle the alarm.
----End
Related Information
None.
7.2 ALM_GFP_dLFD
Description
The ALM_GFP_dLFD is an alarm indicating that the generic framing procedure (GFP) frame
is out of frame. This alarm occurs when the GFP state machine escapes from the SYNC state,
and is cleared when the state machine enters the SYNC state again.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1 Indicates the ID of the logical port, and the value is always 0.
Parameter 2, Parameter Indicate the VCTRUNK number where the alarm occurs.
3 Parameter 2 indicates the most significant byte (MSB) and
Parameter 3 indicates the least significant byte (LSB).
The services are interrupted unidirectionally on certain boards such as the N2EFS4 and
N4EFS0.
l If the number of uplink timeslots at the local end is more than the number of downlink
timeslots at the opposite end, the services that are transmitted from the local end to the
opposite end are interrupted.
l If the number of uplink timeslots at the local end is less than the number of downlink
timeslots at the opposite end, the services that are transmitted from the local end to the
opposite end are not interrupted.
If the possible causes do not correspond to any symptoms, or the symptoms are not listed in this topic,
handle the alarm according to the handling procedures.
Table 7-2 lists the common fault symptoms of the ALM_GFP_dLFD alarm.
The alarms related to errors and optical power Cause 2: The performance of the service
and the performance events related to errors transmission line degrades.
occur in the service transmission line.
Possible Causes
The possible causes of the ALM_GFP_dLFD alarm are as follows:
l Cause 1: The settings of timeslots and other parameters of the VCTRUNKs at both ends
are inconsistent.
l Cause 2: The performance of the service transmission line degrades.
l Cause 3: A certain board is faulty.
Procedure
Step 1 Check the alarm on the NMS. Determine the VCTRUNK ID according to the alarm
parameter. For details, see Viewing the Current Alarms in the Supporting Tasks.
Step 2 Cause 1: The settings of timeslots and other parameters of the VCTRUNKs at both ends are
inconsistent.
1. Check whether the number of uplink (or downlink) timeslots bound with the VCTRUNK
at the local end is consistent with the number of downlink (or uplink) timeslots bound
with the VCTRUNK at the opposite end.
If... Then...
2. Select the relevant NE. Choose Configuration > SDH Service Configuration from the
Function Tree.
3. Check whether the number of timeslots bound with the VCTRUNK is consistent with the
settings of the cross-connections.
If... Then...
The number of timeslots bound with the Reset the number of timeslots bound with
VCTRUNK is inconsistent with the the VCTRUNK or cross-connections.
settings of the cross-connections Check whether the alarm is cleared. If the
alarm persists, go to the next step.
4. Check whether the service levels of the SDH cross-connections are the same at both
ends. If the service level of the SDH cross-connections at the local end is VC-3 and the
service level of the SDH cross-connections at the opposite end is VC-4, the
ALM_GFP_dLFD alarm is reported. Thus, you need to reconfigure the cross-connect
service level in the case of the inconsistency.
5. Check whether the alarm is cleared. If the alarm persists, go to Step Step 3.
If... Then...
The BIP_EXC, BIP_SD, B3_EXC, Take priority to clear the preceding alarms or
B3_SD, HPBBE, LPBBE, or performance events. Check whether the alarm
IN_PWR_ABN occurs is cleared. If the alarm persists, go to Step
Step 4.
If... Then...
----End
Related Information
Cell Delimitation State Machine
The cell delimitation state machine is available in three states: HUNT, PRESYNC, and
SYNC. In the HUNT state, the state machine hunts the position of delimitating cells in the
BYTE BY BYTE manner. After finding a correct HCS, the state machine changes to the
PRESYNC state. In the PRESYNC state, the state machine locks the position of delimitating
cells. After consecutively receiving DELTA correct HCS cells, the state machine changes to
the SYNC state. In this case, the cell boundary is found. In the PRESYNC state, after
receiving an incorrect HCS cell, the state machine returns to the HUNT state. In the SYNC
state, after consecutively receiving ALPHA incorrect HCS cells, the state machine changes to
the HUNT state. Otherwise, it keeps in the SYNC state, as shown in the following figure.
7.3 APS_FAIL
Description
The APS_FAIL is an alarm indicating the APS protection switching failure. This alarm is
reported when the MSP switching fails.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1 Indicates the type of the MSP group in which protection switching occurs.
l 0x01: Linear MSP group
l 0x02: Ring MSP group
If this section does not describe the common fault symptom or if the actual fault symptom is not
contained in the description of this section, handle the APS_FAIL alarm by following the steps provided
in Handling Procedure.
None.
Possible Causes
The possible causes of the APS_FAIL alarm are as follows:
l Cause 1: The MSP configuration is incorrect.
l Cause 2: The MSP node configuration is lost.
Procedure
Step 1 Check the alarm on the NMS, and then determine the type and ID of the protection group
where the alarm is generated according to the alarm parameters. For details, see Viewing the
Current Alarms in the Supporting Tasks.
If... Then...
The parameters are set Set the parameters correctly. For details, see Setting
incorrectly Protection Subnet Parameters in the Configuration Guide.
Check whether the alarm is cleared. If the alarm persists,
go to the next step.
3. Check whether the MSP configuration of each NE on the ring and physical connections
are correct. In the case of ring MSP, check the connection of the east and west fibers. In
the case of linear MSP, check the connections of the working and protection fibers.
If... Then...
The fiber is connected Reconnect the fiber according to the actual networking mode
incorrectly and configuration. Check whether the alarm is cleared. If the
alarm persists, go to Step Step 3.
4. Deliver the correct MSP configuration. Check whether the alarm is cleared. If the alarm
persists, go to Step Step 3.
For details on the ring MSP configuration, see Creating an MS Ring Protection
Subnet in the Configuration Guide.
For details on the ring MSP configuration, see Creating a Linear MS Protection
Subnet in the Configuration Guide.
Step 3 Cause 2: The MSP node configuration is lost.
1. Check whether the contents of the network-wide MSP protocol are normal, such as the
APS parameter and status.
If... Then...
The switching protocol is Stop the switching protocol and then restart it.
abnormal. For example,
the switching protocol Restart the APS protocol for the ring MSP. For
cannot be normally started details, see Creating an MS Ring Protection Subnet
or stopped, the switching in the Configuration Guide.
cannot be initiated, or the Restart the APS protocol for the linear MSP. For
switching state is incorrect. details, see Creating a Linear MS Protection Subnet
in the Configuration Guide.
Check whether the alarm is cleared. If the alarm
persists, go to Step Step 4.
For the definition of the K byte in the case of linear MSP, see Basic Concepts in the Feature
Description. For the meanings of the K byte in the case of ring MSP, see Basic Concepts in the
Feature Description.
If... Then...
The service board is Replace the service board. For details, see Replacing an
faulty SDH Board in the Parts Replacement.
Check whether the alarm is cleared. If the alarm persists, go
to Step Step 5.
Step 5 Cause 4: The configuration data of the SCC board is different from the configuration data of
the cross-connect board.
1. In the case of the OptiX OSN equipment, the MSP protocol is implemented by the cross-
connect board. If the data on the SCC board is different from the data on the cross-
connect board, the MSP switching becomes abnormal. In this case, contact Huawei
technical support engineers to check whether the MSP node parameters of the cross-
connect board where the alarm is reported are the same as the parameters of the SCC
board.
If... Then...
The MSP node parameters of the cross-connect board are Go to the next step.
different from the parameters of the SCC board.
The MSP node parameters of the cross-connect board are the Go to Step Step 6.
same as the parameters of the SCC board
2. Perform a warm reset on the cross-connect board. For details on how to perform a reset
operation, see Resetting Boards in the Supporting Tasks. Check whether the alarm is
cleared. If the alarm persists, go to Step Step 6.
Step 6 Cause 5: The MSP protocol types are different from each other.
1. In the Main Topology, select the NE. Right-click the NE and choose SDH Protection
Subnet > SDH Protection Subnet Management from the shortcut menu. On the SDH
Protection Subnet Management tab, query the parameters such as Consistent Status
and Protocol Type.
2. Check whether the protocol types specified for the nodes are consistent with each other.
If a new protocol is set for the active cross-connect board and an old protocol is set for
the standby cross-connect board, the MSP switching may be abnormal.
If... Then...
The protocol types are Contact Huawei technical support engineers to specify
specified incorrectly the protocol types again to ensure consistency of all the
nodes on the same MSP ring network.
The protocol types are Contact Huawei technical support engineers to handle
specified correctly the alarm.
----End
Related Information
None.
7.4 APS_INDI
Description
The APS_INDI is an alarm indicating the APS state. This alarm is reported when the MSP is
in the switching state.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1 Indicates the type of the MSP group in which protection switching occurs.
l 0x01: Linear MSP group
l 0x02: Ring MSP group
If this section does not describe the common fault symptom or if the actual fault symptom is not
contained in the description of this section, handle the APS_INDI alarm by following the steps provided
in Handling Procedure.
None.
Possible Causes
The possible causes of the APS_INDI alarm are as follows:
l Cause 1: An external command is issued to initiate a switching (such as manual
switching, forced switching, exercise switching, and lockout of switching).
l Cause 2: There is an alarm (such as the R_LOS, R_LOF, MS_AIS, B2_EXC, or B2_SD
alarm) that triggers an automatic MSP switching.
l Cause 3: The service board is faulty.
l Cause 4: The cross-connect board is faulty.
Procedure
Step 1 Check the alarm on the NMS, and then determine the type and ID of the protection group
where the alarm is generated according to the alarm parameters. For details, see Viewing the
Current Alarms in the Supporting Tasks.
Step 2 Cause 1: An external command is issued to initiate a switching (such as manual switching,
forced switching, exercise switching, and lockout of switching).
1. Check the switching state of the protection group. For details, see Querying and Clearing
the Switching Status in the Supporting Tasks.
If... Then...
The MSP is in a state of manual switching, Clear the switching state. Check
forced switching, exercise switching, or whether the alarm is cleared. If the
lockout of switching alarm persists, go to Step Step 3.
Step 3 Cause 2: There is an alarm (such as the R_LOS, R_LOF, MS_AIS, B2_EXC, or B2_SD
alarm) that triggers an automatic MSP switching.
1. Check whether the protection group is in the automatic switching state.
If... Then...
The equipment reports the The MSP protection group changes to the switching
R_LOS, R_LOF, MS_AIS or state and reports the APS_INDI alarm. Clear the
B2_EXC alarm alarm immediately, and then check whether the
APS_INDI alarm is cleared.
If the APS_INDI alarm persists, go to the next step.
The equipment reports the After you enable the SD switching condition, the SD
B2_SD alarm alarm can trigger the MSP switching. You can use
any of the following methods to clear the APS_INDI
NOTE
alarm.
The automatic MSP switching
conditions include the SF Disable the SD switching condition. For details,
condition and SD condition. By see Setting Protection Subnet Parameters in the
default, the B2_SD alarm is not a
Configuration Guide.
trigger condition of MSP
switchings, but you can set the Clear the B2_SD alarm immediately.
alarm to SD Condition.
Check whether the APS_INDI alarm is cleared. If
the APS_INDI alarm persists, go to the next step.
2. Check the method for setting the revertive mode of the protection group.
If... Then...
Revertive Mode After the working path recovers, the services can be switched
is set to automatically from the protection path to the working path only
Revertive when the preset wait to restore (WTR) time expires. After the
switching is successful, the APS_INDI alarm is cleared.
Wait for the MSP switching to be restored automatically to the
normal state, and then check whether the APS_INDI alarm is
cleared. If the APS_INDI alarm persists, go to Step Step 4.
Revertive Mode After the working path recovers, the services are not switched
is set to Non- automatically from the protection path to the working path, and the
Revertive APS_INDI alarm persists.
To clear the APS_INDI alarm, switch the services manually from
the working path to the protection path. Go to the next step.
3. In the NE Explorer, select the NE, and then choose Configuration > Linear MS or
Configuration > Ring MS from the Function Tree. In Slot Mapping Relation, select
the working unit or protection unit of a protection group. Right-click the working unit or
protection unit, and then choose the required switching from the short-cut menu.
4. After successful manual switching, check whether the APS_INDI alarm is cleared. If the
alarm persists, go to Step Step 4.
Step 4 Cause 3: The service board is faulty.
1. Check the service board of the MSP is faulty.
If... Then...
If... Then...
2. Replace the corresponding cross-connect board. For details, see Replacing a CXL Board
in the Parts Replacement. Then, check whether alarm is cleared. If the alarm persists,
contact Huawei technical support engineers to handle the alarm.
----End
Related Information
Revertive Mode
The Revertive Mode field can be set to Revertive or Non-Revertive. Generally, it is
recommended that you set Revertive Mode to Revertive.
l If you set Revertive Mode to Revertive, the services are switched automatically from
the protection path to the working path after the working path recovers.
l If you set Revertive Mode to Non-Revertive, the services are not switched
automatically from the protection path to the working path after the working path
recovers, and the services are still transmitted over the protection path.
7.5 AU_AIS
Description
The AU_AIS is an alarm indication of the administrative unit (AU). This alarm occurs when
the optical interface on the local NE receives the AU pointer of all 1s.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 2, Indicates the ID of the AU-4 path. Parameter 2 indicates the most
Parameter 3 significant byte (MSB) and Parameter 3 indicates the least significant
byte (LSB).
For example, Parameter 1 = 0x01, Parameter 2 = 0x00, Parameter 3 =
0x01. The parameters indicate that the alarm is reported by AU-4 path 1
at port 1 on the relevant board.
If this section does not describe the common fault symptom or the actual fault symptom is not contained
in the description of this section, handle the AU_AIS alarm by following the steps provided in Handling
Procedure.
Table 7-3 lists the common fault symptoms of the AU_AIS alarm.
The higher level alarms occur on the NE, such Cause 1: The local NE inserts the AIS
as R_LOS, R_LOF, R_OOF, B1_EXC, and alarm to the lower level circuit.
B2_EXC.
The higher level alarms listed in Table 7-4 Cause 2: The upstream NE inserts the
occur on the upstream NE. AIS alarm to the downstream NE.
The AU_AIS alarm is reported by all the VC-4 Cause 3: The transmit boards (including
paths on multiple boards of the NE. The alarm the cross-connect and timing board) on
may be caused by the fault of the clock unit. the upstream NE are faulty.
Possible Causes
The possible causes of the AU_AIS alarm are as follows:
l Cause 1: The local NE inserts the AIS alarm to the lower level circuit.
l Cause 2: The upstream NE inserts the AIS alarm to the downstream NE.
NE1 NE(n)
West NE2 East West NE3 East
(Source end of the VC4) (Sink end of the VC4)
l Cause 3: The transmit boards (including the cross-connect and timing board) on the
upstream NE are faulty.
l Cause 4: The receive boards on the local NE are faulty.
Procedure
Step 1 Cause 1: The local NE inserts the AIS alarm to the lower level circuit.
1. On the NMS, check whether any higher level alarm occurs on the local NE. As shown in
Figure 7-4, the east line board on NE2 inserts the AIS alarm to the lower level circuit.
Thus, check whether the west line board on NE2 reports a higher level alarm such as
R_LOS. For details, see Viewing the Current Alarms in the Supporting Tasks.
If... Then...
If the R_LOS, R_LOF, R_OOF, Clear the alarm immediately, and then check
B1_EXC, or B2_EXC alarm is whether the AU_AIS alarm is cleared. If the
reported AU_AIS alarm persists, go to Step Step 2.
Step 2 Cause 2: The upstream NE inserts the AIS alarm to the downstream NE.
1. Check whether any higher level alarm occurs on the upstream NE according to the VC-4
service signal flow. As shown in Figure 7-4, if NEn reports the AU_AIS alarm, check
whether any higher level alarm occurs on the upstream NEs (NEn-1, ... NE2).
If... Then...
Any of the alarms listed in Table Clear the alarm immediately, and then check
7-4 occurs whether the AU_AIS alarm is cleared. If the
AU_AIS alarm persists, go to Step Step 3.
If... Then...
Step 3 Use the loopback method to locate the NE that first reports the AU_AIS alarm according to
the VC-4 service signal flow. For the loopback capabilities of the boards, see Loopback
Capability of the Boards in the Hardware Description.
NOTICE
A loopback causes service interruptions.
NE1 NE5
(Source end of the VC4) (Sink end of the VC4)
West East West NE2 East West NE3 East West NE4 East West
AU_AIS
1. As shown in Figure 7-5, if the local NE (NE5) reports the AU_AIS alarm, perform an
inloop for the relevant VC-4 path or optical interface on the transmit board (east line
board) of the opposite NE (NE4). For details on how to loop back a board, see the
Supporting Tasks.
Setting a Loopback on an SDH Optical Interface Board
Setting a Loopback on a PDH Electrical Interface Board
Setting a Loopback on an Ethernet Port
Setting a Loopback on an ATM Board Port
Setting Loopback on the IF Board
2. Check whether the AU_AIS alarm is reported by the opposite NE after the loopback is
performed.
If... Then...
The AU_AIS alarm is The alarm reported by the local NE is inserted by the
reported by the upstream NEs, such as NE1, NE2, and NE3. Release the
opposite NE inloop, and go to the next step.
If... Then...
The AU_AIS alarm is The fault is located on the receive board of the local NE (for
not reported by the example, the west line board on NE5) or the transmit board
opposite NE of the opposite NE (for example, the east line board on
NE4). Release the inloop, and go to Step Step 3.4.
3. According to the VC-4 service signal flow, perform an inloop for the relevant VC-4 path
on the east line board of the upstream NE. Then, check whether the upstream NE reports
the AU_AIS alarm.
If... Then...
The upstream NE The upstream NE and all the other upstream NEs may be
reports the AU_AIS faulty.
alarm
Release the inloop and repeat the loopback method to locate
the NE that first reports the AU_AIS alarm. Go to Step Step 4.
The upstream NE The AU_AIS alarm is first reported by the lower level NE of
does not report the the upstream NE.
AU_AIS alarm
If NE2 does not report the AU_AIS alarm after the inloop is
performed, NE3 first reports the AU_AIS alarm.
Release the inloop, and go to Step Step 4.
4. Perform a hardware inloop for the optical interface on the transmit board of the opposite
NE. For details, see Hardware Loopback in the Supporting Tasks. Check whether the
AU_AIS alarm is reported by the opposite NE after the loopback is performed.
NOTICE
A loopback causes service interruptions. In the case of a hardware inloop, the optical
power should not exceed the threshold. Add an optical attenuator to the optical interface
according to the optical power specifications of the board.
If... Then...
The AU_AIS alarm is The east line board of the opposite NE is faulty. The
reported by the opposite NE board first reports the AU_AIS alarm.
Release the inloop, and go to Step Step 5.
The AU_AIS alarm is not The west line board of the local NE is faulty.
reported by the opposite NE
Release the inloop, and go to Step Step 6.
Step 4 Locate the board that first reports the AU_AIS alarm.
If... Then...
The NE that first reports the AU_AIS alarm is the The west line board, east line
source of SDH services. As shown in Figure 7-5, NE1 board, and cross-connect board of
is the source of SDH services the NE may be faulty. Go to Step
Step 5.
The NE that first reports the AU_AIS alarm is the The west line board of the NE is
sink of SDH services. As shown in Figure 7-5, NE5 is faulty. Go to Step Step 6.
the source of SDH services
The NE that first reports the AU_AIS alarm is not Go to the next step.
the source or sink of SDH services, for example,
NE2, NE3, or NE4
1. Perform an outloop for the west line board of the NE. Then, check whether the AU_AIS
alarm occurs on the NE.
If... Then...
The AU_AIS alarm occurs The west line board of the NE is faulty.
on the NE
Release the outloop, and go to Step Step 5.
The AU_AIS alarm does The east line board or cross-connect unit of the NE is
not occur on the NE faulty.
Release the outloop, and go to Step Step 5.
Step 5 Cause 3: The transmit boards (including the cross-connect and timing board) on the upstream
NE are faulty.
1. Replace the transmit board that first reports the AU_AIS alarm on the NE. For details,
see Replacing Boards Onsite in the Supporting Tasks.
2. Check whether the alarm is cleared. If the alarm persists, replace the cross-connect and
timing board of the NE. For details, see Replacing a CXL Board in the Parts
Replacement.
3. Check whether the alarm is cleared. If the alarm persists, contact Huawei technical
support engineers to handle the alarm.
Step 6 Cause 4: The receive boards on the local NE are faulty.
1. Replace the receive board that reports the alarm on the local NE. For details, see
Replacing Boards Onsite in the Supporting Tasks.
2. Check whether the alarm is cleared. If the alarm persists, contact Huawei technical
support engineers to handle the alarm.
----End
Related Information
7.6 AU_LOP
Description
The AU_LOP is an alarm indicating the loss of the AU pointer. This alarm occurs when the
optical interface of the local NE receives the AU pointers with NDF or of invalid values for
eight consecutive frames.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 2, Indicates the ID of the AU-4 path. Parameter 2 indicates the most
Parameter 3 significant byte (MSB) and Parameter 3 indicates the least significant
byte (LSB).
For example, Parameter 1 = 0x01, Parameter 2 = 0x00, and Parameter 3
= 0x01. The parameters indicate that the AU_LOP alarm is reported by
optical interface 1 in path 1 of the relevant board.
Name Meaning
Parameter 4 Indicates that an STM-4 line board or a line board at a higher rate detects
an AU_CMM alarm when its value is 0x02. This parameter is
meaningless when its value is not 0x02.
If this section does not describe the common fault symptom or the actual fault symptom is not contained
in the description of this section, handle the AU_LOP alarm by following the steps provided in Handling
Procedure.
Table 7-5 provides the details about the common fault symptom when the AU_LOP alarm
occurs.
The NE reports the AU_LOP alarm and the Cause 1: The local NE receives too many
multiplex section (MS) or regenerator section errors.
(RS) alarms, such as B1_EXC, B1_SD,
B2_EXC, and B2_SD.
Possible Causes
The possible causes of the AU_LOP alarm are as follows:
l Cause 1: The local NE receives too many errors.
l Cause 2: The concatenation level of the service transmitted at the opposite end is
different from the concatenation level of the service to be received at the local end.
l Cause 3: The transmit boards (including the cross-connect and timing board) on the local
NE are faulty.
l Cause 4: The transmit boards (including the cross-connect and timing board) on the
opposite NE are faulty.
Procedure
Step 1 Cause 1: The local NE receives too many errors.
1. Check whether the following error alarms are reported by the local NE:
B1_EXC
B1_SD
B2_EXC
B2_SD
2. If yes, clear these alarms before you proceed. Then check whether the AU_LOP alarm is
cleared. If the AU_LOP alarm persists or no error alarms are reported, go to Step Step 2.
Step 2 Cause 2: The concatenation level of the service transmitted at the opposite end is different
from the concatenation level of the service to be received at the local end.
1. Check whether the concatenation level of the service transmitted by the opposite NE is
consistent with the concatenation level of the receivable service at the local NE.
If... Then...
The service levels are Reconfigure the service levels at both ends. Check
inconsistent whether the alarm is cleared. If the alarm persists, go
to Step Step 3.
Step 3 Cause 3: The transmit boards (including the cross-connect and timing board) on the local NE
are faulty.
1. Perform loopbacks to locate the faulty board. For details, see the handling method of the
TU_AIS alarm.
2. If the receive board at the local end is faulty, perform a cold reset on the board by using
the NMS or reseat the board. For details on how to perform a cold reset on the board, see
Resetting Boards in the Supporting Tasks. For details on how to reseat the board, see
Removing the Boards in the Installation Reference and Installing the Boards in the
Installation Reference.
NOTICE
If the service on the board is not protected, a cold reset on the board causes service
interruptions.
3. Check whether the alarm is cleared. If the alarm persists, replace the receive board at the
local NE. For details, see Replacing Boards Onsite in the Supporting Tasks.
4. Check whether the alarm is cleared. If the alarm persists, perform a cold reset by using
the NMS or reinstall the cross-connect and timing board. For the operations on the NMS,
see Resetting Boards in the Supporting Tasks. For details on how to reseat the board, see
Removing the Boards in the Installation Reference and Installing the Boards in the
Installation Reference.
NOTICE
If there is no protection cross-connect board, performing a cold reset on the cross-
connect and timing board may cause service interruptions.
5. Check whether the alarm is cleared. If the alarm persists, replace the cross-connect and
timing board on the local NE. For details, see Replacing a CXL Board in the Parts
Replacement.
6. Check whether the alarm is cleared. If the alarm persists, go to Step Step 4.
Step 4 Cause 4: The transmit boards (including the cross-connect and timing board) on the opposite
NE are faulty.
1. Perform loopbacks to locate the faulty board. For details, see the handling method of the
TU_AIS alarm.
2. If the transmit board at the opposite end is faulty, perform a cold reset on the board by
using the NMS or reseat the board. For details on how to perform a cold reset on the
board, see Resetting Boards in the Supporting Tasks. For details on how to reseat the
board, see Removing the Boards in the Installation Reference and Installing the Boards
in the Installation Reference.
NOTICE
If the service on the board is not protected, a cold reset on the board causes service
interruptions.
3. Check whether the alarm is cleared. If the alarm persists, replace the transmit board on
the opposite NE. For details, see Replacing Boards Onsite in the Supporting Tasks.
4. Check whether the alarm is cleared. If the alarm persists, perform a cold reset by using
the NMS or reseat the cross-connect and timing board on the opposite NE. For the
operations on the NMS, see Resetting Boards in the Supporting Tasks. For details on
how to reseat the board, see Removing the Boards in the Installation Reference and
Installing the Boards in the Installation Reference.
NOTICE
If there is no protection cross-connect board, performing a cold reset on the cross-
connect and timing board may cause service interruptions.
5. Check whether the alarm is cleared. If the alarm persists, replace the cross-connect and
timing board on the opposite NE. For details, see Replacing a CXL Board in the Parts
Replacement.
6. Check whether the alarm is cleared. If not, contact Huawei technical support engineers to
handle the alarm.
----End
Related Information
The concatenation service levels include AU-3, VC-4, VC4-4c, VC4-8c, VC4-16c and
VC4-64c.
NOTE
If the alarm is reported by an NE on the existing network, inform Huawei technical support engineers of
the alarm even if the alarm is cleared by using the previous methods.
7.7 B1_SD
Description
The B1_SD is an alarm indicating that the received signal degrades due to the excessive B1
errors (in the regenerator section). This alarm occurs when the board detects that the B1 errors
exceed the preset B1_SD alarm threshold (10-6 by default) but do not reach the preset
B1_EXC alarm threshold (10-3 by default).
NOTE
The alarm may be reported by the IF that works in PDH mode. This alarm is detected by using the self-
defined overhead byte B1 in PDH microwave frames.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1 Indicates the ID of the port on the board. For example, 0x01 indicates
that the alarm is reported by port 1 of the related board.
Parameter 2, Indicate the path ID. For example, in the case of Parameter 2 = 0x00
Parameter 3 and Parameter 3 = 0x01, the alarm is reported by path 1 of the board.
If this section does not describe the common fault symptom or the actual fault symptom is not contained
in the description of this section, handle the B1_EXC alarm by following the steps provided in Handling
Procedure.
Table 7-6 lists the common faulty symptoms of the alarms related to B1, B2, and B3 errors.
Table 7-6 Symptoms of the alarms related to B1, B2, and B3 errors
Common Fault Symptom Possible Cause
Multiple NEs reports error alarms. In a period of Cause 2: The external environment
time, the NEs also report the alarms related to is abnormal.
temperature or fan failure, such as TEMP_OVER
and FAN_FAIL.
1. In a period of time, the NEs that report error Cause 7: The clock configuration is
alarms and the downstream NEs report a large incorrect or the performance of the
number of performance events or alarms related cross-connect and timing unit
to pointer justifications, such as AUPJCHIGH deteriorates.
and SYN_BAD.
2. The boards on the local NE and the boards on
the opposite NE report B1 and B2 errors.
3. Multiple VC-4 paths on multiple boards report
the higher order error alarms.
The error alarms are reported by certain VC-4 paths The board is faulty.
on certain boards.
Possible Causes
The possible causes of the B1_SD alarm are as follows:
l Cause 1: The error threshold is set incorrectly.
l Cause 2: The external environment is abnormal.
l Cause 3: The line performance deteriorates.
l Cause 4: The grounding is improper.
l Cause 5: The receive board on the local NE is faulty.
l Cause 6: The transmit board on the opposite NE is faulty.
l Cause 7: The clock configuration is incorrect or the performance of the cross-connect
and timing unit deteriorates.
Procedure
Step 1 Cause 1: The error threshold is set incorrectly.
1. Query the error threshold set on the board that reports the alarm. Increase the error
threshold according to the actual situation. For details, see Setting the Threshold for the
Bit Error Alarm in the Supporting Tasks.
2. Check whether the alarm is cleared. If the alarm persists, go to Step Step 2.
Step 2 Cause 2: The external environment is abnormal.
1. Check the temperature in the telecommunications room, the air filter, and the fans. For
details, see the handling procedures of TEMP_OVER.
2. Check whether the alarm is cleared. If the alarm persists, check whether there is any
electromagnetic interference. For example, the electromagnetic interference may be
caused by electronic devices, unstable power supply, lightening, and high voltage
transmission lines. If any, take proper anti-interference measures and then check whether
the alarm is cleared.
3. If the alarm persists, handle the alarm according to the type of the board that reports the
alarm.
If... Then...
Step 3 Cause 3: The line performance deteriorates. (SDH optical interface board)
1. On the NMS, check whether the transmit optical power of the opposite NE is within the
normal range. For details on the optical power of the board, see Specifications of the
Boards in the Technical Specifications Reference. For the operations on the NMS, see
Querying the Optical Power in the Supporting Tasks.
NOTE
You can obtain the manufacturer information about the optical module by referring to Querying
the Board Manufacturer Information Report in the Supporting Tasks or Bar Code in the Hardware
Description.
If... Then...
2. On the NMS, check whether the transmit optical power of the local NE is within the
normal range.
If... Then...
The transmit optical power is beyond the normal range Go to Step Step 7.
The transmit optical power is within the normal range Go to the next step.
3. On the NMS, check whether the receive optical power of the local NE is within the
normal range.
If... Then...
The receive optical power is beyond the Check the fiber connector and optical
normal range fiber as follows
If... Then...
The fiber connector is loose Properly connect the fiber connector. Check whether
the alarm is cleared. If the alarm persists, go to the
next step.
5. Check whether the fiber connector is damaged. For details, see Checking the Optical
Fiber Connector in the Supporting Tasks.
If... Then...
The fiber Clean the optical connector immediately. For details, see the
connector is dirty Supporting Tasks.
Using the Fiber Cleaner to Clean the Optical Fiber Connector
Using the Lens Tissue to Clean the Optical Fiber Connector
Using the Dust-Free Cotton Bar to Clean the Optical Fiber
Adapter
Check whether the alarm is cleared. If the alarm persists, go to
the next step.
6. Check whether the bend radius of the fiber jumper is within the normal range and
whether the optical fiber is pressed or damaged, or peels off. If the bend radius is less
than 6 cm, roll the fiber jumper again. If the fiber is faulty, replace the fiber. Check
whether the alarm is cleared.
7. If the alarm persists, check whether the optical interface board matches the type of the
optical fiber. If yes, the over low sensitivity, over high dispersion, or distortion may
cause errors.
If... Then...
The optical interface board does not match Replace the fiber or line board as
the type of the optical fiber required. Check whether the alarm is
cleared.
If... Then...
The errors vary with the change of the cable Go to the next step.
The errors do not vary with the change of the cable Go to Step Step 6.
2. Check whether the cable is grounded properly and whether the cable connector and cable
are damaged. If the cable is faulty, replace the cable. Check whether the alarm is cleared.
If not, go to Step Step 6.
Step 9 Cause 7: The clock configuration is incorrect or the performance of the cross-connect and
timing unit deteriorates.
1. The clock sources of the local NE and opposite NE are asynchronous or interlocked,
causing errors and even service interruptions. If the NEs also report the performance
events or alarms related to pointer justifications, such as AUPJCHIGH, TUPJCHIGH,
and SYN_BAD, rectify the fault caused by clock configuration accordingly.
2. Check whether the alarm is cleared. If the alarm persists, replace the cross-connect and
timing board on the local NE. For details, see Replacing a CXL Board in the Parts
Replacement.
3. Check whether the alarm is cleared. If the alarm persists, replace the cross-connect and
timing board on the opposite NE. For details, see Replacing a CXL Board in the Parts
Replacement.
4. Check whether the alarm is cleared. If the alarm persists, contact Huawei technical
support engineers to handle the alarm.
----End
Related Information
None.
7.8 B2_SD
Description
The B2_SD is an alarm indicating that the received signal degrades due to the excessive B2
errors (in the multiplex section). This alarm occurs when the board detects that the B2 errors
exceed the preset B2_SD alarm threshold (10-6 by default) but do not reach the preset
B2_EXC alarm threshold (10-3 by default).
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1 Indicates the ID of the port on the board. For example, 0x01 indicates
that the alarm is reported by port 1 of the related board.
Parameter 2, Indicate the path ID. For example, in the case of Parameter 2 = 0x00
Parameter 3 and Parameter 3 = 0x01, the alarm is reported by path 1 of the board.
If this section does not describe the common fault symptom or the actual fault symptom is not contained
in the description of this section, handle the B1_EXC alarm by following the steps provided in Handling
Procedure.
Table 7-7 lists the common faulty symptoms of the alarms related to B1, B2, and B3 errors.
Table 7-7 Symptoms of the alarms related to B1, B2, and B3 errors
Common Fault Symptom Possible Cause
Multiple NEs reports error alarms. In a period of Cause 2: The external environment
time, the NEs also report the alarms related to is abnormal.
temperature or fan failure, such as TEMP_OVER
and FAN_FAIL.
1. In a period of time, the NEs that report error Cause 7: The clock configuration is
alarms and the downstream NEs report a large incorrect or the performance of the
number of performance events or alarms related cross-connect and timing unit
to pointer justifications, such as AUPJCHIGH deteriorates.
and SYN_BAD.
2. The boards on the local NE and the boards on
the opposite NE report B1 and B2 errors.
3. Multiple VC-4 paths on multiple boards report
the higher order error alarms.
The error alarms are reported by certain VC-4 paths The board is faulty.
on certain boards.
Possible Causes
The possible causes of the B2_SD alarm are as follows:
l Cause 1: The error threshold is set incorrectly.
l Cause 2: The external environment is abnormal.
l Cause 3: The line performance deteriorates.
l Cause 4: The grounding is improper.
l Cause 5: The receive board on the local NE is faulty.
l Cause 6: The transmit board on the opposite NE is faulty.
l Cause 7: The clock configuration is incorrect or the performance of the cross-connect
and timing unit deteriorates.
Procedure
Step 1 Cause 1: The error threshold is set incorrectly.
1. Query the error threshold set on the board that reports the alarm. Increase the error
threshold according to the actual situation. For details, see Setting the Threshold for the
Bit Error Alarm in the Supporting Tasks.
2. Check whether the alarm is cleared. If the alarm persists, go to Step Step 2.
Step 2 Cause 2: The external environment is abnormal.
1. Check the temperature in the telecommunications room, the air filter, and the fans. For
details, see the handling procedures of TEMP_OVER.
2. Check whether the alarm is cleared. If the alarm persists, check whether there is any
electromagnetic interference. For example, the electromagnetic interference may be
caused by electronic devices, unstable power supply, lightening, and high voltage
transmission lines. If any, take proper anti-interference measures and then check whether
the alarm is cleared.
3. If the alarm persists, handle the alarm according to the type of the board that reports the
alarm.
If... Then...
Step 3 Cause 3: The line performance deteriorates. (SDH optical interface board)
1. On the NMS, check whether the transmit optical power of the opposite NE is within the
normal range. For details on the optical power of the board, see Specifications of the
Boards in the Technical Specifications Reference. For the operations on the NMS, see
Querying the Optical Power in the Supporting Tasks.
NOTE
You can obtain the manufacturer information about the optical module by referring to Querying
the Board Manufacturer Information Report in the Supporting Tasks or Bar Code in the Hardware
Description.
If... Then...
2. On the NMS, check whether the transmit optical power of the local NE is within the
normal range.
If... Then...
The transmit optical power is beyond the normal range Go to Step Step 7.
The transmit optical power is within the normal range Go to the next step.
3. On the NMS, check whether the receive optical power of the local NE is within the
normal range.
If... Then...
The receive optical power is beyond the Check the fiber connector and optical
normal range fiber as follows
If... Then...
The fiber connector is loose Properly connect the fiber connector. Check whether
the alarm is cleared. If the alarm persists, go to the
next step.
5. Check whether the fiber connector is damaged. For details, see Checking the Optical
Fiber Connector in the Supporting Tasks.
If... Then...
The fiber Clean the optical connector immediately. For details, see the
connector is dirty Supporting Tasks.
Using the Fiber Cleaner to Clean the Optical Fiber Connector
Using the Lens Tissue to Clean the Optical Fiber Connector
Using the Dust-Free Cotton Bar to Clean the Optical Fiber
Adapter
Check whether the alarm is cleared. If the alarm persists, go to
the next step.
6. Check whether the bend radius of the fiber jumper is within the normal range and
whether the optical fiber is pressed or damaged, or peels off. If the bend radius is less
than 6 cm, roll the fiber jumper again. If the fiber is faulty, replace the fiber. Check
whether the alarm is cleared.
7. If the alarm persists, check whether the optical interface board matches the type of the
optical fiber. If yes, the over low sensitivity, over high dispersion, or distortion may
cause errors.
If... Then...
The optical interface board does not match Replace the fiber or line board as
the type of the optical fiber required. Check whether the alarm is
cleared.
If... Then...
Step 4 Cause 3: The line performance deteriorates. (SDH electrical interface board)
1. Exchange the cables that are possibly faulty in the receive and transmit directions to
locate the fault.
If... Then...
The errors vary with the change of the cable Go to the next step.
The errors do not vary with the change of the cable Go to Step Step 6.
2. Check whether the cable is grounded properly and whether the cable connector and cable
are damaged. If the cable is faulty, replace the cable. Check whether the alarm is cleared.
If not, go to Step Step 6.
Step 9 Cause 7: The clock configuration is incorrect or the performance of the cross-connect and
timing unit deteriorates.
1. The clock sources of the local NE and opposite NE are asynchronous or interlocked,
causing errors and even service interruptions. If the NEs also report the performance
events or alarms related to pointer justifications, such as AUPJCHIGH, TUPJCHIGH,
and SYN_BAD, rectify the fault caused by clock configuration accordingly.
2. Check whether the alarm is cleared. If the alarm persists, replace the cross-connect and
timing board on the local NE. For details, see Replacing a CXL Board in the Parts
Replacement.
3. Check whether the alarm is cleared. If the alarm persists, replace the cross-connect and
timing board on the opposite NE. For details, see Replacing a CXL Board in the Parts
Replacement.
4. Check whether the alarm is cleared. If the alarm persists, contact Huawei technical
support engineers to handle the alarm.
----End
Related Information
None.
7.9 B3_SD
Description
The B3_SD is an alarm indicating that the receive signal degrades due to the excessive B3
errors (in the higher order path). This alarm occurs when the board detects that the B3 errors
exceed the preset B3_SD alarm threshold (10-6 by default) but do not reach the preset
B3_EXC alarm threshold (10-3 by default).
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1 Indicates the ID of the port on the board. For example, 0x01 indicates
that the alarm is reported by port 1 of the related board.
Name Meaning
If this section does not describe the common fault symptom or the actual fault symptom is not contained
in the description of this section, handle the B1_EXC alarm by following the steps provided in Handling
Procedure.
Table 7-8 lists the common faulty symptoms of the alarms related to B1, B2, and B3 errors.
Table 7-8 Symptoms of the alarms related to B1, B2, and B3 errors
Multiple NEs reports error alarms. In a period of Cause 2: The external environment
time, the NEs also report the alarms related to is abnormal.
temperature or fan failure, such as TEMP_OVER
and FAN_FAIL.
1. In a period of time, the NEs that report error Cause 7: The clock configuration is
alarms and the downstream NEs report a large incorrect or the performance of the
number of performance events or alarms related cross-connect and timing unit
to pointer justifications, such as AUPJCHIGH deteriorates.
and SYN_BAD.
2. The boards on the local NE and the boards on
the opposite NE report B1 and B2 errors.
3. Multiple VC-4 paths on multiple boards report
the higher order error alarms.
The error alarms are reported by certain VC-4 paths The board is faulty.
on certain boards.
Possible Causes
The possible causes of the B3_SD alarm are as follows:
Procedure
Step 1 Cause 1: The error threshold is set incorrectly.
1. Query the error threshold set on the board that reports the alarm. Increase the error
threshold according to the actual situation. For details, see Setting the Threshold for the
Bit Error Alarm in the Supporting Tasks.
2. Check whether the alarm is cleared. If the alarm persists, go to Step Step 2.
If... Then...
Step 3 Cause 3: The line performance deteriorates. (SDH optical interface board)
1. On the NMS, check whether the transmit optical power of the opposite NE is within the
normal range. For details on the optical power of the board, see Specifications of the
Boards in the Technical Specifications Reference. For the operations on the NMS, see
Querying the Optical Power in the Supporting Tasks.
NOTE
You can obtain the manufacturer information about the optical module by referring to Querying
the Board Manufacturer Information Report in the Supporting Tasks or Bar Code in the Hardware
Description.
If... Then...
2. On the NMS, check whether the transmit optical power of the local NE is within the
normal range.
If... Then...
The transmit optical power is beyond the normal range Go to Step Step 7.
The transmit optical power is within the normal range Go to the next step.
3. On the NMS, check whether the receive optical power of the local NE is within the
normal range.
If... Then...
The receive optical power is beyond the Check the fiber connector and optical
normal range fiber as follows
If... Then...
The fiber connector is loose Properly connect the fiber connector. Check whether
the alarm is cleared. If the alarm persists, go to the
next step.
5. Check whether the fiber connector is damaged. For details, see Checking the Optical
Fiber Connector in the Supporting Tasks.
If... Then...
The fiber Clean the optical connector immediately. For details, see the
connector is dirty Supporting Tasks.
Using the Fiber Cleaner to Clean the Optical Fiber Connector
Using the Lens Tissue to Clean the Optical Fiber Connector
Using the Dust-Free Cotton Bar to Clean the Optical Fiber
Adapter
Check whether the alarm is cleared. If the alarm persists, go to
the next step.
6. Check whether the bend radius of the fiber jumper is within the normal range and
whether the optical fiber is pressed or damaged, or peels off. If the bend radius is less
than 6 cm, roll the fiber jumper again. If the fiber is faulty, replace the fiber. Check
whether the alarm is cleared.
7. If the alarm persists, check whether the optical interface board matches the type of the
optical fiber. If yes, the over low sensitivity, over high dispersion, or distortion may
cause errors.
If... Then...
The optical interface board does not match Replace the fiber or line board as
the type of the optical fiber required. Check whether the alarm is
cleared.
Step 4 Cause 3: The line performance deteriorates. (SDH electrical interface board)
1. Exchange the cables that are possibly faulty in the receive and transmit directions to
locate the fault.
If... Then...
The errors vary with the change of the cable Go to the next step.
The errors do not vary with the change of the cable Go to Step Step 6.
2. Check whether the cable is grounded properly and whether the cable connector and cable
are damaged. If the cable is faulty, replace the cable. Check whether the alarm is cleared.
If not, go to Step Step 6.
Step 9 Cause 7: The clock configuration is incorrect or the performance of the cross-connect and
timing unit deteriorates.
1. The clock sources of the local NE and opposite NE are asynchronous or interlocked,
causing errors and even service interruptions. If the NEs also report the performance
events or alarms related to pointer justifications, such as AUPJCHIGH, TUPJCHIGH,
and SYN_BAD, rectify the fault caused by clock configuration accordingly.
2. Check whether the alarm is cleared. If the alarm persists, replace the cross-connect and
timing board on the local NE. For details, see Replacing a CXL Board in the Parts
Replacement.
3. Check whether the alarm is cleared. If the alarm persists, replace the cross-connect and
timing board on the opposite NE. For details, see Replacing a CXL Board in the Parts
Replacement.
4. Check whether the alarm is cleared. If the alarm persists, contact Huawei technical
support engineers to handle the alarm.
----End
Related Information
None.
7.10 B3_EXC
Description
The B3_EXC is an alarm indicating that the B3 errors in the signals received by the line
crosses the threshold. This alarm occurs when the line board detects that the error rate of the
higher order path (B3 errors) exceeds the threshold preset for the B3_EXC alarm (103 by
default).
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1 Indicates the ID of the port on the board. For example, 0x01 indicates
that the alarm is reported by port 1 of the related board.
If this section does not describe the common fault symptom or the actual fault symptom is not contained
in the description of this section, handle the B1_EXC alarm by following the steps provided in Handling
Procedure.
Table 7-9 lists the common faulty symptoms of the alarms related to B1, B2, and B3 errors.
Table 7-9 Symptoms of the alarms related to B1, B2, and B3 errors
Common Fault Symptom Possible Cause
Multiple NEs reports error alarms. In a period of Cause 2: The external environment
time, the NEs also report the alarms related to is abnormal.
temperature or fan failure, such as TEMP_OVER
and FAN_FAIL.
1. In a period of time, the NEs that report error Cause 7: The clock configuration is
alarms and the downstream NEs report a large incorrect or the performance of the
number of performance events or alarms related cross-connect and timing unit
to pointer justifications, such as AUPJCHIGH deteriorates.
and SYN_BAD.
2. The boards on the local NE and the boards on
the opposite NE report B1 and B2 errors.
3. Multiple VC-4 paths on multiple boards report
the higher order error alarms.
The error alarms are reported by certain VC-4 paths The board is faulty.
on certain boards.
Possible Causes
The possible causes of the B3_EXC alarm are as follows:
l Cause 1: The error threshold is set incorrectly.
l Cause 2: The external environment is abnormal.
l Cause 3: The line performance deteriorates.
l Cause 4: The grounding is improper.
l Cause 5: The receive board on the local NE is faulty.
l Cause 6: The transmit board on the opposite NE is faulty.
l Cause 7: The clock configuration is incorrect or the performance of the cross-connect
and timing unit deteriorates.
Procedure
Step 1 Cause 1: The error threshold is set incorrectly.
1. Query the error threshold set on the board that reports the alarm. Increase the error
threshold according to the actual situation. For details, see Setting the Threshold for the
Bit Error Alarm in the Supporting Tasks.
2. Check whether the alarm is cleared. If the alarm persists, go to Step Step 2.
Step 2 Cause 2: The external environment is abnormal.
1. Check the temperature in the telecommunications room, the air filter, and the fans. For
details, see the handling procedures of TEMP_OVER.
2. Check whether the alarm is cleared. If the alarm persists, check whether there is any
electromagnetic interference. For example, the electromagnetic interference may be
caused by electronic devices, unstable power supply, lightening, and high voltage
transmission lines. If any, take proper anti-interference measures and then check whether
the alarm is cleared.
3. If the alarm persists, handle the alarm according to the type of the board that reports the
alarm.
If... Then...
Step 3 Cause 3: The line performance deteriorates. (SDH optical interface board)
1. On the NMS, check whether the transmit optical power of the opposite NE is within the
normal range. For details on the optical power of the board, see Specifications of the
Boards in the Technical Specifications Reference. For the operations on the NMS, see
Querying the Optical Power in the Supporting Tasks.
NOTE
You can obtain the manufacturer information about the optical module by referring to Querying
the Board Manufacturer Information Report in the Supporting Tasks or Bar Code in the Hardware
Description.
If... Then...
2. On the NMS, check whether the transmit optical power of the local NE is within the
normal range.
If... Then...
The transmit optical power is beyond the normal range Go to Step Step 7.
The transmit optical power is within the normal range Go to the next step.
3. On the NMS, check whether the receive optical power of the local NE is within the
normal range.
If... Then...
The receive optical power is beyond the Check the fiber connector and optical
normal range fiber as follows
If... Then...
The fiber connector is loose Properly connect the fiber connector. Check whether
the alarm is cleared. If the alarm persists, go to the
next step.
5. Check whether the fiber connector is damaged. For details, see Checking the Optical
Fiber Connector in the Supporting Tasks.
If... Then...
The fiber Clean the optical connector immediately. For details, see the
connector is dirty Supporting Tasks.
Using the Fiber Cleaner to Clean the Optical Fiber Connector
Using the Lens Tissue to Clean the Optical Fiber Connector
Using the Dust-Free Cotton Bar to Clean the Optical Fiber
Adapter
Check whether the alarm is cleared. If the alarm persists, go to
the next step.
6. Check whether the bend radius of the fiber jumper is within the normal range and
whether the optical fiber is pressed or damaged, or peels off. If the bend radius is less
than 6 cm, roll the fiber jumper again. If the fiber is faulty, replace the fiber. Check
whether the alarm is cleared.
7. If the alarm persists, check whether the optical interface board matches the type of the
optical fiber. If yes, the over low sensitivity, over high dispersion, or distortion may
cause errors.
If... Then...
The optical interface board does not match Replace the fiber or line board as
the type of the optical fiber required. Check whether the alarm is
cleared.
If... Then...
The errors vary with the change of the cable Go to the next step.
The errors do not vary with the change of the cable Go to Step Step 6.
2. Check whether the cable is grounded properly and whether the cable connector and cable
are damaged. If the cable is faulty, replace the cable. Check whether the alarm is cleared.
If not, go to Step Step 6.
Step 9 Cause 7: The clock configuration is incorrect or the performance of the cross-connect and
timing unit deteriorates.
1. The clock sources of the local NE and opposite NE are asynchronous or interlocked,
causing errors and even service interruptions. If the NEs also report the performance
events or alarms related to pointer justifications, such as AUPJCHIGH, TUPJCHIGH,
and SYN_BAD, rectify the fault caused by clock configuration accordingly.
2. Check whether the alarm is cleared. If the alarm persists, replace the cross-connect and
timing board on the local NE. For details, see Replacing a CXL Board in the Parts
Replacement.
3. Check whether the alarm is cleared. If the alarm persists, replace the cross-connect and
timing board on the opposite NE. For details, see Replacing a CXL Board in the Parts
Replacement.
4. Check whether the alarm is cleared. If the alarm persists, contact Huawei technical
support engineers to handle the alarm.
----End
Related Information
None.
7.11 BIP_SD
Description
The BIP_SD is an alarm indicating that the signal degrades due to the excessive BIP errors.
This alarm is reported when the board detects that the BIP-2 errors (in byte V5) exceed the
BIP_SD alarm threshold (10-6 by default) but does not reach the BIP_EXC alarm threshold
(10-3 by default).
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1 In the case of the line board, indicates the ID of the optical interface on the
board.
l 0x40: The N2PQ1 board works in MUX/SERVER mode (E13/M13
Function).
l 0x21: The R2PD1 board works in MUX/SERVER mode (E13/M13
Function).
l 0x0d: The N2PQ3 board works in DEMUX/SERVER mode (E13/M13
Function).
l 0x07: The N2PD3 board works in DEMUX/SERVER mode (E13/M13
Function).
l 0x04: The N2PL3 or N2PL3A board works in DEMUX/SERVER mode
(E13/M13 Function).
For other tributary boards, the value is always 0x01.
For the Ethernet boards, the value is always 0x01.
If this section does not describe the common fault symptom or the actual fault symptom is not contained
in the description of this section, handle the BIP_EXC alarm by following the steps provided in
Handling Procedure.
Table 7-10 lists the common fault symptoms of the BIP_EXC alarm.
The board reports the BIP_EXC and higher Cause 1: The higher level error alarms
level alarms including the alarms related to B1, are reported by the system.
B2, and B3 errors.
l In a period of time, the NEs that report Cause 4: The performance of the cross-
error alarms and the downstream NEs connect unit degrades.
report a large number of performance
events or alarms related to pointer
justifications, such as TUPJCHIGH and
SYN_BAD.
l The tributary board on the local NE and the
tributary board of the downstream NE
report the path errors.
l Certain VC-12 paths on the local NE report
the lower path errors.
The error alarms are reported by certain VC-12 The board is faulty.
paths on certain boards.
Possible Causes
The possible causes of the BIP_SD alarm are as follows:
l Cause 1: The higher level error alarms are reported by the system.
l Cause 2: The receive board on the local NE is faulty.
l Cause 3: The transmit board on the opposite NE is faulty.
l Cause 4: The performance of the cross-connect unit degrades.
Procedure
Step 1 Cause 1: The higher level error alarms are reported by the system.
1. On the NMS, check whether any higher level error alarm occurs on the local NE. If the
alarm occurs, clear the alarm first.
B1_EXC
B1_SD
B2_EXC
B2_SD
B3_EXC
B3_SD
2. Check whether the alarm is cleared. If the alarm persists, go to Step Step 2.
Step 2 Cause 2: The receive board on the local NE is faulty.
1. On the NMS, check whether the transmit optical power of the opposite NE is within the
normal range. For details on the optical power of the board, see Specifications of the
Boards in the Technical Specifications Reference. For the operations on the NMS, see
Querying the Optical Power in the Supporting Tasks.
NOTE
You can obtain the manufacturer information about the optical module by referring to Querying
the Board Manufacturer Information Report in the Supporting Tasks or Bar Code in the Hardware
Description.
If... Then...
The transmit optical power on the opposite NE is normal Go to the next step.
2. On the NMS, check whether the transmit optical power of the local NE is within the
normal range.
If... Then...
The transmit optical power of is beyond the normal range Go to the next step.
The transmit optical power of is within the normal range Go to Step Step 3.
3. Perform a cold reset by using the NMS, or directly reseat the transmit board of the local
NE. For details on how to perform the cold reset, see Resetting Boards in the Supporting
Tasks. For details on how to reseat the board, see Removing the Boards in the
Installation Reference and Installing the Boards in the Installation Reference.
NOTICE
If the service on the board is not protected, a cold reset on the board causes service
interruptions.
4. Check whether the alarm is cleared. If the alarm persists, replace the optical module or
board. If the board supports the pluggable optical module, replace the pluggable optical
module. For details, see Replacing a Pluggable Optical Module in the Parts
Replacement. Otherwise, replace the faulty board. For details, see Replacing Boards
Onsite in the Supporting Tasks.
5. Check whether the alarm is cleared. If the alarm persists, go to Step Step 3.
Step 3 Cause 3: The transmit board on the opposite NE is faulty.
1. Perform a cold reset by using the NMS, or directly reseat the transmit board of the
opposite NE. For the operations on the NMS, see Resetting Boards in the Supporting
Tasks. For details on how to reseat the board, see Removing the Boards in the
Installation Reference and Installing the Boards in the Installation Reference.
NOTICE
If the service on the board is not protected, a cold reset on the board causes service
interruptions.
2. Check whether the alarm is cleared. If the alarm persists, replace the optical module or
board. If the board supports the pluggable optical module, replace the pluggable optical
module. For details, see Replacing a Pluggable Optical Module in the Parts
Replacement. Otherwise, replace the faulty board. For details, see Replacing Boards
Onsite in the Supporting Tasks.
3. Check whether the alarm is cleared. If the alarm persists, go to Step Step 4.
----End
Related Information
None.
7.12 B1_EXC
Description
The B1_EXC is an alarm indicating that the B1 errors in the signals received by the line
crosses the threshold. This alarm occurs when the line board detects that the error rate of the
regenerator section (B1 errors) exceeds the threshold preset for the B1_EXC alarm (103 by
default).
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1 Indicates the actual number of the optical interface on the board of the
local NE. For example, 0x01 indicates that the alarm is reported by
port 1 of the related board.
Parameter 2, Indicate the path ID. For example, Parameter 2 = 0x00 and Parameter 3
Parameter 3 = 0x01. The parameters indicate that the alarm is reported by path 1 of
the board.
If this section does not describe the common fault symptom or the actual fault symptom is not contained
in the description of this section, handle the B1_EXC alarm by following the steps provided in Handling
Procedure.
Table 7-11 lists the common faulty symptoms of the alarms related to B1, B2, and B3 errors.
Table 7-11 Symptoms of the alarms related to B1, B2, and B3 errors
Common Fault Symptom Possible Cause
Multiple NEs reports error alarms. In a period of Cause 2: The external environment
time, the NEs also report the alarms related to is abnormal.
temperature or fan failure, such as TEMP_OVER
and FAN_FAIL.
1. In a period of time, the NEs that report error Cause 7: The clock configuration is
alarms and the downstream NEs report a large incorrect or the performance of the
number of performance events or alarms related cross-connect and timing unit
to pointer justifications, such as AUPJCHIGH deteriorates.
and SYN_BAD.
2. The boards on the local NE and the boards on
the opposite NE report B1 and B2 errors.
3. Multiple VC-4 paths on multiple boards report
the higher order error alarms.
The error alarms are reported by certain VC-4 paths The board is faulty.
on certain boards.
Possible Causes
The possible causes of the B1_EXC alarm are as follows:
Procedure
Step 1 Cause 1: The error threshold is set incorrectly.
1. Query the error threshold set on the board that reports the alarm. Increase the error
threshold according to the actual situation. For details, see Setting the Threshold for the
Bit Error Alarm in the Supporting Tasks.
2. Check whether the alarm is cleared. If the alarm persists, go to Step Step 2.
If... Then...
Step 3 Cause 3: The line performance deteriorates. (SDH optical interface board)
1. On the NMS, check whether the transmit optical power of the opposite NE is within the
normal range. For details on the optical power of the board, see Specifications of the
Boards in the Technical Specifications Reference. For the operations on the NMS, see
Querying the Optical Power in the Supporting Tasks.
NOTE
You can obtain the manufacturer information about the optical module by referring to Querying
the Board Manufacturer Information Report in the Supporting Tasks or Bar Code in the Hardware
Description.
If... Then...
2. On the NMS, check whether the transmit optical power of the local NE is within the
normal range.
If... Then...
The transmit optical power is beyond the normal range Go to Step Step 7.
The transmit optical power is within the normal range Go to the next step.
3. On the NMS, check whether the receive optical power of the local NE is within the
normal range.
If... Then...
The receive optical power is beyond the Check the fiber connector and optical
normal range fiber as follows
If... Then...
The fiber connector is loose Properly connect the fiber connector. Check whether
the alarm is cleared. If the alarm persists, go to the
next step.
5. Check whether the fiber connector is damaged. For details, see Checking the Optical
Fiber Connector in the Supporting Tasks.
If... Then...
The fiber Clean the optical connector immediately. For details, see the
connector is dirty Supporting Tasks.
Using the Fiber Cleaner to Clean the Optical Fiber Connector
Using the Lens Tissue to Clean the Optical Fiber Connector
Using the Dust-Free Cotton Bar to Clean the Optical Fiber
Adapter
Check whether the alarm is cleared. If the alarm persists, go to
the next step.
6. Check whether the bend radius of the fiber jumper is within the normal range and
whether the optical fiber is pressed or damaged, or peels off. If the bend radius is less
than 6 cm, roll the fiber jumper again. If the fiber is faulty, replace the fiber. Check
whether the alarm is cleared.
7. If the alarm persists, check whether the optical interface board matches the type of the
optical fiber. If yes, the over low sensitivity, over high dispersion, or distortion may
cause errors.
If... Then...
The optical interface board does not match Replace the fiber or line board as
the type of the optical fiber required. Check whether the alarm is
cleared.
Step 4 Cause 3: The line performance deteriorates. (SDH electrical interface board)
1. Exchange the cables that are possibly faulty in the receive and transmit directions to
locate the fault.
If... Then...
The errors vary with the change of the cable Go to the next step.
The errors do not vary with the change of the cable Go to Step Step 6.
2. Check whether the cable is grounded properly and whether the cable connector and cable
are damaged. If the cable is faulty, replace the cable. Check whether the alarm is cleared.
If not, go to Step Step 6.
Step 9 Cause 7: The clock configuration is incorrect or the performance of the cross-connect and
timing unit deteriorates.
1. The clock sources of the local NE and opposite NE are asynchronous or interlocked,
causing errors and even service interruptions. If the NEs also report the performance
events or alarms related to pointer justifications, such as AUPJCHIGH, TUPJCHIGH,
and SYN_BAD, rectify the fault caused by clock configuration accordingly.
2. Check whether the alarm is cleared. If the alarm persists, replace the cross-connect and
timing board on the local NE. For details, see Replacing a CXL Board in the Parts
Replacement.
3. Check whether the alarm is cleared. If the alarm persists, replace the cross-connect and
timing board on the opposite NE. For details, see Replacing a CXL Board in the Parts
Replacement.
4. Check whether the alarm is cleared. If the alarm persists, contact Huawei technical
support engineers to handle the alarm.
----End
Related Information
None.
7.13 B2_EXC
Description
The B2_EXC is an alarm indicating that the multiplex section B2 bit errors in the signals
received by the line crosses the threshold. This alarm occurs when the line board detects that
the error rate of the multiplex section (B2 errors) exceeds the threshold preset for the
B2_EXC alarm (103 by default).
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1 Indicates the ID of the port on the board. For example, 0x01 indicates
that the alarm is reported by port 1 of the related board.
Parameter 2, Indicate the path ID. For example, in the case of Parameter 2 = 0x00
Parameter 3 and Parameter 3 = 0x01, the alarm is reported by path 1 of the board.
If this section does not describe the common fault symptom or the actual fault symptom is not contained
in the description of this section, handle the B1_EXC alarm by following the steps provided in Handling
Procedure.
Table 7-12 lists the common faulty symptoms of the alarms related to B1, B2, and B3 errors.
Table 7-12 Symptoms of the alarms related to B1, B2, and B3 errors
Common Fault Symptom Possible Cause
Multiple NEs reports error alarms. In a period of Cause 2: The external environment
time, the NEs also report the alarms related to is abnormal.
temperature or fan failure, such as TEMP_OVER
and FAN_FAIL.
1. In a period of time, the NEs that report error Cause 7: The clock configuration is
alarms and the downstream NEs report a large incorrect or the performance of the
number of performance events or alarms related cross-connect and timing unit
to pointer justifications, such as AUPJCHIGH deteriorates.
and SYN_BAD.
2. The boards on the local NE and the boards on
the opposite NE report B1 and B2 errors.
3. Multiple VC-4 paths on multiple boards report
the higher order error alarms.
The error alarms are reported by certain VC-4 paths The board is faulty.
on certain boards.
Possible Causes
The possible causes of the B2_EXC alarm are as follows:
l Cause 1: The error threshold is set incorrectly.
l Cause 2: The external environment is abnormal.
l Cause 3: The line performance deteriorates.
l Cause 4: The grounding is improper.
l Cause 5: The receive board on the local NE is faulty.
l Cause 6: The transmit board on the opposite NE is faulty.
l Cause 7: The clock configuration is incorrect or the performance of the cross-connect
and timing unit deteriorates.
Procedure
Step 1 Cause 1: The error threshold is set incorrectly.
1. Query the error threshold set on the board that reports the alarm. Increase the error
threshold according to the actual situation. For details, see Setting the Threshold for the
Bit Error Alarm in the Supporting Tasks.
2. Check whether the alarm is cleared. If the alarm persists, go to Step Step 2.
Step 2 Cause 2: The external environment is abnormal.
1. Check the temperature in the telecommunications room, the air filter, and the fans. For
details, see the handling procedures of TEMP_OVER.
2. Check whether the alarm is cleared. If the alarm persists, check whether there is any
electromagnetic interference. For example, the electromagnetic interference may be
caused by electronic devices, unstable power supply, lightening, and high voltage
transmission lines. If any, take proper anti-interference measures and then check whether
the alarm is cleared.
3. If the alarm persists, handle the alarm according to the type of the board that reports the
alarm.
If... Then...
Step 3 Cause 3: The line performance deteriorates. (SDH optical interface board)
1. On the NMS, check whether the transmit optical power of the opposite NE is within the
normal range. For details on the optical power of the board, see Specifications of the
Boards in the Technical Specifications Reference. For the operations on the NMS, see
Querying the Optical Power in the Supporting Tasks.
NOTE
You can obtain the manufacturer information about the optical module by referring to Querying
the Board Manufacturer Information Report in the Supporting Tasks or Bar Code in the Hardware
Description.
If... Then...
2. On the NMS, check whether the transmit optical power of the local NE is within the
normal range.
If... Then...
The transmit optical power is beyond the normal range Go to Step Step 7.
The transmit optical power is within the normal range Go to the next step.
3. On the NMS, check whether the receive optical power of the local NE is within the
normal range.
If... Then...
The receive optical power is beyond the Check the fiber connector and optical
normal range fiber as follows
If... Then...
The fiber connector is loose Properly connect the fiber connector. Check whether
the alarm is cleared. If the alarm persists, go to the
next step.
5. Check whether the fiber connector is damaged. For details, see Checking the Optical
Fiber Connector in the Supporting Tasks.
If... Then...
The fiber Clean the optical connector immediately. For details, see the
connector is dirty Supporting Tasks.
Using the Fiber Cleaner to Clean the Optical Fiber Connector
Using the Lens Tissue to Clean the Optical Fiber Connector
Using the Dust-Free Cotton Bar to Clean the Optical Fiber
Adapter
Check whether the alarm is cleared. If the alarm persists, go to
the next step.
6. Check whether the bend radius of the fiber jumper is within the normal range and
whether the optical fiber is pressed or damaged, or peels off. If the bend radius is less
than 6 cm, roll the fiber jumper again. If the fiber is faulty, replace the fiber. Check
whether the alarm is cleared.
7. If the alarm persists, check whether the optical interface board matches the type of the
optical fiber. If yes, the over low sensitivity, over high dispersion, or distortion may
cause errors.
If... Then...
The optical interface board does not match Replace the fiber or line board as
the type of the optical fiber required. Check whether the alarm is
cleared.
If... Then...
The errors vary with the change of the cable Go to the next step.
The errors do not vary with the change of the cable Go to Step Step 6.
2. Check whether the cable is grounded properly and whether the cable connector and cable
are damaged. If the cable is faulty, replace the cable. Check whether the alarm is cleared.
If not, go to Step Step 6.
Step 9 Cause 7: The clock configuration is incorrect or the performance of the cross-connect and
timing unit deteriorates.
1. The clock sources of the local NE and opposite NE are asynchronous or interlocked,
causing errors and even service interruptions. If the NEs also report the performance
events or alarms related to pointer justifications, such as AUPJCHIGH, TUPJCHIGH,
and SYN_BAD, rectify the fault caused by clock configuration accordingly.
2. Check whether the alarm is cleared. If the alarm persists, replace the cross-connect and
timing board on the local NE. For details, see Replacing a CXL Board in the Parts
Replacement.
3. Check whether the alarm is cleared. If the alarm persists, replace the cross-connect and
timing board on the opposite NE. For details, see Replacing a CXL Board in the Parts
Replacement.
4. Check whether the alarm is cleared. If the alarm persists, contact Huawei technical
support engineers to handle the alarm.
----End
Related Information
None.
7.14 BIP_EXC
Description
The BIP_EXC is an alarm indicating that the BIP errors exceed the threshold. This alarm
occurs when the board detects that the number of BIP-2 errors (in byte V5) exceeds the preset
BIP_EXC alarm threshold (10-3 by default).
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 2, Indicate the ID of the path that reports the alarm. Parameter 2 indicates the
Parameter 3 most significant byte (MSB) and Parameter 3 indicates the least significant
byte (LSB).
For example, when Parameter 2 = 0x00 and Parameter 3 = 0x01, the
BIP_EXC alarm is reported by path 1 of the board.
Exception:
When the N2PQ1/R2PD1 board works in MUX mode, the ID of the path is
indicated from the value of 0x40. That is, 0x40 indicates that the BIP_EXC
alarm occurs in VC-3 path 1.
For the Ethernet boards, indicates the number of the VC-12 order path.
If this section does not describe the common fault symptom or the actual fault symptom is not contained
in the description of this section, handle the BIP_EXC alarm by following the steps provided in
Handling Procedure.
Table 7-13 lists the common fault symptoms of the BIP_EXC alarm.
The board reports the BIP_EXC and higher Cause 1: The higher level error alarms
level alarms including the alarms related to B1, are reported by the system.
B2, and B3 errors.
l In a period of time, the NEs that report Cause 4: The performance of the cross-
error alarms and the downstream NEs connect unit degrades.
report a large number of performance
events or alarms related to pointer
justifications, such as TUPJCHIGH and
SYN_BAD.
l The tributary board on the local NE and the
tributary board of the downstream NE
report the path errors.
l Certain VC-12 paths on the local NE report
the lower path errors.
The error alarms are reported by certain VC-12 The board is faulty.
paths on certain boards.
Possible Causes
The possible causes of the BIP_EXC alarm are as follows:
l Cause 1: The higher level error alarms are reported by the system.
l Cause 2: The receive board on the local NE is faulty.
l Cause 3: The transmit board on the opposite NE is faulty.
l Cause 4: The performance of the cross-connect unit degrades.
Procedure
Step 1 Cause 1: The higher level error alarms are reported by the system.
1. On the NMS, check whether any higher level error alarm occurs on the local NE. If the
alarm occurs, clear the alarm first.
B1_EXC
B1_SD
B2_EXC
B2_SD
B3_EXC
B3_SD
2. Check whether the alarm is cleared. If the alarm persists, go to Step Step 2.
Boards in the Technical Specifications Reference. For the operations on the NMS, see
Querying the Optical Power in the Supporting Tasks.
NOTE
You can obtain the manufacturer information about the optical module by referring to Querying
the Board Manufacturer Information Report in the Supporting Tasks or Bar Code in the Hardware
Description.
If... Then...
The transmit optical power on the opposite NE is normal Go to the next step.
2. On the NMS, check whether the transmit optical power of the local NE is within the
normal range.
If... Then...
The transmit optical power of is beyond the normal range Go to the next step.
The transmit optical power of is within the normal range Go to Step Step 3.
3. Perform a cold reset by using the NMS, or directly reseat the transmit board of the local
NE. For details on how to perform the cold reset, see Resetting Boards in the Supporting
Tasks. For details on how to reseat the board, see Removing the Boards in the
Installation Reference and Installing the Boards in the Installation Reference.
NOTICE
If the service on the board is not protected, a cold reset on the board causes service
interruptions.
4. Check whether the alarm is cleared. If the alarm persists, replace the optical module or
board. If the board supports the pluggable optical module, replace the pluggable optical
module. For details, see Replacing a Pluggable Optical Module in the Parts
Replacement. Otherwise, replace the faulty board. For details, see Replacing Boards
Onsite in the Supporting Tasks.
5. Check whether the alarm is cleared. If the alarm persists, go to Step Step 3.
Step 3 Cause 3: The transmit board on the opposite NE is faulty.
1. Perform a cold reset by using the NMS, or directly reseat the transmit board of the
opposite NE. For the operations on the NMS, see Resetting Boards in the Supporting
Tasks. For details on how to reseat the board, see Removing the Boards in the
Installation Reference and Installing the Boards in the Installation Reference.
NOTICE
If the service on the board is not protected, a cold reset on the board causes service
interruptions.
2. Check whether the alarm is cleared. If the alarm persists, replace the optical module or
board. If the board supports the pluggable optical module, replace the pluggable optical
module. For details, see Replacing a Pluggable Optical Module in the Parts
Replacement. Otherwise, replace the faulty board. For details, see Replacing Boards
Onsite in the Supporting Tasks.
3. Check whether the alarm is cleared. If the alarm persists, go to Step Step 4.
----End
Related Information
None.
7.15 BD_STATUS
Description
The BD_STATUS is an alarm indicating that the physical board is not inserted into the
relevant slot. This alarm occurs when the user adds a board on the NMS, but the physical
board is not inserted into the relevant slot.
Attribute
Parameters
None.
If this section does not describe the common fault symptom or the actual fault symptom is not contained
in the description of this section, handle the BD_STATUS alarm by following the steps provided in
Handling Procedure.
Table 7-14 provides the details about the common fault symptom when the BD_STATUS
alarm occurs.
l When the equipment is configured with an Cause 1 (board): Other alarms trigger the
extended subrack, the equipment reports BD_STATUS alarm.
the Ext_COMM_FAIL alarm and multiple
processing boards on the extended subrack
reports the BD_STATUS alarm.
l When the equipment is configured with an
extended subrack, multiple processing
boards on the master and slave subracks
report the BD_STATUS and
COMMUN_FAIL alarms.
l Multiple boards (including the line boards,
data boards, and auxiliary boards) on the
NE report the BD_STATUS and
COMMUN_FAIL alarms.
The PROG indicator on the board that reports Cause 2: The board is in the reset state.
the alarm blinks green with a period of 600 ms
(300 ms off and 300 ms on) and then blinks
green with a period of 200 ms (100 ms off and
100 ms on).
The IF board reports hardware alarms such as Cause 5 (ODU): Other alarms trigger the
HARD_BAD, IF_CABLE_OPEN, and BD_STATUS alarm.
VOLT_LOS.
Possible Causes
If the BD_STATUS alarm is reported on the board, the possible causes are as follows:
If the alarm is reported on the ODU, the possible causes are as follows:
Procedure
Step 1 Cause 1 (board): Other alarms trigger the BD_STATUS alarm.
1. On the NMS, check whether the relevant NE reports the COMMUN_FAIL or
Ext_COMM_FAIL alarm.
2. If yes, clear the alarm immediately. Then, check whether the BD_STATUS alarm is
cleared. If the BD_STATUS alarm persists or none of the preceding alarms is reported,
go to Step Step 2.
If... Then...
The board is in the reset state The reset is complete five minutes later. Check
whether the alarm is cleared.
2. Check whether the alarm is cleared. If the alarm persists, go to Step Step 3.
Step 3 Cause 3: The board is not inserted in the corresponding slot or the board and the backplane is
connected improperly.
1. In the Main Topology, double-click the NE that reports the alarm. Then, the front panel
is displayed. Record the logical board type of the slot that reports the BD_STATUS
alarm.
2. Check whether the physical board is inserted in the corresponding slot.
If... Then...
The physical board is Properly insert the physical board that corresponds to the
not inserted logical board type. For details, see Installing the Boards in
the Installation Reference.
Check whether the alarm is cleared. If the alarm persists, go
to Step Step 4.
If... Then...
If... Then...
The board is improperly Reseat the board. For details, see Removing the
connected to the backplane Boards in the Installation Reference and Installing the
Boards in the Installation Reference.
Check whether the alarm is cleared. If the alarm
persists, go to Step Step 4.
Step 4 Cause 4: The board is faulty or the backplane has bent pins.
1. Replace the board that reports the BD_STATUS alarm. For details, see Replacing Boards
Onsite in the Supporting Tasks. Check whether the alarm is cleared.
2. If the alarm persists, check whether the backplane has bent pins.
If... Then...
The backplane has bent pins Contact Huawei technical support engineers to repair
the bent pins. Then, reseat the board.
----End
Related Information
None.
7.16 BUS_ERR
Description
The BUS_ERR is an alarm of bus errors. This alarm occurs when the cross-connect board
detects that the bus from the service board to the cross-connect board becomes abnormal.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1 By default, this parameter indicates the logical slot ID of the cross-connect
boards (including the extended slot).
If the value of Parameter 4 is 0x03, Parameter 1 indicates the ID of the higher
order cross-connect chip where the internal bus resides.
Parameter 2 By default, this parameter indicates the sequence number of the faulty bus.
If the value of Parameter 4 is 0x03, Parameter 2 indicates the physical
sequence number of the internal bus in the chip.
Parameter 3 In the case of cross-connect boards, different bits indicate different states that
the bus detects. If the bit corresponding to the parameter is 1, the state exists.
If the bit corresponding to the parameter is 0, the state does not exist.
The parameter indicates the following faults:
l Bit[0]: BUS_OOA.
l Bit[1]: BUS_OOF.
l Bit[2]: B1 errors.
l Bit[3]: FIFO overflow.
l Bit[4]: BUS_LOS.
Name Meaning
Parameter 4 In the case of cross-connect boards, this parameter indicates the type of the
BUS_ERR alarm.
l 0x01: Type I BUS_ERR alarm, detected by one cross-connect board.
l 0x02: Type II BUS_ERR alarm, detected by active/standby cross-connect
boards through the handshake.
l 0x03: Type III BUS_ERR alarm, detected through the internal bus of the
cross-connect board.
If this section does not describe the common fault symptom or the actual fault symptom is not contained
in the description of this section, handle the BUS_ERR alarm by following the steps provided in
Handling Procedure.
Table 7-15 lists the common fault symptoms of the BUS_ERR alarm.
1. The cross-connect the BUS_ERR alarm Cause 5: The electrical cable between
(Parameter 1 = 0x12, Parameter 3 = 0x04 or the extended subrack and master
0x06). subrack is faulty.
2. Generally, the HSC_UNAVAIL alarm is also
reported and Parameter 1 of the alarm is
0x04.
Possible Causes
The possible causes of the BUS_ERR alarm are as follows:
l Cause 1: The software version of the service board does not match the software version
of the cross-connect board.
l Cause 2: The software version of the cross-connect board does not match the logical
version.
l Cause 3: The service board is faulty.
l Cause 4: The cross-connect board is faulty.
l Cause 5: The electrical cable between the extended subrack and master subrack is faulty.
l Cause 6: The backplane bus from the service board to the cross-connect board is faulty.
Procedure
Step 1 On the NMS, query the current alarms and determine the cross-connect board that reports the
BUS_ERR alarm. Determine the service board corresponding to the cross-connect board
according Parameter 1. Determine the type of the BUS_ERR alarm according to Parameter 4.
For the operations on the NMS, see Viewing the Current Alarms in the Supporting Tasks.
Step 2 Cause 1: The software version of the service board does not match the software version of the
cross-connect board.
l If Parameter 4 is 0x01 or 0x02, go to the next step.
l If Parameter 4 is 0x03, go to Step Step 3.
1. Query the software version of the cross-connect board that reports the alarm, and the
software version of the service board indicated by Parameter 1. For details, see Querying
the Board Information Report in the Supporting Tasks. Determine whether the software
versions match according to the software version mapping table.
If... Then...
The software versions do Upgrade the earlier version to a mapping version. For
not match details, see the product software upgrade guide.
Check whether the alarm is cleared. If the alarm persists,
go to Step Step 3.
Step 3 Cause 2: The software version of the cross-connect board does not match the logical version.
1. Query the logical version and software version of the cross-connect board. For details,
see Querying the Board Information Report in the Supporting Tasks. Determine whether
the software versions match according to the software version mapping table.
If... Then...
If... Then...
The software versions do Upgrade the earlier version to a mapping version. For
not match details, see the product software upgrade guide.
Check whether the alarm is cleared. If the alarm persists,
go to Step Step 4.
A warm reset can be performed first. If the alarm persists after the warm reset, perform a cold
reset.
3. If the alarm persists, replace the service board. For details, see Replacing Boards Onsite
in the Supporting Tasks. Check whether the alarm is cleared.
NOTICE
If the services on the board are not protected, do not perform any cold reset or replace
the board. Otherwise, the services may be interrupted.
A warm reset can be performed first. If the alarm persists after the warm reset, perform a cold
reset.
2. If the alarm persists, replace the board that reports the alarm. For details, see Replacing a
CXL Board in the Parts Replacement. Check whether the alarm is cleared.
NOTICE
If no protection cross-connect board that working normally, do not perform the
operations. Otherwise, the services may be interrupted.
3. If the alarm persists, reset or replace the cross-connect board that does not report the
alarm. Check whether the alarm is cleared.
4. If the alarm persists, go to Step Step 6.
Step 6 Cause 5: The electrical cable between the extended subrack and master subrack is faulty.
1. Check whether the communication electrical cable between the master subrack and
extended subrack is loose. If yes, properly connect the cable. Check whether the alarm is
cleared.
2. If the alarm persists, contact Huawei technical support engineers to collect the data of the
bus fault, locate the fault among the four buses between the master subrack and extended
subrack, and replace the faulty electrical cable.
3. If the alarm persists, go to Step Step 7.
Step 7 Cause 6: The backplane bus from the service board to the cross-connect board is faulty.
1. Contact Huawei technical support engineers to check whether the fault is caused by the
bent pins of the backplane. If the backplane is faulty, replace the backplane.
----End
Related Information
None.
7.17 COMMUN_FAIL
Description
The COMMUN_FAIL is an alarm indicating the inter-board communication failure. This
alarm occurs when the communication between the SCC board and the other boards is
interrupted.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1 Indicates the ID of the port and the value is always 0x01.
Name Meaning
Parameter 2, Indicate the ID of the path that reports the alarm. Parameter 2 is always
Parameter 3 0x00. Parameter 3 has the following meanings:
l 0x01: RS485 path 1.
l 0x02: RS485 path 2.
l 0x03: Inter-board Ethernet communication.
l 0x04: Inter-subrack Ethernet emergency path.
If this section does not describe the common fault symptom or the actual fault symptom is not contained
in the description of this section, handle the COMMUN_FAIL alarm by following the steps provided in
Handling Procedure.
Table 7-16 lists the common fault symptoms of the COMMUN_FAIL alarm.
A single board l The PROG indicator on the board that Cause 1 (single
reports the reports the alarm blinks green with a period board): The board is
COMMUN_FA of 600 ms (300 ms off and 300 ms on) and in the reset state.
IL alarm. then blinks green with a period of 200 ms
(100 ms off and 100 ms on).
l The board reports the COMMUN_FAIL and
BD_STATUS alarms.
Multiple l The protection SCC board does not report Cause 1 (multiple
service boards the alarm. boards): The AUX
report the l The AUX board reports the BD_STATUS. board is faulty.
COMMUN_FA
IL alarm.
Possible Causes
A single board may report the COMMUN_FAIL alarm due to the following causes:
l Cause 1 (single board): The board is in the reset state.
l Cause 2 (single board): The versions do not match.
l Cause 3 (single board): The service board is faulty.
Multiple boards may report the COMMUN_FAIL alarm due to the following causes:
l Cause 1 (multiple boards): The AUX board is faulty.
l Cause 2 (multiple boards): The CXL board is faulty.
l Cause 3 (multiple boards): On the AUX board, the COM port is directly connected to the
HUB or exchange.
Procedure
Step 1 Cause 1 (single board): The board is in the reset state.
1. Observe the indicator on the board or query the reset record of the board. Check whether
the board is in the reset state. For details about the meanings of board indicators, see
Alarm Indicators on the Boards in the Hardware Description. For details on how to
query the reset record, see Querying the Operation Log of the NMS in Supporting Tasks.
If... Then...
The board is in the reset state The reset is complete five minutes later. Check
whether the alarm is cleared.
If... Then...
The version does not Contact Huawei technical support engineers to upgrade the
match relevant software. Check whether the alarm is cleared. If
the alarm persists, go to Step Step 3.
The VLAN of the equipment is used to isolate different NEs on the network and ensure that the
intra-NE communication is not affected.
2. If the COM port is required for debugging, directly connect the port to the computer
where the NMS is running.
NOTICE
The COM port is used for internal testing only. Thus, the port can be connected to the
computer for debugging only, rather than a hub or switch.
3. Check whether the alarm is cleared. If the alarm persists, contact Huawei technical
support engineers to handle the alarm.
----End
Related Information
None.
7.18 DOWN_E1_AIS
Description
The DOWN_E1_AIS is an alarm indicating the downstream 2 Mbit/s signals. If a tributary
board has detected that the value of the downstream E1 signals is all "1"s, the
DOWN_E1_AIS alarm is reported.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 2, Indicates the path number. Parameter 2 is the higher byte, and
Parameter 3 Parameter 3 is the lower byte.
For example, Parameter 2 = 0x00, Parameter 3 = 0x01. In this case, the
DOWN_E1_AIS alarm is reported from path 1 of the board.
If this section does not describe the common fault symptom or if the actual fault symptom is not
contained in the description of the common fault symptom, handle the DOWN_E1_AIS alarm by
following the steps provided in Handling Procedure.
Table 7-17 lists the common fault symptoms of the DOWN_E1_AIS alarm.
In the service direction, the tributary unit at the Cause 1: The tributary unit at the
opposite end reports an alarm (such as the opposite end reports an alarm such as
UP_E1_AIS and T_ALOS alarm) indicating the UP_E1_AIS or T_ALOS alarm.
that the accessed signals are lost.
Possible Causes
The possible causes of the DOWN_E1_AIS alarm are as follows:
l Cause 1: The tributary unit at the opposite end reports an alarm such as the UP_E1_AIS
or T_ALOS alarm.
X X
T L L T
C C
U U U U
S S
DOWN_E1_AIS
X X
T L L T
C C
U U U U
S S
l Cause 3: The cross-connect and timing board at the local end is faulty.
DOWN_E1_AIS
X X
T L L T
C C
U U U U
S S
Procedure
Step 1 Check the alarm on the NMS, and then determine the board where the alarm is generated. For
details, see Viewing the Current Alarms in the Supporting Tasks.
Step 2 Cause 1: The tributary unit at the opposite end reports an alarm such as the UP_E1_AIS or
T_ALOS alarm.
1. As shown in Figure 7-6, check whether the tributary unit at the opposite end reports an
alarm indicating that the accessed signals are lost in the service direction.
If... Then...
The tributary unit at the opposite end Clear the alarm immediately, and then
reports an alarm such as the UP_E1_AIS check whether the DOWN_E1_AIS
or T_ALOS alarm alarm is cleared. If the DOWN_E1_AIS
alarm persists, go to Step Step 3.
NOTICE
If the service on the board is not protected, a cold reset on the board causes service
interruption.
2. Check whether the alarm is cleared. If the alarm persists, replace the tributary board that
reports the alarm. For details, see in the Parts Replacement.
3. Check whether the alarm is cleared. If the alarm persists, go to Step Step 4.
Step 4 Cause 3: The cross-connect and timing board at the local end is faulty.
1. As shown in Figure 7-8, if the cross-connect unit at the local end works abnormally, the
DOWN_E1_AIS alarm is reported. Perform a cold reset on the cross-connect and timing
board by using the NMS, or directly reseat the cross-connect and timing board. For
details on how to perform a cold reset, see Resetting Boards in the Supporting Tasks. For
details on how to reseat a board, see Removing the Boards in the Installation Reference
and Installing the Boards in the Installation Reference.
NOTICE
If there is no protection cross-connect and timing board, performing a cold reset on the
working cross-connect and timing board may cause service interruption.
2. Check whether the alarm is cleared. If the alarm persists, replace the relevant cross-
connect and timing board. For details, see Replacing a CXL Board in the Parts
Replacement.
3. Check whether the alarm is cleared. If the alarm persists, contact Huawei technical
support engineers to handle the alarm.
----End
Related Information
None.
7.19 ETH_LOS
Description
The ETH_LOS is an alarm indicating the loss of network connection. This alarm occurs when
the Ethernet port fails to receive any Ethernet signal.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1 Indicates the ID of the port that reports the alarm. The value
ranges are different for different boards.
If this section does not describe the common fault symptom or the actual fault symptom is not contained
in the description of the common fault symptom, handle the ETH_LOS alarm by following the steps
provided in Handling Procedure.
None.
Possible Causes
The possible causes of the ETH_LOS alarm are as follows:
l Cause 1: The port is enabled, but no signal is accessed from the client side.
l Cause 2: The working mode of the local port does not match the working mode of the
opposite port.
l Cause 3: The port is enabled, but the network cable or fiber is connected incorrectly or
faulty.
l Cause 4: The opposite board is faulty.
l Cause 5: The local board is faulty.
Procedure
Step 1 On the NMS, check the alarms. Determine the port that reports the alarm according to the
alarm parameters. For details, see Viewing the Current Alarms in the Supporting Tasks.
Step 2 Cause 1: The port is enabled, but no signal is accessed from the client side.
1. If the services on the Ethernet port are deleted but the Ethernet port is still Enabled, the
ETH_LOS alarm may be reported. Check whether the port accesses signals from the
client side and whether the port is enabled.
2. If the services at the port are deleted, configure services properly. If the port is no longer
required, disable the port. For details on configuring services, see the Configuration
Guide. For details on how to set the attribute of the port, see Configuring the External
Port on an Ethernet Board in the Feature Description.
3. Check whether the alarm is cleared. If the alarm persists, go to Step Step 3.
Step 3 Cause 2: The working mode of the local port does not match the working mode of the
opposite port.
1. Query the working modes of the interconnected ports. Determine whether the ports
support the auto-negotiation mode, and then select a proper working mode. For details,
see Configuring the External Port on an Ethernet Board in the Feature Description.
2. Ensure that the working modes of the interconnected ports are consistent. Then, check
whether the alarm is cleared. If the alarm persists, go to Step Step 4.
Step 4 Cause 3: The port is enabled, but the network cable or fiber is connected incorrectly or faulty.
1. Check whether the port where the alarm is reported is connected correctly to the network
cable or fiber. If the port is connected incorrectly to the network cable or fiber, connect
the port to the network cable or fiber correctly according to the requirements of the
actual network. Then, check whether the alarm is cleared.
2. Check whether the network cable or fiber jumper at the port is loose. If yes, install the
network cable or fiber jumper correctly. Check whether the alarm is cleared.
3. In the case of an optical interface, check whether the fiber connector is dirty. For details,
see Checking the Optical Fiber Connector in the Supporting Tasks. If the fiber connector
is dirty, clean it immediately. Check whether the alarm is cleared. For details on how to
clean the fiber connector, see the Supporting Task.
Using the Fiber Cleaner to Clean the Optical Fiber Connector
Using the Lens Tissue to Clean the Optical Fiber Connector
Using the Dust-Free Cotton Bar to Clean the Optical Fiber Adapter
4. If the alarm persists, exchange the cables or fibers to locate the fault. If the cable or fiber
is faulty, the Ethernet services may be interrupted. Replace the cable or fiber which may
be faulty with a good one. Check whether the alarm is cleared.
5. Check whether the alarm is cleared. If the alarm persists, go to Step Step 5.
Step 5 Cause 4: The opposite board is faulty.
If... Then...
1. In the case of an optical interface board, check whether the transmit optical power of the
opposite board is within the normal range on the NMS. For details on the optical power
of the board, see Specifications of the Boards in the Technical Specifications Reference.
For the operations on the NMS, see Querying the Optical Power in the Supporting Tasks.
NOTE
You can obtain the manufacturer information about the optical module by referring to Querying
the Board Manufacturer Information Report in the Supporting Tasks or Bar Code in the Hardware
Description.
If... Then...
The transmit optical power on Replace the relevant board. For details, see
the opposite NE is abnormal Replacing an Ethernet Board in the Parts
Replacement. Check whether the alarm is cleared.
If the alarm persists, go to Step Step 6.
2. In the case of an electrical interface board, check whether the transmit optical power of
the local board is within the normal range on the NMS.
If... Then...
The transmit optical power on the local NE is normal Go to Step Step 5.4.
3. In the case of an electrical interface board, check whether the board reports the alarms
indicating the fault of the board or chip, such as HARD_BAD.
If... Then...
None of the preceding alarms is reported Exchange the boards to locate the fault.
4. If the Ethernet board works with an interface board, replace the interface board first. If
the Ethernet board does not work with any interface board, replace the processing board.
For details, see Replacing an Ethernet Board in the Parts Replacement. Check whether
the alarm is cleared. If the alarm persists, go to Step Step 6.
Step 6 Cause 5: The local board is faulty.
1. If the Ethernet board works with an interface board, replace the interface board first. If
the Ethernet board does not work with an interface board, replace the processing board.
For details, see Replacing an Ethernet Board in the Parts Replacement.
2. Check whether the alarm is cleared. If the alarm persists, contact Huawei technical
support engineers to handle the alarm.
----End
Related Information
If the negotiated mode of the Ethernet ports is half duplex, signals are transmitted in one
direction at the same time. As a result, the data transmission performance degrades greatly.
When the service traffic is low, packet loss occurs at the interconnected ports. When the
service traffic is high, services are interrupted.
7.20 ETH_CFM_LOC
Description
The ETH_CFM_LOC is an alarm indicating the loss of connectivity. This alarm is reported
when the system does not receive CCM packets from the remote MEP in the 3.5xCC period.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameters 1 (4 Indicates the number of the Ethernet port where the ETH_CFM_RDI
byte) alarm is reported.
l MAC port number: 0x0001-0x0000 plus MAX_ETH_PORT.
l VCTRUNK port number: 0x8001-0x8000 plus
MAX_ETH_VCTRUNK.
NOTE
l MAX_ETH_PORT indicates the maximum MAC port number supported by
the board.
l MAX_ETH_VCTRUNK indicates the maximum VCTRUNK port number
supported by the board.
Parameters 2 (2
Indicates the service VLAN ID.
byte)
Parameters 3 (1 Indicates the direction of the local MEP.
byte)
l 0x00: The port is direction insensitive.
l 0x01: The port is in the ingress direction.
l 0x02: The port is in the egress direction.
Parameters 4 (1 Indicates the maintenance domain level.
byte)
l 0x00: Consumer MP level (high).
l 0x01: Consumer MP level (middle).
l 0x02: Consumer MP level (low).
l 0x03: Provider MP level (high).
l 0x04: Provider MP level (low).
l 0x05: Operator MP level (high).
l 0x06: Operator MP level (middle).
l 0x07: Operator MP level (low).
NOTE
Consumers refer to end users, service providers, and service carriers.
Parameters 5 (2
Indicates the ID of the remote MEP.
byte)
If this section does not describe the common fault symptom or if the actual fault symptom is not
contained in the description of the common fault symptom, handle the ETH_CFM_LOC alarm by
following the steps provided in Handling Procedure.
None.
Possible Causes
The possible causes of the ETH_CFM_LOC alarm are as follows:
l Cause 1: The corresponding MEP at the opposite end is not configured correctly.
ETH_CFM_LOC
Incorrect configuration
PE1 PE2
RMEP: MEP 2 RMEP: MEP 1
l Cause 2: The configuration of the Ethernet services that correspond to the MAs of the
MEPs at both ends is incorrect.
ETH_CFM_LOC
Incorrect
PE1 configuration of the PE2
RMEP: MEP 2 Ethernet service RMEP: MEP 1
l Cause 3: The service transmission line between the MEPs at both ends is interrupted.
ETH_CFM_LOC
Interrupted
transmission
PE1 PE2
RMEP: MEP 2 RMEP: MEP 1
ETH_CFM_LOC
Procedure
Step 1 Check the alarm on the NMS, and then determine the board where the alarm is generated and
the MEP where the alarm is reported. For details, see Viewing the Current Alarms in the
Supporting Tasks.
Step 2 Cause 1: The corresponding MEP at the opposite end is not configured correctly.
1. As shown in Figure 7-9, if PE2 reports the ETH_CFM_LOC alarm, check whether the
MEP of PE1 is configured correctly.
If... Then...
2. Modify the configuration of the MEP to ensure consistency at both ends. For details, see
Creating an MD in the Feature Description.
3. Check whether the alarm is cleared. If the alarm persists, go to Step Step 3.
Step 3 Cause 2: The configuration of the Ethernet services that correspond to the MAs of the MEPs
at both ends is incorrect.
1. As shown in Figure 7-9, if PE2 reports the ETH_CFM_LOC alarm, it indicates that the
PE1-PE2 connectivity of the service configuration is abnormal. Check whether the
configuration of the Ethernet services from PE1 to PE2 is correct, such as the cross-
connection of PE1, whether the port is enabled, and port attribute.
If... Then...
Step 4 Cause 3: The service transmission line between the MEPs at both ends is interrupted.
1. As shown Figure 7-10, if PE2 reports the ETH_CFM_LOC alarm, it indicates that the
path connectivity from PE1 to PE2 is abnormal. Check whether the physical links (such
as cables or fibers) between the MEPs at both ends are correct.
If... Then...
The connection is incorrect Connect the cable properly. Check whether the alarm is
cleared. If the alarm persists, go to the next step.
If... Then...
The cable connector is loose Connect the cable connector properly. Check
whether the alarm is cleared. If the alarm persists, go
to the next step.
3. Check whether the cable is pressed, damaged, peeled off, aged, or cut. If the cable is
faulty, replace the cable. Check whether the alarm is cleared. If the alarm persists, go to
Step Step 5.
Step 5 Cause 4: The network is congested seriously.
1. If you activate the CC test, certain bandwidth is required. When congestion occurs on the
network, the remote MEP fails to receive the CCM packets. Check the bandwidth
utilization of the MEPs at both ends. For example, check whether the FLOW_OVER
alarm is reported.
If... Then...
If... Then...
The bandwidth is not Contact Huawei technical support engineers to handle the
exhausted alarm.
----End
Related Information
Standard MEPs refer to the MEPs that comply with IEEE802.1ag standard.
7.21 ETH_CFM_MISMERGE
Description
The ETH_CFM_MISMERGE is an alarm indicating that the connection is incorrect. This
alarm is reported when the system receives the continuity check message (CCM) packets with
mismatched maintenance association (MA) ID or the CCM packets of a lower level.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameters 1 (4 Indicates the number of the Ethernet port where the
byte) ETH_CFM_MISMERGE alarm is reported.
l MAC port number: 0x00010x0000 plus MAX_ETH_PORT.
l VCTRUNK port number: 0x80010x8000 plus
MAX_ETH_VCTRUNK.
NOTE
l MAX_ETH_PORT indicates the maximum MAC port number supported by the
board.
l MAX_ETH_VCTRUNK indicates the maximum VCTRUNK port number
supported by the board.
Parameters 2 (2
Indicates the service VLAN ID.
byte)
Name Meaning
Parameters 3 (1 Indicates the direction of the local MEP.
byte)
l 0x00: The port is direction insensitive.
l 0x01: The port is in the ingress direction.
l 0x02: The port is in the egress direction.
Parameters 4 (1 Indicates the maintenance domain level.
byte)
l 0x00: Consumer MP level (high).
l 0x01: Consumer MP level (middle).
l 0x02: Consumer MP level (low).
l 0x03: Provider MP level (high).
l 0x04: Provider MP level (low).
l 0x05: Operator MP level (high).
l 0x06: Operator MP level (middle).
l 0x07: Operator MP level (low).
NOTE
Consumers refer to end users, service providers, and service carriers.
If this section does not describe the common fault symptom or if the actual fault symptom is not
contained in the description of the common fault symptom, handle the ETH_CFM_MISMERGE alarm
by following the steps provided in Handling Procedure.
None.
Possible Causes
The possible causes of the ETH_CFM_MISMERGE alarm are as follows:
l Cause 1: The MD levels of the MEPs at both ends are different from each other.
ETH_CFM_MISMERGE
MD level: 1 MD level: 3
PE1 PE2
RMEP: MEP 2 RMEP: MEP 1
l Cause 2: The MD names or MA names of MEPs at both ends are different from each
other.
PE1 PE2
RMEP: MEP 2 RMEP: MEP 1
l Cause 3: The physical links between different services are connected incorrectly.
ETH_CFM_MISMERGE
Correct
path
Incorrect
path
PE1 PE2
RMEP: MEP 2 RMEP: MEP 1
Procedure
Step 1 Check the alarm on the NMS, and then determine the board where the alarm is generated and
the MEP where the alarm is reported. For details, see Viewing the Current Alarms in the
Supporting Tasks.
Step 2 Cause 1: The MD levels of the MEPs at both ends are different from each other.
1. Check whether the MD levels of the MEPs at both ends are set to the same value.
If... Then...
The MD levels are different Set the MD levels again to ensure consistency at
from each other both ends. For details, see Creating an MD in the
Feature Description.
2. Check whether the alarm is cleared. If the alarm persists, go to Step Step 3.
Step 3 Cause 2: The MD names or MA names of MEPs at both ends are different from each other.
1. Check whether the MD names or MA names of the MEPs at both ends are the same.
If... Then...
2. Check whether the alarm is cleared. If the alarm persists, go to Step Step 4.
Step 4 Cause 3: The physical links between different services are connected incorrectly.
1. According to the Ethernet service routes, check whether the physical links that
correspond to the service routes are connected incorrectly.
If... Then...
Certain physical links are Reconnect the fibers or reconfigure the service routes.
connected incorrectly Check whether the alarm is cleared. If the alarm
persists, contact Huawei technical support engineers to
handle the alarm.
----End
Related Information
Standard MEPs refer to the MEPs that comply with IEEE802.1ag standard.
7.22 ETH_CFM_RDI
Description
The ETH_CFM_RDI is an alarm indicating that the function of receiving the CCM packets of
the remote MEP fails. This alarm is reported when the system receives the CCM packets with
RDI transmitted from the remote end.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameters 1 (4 Indicates the number of the Ethernet port where the ETH_CFM_RDI
byte) alarm is reported.
l MAC port number: 0x00010x0000 plus MAX_ETH_PORT.
l VCTRUNK port number: 0x80010x8000 plus
MAX_ETH_VCTRUNK.
NOTE
l MAX_ETH_PORT indicates the maximum MAC port number supported by
the board.
l MAX_ETH_VCTRUNK indicates the maximum VCTRUNK port number
supported by the board.
Parameters 2 (2
Indicates the service VLAN ID.
byte)
Parameters 3 (1 Indicates the direction of the local MEP.
byte)
l 0x00: The port is direction insensitive.
l 0x01: The port is in the ingress direction.
l 0x02: The port is in the egress direction.
Parameters 4 (1 Indicates the maintenance domain level.
byte)
l 0x00: Consumer MP level (high).
l 0x01: Consumer MP level (middle).
l 0x02: Consumer MP level (low).
l 0x03: Provider MP level (high).
l 0x04: Provider MP level (low).
l 0x05: Operator MP level (high).
l 0x06: Operator MP level (middle).
l 0x07: Operator MP level (low).
NOTE
Consumers refer to end users, service providers, and service carriers.
Parameters 5 (2
Indicates the ID of the remote MEP.
byte)
If this section does not describe the common fault symptom or if the actual fault symptom is not
contained in the description of the common fault symptom, handle the ETH_CFM_RDI alarm by
following the steps provided in Handling Procedure.
None.
Possible Causes
The possible cause of the ETH_CFM_RDI alarm is as follows:
Cause 1: The equipment of the remote MEP is faulty.
ETH_CFM_RDI
Fault detected at the port
PE1 PE2
RMEP: MEP 2 RMEP: MEP 1
Procedure
Step 1 Check the alarm on the NMS, and then determines the board where the alarm is generated and
the MEP where the alarm is reported. For details, see Viewing the Current Alarms in the
Supporting Tasks.
Step 2 Cause 1: The equipment of the remote MEP is faulty.
1. Check whether the remote MEP that is connected to the port where the ETH_CFM_RDI
alarm is reported is faulty. As shown in Figure 7-16, if PE2 reports the ETH_CFM_RDI
alarm, check whether port 1 of the MEP at PE1 reports an Ethernet alarm.
If... Then...
----End
Related Information
Standard MEPs refer to the MEPs that comply with IEEE802.1ag standard.
7.23 ETH_CFM_UNEXPERI
Description
The ETH_CFM_UNEXPERI is an alarm indicating the errored frame. This alarm is reported
when the system receives invalid CCM packets.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameters 1 (4 Indicates the number of the Ethernet port where the
byte) ETH_CFM_UNEXPERI alarm is reported.
l MAC port number: 0x0001-0x0000 plus MAX_ETH_PORT.
l VCTRUNK port number: 0x8001-0x8000 plus
MAX_ETH_VCTRUNK.
NOTE
l MAX_ETH_PORT indicates the maximum MAC port number supported by the
board.
l MAX_ETH_VCTRUNK indicates the maximum VCTRUNK port number
supported by the board.
Parameters 2 (2
Indicates the service VLAN ID.
byte)
Parameters 3 (1 Indicates the direction of the local MEP.
byte)
l 0x00: The port is direction insensitive.
l 0x01: The port is in the ingress direction.
l 0x02: The port is in the egress direction.
Parameters 4 (1 Indicates the maintenance domain level.
byte)
l 0x00: Consumer MP level (high).
l 0x01: Consumer MP level (middle).
l 0x02: Consumer MP level (low).
l 0x03: Provider MP level (high).
l 0x04: Provider MP level (low).
l 0x05: Operator MP level (high).
l 0x06: Operator MP level (middle).
l 0x07: Operator MP level (low).
NOTE
Consumers refer to end users, service providers, and service carriers.
If this section does not describe the common fault symptom or if the actual fault symptom is not
contained in the description of the common fault symptom, handle the ETH_CFM_UNEXPERI alarm
by following the steps provided in Handling Procedure.
None.
Possible Causes
The possible causes of the ETH_CFM_UNEXPERI alarm are as follows:
l Cause 1: The cycles of the continuity check (CC) of the MEPs at both ends are different
from each other.
CC
frame
PE1
PE3 PE2
MEP: Maintenance
association end point
MIP: Maintenance
association intermediate
point
Transmission path of
the CC frames
l Cause 2: The IDs of the MEPs at both ends conflict with each other.
CC
frame
PE1
MEP 1
MIP 5 MIP 3
MEP 4
PE3 PE2
MEP: Maintenance
association end point
MIP: Maintenance
association intermediate
point
Transmission path of
the CC frames
l Cause 3: Loopback occurs in the service, and loopback packets are received.
CC
frame
PE1
MEP 2
MIP 5 MIP 3
MEP 4
PE3 PE2
ETH_CFM_UNEXPERI
MEP: Maintenance
association end point
MIP: Maintenance
association intermediate
point
Transmission path of
the CC frames
CC
frame
PE1
MEP 2
MIP 5 MIP 3
MEP 4
PE3 PE2
ETH_CFM_UNEXPERI
MEP: Maintenance
association end point
MIP: Maintenance
association intermediate
point
Transmission path of
the CC frames
Procedure
Step 1 Check the alarm on the NMS, and then determine the board where the alarm is generated and
the MEP where the alarm is reported. For details, see Viewing the Current Alarms in the
Supporting Tasks.
Step 2 Cause 1: The cycles of the continuity check (CC) of the MEPs at both ends are different from
each other.
1. As shown in Figure 7-17, if MEP 1 of PE2 reports the ETH_CFM_LOC alarm, check
whether the cycles of the CC test of the MEPs at both ends are the same
If... Then...
The cycles of the CC test are Modify CCM Sending Period to ensure
different from each other consistency at both ends. For details, see
Creating an MD in the Feature Description.
2. Check whether the alarm is cleared. If the alarm persists, go to Step Step 3.
Step 3 Cause 2: The IDs of the MEPs at both ends conflict with each other.
1. The maintenance point (MP) IDs in the maintenance domain must be unique. As shown
in Figure 7-18, if the MP IDs in the maintenance domain are duplicate, the system
receives invalid CCM packets. Check whether the MP IDs in the maintenance domain
conflict with each other.
If... Then...
The MP IDs conflict with each Change the settings of the MP IDs. For details,
other see Creating an MD in the Feature Description.
2. Check whether the alarm is cleared. If the alarm persists, go to Step Step 4.
Step 4 Cause 3: Loopback occurs in the service, and loopback packets are received.
1. Enable the Self-Loop Test function of IEEE 802.3ah OAM to determine whether a loop
is generated in the service. Check whether a loop is generated on the MP ports of the
service path. For details, see Enabling Self-Loop Detection in the Feature Description.
If... Then...
2. Check whether the alarm is cleared. If the alarm persists, go to Step Step 5.
Step 5 Cause 4: A board of the MEP at the source end works abnormally.
1. Perform a warm reset on the Ethernet board where the source MEP is located. For
details, see Resetting Boards in the Supporting Tasks.
2. Check whether the alarm is cleared. If the alarm persists, contact Huawei technical
support engineers to handle the alarm.
----End
Related Information
Standard MEPs refer to the MEPs that comply with IEEE802.1ag standard.
7.24 EXT_SYNC_LOS
Description
The EXT_SYNC_LOS is an alarm of the loss of the external clock source. This alarm occurs
when the system detects that the external clock source traced by the equipment is lost.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
If this section does not describe the common fault symptom or the actual fault symptom is not contained
in the description of the common fault symptom, handle the EXT_SYNC_LOS alarm by following the
steps provided in Handling Procedure.
Table 7-18 lists the common fault symptoms of the EXT_SYNC_LOS alarm.
Only one cross-connect and timing board Cause 7: The cross-connect and timing
reports the EXT_SYNC_LOS alarm. board is abnormal.
Possible Causes
The possible causes of the EXT_SYNC_LOS alarm are as follows:
Configuration
l Cause 1: The configured input/output mode of the external clock does not match the
actual type of the external clock.
l Cause 2: The NE clock is in free-run state due to inappropriate allocation of the IDs of
clock sources.
l Cause 3: The synchronization status message byte (SSMB) timeslot of the external clock
mismatches.
l Cause 4: The equipment fails to identify the quality of the external source.
l Cause 5: The external source signal is interrupted.
Hardware
l Cause 6: The cable that connects the external clock is incorrectly connected or damaged.
l Cause 7: The cross-connect and timing board is abnormal.
l Cause 8: The external clock equipment is faulty.
Procedure
Step 1 Check the alarm on the NMS. Then, determine which channel of external clock source is lost
according to Parameter 1. For details, see Viewing the Current Alarms in the Supporting
Tasks.
Step 2 Cause 1: The configured input/output mode of the external clock does not match the actual
type of the external clock.
1. Check the configured input mode of the external clock.
If... Then...
The configured input/output According to the actual type of external clock,
mode of the external clock does set External Clock Source Mode to 2 MHz or 2
not match the actual type of the Mbit/s. For details, see Configuring NE Clock
external clock Sources in the Feature Description.
Check whether the alarm is cleared. If the alarm
persists, go to the next step.
If... Then...
The output mode of 2M phase- According to the actual type of the external
locked source does not match synchronous clock, set Output Mode of External
the actual type of external Clock Source in External Clock Output Phase-
synchronous clock Locked Source to 2 MHz or 2 Mbit/s. For details,
see Configuring the Phase-Locked Source for
External Clock Output in the Feature Description.
Check whether the alarm is cleared. If the alarm
persists, go to the next step.
If... Then...
The output impedance of 2M According to the actual impedance of the external
phase-locked source does not synchronous clock, set Output Impedance of
match the impedance of the External Clock Source in External Clock Output
external synchronous clock Phase-Locked Source to 75 ohms or 120 ohms.
source For details, see Configuring the Phase-Locked
Source for External Clock Output in the Feature
Description.
Check whether the alarm is cleared. If the alarm
persists, go to Step Step 3.
Step 3 Cause 2: The NE clock is in free-run state due to inappropriate allocation of the IDs of clock
sources.
1. If the extended SSM protocol is enabled on the entire network, set the IDs of clock
sources according to the clock ID planning principle. If no ID is allocated for the
external clock source, or if the clock IDs set on the NE are in conflict, the NE clock is in
the free-run state. Check the clock IDs set on the NE. For details, see Configuring the
Clock Source Protection in the Feature Description.
2. If no ID is allocated for the external clock source, or if the clock IDs set on the NE are in
conflict, modify the IDs according to the requirements of the network. Check whether
the alarm is cleared. If the alarm persists, go to Step Step 4.
Step 4 Cause 3: The synchronization status message byte (SSMB) timeslot of the external clock
mismatches.
1. If the SSM protocol is enabled on the NE and the input external clock is 2 Mbit/s, check
in which timeslot the SSMB set on the NE is located.
If... Then...
The timeslot set on the NE is According to the actual timeslot of the external
different from the actual timeslot clock, reset the SSMB. For details, see
of the external clock Configuring NE Clock Sources in the Feature
Description.
Check whether the alarm is cleared. If the alarm
persists, go to Step Step 5.
Step 5 Cause 4: The equipment fails to identify the quality of the external source.
1. If the SSM protocol is enabled on the NE, query the information about the clock
synchronization quality on the NMS. For details, see Viewing Clock Synchronization
Status in the Feature Description.
If... Then...
The information is According to the precision of the external clock,
Unknown Synchronization manually set the quality of the external clock. For
Quality details, see Setting the Clock Source Quality in the
Feature Description.
Check whether the alarm is cleared. If the alarm persists,
go to Step Step 6.
If... Then...
The clock input cable is not connected to Properly connect clock cable. For
the external clock interface, or the details, see the Quick Installation
impedance of the clock input cable does not Guide. Check whether the alarm is
match the impedance of the external clock cleared. If the alarm persists, go to the
interface next step.
2. If the possible cause is the faulty electrical cable and only one channel of external clock
cable reports the EXT_SYNC_LOS alarm, locate the fault by exchanging the two
channels of external clock cables. If both channels of external clock cables report the
EXT_SYNC_LOS alarm, go to the next step.
If... Then...
The EXT_SYNC_LOS alarm changes with the change of Go to the next step.
cables
The EXT_SYNC_LOS alarm does not change with the change Go to Step Step 8.
of cables
3. Check whether the channel of external clock cable that reports the alarm is loose,
pressed, or damaged. If yes, reinstall the connector of the cable or replace the faulty
cable. Check whether the alarm is cleared. If the alarm persists, go to Step Step 8.
Step 8 Cause 7: The cross-connect and timing board is abnormal.
If... Then...
The protection cross-connect and timing board The protection board may be faulty.
reports the EXT_SYNC_LOS alarm Reset or reinstall the protection board.
Go to Step Step 8.2.
1. Perform the working/protection switching of the cross-connect and timing boards. For
details, see Replacing a CXL Board in the Parts Replacement.
If... Then...
After the switching is performed, the original The original working board may be
protection board does not report the faulty. Reset or reinstall the
EXT_SYNC_LOS alarm original working board. Go to the
next step.
If... Then...
2. Perform a cold reset by using the NMS or reinstall the cross-connect and timing board.
For details on how to perform the cold reset, see Resetting Boards in the Supporting
Tasks. For details on how to reinstall the board, see Removing the Boards in the
Installation Reference and Installing the Boards in the Installation Reference.
3. Check whether the alarm is cleared. If the alarm persists, replace the relevant cross-
connect and timing board. For details, see Replacing a CXL Board in the Parts
Replacement.
4. Check whether the alarm is cleared. If the alarm persists, go to Step Step 9.
----End
Related Information
None.
7.25 FAN_FAIL
Description
The FAN_FAIL is an alarm indicating that a fan is faulty. This alarm occurs when a fan is
faulty.
Attribute
Parameters
None.
If this section does not describe the common fault symptom or the actual fault symptom is not contained
in the description of this section, handle the FAN_FAIL alarm by following the steps provided in
Handling Procedure.
None.
Possible Causes
The possible causes of the FAN_FAIL alarm are as follows:
Procedure
Step 1 Cause 1: The fan tray assembly is not tightly inserted.
1. Check whether the fan tray assembly is tightly inserted. If not, reseat the fan tray
assembly. Check whether the alarm is cleared. If the alarm persists, go to Step Step 2.
If... Then...
----End
Related Information
None.
7.26 FCS_ERR
Description
The FCS_ERR is an alarm indicating that errors occur in the verification of the frame check
sequence (FCS). This alarm occurs if errors occur when a board performs FCS verification of
the received GFP frames.
NOTE
This alarm is reported when the local end receives the GFP service.
If an idle frame encapsulated in the GFP format is detected, errors occur in the verification of the FCS
because the idle frame does not contain the FCS field.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 2, Parameter Indicate the VCTRUNK number where the alarm occurs.
3 Parameter 2 indicates the most significant byte (MSB) and
Parameter 3 indicates the least significant byte (LSB).
If the possible causes do not correspond to any symptoms, or the symptoms are not listed in this topic,
handle the alarm according to the handling procedures.
Table 7-19 lists the common fault symptoms of the FCS_ERR alarm.
The alarms related to errors and optical power Cause 2: The performance of the service
and the performance events related to errors transmission line degrades.
occur in the service transmission line.
Possible Causes
The possible causes of the FCS_ERR alarm are as follows:
Procedure
Step 1 Check the alarm on the NMS. Determine the VCTRUNK ID according to the alarm
parameter. For details, see Viewing the Current Alarms in the Supporting Tasks.
If... Then...
The BIP_EXC, BIP_SD, B3_EXC, Take priority to clear the preceding alarms
B3_SD, IN_PWR_ABN, RSBBE, or performance events. Check whether the
MSBBE, HPBBE, or LPBBE occurs alarm is cleared. If the alarm persists, go to
Step Step 4.
----End
Related Information
None.
7.27 HARD_BAD
Description
The HARD_BAD is an alarm indicating that the hardware is faulty. This alarm occurs when
the board detects a hardware fault.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1 Indicates the cause of the hardware error if the board is a cross-connect and
timing board.
l Bit[0]: The board is considered faulty because the hardware automatically
detects an error.
l Bit[1]: The board is considered faulty because the software detects an error
during the routine inspection.
Indicates the slot ID of the board that reports the alarm if the board is an SCC
board.
In the case of the ATM, data switching board (excluding the N3EAS2 board),
and RPR boards, the value is always 0x01.
Indicates the cause of the fault in the case of the transparent data transmission
board, the 10G data switching board (the N3EAS2 board), OBU1 board, IF
board, and ODU.
l 0x01: The power module is working abnormally.
l 0x02: The board is installed incorrectly. (The contact between the board
and the backplane is poor. For example, the board is not inserted firmly.)
l 0x03: 38 Mbit/s system clock 1 is abnormal.
l 0x04: 38 Mbit/s system clock 2 is abnormal.
l 0x05: 2 Mbit/s clock source is abnormal.
l 0x06: The digital phase-locked loop is abnormal.
l 0x07: The 38 Mbit/s service clock is lost.
l 0x08: The bus is abnormal.
l 0x09: The board configured with the TPS protection is abnormal.
l 0x0A: The primary crystal oscillator stops oscillating.
l 0x0B: The frequency offset of the primary crystal oscillator is excessive.
l 0x0C: The secondary crystal oscillator stops oscillating.
l 0x0D: The processor (CPU/DSP/coprocessor) is faulty.
l 0x0E: The storage components are faulty.
l 0x0F: The programmable logic device is faulty.
l 0x10: The SDH components are faulty.
l 0x11: The data communication components are faulty.
l 0x12: The clock components are faulty.
l 0x13: The interface components are faulty.
l 0x14: The power components are faulty.
l 0x15: Another fault occurs.
l 0x16: The analog phase-locked loop is abnormal.
l 0x17: The 32 Mbit/s clock is unavailable.
l 0x18: The 66 Mbit/s clock is unavailable.
l 0x19: The 25 Mbit/s clock is unavailable.
Name Meaning
l 0x1A: The loop of the cross-connect chip is faulty.
l 0x1B: The 8K in-service line of the board is at low level.
For the SAN board, Parameter 1 indicates the type of hardware failure. Bit[0]:
The oscillator fails.
For the BPA/BA2 board, the alarm has no parameter.
Name Meaning
Parameter 2 Indicates the specific cause of the hardware failure detected during a hardware
check if the board is a cross-connect and timing board.
In the case of an ATM board, Parameters 2 and 3 indicate the fault type of the
board. The value 0x01 indicates that the board clock is faulty. Other values
indicate that the RAM of the service chip is faulty (in the case of only the
N1IDQ1A and N1IDL4A boards).
In the case of the transparent data transmission board, the 10G data switching
board (the N3EAS2 board), OBU1 board, IF board, and ODU, Parameter 2 has
different meanings, depending on the value of Parameter 1.
Indicates the following meanings when Parameter 1 is 0x08.
l 0x01: Bus A is abnormal.
l 0x02: Bus B is abnormal.
Parameter 2 is always 0xFF when Parameter 1 is not 0x08.
Parameters 2 and 3 indicate the cause of the fault in the case of the 10G data
switching board (the N1EAS2 board).
l 0x04: The FPGA chip is faulty.
l 0x06: The PLL is out of lock.
l 0x07: The read and write operations on a chip of the board fail.
l 0x0E: The memory is faulty.
l 0x0F: The logical component is faulty.
l 0x12: The clock is faulty.
l 0x13: The interface component is faulty.
l 0x14: The voltage is abnormal.
l 0x05, 0x08, 0x15 to 0x19: Respectively indicates that the chip on the board
is faulty.
Parameters 2 and 3 indicate the cause of the fault in the case of other data
switching boards and RPR boards.
l 0x01: The power module is working abnormally.
l 0x02: The board is installed incorrectly. (The contact between the board
and the backplane is poor. For example, the board is not inserted firmly.)
l 0x03: 38 Mbit/s system clock 1 is abnormal.
l 0x04: 38 Mbit/s system clock 2 is abnormal.
l 0x05: 2 Mbit/s clock source is abnormal.
l 0x06: The digital phase-locked loop is abnormal.
l 0x07: The 38 Mbit/s service clock is lost.
l 0x08: The bus is abnormal.
l 0x09: The board configured with the TPS protection is abnormal.
l 0x0A: The primary crystal oscillator stops oscillating.
l 0x0B: The frequency offset of the primary crystal oscillator is excessive.
Name Meaning
l 0x0C: The secondary crystal oscillator stops oscillating.
l 0x0D: The processor (CPU/DSP/coprocessor) is faulty.
l 0x0E: The storage components are faulty.
l 0x0F: The programmable logic device is faulty.
l 0x10: The SDH components are faulty.
l 0x11: The data communication components are faulty.
l 0x12: The clock components are faulty.
l 0x13: The interface components are faulty.
l 0x14: The power components are faulty.
l 0x15: Another fault occurs.
l 0x16: The analog phase-locked loop is abnormal.
l 0x17: The 32 Mbit/s clock is unavailable.
l 0x18: The 66 Mbit/s clock is unavailable.
l 0x19: The 25 Mbit/s clock is unavailable.
l 0x1A: The loop of the cross-connect chip is faulty.
l 0x1B: The 8K in-service line of the board is at low level.
Parameter 3 Indicates the specific cause of the hardware failure detected during a software
check if the board is a cross-connect and timing board.
For the SAN board, Parameter 2 indicates the type of the failed oscillator.
l 0x01: The 212M oscillator fails.
l 0x02: The 125M oscillator fails.
l 0x04: The 100M oscillator fails.
l 0x08: The 135M oscillator fails.
Parameter 4 In this case, for the GSCC. If Parameter 1 equals 0xFF, Parameter 4 has
different meanings:
l bit[0]: The software detects a hardware fault.
l bit[3]: An internal chip malfunctions.
l bit[4]: The 20M oscillator is damaged.
l bit[5]: The 25M oscillator is damaged.
l bit[6]: The first 38M clock is damaged.
l bit[7]: The second 38M clock is damaged.
If the bit corresponding to Parameter 4 is 1, the HARD_BAD alarm occurs. If
the bit corresponding to Parameter 4 is 0, the HARD_BAD alarm does not
occur. Multiple bits can take effect simultaneously.
Name Meaning
Parameter 5 In this case, for the GSCC, Parameter 5 has the following meanings:
l bit[0]: The 3.3 V power supply on the local board malfunctions.
l bit[1]: The Ethernet port between the GSCC board and the NMS is faulty.
l bit[2]: The Ethernet port for communications between the GSCC board and
other boards is faulty.
l bit[3]: The internal network interface between the active and standby
GSCC boards is faulty.
l bit[4]: The 1.8432M oscillator is damaged.
If the bit corresponding to Parameter 5 is 1, the HARD_BAD alarm occurs. If
the bit corresponding to Parameter 5 is 0, the HARD_BAD alarm does not
occur. Multiple bits can take effect simultaneously.
If this section does not describe the common fault symptom or the actual fault symptom is not contained
in the description of this section, handle the HARD_BAD alarm by following the steps provided in
Handling Procedure.
Table 7-20 lists the common fault symptoms of the HARD_BAD alarm.
Table 7-20 Common fault symptoms when the HARD_BAD alarm occurs
Common Fault Symptom Possible Cause
The SCC board reports the alarm. The slot ID in Cause 1: The service board is not in
the reported alarm is the slot ID of the service good contact with the backplane, the
board that generates the alarm. Parameter 2 - version of the board is mismatched with
Parameter 4 of the alarm are 0xFF. the version of the NE, or the service
board is faulty.
The following causes are mutually exclusive. Cause 2: The cross-connect board is not
l The SCC board reports the alarm. The slot in good contact with the backplane, or is
ID in the reported alarm is the slot ID of the faulty.
cross-connect and timing board.
l The SCC board reports the alarm. The slot
ID in the reported alarm is the slot ID of the
SCC board. Parameter 4 of the alarm is
0x40.
l The SCC board reports the alarm. The slot
ID in the reported alarm is the slot ID of the
SCC board. Parameter 4 of the alarm is
0x80.
l The cross-connect and timing board reports
the HARD_BAD alarm.
The SCC board reports the alarm. Parameters Cause 3: The SCC board is not in good
1-3 of the alarm are 0xFF, whereas parameters 4 contact with the backplane, or is faulty.
and 5 are not 0xFF.
l The service board (such as a data board) Cause 4: The power supply of the NE is
reports the HARD_BAD alarm for tens of abnormal.
seconds each time, and reports the alarm
frequently. The services are not affected
during the report of the alarm.
l The HARD_BAD alarm is reported with the
POWER_ABNORMAL alarm by the SCC
board.
Possible Causes
If the HARD_BAD alarm is reported by a board, the possible causes are as follows:
l Cause 1: The service board is not in good contact with the backplane, the version of the
board is mismatched with the version of the NE, or the service board is faulty.
l Cause 2: The cross-connect board is not in good contact with the backplane, or is faulty.
l Cause 3: The SCC board is not in good contact with the backplane, or is faulty.
l Cause 4: The power supply of the NE is abnormal.
Procedure
Step 1 Check the alarm on the NMS. Determine the slot ID of the board that reports the alarm, and
the meanings of the parameters. For details, see Viewing the Current Alarms in the
Supporting Tasks.
Step 2 Cause 1: The service board is not in good contact with the backplane, the version of the board
is mismatched with the version of the NE, or the service board is faulty.
1. Query the version of the board software and the version of the NE software, and check
whether they are matched. For details, see Querying the Board Information Report in the
Supporting Tasks.
If... Then...
They are not matched Contact Huawei technical support engineers to upgrade the
relevant software. Check whether the alarm is cleared. If the
alarm persists, go to the next step.
2. Reseat the service board indicated by Parameter 1 of the alarm. For details on how to
reseat a board, see Removing the Boards in the Installation Reference and Installing the
Boards in the Installation Reference. Check whether the alarm is cleared.
3. If the alarm persists, replace the service board. For details, see Replacing Boards Onsite
in the Supporting Tasks.
4. Check whether the alarm is cleared. If the alarm persists, go to Step Step 5.
Step 3 Cause 2: The cross-connect board is not in good contact with the backplane, or is faulty.
1. Reseat the cross-connect board. For details on how to reseat a board, see Removing the
Boards in the Installation Reference and Installing the Boards in the Installation
Reference. Check whether the alarm is cleared.
2. If the alarm persists, replace the cross-connect board. For details, see Replacing a CXL
Board in the Parts Replacement.
3. Check whether the alarm is cleared. If the alarm persists, go to Step Step 5.
Step 4 Cause 3: The SCC board is not in good contact with the backplane, or is faulty.
1. Reseat the SCC board. For details on how to reseat a board, see Removing the Boards in
the Installation Reference and Installing the Boards in the Installation Reference. Check
whether the alarm is cleared.
2. If the alarm persists, replace the SCC board. For details, see Replacing a CXL Board in
the Parts Replacement.
3. Check whether the alarm is cleared. If the alarm persists, go to Step Step 5.
2. Check whether the alarm is cleared. If the alarm persists, contact Huawei technical
support engineers to handle the alarm.
----End
Related Information
None.
7.28 HP_LOM
Description
The HP_LOM is an alarm indicating loss of multiframe in the higher order path.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
If this section does not describe the common fault symptom or the actual fault symptom is not contained
in the description of this section, handle the HP_LOM alarm by following the steps provided in
Handling Procedure.
None.
Possible Causes
The possible causes of the HP_LOM alarm are as follows:
l Cause 1: The settings of the service levels are different at both ends.
l Cause 2: The board (such as a cross-connect and timing board or a line board) is faulty,
resulting in the lost or incorrect H4 bytes.
Procedure
Step 1 Check the alarm on the NMS. Determine the ID of the path that reports the alarm according to
the alarm Parameter 1. For details, see Viewing the Current Alarms in the Supporting Tasks.
Step 2 Cause 1: The settings of the service levels are different at both ends.
1. Check the service configurations of the path that reports the alarm. As shown in Figure
7-21, if the settings of the service levels are different at both ends, reset the service levels
as required.
2. Check whether the alarm is cleared. If the alarm persists, go to Step Step 3.
Step 3 Cause 2: The board (such as a cross-connect and timing board or a line board) is faulty,
resulting in the lost or incorrect H4 bytes.
1. Perform loopbacks to locate the hardware fault on the local end or the opposite end. For
example, perform a loopback on the optical port (on a local line board) that report the
alarm.
If... Then...
The local end reports the Reset or replace the local line board. Go to the next step.
alarm
The local end does not The receive direction at the local end is running properly,
report the alarm and the transmit direction at the opposite end may be
faulty. Go to step Step 3.4.
2. Check whether the alarm is cleared. If the alarm persists, reset or replace the local cross-
connect and timing board.
NOTICE
If there is no protection cross-connect and timing board, services are interrupted if you
perform a cold reset on the working cross-connect and timing board.
3. Check whether the alarm is cleared. If the alarm persists, go to the next step.
4. Reset or replace the line board at the opposite end. Check whether the alarm is cleared. If
the alarm persists, go to the next step.
5. Reset or replace the cross-connect and timing board at the opposite end.
NOTICE
If there is no protection cross-connect and timing board, services are interrupted if you
perform a cold reset on the working cross-connect and timing board.
6. Check whether the alarm is cleared. If the alarm persists, contact Huawei technical
support engineers to handle the alarm.
----End
Related Information
None.
7.29 HP_RDI
Description
The HP_RDI is an alarm indicating a remote defect in the higher order path.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Name Meaning
If the possible causes do not correspond to any symptoms, or the symptoms are not listed in this topic,
handle the alarm according to the handling procedures.
Table 7-21 lists the common fault symptoms of the HP_RDI alarm.
l The service receive end (opposite end) Cause 1: The service receive end
terminates the higher order path overhead (opposite end) terminates the HPOH, the
(HPOH), and the opposite end reports the SF section-level or higher order alarm
alarms of the server, multiplex section, or exists.
regenerator section, such as the R_LOS,
R_LOF, and MS_AIS alarms.
l The service receive end (opposite end)
terminates the HPOH, and the opposite end
reports the alarms of the higher order path,
such as the AU_AIS, AU_LOP, and
HP_UNEQ alarms.
The receive end (opposite end) is configured Cause 2: The receive end (opposite end)
with lower order services, the opposite end is configured with lower order services,
reports the HP_TIM, HP_SLM, and HP_LOM and the HP_SLM, HP_TIM, HP_LOM
alarms, and the insertion function is enabled. alarms are reported.
The service receive end (opposite end) Cause 3: The service receive end
terminates the HPOH, and the insertion function (opposite end) terminates the HPOH,
is enabled for the alarms (such as the R_OOF or and the alarms that insert the AIS signal
B1 alarm) reported by the opposite end. As a exist.
result, the AU_AIS alarm signal is inserted and
the HP_RDI alarm is transmitted to the local
end.
Possible Causes
The possible causes of the HP_RDI alarm are as follows:
l Cause 1: The service receive end (opposite end) terminates the HPOH, the section-level
or higher order alarm exists.
West Line unit East Returned byte G1 West Line unit East
HP_RDI (b5)
Highorder Highorder
path overhead path overhead
The AIS
signal in the
overhead is Indicates
detected. termination
Indicates
regeneration
l Cause 2: The receive end (opposite end) is configured with lower order services, and the
HP_SLM, HP_TIM, HP_LOM alarms are reported.
l Cause 3: The service receive end (opposite end) terminates the HPOH, and the alarms
that insert the AIS signal exist.
Procedure
Step 1 Check the alarm on the NMS. Determine the ID of the path that reports the alarm according to
the alarm parameter. For details, see Viewing the Current Alarms in the Supporting Tasks.
Step 2 Check whether the east line unit is set to terminate the HPOH. The HP_RDI alarm is
transmitted to the local end only when the HPOH termination mode is adopted.
If... Then...
The opposite end is configured The HPOH termination mode is adopted. Go to the
with higher order services next step, and set the overhead mode to pass-
through.
1. Choose Service > SDH Circuit > SDH Trail Management from the main menu. In the
Set Trail Browse Filter Condition dialog box, set the filter condition, and then click
Filter All. The trails are displayed in the list.
2. Select a trail to be viewed, click Maintenance, and then select Overhead Termination.
The Set Overhead dialog box is displayed.
3. Browse Overhead Status of the higher order path. Set Overhead Status to
Termination or Pass-Through as required.
4. Check whether the HP_RDI alarm is cleared. If the alarm persists, go to Step Step 3.
Step 3 Cause 1: The service receive end (opposite end) terminates the HPOH, the section-level or
higher order alarm exists.
1. Check whether the section-level or higher order alarm exists, such as the R_LOS,
R_LOF, MS_AIS, AU_AIS, AU_LOP, or HP_UNEQ.
If... Then...
Step 4 Cause 2: The receive end (opposite end) is configured with lower order services, and the
HP_SLM, HP_TIM, HP_LOM alarms are reported.
1. The opposite end forcibly inserts the AIS signal, which results in the transmission of the
RDI signal to the local end. Check whether the HP_SLM, HP_TIM, or HP_LOM alarm
occurs on the opposite end, and whether the AIS insertion function is enabled.
If... Then...
2. Disable the AIS insertion function, or take priority to handle the HP_SLM, HP_TIM, or
HP_LOM alarm. For details on how to disable the AIS insertion function, see Setting
the AIS Insertion Switch in the Supporting Tasks.
3. Check whether the HP_RDI alarm is cleared. If the alarm persists, go to Step Step 5.
Step 5 Cause 3: The service receive end (opposite end) terminates the HPOH, and the alarms that
insert the AIS signal exist.
1. The opposite end forcibly inserts the AIS signal, which results in the return of the RDI
signal to the local end. Check whether the R_OOF or B1 alarm occurs on the opposite
end, and whether the AIS insertion function is enabled.
If... Then...
2. Disable the AIS insertion function, or take priority to handle the R_OOF or B1 alarm.
For details on how to disable the AIS insertion function, see Setting the AIS Insertion
Switch in the Supporting Tasks.
3. Check whether the HP_RDI alarm is cleared. If the alarm persists, contact Huawei
technical support engineers to handle the alarm.
----End
Related Information
Higher order path overheads are processed in three modes: overhead pass-through, overhead
termination, and overhead detection.
Overhead pass-through
The transmission equipment (local NE) performs the overhead detection on the higher order
path overhead that is sent by the upstream NE, and does not regenerate the higher order path
overhead but directly forwards the received higher order path overhead to the downstream
NE. Generally, the higher order path overhead of the higher order service at the VC-4 level or
higher is transparently transmitted.
Overhead termination
The transmission equipment (local NE) performs the overhead detection on the higher order
path overhead that is sent by the upstream NE, regenerates the higher order path overhead,
and forwards the higher order path overhead to the downstream NE. The value of the
overhead byte that is sent to the downstream NE is determined by the service condition of the
local NE. The higher order path overhead must be terminated at the sink that receives the
lower order service (such as the VC-3 or VC-12 service).
Overhead detection
The transmission equipment (local NE) extracts the higher order path overhead that is sent by
the upstream NE, and processes or reports alarms according to the extracted value. During the
overhead detection, the value of the higher order path overhead is not changed.
The overhead pass-through and overhead termination are as shown in Figure 7-23.
Overhead Overhead
detection detection
A Overhead pass-through B Overhead termination
Indicates
termination
Indicates
regeneration
l If the corresponding higher order path overhead of the east line board is set to pass-
through, the received overhead directly passes through the west line board and arrives at
the east line board.
l If the corresponding higher order path overhead of the east line board is set to
termination, the received overhead is terminated on the west line board and is
regenerated on the east line board.
7.30 HP_SLM
Description
The HP_SLM is an alarm indicating signal label mismatch in the higher order path. This
alarm occurs when a board detects that the actually received C2 byte is inconsistent with the
C2 byte to be received (in terms of the byte format and value) and that the actually received
C2 byte is not 0x00.
NOTE
The C2 byte is used to indicate the structures of the higher order virtual containers (VC-3, VC-4, and
VC-4-Xc) and the payload property.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
If this section does not describe the common fault symptom or the actual fault symptom is not contained
in the description of the common fault symptom, handle the HP_SLM alarm by following the steps
provided in Handling Procedure.
None.
Possible Causes
The possible causes of the HP_SLM alarm are as follows:
l Cause 1: The overhead pass-through function is enabled on the pass-through NEs. The
service type of this NE or the C2 byte to be received is set incorrectly.
l Cause 2: The overhead pass-through function is enabled on the pass-through NEs. The
service type or the C2 byte to be transmitted at the termination station is set incorrectly.
HP_SLM
A B C D
l Cause 3: The overhead pass-through function is enabled on the pass-through NEs. The
C2 byte to be transmitted on the pass-through NE is set incorrectly.
HP_SLM
A B C D
Procedure
Step 1 Check the alarm on the NMS. Determine the ID of the path that reports the alarm according to
the alarm parameter. For details, see Viewing the Current Alarms in the Supporting Tasks.
Step 2 Cause 1: The overhead pass-through function is enabled on the pass-through NEs. The service
type of this NE or the C2 byte to be received is set incorrectly.
1. Check whether the service type configured at the local NE matches with the value of the
C2 byte to be received. If not, reset the C2 byte to be received or change the service type.
2. Check whether the alarm is cleared. If the alarm persists, go to Step Step 3.
Step 3 Cause 2: The overhead pass-through function is enabled on the pass-through NEs. The service
type or the C2 byte to be transmitted at the termination station is set incorrectly.
1. According to the signal flow, query the upstream NE about the NE that transmits the
lower order service. The source board on the NE is the source end that sends the C2 byte.
In this manner, you can obtain which NE transmits the regenerated C2 byte to the local
NE after terminating the higher order path overhead. If the overhead pass-through
function is enabled on the intermediate NEs, the intermediate NEs transparently transmit
the C2 byte. As shown in Figure 7-24, NE A terminates the overhead, and NE B and NE
C transparently transmit the C2 byte.
2. Check whether the service type configured at the termination station matches with the
value of the C2 byte to be transmitted on the NE. If not, reset the C2 byte to be
transmitted or change the service type. For details of resetting the C2 byte, see
Configuring C2 Byte in the Supporting Tasks.
3. Check whether the alarm is cleared. If the alarm persists, go to Step Step 4.
Step 4 Cause 3: The overhead pass-through function is enabled on the pass-through NEs. The C2
byte to be transmitted on the pass-through NE is set incorrectly.
1. According to the signal flow, check whether the pass-through NEs on the service path
are set to terminate the overhead. As shown in Figure 7-25, NE A transmits the lower
order service, and thus is the termination station. NE B and NE C pass through the
service that is transmitted from NE A to NE D, and thus are pass-through NEs.
2. According to the actual service type, reset the C2 byte that passes through the NE, or set
the overhead mode to pass-through. For details of resetting the C2 byte, see Configuring
C2 Byte in the Supporting Tasks. For details of setting the overhead mode, see the
following steps.
a. Choose Service > SDH Circuit > SDH Trail Management from the main menu.
In the Set Trail Browse Filter Condition dialog box, set the filter condition, and
then click Filter All. The trails are displayed in the list.
b. Select a trail to be viewed, click Maintenance, and then select Overhead
Termination. The Set Overhead dialog box is displayed.
c. Browse Overhead Status of the higher order path. Set Overhead Status to
Termination or Pass-Through as required.
3. Check whether the alarm is cleared. If the alarm persists, contact Huawei technical
support engineers to handle the alarm.
----End
Related Information
Higher order path overheads are processed in three modes: overhead pass-through, overhead
termination, and overhead detection.
Overhead pass-through
The transmission equipment (local NE) performs the overhead detection on the higher order
path overhead that is sent by the upstream NE, and does not regenerate the higher order path
overhead but directly forwards the received higher order path overhead to the downstream
NE. Generally, the higher order path overhead of the higher order service at the VC-4 level or
higher is transparently transmitted.
Overhead termination
The transmission equipment (local NE) performs the overhead detection on the higher order
path overhead that is sent by the upstream NE, regenerates the higher order path overhead,
and forwards the higher order path overhead to the downstream NE. The value of the
overhead byte that is sent to the downstream NE is determined by the service condition of the
local NE. The higher order path overhead must be terminated at the sink that receives the
lower order service (such as the VC-3 or VC-12 service).
Overhead detection
The transmission equipment (local NE) extracts the higher order path overhead that is sent by
the upstream NE, and processes or reports alarms according to the extracted value. During the
overhead detection, the value of the higher order path overhead is not changed.
The overhead pass-through and overhead termination are as shown in Figure 7-26.
Overhead Overhead
detection detection
A Overhead pass-through B Overhead termination
Indicates
termination
Indicates
regeneration
l If the corresponding higher order path overhead of the east line board is set to pass-
through, the received overhead directly passes through the west line board and arrives at
the east line board.
l If the corresponding higher order path overhead of the east line board is set to
termination, the received overhead is terminated on the west line board and is
regenerated on the east line board.
7.31 HP_TIM
Description
The HP_TIM is an alarm indicating that the higher order path trace identifier is mismatched.
This alarm occurs when the actually received J1 byte is different from the J1 byte to be
received (in terms of the byte format and value).
NOTE
This byte is used to repetitively transmit a path access point identifier (APID) so that the receive end can
check whether the channel is correctly connected to the specified transmit end.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
If the possible causes do not correspond to any symptoms, or the symptoms are not listed in this topic,
handle the alarm according to the handling procedures.
None.
Possible Causes
The possible causes of the HP_TIM alarm are as follows:
l Cause 1: The overhead pass-through function is enabled on the pass-through NEs. The J1
byte to be received on the local NE is set incorrectly.
l Cause 2: The overhead pass-through function is enabled on the pass-through NEs. The J1
byte to be transmitted or service cross-connection on the termination station is set
incorrectly.
HP_TIM
A B C D
l Cause 3: The overhead termination function is enabled on the pass-through NEs. The J1
byte to be transmitted on the pass-through NE is set incorrectly.
HP_TIM
A B C D
Procedure
Step 1 Check the alarm on the NMS. Determine the ID of the path that reports the alarm according to
the alarm parameter. For details, see Viewing the Current Alarms in the Supporting Tasks.
Step 2 Cause 1: The overhead pass-through function is enabled on the pass-through NEs. The J1 byte
to be received on the local NE is set incorrectly.
1. Check whether the J1 byte to be received on the local NE meets the actual requirement.
If not, reset the J1 byte according to the related recommendation. For details, see
Configuring Trace Byte in the Supporting Tasks.
NOTE
If the Ethernet boards are connected with each other, you need to correctly set the J1 byte to be
received and the J1 byte to be transmitted on the SDH path.
2. Check whether the alarm is cleared. If the alarm persists, go to Step Step 3.
Step 3 Cause 2: The overhead pass-through function is enabled on the pass-through NEs. The J1 byte
to be transmitted or service cross-connection on the termination station is set incorrectly.
1. Query the upstream NE about the NE that transmits the lower order service. The source
board on the NE is the source end that sends the J1 byte. In this manner, you can obtain
which NE transmits the regenerated J1 byte to the local NE after terminating the higher
order path overhead. As shown in Figure 7-27, NE A terminates the overhead, and NE B
and NE C transparently transmit the J1 byte.
2. Check whether the J1 byte to be transmitted at the termination station meets the actual
requirement. If not, reset the J1 byte according to the related recommendation.
3. Check whether the alarm is cleared. If the alarm persists, check whether the service
cross-connection on the termination station is set correctly. If not, reset the service cross-
connection.
4. Check whether the alarm is cleared. If the alarm persists, go to Step Step 4.
Step 4 Cause 3: The overhead termination function is enabled on the pass-through NEs. The J1 byte
to be transmitted on the pass-through NE is set incorrectly.
1. Check whether the pass-through NE on the service path is set to terminate the overhead.
As shown in Figure 7-28, NE A transmits the lower order service, and thus is a
termination station. NE B and NE C pass through the service that is transmitted from NE
A to NE D, and thus are pass-through NEs.
2. According to the actual service type, reset the J1 byte that passes through the NE, or set
the overhead mode to pass-through. For details of resetting the J1 byte, see Configuring
C2 Byte in the Supporting Tasks. For details of setting the overhead mode, see the
following steps.
a. Choose Service > SDH Circuit > SDH Trail Management from the main menu.
In the Set Trail Browse Filter Condition dialog box, set the filter condition, and
then click Filter All. The trails are displayed in the list.
b. Select a trail to be viewed, click Maintenance, and then select Overhead
Termination. The Set Overhead dialog box is displayed.
c. Browse Overhead Status of the higher order path. Set Overhead Status to
Termination or Pass-Through as required.
3. Check whether the alarm is cleared. If the alarm persists, contact Huawei technical
support engineers to handle the alarm.
----End
Related Information
Higher order path overheads are processed in three modes: overhead pass-through, overhead
termination, and overhead detection.
Overhead pass-through
The transmission equipment (local NE) performs the overhead detection on the higher order
path overhead that is sent by the upstream NE, and does not regenerate the higher order path
overhead but directly forwards the received higher order path overhead to the downstream
NE. Generally, the higher order path overhead of the higher order service at the VC-4 level or
higher is transparently transmitted.
Overhead termination
The transmission equipment (local NE) performs the overhead detection on the higher order
path overhead that is sent by the upstream NE, regenerates the higher order path overhead,
and forwards the higher order path overhead to the downstream NE. The value of the
overhead byte that is sent to the downstream NE is determined by the service condition of the
local NE. The higher order path overhead must be terminated at the sink that receives the
lower order service (such as the VC-3 or VC-12 service).
Overhead detection
The transmission equipment (local NE) extracts the higher order path overhead that is sent by
the upstream NE, and processes or reports alarms according to the extracted value. During the
overhead detection, the value of the higher order path overhead is not changed.
The overhead pass-through and overhead termination are as shown in Figure 7-29.
Overhead Overhead
detection detection
A Overhead pass-through B Overhead termination
Indicates
termination
Indicates
regeneration
l If the corresponding higher order path overhead of the east line board is set to pass-
through, the received overhead directly passes through the west line board and arrives at
the east line board.
l If the corresponding higher order path overhead of the east line board is set to
termination, the received overhead is terminated on the west line board and is
regenerated on the east line board.
7.32 HP_UNEQ
Description
The HP_UNEQ is an alarm indicating that the higher order path is unequipped. The actually
received C2 byte is 0x00.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
If the possible causes do not correspond to any symptoms, or the symptoms are not listed in this topic,
handle the alarm according to the handling procedures.
Table 7-22 lists the common fault symptoms of the HP_UNEQ alarm.
The corresponding channels on the upstream Cause 1: The upstream NEs are not
NEs report the HP_UNEQ alarm. configured with services.
Possible Causes
The possible causes of the HP_UNEQ alarms are as follows:
Unequipped
HP_UNEQ HP_UNEQ HP_UNEQ
services
A B C D
l Cause 2: The C2 byte to be transmitted on the termination station is 0x00, and the pass-
through NEs are set to pass through the overhead.
C2=0X00 HP_UNEQ
A B C D
l Cause 3: The C2 to be transmitted at the termination station is not 0x00, the pass-through
NE is set to terminate the overhead, and the C2 byte to be transmitted is set to 0x00.
C2=0X00 HP_UNEQ
A B C D
Procedure
Step 1 Check the alarm on the NMS. Determine the ID of the path that reports the alarm according to
the alarm parameter. For details, see Viewing the Current Alarms in the Supporting Tasks.
Step 2 Cause 1: The upstream NEs are not configured with services.
1. Check whether the corresponding channel on the opposite NE is configured with
services. As shown in Figure 7-30, if the corresponding channel of NE B reports the
HP_UNEQ alarm, the opposite end is NE A.
If... Then...
The NE at the opposite The NE at the opposite end transmits the unequipped
end is not configured with service, the NE at the local end reports the HP_UNEQ
services alarm. After the NE at the opposite end is configured
with services correctly, check whether the alarm is
cleared. For details, see the Configuration Guide. If the
alarm persists, go to the next step.
2. Check whether the corresponding channel of the upstream NEs reports the HP_UNEQ
alarm.
If... Then...
3. Query the source end that is not configured with services. After the NE is configured
with services correctly, check whether the alarm is cleared. If the alarm persists, go to
Step Step 3.
Step 3 Cause 2: The C2 byte to be transmitted on the termination station is 0x00, and the pass-
through NEs are set to pass through the overhead.
1. According to the signal flow, query the upstream NE about the NE that transmits the
lower order service. The source board on the NE is the source end that sends the C2 byte.
In this manner, you can obtain which NE transmits the C2 byte to the local NE after
terminating the higher order path overhead. If the overhead pass-through function is
enabled on the intermediate NEs, the intermediate NEs transparently transmits the C2
byte. As shown in Figure 7-31, NE A terminates the overhead, and NE B and NE C
transparently transmit the C2 byte.
2. Check whether the C2 byte to be transmitted at the termination station is 0x00.
If... Then...
The C2 byte to be transmitted Reset the C2 byte according to the actual service
is 0x00 type. For details, see Configuring C2 Byte in the
Supporting Tasks. Check whether the alarm is
cleared. If the alarm persists, go to Step Step 4.
Step 4 Cause 3: The C2 to be transmitted at the termination station is not 0x00, the pass-through NE
is set to terminate the overhead, and the C2 byte to be transmitted is set to 0x00.
1. According to the signal flow, check whether the pass-through NE on the service path is
set to terminate the overhead, and the C2 byte to be transmitted is 0x00. As shown in
Figure 7-32, NE A transmits the lower order service, and thus is a termination station.
NE B and NE C pass through the service that is transmitted from NE A to NE D, and
thus are pass-through NEs.
2. According to the actual service type, reset the C2 byte that passes through the NE, or set
the overhead mode to pass-through. For details of resetting the C2 byte, see Configuring
C2 Byte in the Supporting Tasks. For details of setting the overhead mode, see the
following steps.
a. Choose Service > SDH Circuit > SDH Trail Management from the main menu.
In the Set Trail Browse Filter Condition dialog box, set the filter condition, and
then click Filter All. The trails are displayed in the list.
b. Select a trail to be viewed, click Maintenance, and then select Overhead
Termination. The Set Overhead dialog box is displayed.
c. Browse Overhead Status of the higher order path. Set Overhead Status to
Termination or Pass-Through as required.
3. Check whether the alarm is cleared. If the alarm persists, contact Huawei technical
support engineers to handle the alarm.
----End
Related Information
Higher order path overheads are processed in three modes: overhead pass-through, overhead
termination, and overhead detection.
Overhead pass-through
The transmission equipment (local NE) performs the overhead detection on the higher order
path overhead that is sent by the upstream NE, and does not regenerate the higher order path
overhead but directly forwards the received higher order path overhead to the downstream
NE. Generally, the higher order path overhead of the higher order service at the VC-4 level or
higher is transparently transmitted.
Overhead termination
The transmission equipment (local NE) performs the overhead detection on the higher order
path overhead that is sent by the upstream NE, regenerates the higher order path overhead,
and forwards the higher order path overhead to the downstream NE. The value of the
overhead byte that is sent to the downstream NE is determined by the service condition of the
local NE. The higher order path overhead must be terminated at the sink that receives the
lower order service (such as the VC-3 or VC-12 service).
Overhead detection
The transmission equipment (local NE) extracts the higher order path overhead that is sent by
the upstream NE, and processes or reports alarms according to the extracted value. During the
overhead detection, the value of the higher order path overhead is not changed.
The overhead pass-through and overhead termination are as shown in Figure 7-33.
Overhead Overhead
detection detection
A Overhead pass-through B Overhead termination
Indicates
termination
Indicates
regeneration
l If the corresponding higher order path overhead of the east line board is set to pass-
through, the received overhead directly passes through the west line board and arrives at
the east line board.
l If the corresponding higher order path overhead of the east line board is set to
termination, the received overhead is terminated on the west line board and is
regenerated on the east line board.
7.33 HSC_UNAVAIL
Description
The HSC_UNAVAIL is an alarm indicating that the active/standby switching function failure.
This alarm is reported by the protection board when the active/standby switching function
cannot be performed if the protection board is configured.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
Name Meaning
If this section does not describe the common fault symptom or if the actual fault symptom is not
contained in the description of this section, handle the HSC_UNAVAIL alarm by following the steps
provided in Handling Procedure.
Table 7-23 lists the common fault symptoms of the HSC_UNAVAIL alarm.
Parameter 1 = 0x02: Only certain service boards Cause 5: The service board is faulty.
or no service boards report the TR_LOC or
T_LOSEX alarm.
If the equipment contains an extended subrack,
the XCE board does not report the BUS_ERR
alarm.
The SCC board resets frequently, and the cross- Cause 3: The NE software version of a
connect board reports the HSC_UNAVAIL board does not match the hardware
alarm frequently. version.
Possible Causes
The possible causes of the HSC_UNAVAIL alarms are as follows:
l Cause 1: After a successful cold reset on the protection cross-connect board, the elapsed
time is less than five minutes.
l Cause 2: The versions of the working and protection cross-connect boards are different
from each other.
l Cause 3: The NE software version of a board does not match the hardware version.
l Cause 4 The cross-connect board is faulty.
l Cause 5: The service board is faulty.
l Cause 6: The backplane of the subrack is faulty.
Procedure
Step 1 Check the alarm on the NMS, and then determine the cause of the alarm according to the
alarm parameters. For details, see Viewing the Current Alarms in the Supporting Tasks.
Step 2 Cause 1: After a successful cold reset on the protection cross-connect board, the elapsed time
is less than five minutes.
1. The alarm need not be handled. The alarm reminds you not to perform a cold reset on the
working board or not to reseat the working board at this time so that the services are not
affected. After being powered on and started, the protection board needs to maintain
synchronization with the working board. If no exception occurs, wait five to eight
minutes until the board is reset successfully.
2. Check whether the alarm is cleared. If the alarm persists, go to Step Step 3.
Step 3 Cause 2: The versions of the working and protection cross-connect boards are different from
each other. Cause 3: The NE software version of a board does not match the hardware
version.
l Check whether the software versions of the working and protection cross-connect boards
match each other. If the software versions do not match each other, the HSC_UNAVAIL
alarm is reported.
l Check whether the NE software version of the cross-connect board that reports the alarm
matches the hardware version. For example, if the NE software is of the Q1 version and
the hardware is of the Q2 version, the HSC_UNAVAIL alarm is reported.
1. According to the alarm parameters, if a service board detects the bad state of the
protection cross-connect board, query the alarms of each service board on the NE.
If... Then...
All the service boards report the TR_LOC or T_LOSEX Proceed to the next step.
alarm
2. For details on how to check a software version, see Querying the Board Information
Report in the Supporting Tasks. If the versions are different from each other, contact
Huawei technical support engineers to update the corresponding software.
3. Check whether the alarm is cleared. If the alarm persists, go to Step Step 4.
Step 4 Cause 4 The cross-connect board is faulty.
1. Replace the cross-connect board that reports the alarm. For details, see Replacing a CXL
Board in the Parts Replacement. Check whether the alarm is cleared.
2. If the alarm persists, go to Step Step 6.
Step 5 Cause 5: The service board is faulty.
1. Replace the service board that reports the TR_LOC or T_LOSEX alarm. For details, see
Replacing Boards Onsite in the Supporting Tasks. Check whether the TR_LOC or
T_LOSEX alarm is cleared.
2. If the TR_LOC or T_LOSEX alarm persists, go to Step 6.
Step 6 Cause 6: The backplane of the subrack is faulty.
1. Check whether certain pins on the backplane of the subrack are bent. If certain pins on
the backplane of the subrack are bent, replace the backplane of the subrack, and then
check whether the alarm is cleared.
2. If the alarm persists, contact Huawei technical support engineers to handle the alarm.
----End
Related Information
None.
7.34 IN_PWR_ABN
Description
The IN_PWR_LOW is an alarm indicating that the input optical power is abnormal.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
If the possible causes do not correspond to any symptoms, or the symptoms are not listed in this topic,
handle the alarm according to the handling procedures.
None.
Possible Causes
The possible causes of the IN_PWR_ABN alarm are as follows:
l Cause 1: The threshold of the optical power is not set properly.
l Cause 2: The fiber connector is loose or dirty.
l Cause 3: The board at the local end is faulty.
l Cause 4: The board at the opposite end is faulty.
Procedure
Step 1 Cause 1: The threshold of the optical power is not set properly.
1. Query the type of the optical module that reports the alarm. You can obtain the
manufacturer information about the optical module by referring to Querying the Board
Manufacturer Information Report in the Supporting Tasks or Bar Code in the Hardware
Description.
2. Check whether the optical power threshold is set properly. For details, see the Querying
the Optical Power in the Supporting Tasks. If the threshold is set improperly, change
Input Power Reference Lower Threshold and Input Power Reference Upper
Threshold according to the receiver sensitivity or overload threshold of the board. For
details on the optical power of the board, see the Specifications of the Boards in the
Technical Specifications Reference.
3. Check whether the alarm is cleared. If the alarm persists, go to Step Step 2.
If... Then...
2. Query whether the output optical power of the board that reports the alarm on the local
end is within the normal range.
If... Then...
3. Query whether the input optical power of the board that reports the alarm on the local
end is within the normal range.
If... Then...
The input optical power is Repeat the following step to check the fiber
abnormal jumpers and fiber connectors at both ends in order.
4. Check whether the bend radius of the fiber jumper is within the normal range. If the bend
radius is less than 6 cm, roll the fiber jumper again. Check whether the alarm is cleared.
5. If the alarm persists, check whether the fiber connector is loose. Ensure that the fiber
connector is firmly connected. Then, check whether the alarm is cleared.
6. If the alarm persists, check whether the fiber connector is dirty. For details on how to
check the fiber connector, see Checking the Optical Fiber Connector in the Supporting
Tasks. For details on how to clean the fiber connectors, see the Supporting Tasks.
----End
Related Information
None.
7.35 IN_PWR_HIGH
Description
The IN_PWR_HIGH is an alarm indicating that the input optical power is very high. This
alarm occurs when a board detects that the actual input optical power is higher than the upper
threshold of the input power reference value.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1 Indicates the actual number of the optical interface on the board that
reports the alarm.
For example, Parameter 1 = 0x01. This parameter indicates that the
alarm is reported by port 1 of the related board.
If the possible causes do not correspond to any symptoms, or the symptoms are not listed in this topic,
handle the alarm according to the handling procedures.
None.
Possible Causes
The possible causes of the IN_PWR_ABN alarm are as follows:
l Cause 1: The threshold of the optical power is not set properly.
l Cause 2: The transmit power of the opposite station is very high.
l Cause 3: The model of the selected optical module is incorrect.
Procedure
Step 1 Cause 1: The threshold of the optical power is not set properly.
1. Query the type of the optical module that reports the alarm. You can obtain the
manufacturer information about the optical module by referring to Querying the Board
Manufacturer Information Report in the Supporting Tasks or Bar Code in the Hardware
Description.
2. Check whether the optical power threshold is set properly. For details, see the Querying
the Optical Power in the Supporting Tasks. If the threshold is set improperly, change
Input Power Reference Lower Threshold and Input Power Reference Upper
Threshold according to the receiver sensitivity or overload threshold of the board. For
details on the optical power of the board, see the Specifications of the Boards in the
Technical Specifications Reference.
3. Check whether the alarm is cleared. If the alarm persists, go to Step Step 2.
Step 2 Cause 2: The transmit power of the opposite station is very high.
1. Check whether the output optical power of the opposite board that is connected to the
board that reports the alarm is very high, or whether the opposite board reports the
OUT_PWR_HIGH alarm. For details on the optical power of the board, see
Specifications of the Boards in the Technical Specifications Reference. For details of the
operation, see Querying the Optical Power in the Supporting Tasks.
If... Then...
2. If the board supports the pluggable optical module, replace the pluggable optical module.
For details, see Replacing a Pluggable Optical Module in the Parts Replacement.
Otherwise, replace the faulty board. For details, see Replacing Boards Onsite in the
Supporting Tasks.
3. Check whether the alarm is cleared. If the alarm persists, go to Step Step 3.
Step 3 Cause 3: The model of the selected optical module is incorrect.
1. Check whether the type of the optical module on the board is proper according to the
transmission distance. For details on the mapping relationship between the optical
module type and the transmission distance, refer to Pluggable Optical Module in the
Hardware Descripition.
2. If the type is incorrect, replace the optical module or board. If the board supports the
pluggable optical module, replace the pluggable optical module. For details, see the
Replacing a Pluggable Optical Module in the Parts Replacement. Otherwise, replace the
faulty board. For details, see the Replacing Boards Onsite in the Supporting Tasks.
3. Check whether the alarm is cleared. If the alarm persists, contact Huawei technical
support engineers to handle the alarm.
----End
Related Information
None.
7.36 IN_PWR_LOW
Description
The IN_PWR_LOW is an alarm indicating that the input optical power is very low. This
alarm occurs when a board detects that the actual input optical power is lower than the lower
threshold of the input power reference value.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
Name Meaning
Parameter 1 Indicates the actual number of the optical interface on the board that
reports the alarm.
For example, Parameter 1 = 0x01. This parameter indicates that the
alarm is reported by port 1 of the related board.
If the possible causes do not correspond to any symptoms, or the symptoms are not listed in this topic,
handle the alarm according to the handling procedures.
None.
Possible Causes
The possible causes of the IN_PWR_LOW alarm are as follows:
l Cause 1: The threshold of the optical power is not set properly.
l Cause 2: The fiber connector is loose or dirty.
l Cause 3: The transmit power of the opposite station is very low.
l Cause 4: The model of the selected optical module is incorrect.
Procedure
Step 1 Cause 1: The threshold of the optical power is not set properly.
1. Query the type of the optical module that reports the alarm. You can obtain the
manufacturer information about the optical module by referring to Querying the Board
Manufacturer Information Report in the Supporting Tasks or Bar Code in the Hardware
Description.
2. Check whether the optical power threshold is set properly. For details, see the Querying
the Optical Power in the Supporting Tasks. If the threshold is set improperly, change
Input Power Reference Lower Threshold and Input Power Reference Upper
Threshold according to the receiver sensitivity or overload threshold of the board. For
details on the optical power of the board, see the Specifications of the Boards in the
Technical Specifications Reference.
3. Check whether the alarm is cleared. If the alarm persists, go to Step Step 2.
Step 2 Cause 2: The fiber connector is loose or dirty.
1. Check whether the output optical power of the opposite board that is connected to the
board that reports the alarm is very low, or whether the opposite board reports the
OUT_PWR_LOW alarm. For details on the optical power of the board, see
Specifications of the Boards in the Technical Specifications Reference. For details of the
operation, see Querying the Optical Power in the Supporting Tasks.
If... Then...
The output optical power is Repeat the following steps to check the fiber
normal jumpers and fiber connectors at both ends.
2. Check whether the bend radius of the fiber jumper is within the normal range. If the bend
radius is less than 6 cm, roll the fiber jumper again. Check whether the alarm is cleared.
3. If the alarm persists, check whether the fiber connector is loose. Ensure that the fiber
connector is firmly connected. Then, check whether the alarm is cleared.
4. If the alarm persists, check whether the fiber connector is dirty. For details on how to
check the fiber connector, see Checking the Optical Fiber Connector in the Supporting
Tasks. For details on how to clean the fiber connectors, see the Supporting Tasks.
Using the Fiber Cleaner to Clean the Optical Fiber Connector
Using the Lens Tissue to Clean the Optical Fiber Connector
Using the Dust-Free Cotton Bar to Clean the Optical Fiber Adapter
5. Check whether the alarm is cleared. If the alarm persists, go to Step Step 4.
Step 3 Cause 3: The transmit power of the opposite station is very low.
1. If the board supports the pluggable optical module, replace the pluggable optical module.
For details, see Replacing a Pluggable Optical Module in the Parts Replacement.
Otherwise, replace the faulty board. For details, see Replacing Boards Onsite in the
Supporting Tasks.
2. Check whether the alarm is cleared. If the alarm persists, go to Step Step 4.
----End
Related Information
None.
7.37 J0_MM
Description
The J0_MM is an alarm indicating that the trace identifier is mismatched. This alarm occurs
when a line board detects that the received J0 byte at the corresponding optical interface is
different from the J0 byte to be received (in terms of the byte format and value).
NOTE
The J0 byte is used to repeatedly transmit the section access point identifiers. In this manner, the receive
end can check whether it is continuously connected to the specified transmit end.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
If the possible causes do not correspond to any symptoms, or the symptoms are not listed in this topic,
handle the alarm according to the handling procedures.
None.
Possible Causes
The possible causes of the J0_MM alarm are as follows:
Cause 1: The J0 byte to be transmitted at the opposite end is different from the J0 byte to be
received at the local end.
M R S S R M
... S S P P S S ...
T T I I T T
Multiplex section
Procedure
Step 1 Cause 1: The J0 byte to be transmitted at the opposite end is different from the J0 byte to be
received at the local end.
1. Query whether the J0 byte to be received at the local end is the same as the J0 byte to be
transmitted at the opposite end. As shown in Figure 7-34, the opposite NE is NE1. If
not, reset the J0 byte. For details, see Configuring Trace Byte in the Supporting Tasks.
----End
Related Information
None.
7.38 LAG_FAIL
Description
The LAG_FAIL is an alarm indicating the failure of a link aggregation group (LAG). This
alarm is reported when all the ports in the LAG are faulty.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
Name Meaning
Parameter 2, Parameter 3 Indicates the number of the main port in the faulty LAG.
Parameter 2 is the higher byte, and Parameter 3 is the lower byte.
If this section does not describe the common fault symptom or the actual fault symptom is not contained
in the description of this section, handle the LAG_FAIL alarm by following the steps provided in
Handling Procedure.
None.
Possible Causes
The possible causes of the LAG_FAIL alarm are as follows:
Procedure
Step 1 Check the alarm on the NMS, determine the board that reports the alarm, and then determine
the number of the port on the board according to the alarm parameter. For details, see Viewing
the Current Alarms in the Supporting Tasks.
Step 2 Cause 1: All the ports in a LAG are disabled.
1. Check whether all the ports in the LAG are enabled. If these ports are disabled, set them
to be enabled. For details, see Configuring the External Port on an Ethernet Board in the
Feature Description.
2. Check whether the alarm is cleared. If the alarm persists, go to Step Step 3.
Step 3 Cause 2: All the fibers or cables in a LAG are faulty.
1. Check whether the fibers or cables on all the ports in the LAG are connected properly. If
the fibers or cables are connected incorrectly or faulty, reconnect or replace the fibers or
cables.
2. Check whether the alarm is cleared. If the alarm persists, go to Step Step 4.
If... Then...
----End
Related Information
None.
7.39 LAG_PORT_FAIL
Description
The LAG_PORT_FAIL is an alarm indicating that a port in a LAG is unavailable. This alarm
is reported if a port in the LAG is unavailable.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Name Meaning
Parameter 2, The values are always 0x01, and the two parameters are
Parameter 3 meaningless.
If this section does not describe the common fault symptom or the actual fault symptom is not contained
in the description of this section, handle the LAG_PORT_FAIL alarm by following the steps provided in
Handling Procedure.
Table 7-24 lists the common fault symptoms of the LAG_PORT_FAIL alarm.
Possible Causes
The possible causes of the LAG_PORT_FAIL alarm are as follows:
Procedure
Step 1 Check the alarm on the NMS, and determine the board and port where the alarm is generated.
Then, select the corresponding handling procedure according to the cause presented by the
alarm parameter. For details, see Viewing the Current Alarms in the Supporting Tasks.
If... Then...
Parameter 4 = 0x05 Contact Huawei technical support engineers to determine the cause
and handle the alarm according to the networking environment.
Step 2 Cause 1: The port is not enabled. Cause 2: The link connected to the port is faulty.
1. Check whether the port in the LAG is enabled. If the port is disabled, set it to be enabled.
For details, see Configuring the External Port on an Ethernet Board in the Feature
Description.
2. Check whether the alarm is cleared. If the alarm persists, check the link state of the port.
For example, check whether the fiber or cable is connected properly. If the fiber or cable
connection is loose or faulty, reconnect or replace the fiber or cable.
3. Check whether the alarm is cleared. If the alarm persists, contact Huawei technical
support engineers to handle the alarm.
Step 3 Cause 3: The port is in half-duplex mode.
1. Check the working mode of the port in the LAG. If the negotiation result of the Ethernet
port is the half-duplex mode, certain packets are discarded in the case of light traffic
between the ports of the interconnected equipment, and the services are interrupted in the
case of heavy traffic. If the port is in half-duplex mode, change the working mode of the
port to the auto-negotiation or full-duplex mode. For details, see Configuring the
External Port on an Ethernet Board in the Feature Description.
2. Check whether the alarm is cleared. If the alarm persists, contact Huawei technical
support engineers to handle the alarm.
Step 4 Cause 4: The port fails to receive LCAP packets.
1. Check whether the LAG is configured at the opposite end, and check whether the port
that is connected to the faulty port is added to the LAG at the opposite end.
If the port is configured into an LAG protection group, see Configuring an Ethernet
LAG in the Feature Description for details.
If the port is configured into a DLAG protection group, see Configuring an Ethernet
DLAG in the Feature Description for details.
2. Check whether the alarm is cleared. If the alarm persists, contact Huawei technical
support engineers to handle the alarm.
Step 5 Cause 5: The port detects a self-loop.
1. As shown in Figure 7-35, check the cause of the self-loop on the port.
If... Then...
The loopback at the Cancel the setting of the loopback at the PHY/MAC
PHY/MAC layer is set for layer manually. For details, see the Setting a loopback
the port (port 1) on an Ethernet port part in the Supporting Tasks.
Setting a Loopback on an SDH Optical Interface
Board
Setting a Loopback on a PDH Electrical Interface
Board
Setting a Loopback on an Ethernet Port
Setting a Loopback on an ATM Board Port
Setting Loopback on the IF Board
A loopback network is Release the loop of the LAN, or disconnect the ports
generated on the ports from the LAN.
(ports 5 and 6)
3. Check whether the alarm is cleared. If the alarm persists, contact Huawei technical
support engineers to handle the alarm.
----End
Related Information
None.
7.40 LINK_ERR
Description
The LINK_ERR is an alarm indicating an incorrect data link. This alarm is reported when an
Ethernet connection is incorrect and the port negotiation fails.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1 Indicates the number of the Ethernet port where the LINK_ERR
alarm is reported.
If this section does not describe the common fault symptom or the actual fault symptom is not contained
in the description of this section, handle the LINK_ERR alarm by following the steps provided in
Handling Procedure.
None.
Possible Causes
The possible causes of the LINK_ERR alarm are as follows:
l Cause 1: The negotiation fails because the transmit port and receive port work in
different modes.
l Cause 2: The optical modules on the Ethernet boards at both ends are of different types.
The types of these optical modules do not match the types of the connected fibers.
l Cause 3: The fibers or cables that are connected to the Ethernet ports are faulty.
l Cause 4: A board is faulty.
Procedure
Step 1 Check the alarm on the NMS, and determine the board where the alarm is generated. Then,
determine the number of the port on the board according to Parameter 1. For details, see
Viewing the Current Alarms in the Supporting Tasks.
Step 2 Cause 1: The negotiation fails because the transmit port and receive port work in different
modes.
1. Check whether the working mode of the port at the local end is different from the
working mode of the port at the opposite end. For example, the working mode at one end
is set to the auto-negotiation mode, and the working mode at the other end is set to the
non-auto-negotiation mode. If the working modes of the ports at both ends are different
from each other, set them to be the same. For details, see Configuring the External Port
on an Ethernet Board in the Feature Description.
2. Check whether the alarm is cleared. If the alarm persists, go to Step Step 3.
Step 3 Cause 2: The optical modules on the Ethernet boards at both ends are of different types. The
types of these optical modules do not match the types of the connected fibers.
1. Check whether the optical modules on the Ethernet boards at both ends are of the same
type. Generally, a single-mode optical module is not interconnected with a multi-mode
optical module. Otherwise, the services may be unavailable. If the optical modules on the
Ethernet boards at both ends are of different types, replace the Ethernet boards and
ensure that the types of the optical modules at both ends match each other. If the board
supports the pluggable optical module, replace the optical module. For details, see
Replacing a Pluggable Optical Module in the Parts Replacement.
2. Check whether the alarm is cleared. If the alarm persists, check whether the optical
module type matches the fiber type. If a multi-mode optical module is connected to a
single-mode fiber, the services may be unavailable. If the optical module type is different
from the fiber type, replace the board, optical module, or fiber. Ensure that the optical
module type matches the fiber type.
3. Check whether the alarm is cleared. If the alarm persists, go to Step Step 4.
Step 4 Cause 3: The fibers or cables that are connected to the Ethernet ports are faulty.
1. Check whether the fibers or cables are connected properly to the Ethernet ports. If the
fibers or cables are connected incorrectly or faulty, reconnect or replace the fibers or
cables.
2. Check whether the alarm is cleared. If the alarm persists, go to Step Step 5.
If... Then...
The alarm is cleared Replace the board at the opposite end. For details, see
Replacing Boards Onsite in the Supporting Tasks.
The alarm persists Replace the board at the local end. For details, see Replacing
Boards Onsite in the Supporting Tasks.
2. Check whether the alarm is cleared. If the alarm persists, contact Huawei technical
support engineers to handle the alarm.
----End
Related Information
None.
7.41 LP_RDI
Description
The LP_RDI is an alarm indicating a remote defect in the lower order path. This alarm occurs
when a board detects that the value of bit 8 of the V5 byte in the VC-12 path is 1 or the value
of bit 5 of the G1 byte in the VC-3 path is 1.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1 Indicates the number of the optical interface that reports the alarm, in the case
of the PQM board or data board.
Indicates the service mode in the case of the other tributary boards.
l 0x01: The transmitted services are conventional PDH services.
l 0x40: The N2PQ1 board works in MUX/SERVER mode (E13/M13
Function).
l 0x21: The R2PD1 board works in MUX/SERVER mode (E13/M13
Function).
l 0x0d: The N2PQ3 board works in DEMUX/SERVER mode (E13/M13
Function).
l 0x07: The N2PD3 board works in DEMUX/SERVER mode (E13/M13
Function).
l 0x04: The N2PL3 or N2PL3A board works in DEMUX/SERVER mode
(E13/M13 Function).
Parameter 2, Indicate the ID of the path that reports the alarm. Parameter 2 indicates the
Parameter 3 most significant byte (MSB) and Parameter 3 indicates the least significant
byte (LSB).
For example, when Parameter 2 = 0x00 and Parameter 3 = 0x01, the LP_RDI
alarm is reported by path 1 of the board.
Exception:
When the N2PQ1/R2PD1 board works in MUX mode, the ID of the path is
indicated from the value of 0x40. That is, 0x40 indicates that the LP_RDI
alarm occurs in VC-3 path 1.
If the possible causes do not correspond to any symptoms, or the symptoms are not listed in this topic,
handle the alarm according to the handling procedures.
Table 7-25 lists the common fault symptoms of the LP_RDI alarm.
The service receiving end (opposite end) reports Cause 2: The service receiving end
the TU_AIS and TU_LOP alarms. (opposite end) receives the alarms such
as TU_AIS and TU_LOP.
The service receiving end (opposite end) reports Cause 3: The opposite station detects the
the LP_TIM and LP_SLM alarms, and enables LP_TIM or LP_SLM alarm, and enables
the AIS insertion function. the AIS insertion function and the RDI
returning function.
Possible Causes
The possible causes of the LP_RDI alarm are as follows:
TU LU LU TU
l Cause 3: The opposite station detects the LP_TIM or LP_SLM alarm, and enables the
AIS insertion function and the RDI returning function.
Procedure
Step 1 Cause 1: The overhead mode is set incorrectly.
1. Check whether the line unit at the opposite end is set to terminate the higher order path
overhead. To configure the lower order service, the line unit must be set to terminate the
higher order path overhead. Otherwise, the services are interrupted, and thus the RDI
alarm signal is returned.
2. Choose Service > SDH Circuit > SDH Trail Management from the main menu. In the
Set Trail Browse Filter Condition dialog box, set the filter condition, and then click
Filter All. The trails are displayed in the list.
3. Select a trail to be viewed, click Maintenance, and then select Overhead Termination.
The Set Overhead dialog box is displayed.
4. Browse Overhead Status of the higher order path. Set Overhead Status to
Termination or Pass-Through as required.
5. Check whether the alarm is cleared. If the alarm persists, go to Step Step 2.
Step 2 Cause 2: The service receiving end (opposite end) receives the alarms such as TU_AIS and
TU_LOP.
1. Query whether the TU_AIS or TU_LOP alarm occurs at the opposite end. If yes, take
priority to clear the alarm.
If... Then...
2. Check whether the LP_RDI alarm is cleared. If the alarm persists, go to Step Step 3.
Step 3 Cause 3: The opposite station detects the LP_TIM or LP_SLM alarm, and enables the AIS
insertion function and the RDI returning function.
1. Check whether the LP_TIM or LP_SLM alarm occurs at the opposite station, and
whether the AIS insertion function and the RDI returning function are enabled. .
2. If the LP_TIM or LP_SLM alarm occurs, clear the alarm first or disable the AIS
insertion switch. For details on how to disable the AIS insertion function, see Setting the
AIS Insertion Switch in the Supporting Tasks.
3. Check whether the LP_RDI alarm is cleared. If the alarm persists, contact Huawei
technical support engineers to handle the alarm.
----End
Related Information
None.
7.42 LP_UNEQ
Description
The LP_UNEQ is an alarm indicating that no payload is equipped in the lower order path.
This alarm occurs when the board detects that the signal label in the V5 byte or C2 byte is 0.
NOTE
The C2 byte is used to indicate the structures of the higher order virtual containers (VC-3, VC-4, and
VC-4-Xc) and the payload property.
The V5 byte is used to detect bit errors, to indicate the remote error and failure in the lower order path.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1 Indicates the number of the optical interface that reports the alarm, in the case
of the PQM board or data board.
Indicates the service mode in the case of the other tributary boards.
l 0x01: The transmitted services are conventional PDH services.
l 0x40: The N2PQ1 board works in MUX/SERVER mode (E13/M13
Function).
l 0x21: The R2PD1 board works in MUX/SERVER mode (E13/M13
Function).
l 0x0d: The N2PQ3 board works in DEMUX/SERVER mode (E13/M13
Function).
l 0x07: The N2PD3 board works in DEMUX/SERVER mode (E13/M13
Function).
l 0x04: The N2PL3 or N2PL3A board works in DEMUX/SERVER mode
(E13/M13 Function).
Parameter 2, Indicate the ID of the path that reports the alarm. Parameter 2 indicates the
Parameter 3 most significant byte (MSB) and Parameter 3 indicates the least significant
byte (LSB).
For example, when Parameter 2 = 0x00 and Parameter 3 = 0x01, the
LP_UNEQ alarm is reported by path 1 of the board.
Exception:
When the N2PQ1/R2PD1 board works in MUX mode, the ID of the path is
indicated from the value of 0x40. That is, 0x40 indicates that the LP_UNEQ
alarm occurs in VC-3 path 1.
If the possible causes do not correspond to any symptoms, or the symptoms are not listed in this topic,
handle the alarm according to the handling procedures.
None.
Possible Causes
The possible causes of the LP_UNEQ alarm are as follows:
LU TU TU TU TU LU
Procedure
Step 1 Check the alarm on the NMS. Determine the ID of the path that reports the alarm according to
the alarm parameter. For details, see Viewing the Current Alarms in the Supporting Tasks.
Step 2 Cause 1: The service is not incorrectly accessed to the PDH side.
1. According to the signal flow, query the upstream NE of the service about the NE that
transmits the lower order service, and check whether the PDH side of this NE is
configured with services. As shown in Figure 7-37, the tributary unit of NE1 transmits
the lower order service.
If... Then...
The PDH side of this NE is not Configure services for the PDH side. For
configured with services detailed procedures, see the Configuration
Guide.
2. Check whether the service type of the corresponding channel is set correctly.
If... Then...
The service type is set incorrectly Reset the service type. Check whether the alarm is
cleared. If the alarm persists, go to the next step.
3. Check whether the parameters of the tributary board that is related to the service (such as
the service type and the path impedance ) are set correctly. If the parameters are set
incorrectly, reset the parameters according to the service type or the path impedance. For
details, see Checking Board Parameters in the Configuration Guide. Check whether the
alarm is cleared. If the alarm persists, go to Step Step 3.
Step 3 Cause 2: The V5 or C2 byte to be transmitted is set to 0x00.
1. According to the signal flow, query the upstream NE about the NE that transmits the
lower order service. The source board on the NE is the source end that sends the V5 and
C2 bytes.
2. Check the corresponding overhead byte according to the rate level of the configured
service.
If... Then...
The lower order service is at the VC-3 level Go to the next step.
The lower order service is at the VC-12 level Go to Step Step 3.5.
The lower order service is at the VC-3 or VC-12 level Go to the next step.
If... Then...
If... Then...
The VC-12 service is not Check whether the alarm is cleared. If the alarm
configured persists, contact Huawei technical support
engineers to handle the alarm.
If... Then...
6. In the NE Explorer, select the relevant board. In the Function Tree, choose
Configuration > Overhead Management > VC12 Path Overhead.
7. Click Signal Flag. Set the value of transmittable V5 byte according to the actual
services.
8. Check whether the alarm is cleared. If the alarm still persists, contact Huawei technical
support engineers to handle the alarm.
----End
Related Information
None.
7.43 LPT_INEFFECT
Description
The LPT_INEFFECT is an alarm indicating that the LPT function fails. The LPT_INEFFECT
alarm is reported if a user configures the LPT function that is not supported by the board.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
If this section does not describe the common fault symptom or if the actual fault symptom is not
contained in the description of the common fault symptom, handle the LPT_INEFFECT alarm by
following the steps provided in Handling Procedure.
None.
Possible Causes
The possible cause of the LPT_INEFFECT alarm is as follows:
Cause 1: The board hardware is of an early version, and the user configures the LPT function.
Procedure
Step 1 Cause 1: The board hardware is of an early version, and the user configures the LPT function.
l If the LPT function is required, replace the board with one of a proper version. For
information about the boards that support the LPT function, see Availability in the
Feature Description. For details, see Replacing Boards Onsite in the Supporting Tasks.
Check whether the alarm is cleared. If the alarm persists, contact Huawei technical
support engineers to handle the alarm.
l If the LPT function is not required, delete the LPT configuration. For details, see
Configuring LPT in the Feature Description. Check whether the alarm is cleared. If the
alarm persists, contact Huawei technical support engineers to handle the alarm.
----End
7.44 LPT_RFI
Description
The LPT_RFI is an alarm indicating the remote failure of the link state pass through (LPT).
This alarm is reported when the LPT detects the failure of the remote port or the LPT service
network.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
If this section does not describe the common fault symptom or if the actual fault symptom is not
contained in the description of the common fault symptom, handle the LPT_RFI alarm by following the
steps provided in Handling Procedure.
Table 7-26 lists the common fault symptoms of the LPT_RFI alarm.
An alarm (such as the ETH_LOS, LINK_ERR, Cause 1: The remote port is faulty.
or LSR_NO_FITED alarm) is generated on the
remote port.
An alarm (such as the R_LOS, BIP_EXC, Cause 2: The LPT service network is
B3_EXC, TU_LOP, TU_AIS, VCAT_LOA, faulty.
VCAT_LOM_VC12, VCAT_LOM_VC3,
VCAT_LOM_VC4, LP_UNEQ_VC12, or
LP_UNEQ_VC3 alarm) is generated on the
LPT service network.
Possible Causes
The possible causes of the LPT_RFI alarm are as follows:
NE1 NE2
(Local end) (Opposite end)
NE1 NE2
(Local end) (Opposite end)
Procedure
Step 1 Check the alarm on the NMS, determine the board that reports the alarm, and then determine
the number of the port on the board according to according to Parameter 1. For details, see
Viewing the Current Alarms in the Supporting Tasks.
2. If an alarm is generated, clear the alarm immediately. Then, check whether the LPT_RFI
alarm is cleared. If the alarm persists, contact Huawei technical support engineers to
handle the alarm.
----End
Related Information
None.
7.45 LSR_WILL_DIE
Description
The LSR_WILL_DIE is an alarm indicating that the laser is to stop working. This alarm
occurs when the laser is unavailable.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1 Indicates the number of the optical interface on the board that
reports the alarm.
Parameter 4 l 0x01: The service life of the laser will end soon.
l 0x02: An internal register of the laser is faulty.
l 0xFF: No meaning
If this section does not describe the common fault symptom or the actual fault symptom is not contained
in the description of this section, handle the alarm by following the steps provided in Handling
Procedure.
None.
Possible Causes
The possible causes of the LSR_WILL_DIE alarm are as follows:
Procedure
Step 1 Cause 1: The laser is aged.
If... Then...
The board supports the Replace the pluggable optical module. For details, see
pluggable optical module Replacing a Pluggable Optical Module in the Parts
Replacement.
Check whether the alarm is cleared. If the alarm persists,
go to Step Step 2.
----End
Related Information
None.
7.46 LTI
Description
The LTI is an alarm indicating the loss of synchronization source. This alarm occurs when the
NE clock is in an abnormal state.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
If the possible causes do not correspond to any symptoms, or the symptoms are not listed in this topic,
handle the alarm according to Handling Procedure.
Table 7-27 lists the common fault symptoms of the LTI alarm.
Only one cross-connect and timing board Cause 5: The cross-connect and timing
reports the LTI alarm. unit is abnormal.
Possible Causes
The possible causes of the LTI alarm are as follows:
l Cause 1: The external synchronization source is lost.
Procedure
Step 1 Check the alarm on the NMS. Determine the loss type of the synchronization source.
1. According to the alarm parameter, determine whether the lost synchronization source on
the NE is the synchronization source of the system clock or of the 2 Mbit/s phase-locked
source. For details, see Viewing the Current Alarms in the Supporting Tasks.
2. Query the type of the synchronization source traced by the NE. The synchronization
sources include the external clock source, line clock source, and tributary clock source.
For details, see Configuring NE Clock Sources in the Feature Description.
l If all the synchronization sources of the system are lost, query the types of the lost
synchronization sources in System Clock Source Priority Table.
l If the synchronization source of the 2 Mbit/s phase-locked source is lost, query the
types of the lost synchronization sources in Phase-Locked Source Output by
External Clock.
3. Perform the following steps according to the type of the lost synchronization source.
If... Then...
The external clock source traced by the NE is lost Go to Step Step 2.
The line clock source traced by the NE is lost Go to Step Step 3.
The tributary clock source traced by the NE is lost Go to Step Step 4.
If... Then...
The alarms that can trigger the switching of Clear these alarms first. Check
the clock source occur, such as the R_LOS, whether the alarm is cleared. If the
R_LOF, B2_EXC, and AIS alarms. alarm persists, go to the next step.
None of the alarms that can trigger the Go to the next step.
switching of the clock source occurs
3. Check whether the SSM protocol is started on the NE. For details, see Configuring the
Clock Source Protection in the Feature Description. If the standard SSM protocol is
started on the NE at one end and the extended SSM protocol is started on the NE at the
other end, the traced clock source may be lost due to inconsistency of the SSM protocols.
If... Then...
The SSM protocols on the Set the SSM protocols on the networkwide NEs to be
NEs are set to be different the same.
from each other
NOTE
If the extended SSM protocol is started, you need to set the
ID of the traced clock source.
4. Perform a cold reset on the line board by using the NMS, or directly reseat this board.
For details on how to perform a cold reset, see Resetting Boards in the Supporting Tasks.
For details on how to reseat a board, see Removing the Boards in the Installation
Reference and Installing the Boards in the Installation Reference.
NOTICE
If the service on the board is not protected, a cold reset on the board causes service
interruption.
5. After five minutes, check whether the alarm is cleared. If the alarm persists, replace the
line board. For details, see Replacing an SDH Board in the Parts Replacement.
6. Check whether the LTI alarm is cleared. If the alarm persists, go to Step Step 5.
Step 4 Cause 3: The tributary synchronization source is lost.
1. Service interruption occurs in the traced tributary clock source. As a result, the output
clock signal is lost. On the NMS, query whether the corresponding tributary board
reports the alarms related to the loss of analog signals, such as the T_ALOS and P_LOS
alarms.
If... Then...
The preceding alarms Take priority to clear the T_ALOS and P_LOS alarms.
occur
Check whether the is cleared. If the alarm persists, go to
the next step.
2. Perform a cold reset on the tributary board by using the NMS, or directly reseat this
board. For details on how to perform a cold reset, see Resetting Boards in the Supporting
Tasks. For details on how to reseat a board, see Removing the Boards in the Installation
Reference and Installing the Boards in the Installation Reference.
NOTICE
If the service on the board is not protected, a cold reset on the board causes service
interruptions.
3. After five minutes, check whether the alarm is cleared. If the alarm persists, replace the
tributary board. For details, see in the Parts Replacement.
4. Check whether the LTI alarm is cleared. If the alarm persists, go to Step Step 5.
Step 5 Cause 4: The synchronization source is set to the non-revertive or lockout mode.
1. On the NMS, check whether the synchronization source is set to the Non-revertive
mode.
If... Then...
2. On the NMS, check whether the synchronization source is set to the Lockout.
If... Then...
If... Then...
If... Then...
The alarm is reported on the protection The protection board may be faulty. Reset or
cross-connect and timing board re-install the protection board. Go to Step
Step 6.2.
1. Perform the working/protection switching of the cross-connect and timing boards. For
details, see Replacing a CXL Board in the Parts Replacement.
If... Then...
After the switching is performed, the The original working board may be
original protection board does not report faulty. Reset or re-install the original
the LTI alarm working board. Go to the next step.
2. Perform a cold reset by using the NMS or re-install the cross-connect and timing board.
For details on how to perform a cold reset, see Resetting Boards in the Supporting Tasks.
For details on how to reseat a board, see Removing the Boards in the Installation
Reference and Installing the Boards in the Installation Reference.
3. Check whether the alarm is cleared. If the alarm persists, replace the relevant cross-
connect and timing board. For details, see Replacing a CXL Board in the Parts
Replacement.
4. Check whether the alarm is cleared. If the alarm persists, contact Huawei technical
support engineers to handle the alarm.
----End
Related Information
None.
7.47 MS_AIS
Description
The MS_AIS is an alarm indicating a remote defect in the multiplex section. This alarm
occurs when the last three bits of the K2 byte are 111 in five consecutive frames received at
the receive optical interface of the local station. This alarm shows that the signals in the
multiplex section corresponding to the optical interface that reports the alarm are useless.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1 Indicates the ID of the optical interface that reports the alarm.
If the possible causes do not correspond to any symptoms, or the symptoms are not listed in this topic,
handle the alarm according to the handling procedures.
Table 7-28 lists the common fault symptoms of the MS_AIS alarm.
The higher level alarms occur on the Causes 1: The upstream station inserts the
upstream NE, such as R_LOS and R_LOF. AIS alarm signal into the downstream
station.
Possible Causes
The possible causes of the MS_AIS alarm are as follows:
l Causes 1: The upstream station inserts the AIS alarm signal into the downstream station.
As shown in Figure 7-40, if NE3 reports the MS_AIS alarm, query whether the
upstream station (NE2) reports a higher level alarm, according to the signal flow of the
service.
Procedure
Step 1 Causes 1: The upstream station inserts the AIS alarm signal into the downstream station.
1. On the NMS, query the service configuration signal flow related to the alarms. Query
whether higher level alarms, such as R_LOS and R_LOF, occur at the upstream station
according to the signal flow.
If... Then...
Higher level alarms Clear the alarm immediately, and then check whether the
occur MS_AIS alarm is cleared. If the alarm persists, go to Step
Step 2.
NOTICE
If the service on the board is not protected, a cold reset on the board causes service
interruption.
2. Check whether the alarm is cleared. If the alarm persists, use the loopback function to
check whether the receive board at the local station is faulty. As shown in Figure 7-41, if
NE3 reports the MS_AIS alarm, perform an inloop on the optical interface of the
transmit board (east line board) of the upstream station (NE2).
MS_AIS
3. For details on how to loop back a board, see the Supporting Tasks.
NOTICE
A loopback causes service interruption.
If... Then...
The MS_AIS alarm occurs It indicates that the MS_AIS alarm signal of the local
at the upstream station station is transmitted by the upstream station. In this
case, go to Step Step 3.
The MS_AIS alarm does It indicates that the receive board at the local station is
not occur at the upstream faulty. In this case, go to the next step.
station
5. Replace the receive board of the local station. For details, see Replacing Boards Onsite
in the Supporting Tasks. Check whether the alarm is cleared.
6. If the alarm persists, go to Step Step 3.
Step 3 Cause 3: The working and protection cross-connect and timing boards at the upstream station
are offline.
1. Check whether the working and protection cross-connect and timing boards at the local
station are loose. If yes, insert the working and protection cross-connect and timing
boards firmly. For details, see Installing the Boards in the Installation Reference. Check
whether the alarm is cleared.
2. If the alarm persists, perform a cold reset on the cross-connect and timing board. For
details on how to perform a cold reset, see Resetting Boards in the Supporting Tasks.
Check whether the alarm is cleared.
NOTICE
If there is no protection cross-connect and timing board, performing a cold reset on the
working cross-connect and timing board may cause service interruption.
Related Information
None.
7.48 MS_RDI
Description
The MS_RDI is a remote defect indication in the multiplex section. When the last three bits of
the K2 byte are 110 in five consecutive frames received at the receive optical interface of the
local station, the MS_RDI alarm is reported. When the MS_AIS alarm is reported on the
opposite station, the MS_RDI alarm is returned to the local station.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
Name Meaning
Parameter 1 Indicates the actual number of the interface on the board at the local station.
If this section does not describe the common fault symptom or the actual fault symptom is not contained
in the description of the common fault symptom, handle the MS_RDI alarm by following the steps
provided in Handling Procedure.
None.
Possible Causes
The possible causes of the MS_RDI alarm are as follows:
l Cause 1: The R_LOS or MS_AIS alarm is received at the opposite station.
Procedure
Step 1 Cause 1: The R_LOS or MS_AIS alarm is received at the opposite station.
1. See Figure 7-42. On the NMS, check whether the alarm indicating service interruptions
or bit errors is reported on the opposite station (NE3).
If... Then...
The R_LOS, R_LOF, MS_AIS, Clear these alarms first. Check whether the
B2_EXC, or B2_SD alarm is reported MS_RDI alarm is cleared. If the alarm
on the opposite station persists, go to Step Step 2.
NOTICE
If the service on the board is not protected, a cold reset on the board causes service
interruptions.
2. Check whether the MS_RDI alarm is cleared. If the alarm persists, replace the transmit
board at the local station. For details, see Replacing Boards Onsite in the Supporting
Tasks.
3. Check whether the MS_RDI alarm is cleared. If the alarm persists, go to Step Step 3.
Step 3 Cause 3: The receive board at the opposite station is faulty.
1. Perform a cold reset on the receive board at the opposite station (NE3) by using the
NMS, or directly reseat this board. For details on how to perform a cold reset, see
Resetting Boards in the Supporting Tasks. For details on how to reseat a board, see
Removing the Boards in the Installation Reference and Installing the Boards in the
Installation Reference.
NOTICE
If the service on the board is not protected, a cold reset on the board causes service
interruptions.
2. Check whether the MS_RDI alarm is cleared. If the alarm persists, replace receive board
at the opposite station. For details, see Replacing Boards Onsite in the Supporting Tasks.
3. Check whether the MS_RDI alarm is cleared. If the alarm persists, contact Huawei
technical support engineers to handle the alarm.
----End
Related Information
None.
7.49 OOL
Description
The OOL is an alarm indicating that the phase-locked loop is out of lock. This alarm is
reported when the phase-locked loop on the cross-connect and timing board becomes faulty.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
If this section does not describe the common fault symptom or the actual fault symptom is not contained
in the description of this section, handle the OOL alarm by following the steps provided in Handling
Procedure.
None.
Possible Causes
The possible causes of the OOL alarm are as follows:
Procedure
Step 1 Check the alarm on the NMS. Determine the board that reports the alarm. For details, see
Viewing the Current Alarms in the Supporting Tasks.
Step 2 Cause 1: The hardware of the phase-locked loop is damaged.
If... Then...
The OOL alarm is reported on the The protection cross-connect and timing board
protection cross-connect and timing may be faulty. Perform a cold reset on or reseat
board this board. For details, see Step Step 2.2.
1. Switch the working and protection cross-connect and timing boards. For details on how
to perform a working/protection switching, see Replacing a CXL Board in the Parts
Replacement.
If... Then...
The OOL is no longer reported on the The original working cross-connect and
original protection cross-connect and timing board may be faulty. Perform a cold
timing board reset on or reseat this board. For details, see
Step Step 2.2.
The OOL alarm is reported on the Contact Huawei technical support engineers
original protection cross-connect and to handle the alarm.
timing board
2. Perform a cold reset on the cross-connect and timing board by using the NMS, or
directly reseat this board. For details on how to perform a cold reset, see Resetting
Boards in the Supporting Tasks. For details on how to reseat a board, see Removing the
Boards in the Installation Reference and Installing the Boards in the Installation
Reference.
3. Check whether the OOL alarm is cleared. If the alarm persists, replace the cross-connect
and timing board. For details, see Replacing a CXL Board in the Parts Replacement.
4. Check whether the OOL alarm is cleared. If the alarm persists, contact Huawei technical
support engineers to handle the alarm.
----End
Related Information
None.
7.50 P_LOS
Description
The P_LOS is an alarm indicating the loss of analog signals at the 34 Mbit/s or 45 Mbit/s
interface.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 2, Parameter 3 Indicate the path number. Parameter 2 indicates the most
significant byte, and Parameter 3 indicates the least significant
byte.
If this section does not describe the common fault symptom or the actual fault symptom is not contained
in the description of this section, handle the P_LOS alarm by following the steps provided in Handling
Procedure.
None.
Possible Causes
The possible causes of the P_LOS alarm are as follows:
l Cause 1: The service is not accessed at the 34 Mbit/s or 45 Mbit/s electrical interface.
Electrical Electrical
signal input D O O D signal output
T L L T
D IB D D IB D
U U U U
F F F F
Procedure
Step 1 On the NMS, query the alarms. Based on the alarm parameters, locate the board and path that
report this alarm. For details, see Viewing the Current Alarms in the Supporting Tasks.
Step 2 Cause 1: The service is not accessed at the 34 Mbit/s or 45 Mbit/s electrical interface.
1. Check whether the type of the tributary board that reports the alarm matches with the
type of the interface board.
If... Then...
Their types do not See SUBCARD_ABN to handle the alarm. Check whether the
match P_LOS alarm is cleared. If the alarm persists, go to the next
step.
2. Check whether the parameters of the tributary board that are related to the service (such
as the type of the service in the path and path impedance) are correctly set. If the
parameters are incorrectly set, reset the parameters according to the type of the service in
the path or the actual impedance of the board. For details, see Checking Board
Parameters in the Configuration Guide. Check whether the P_LOS alarm is cleared. If
the alarm persists, go to the next step.
3. As shown in Figure 7-43, check whether the output connector of the 34 Mbit/s or 45
Mbit/s interface on the local DDF and the input connector of the 34 Mbit/s or 45 Mbit/s
interface at the local station are loose or disconnected. If yes, reconnect or fix the
connectors. Check whether the P_LOS alarm is cleared.
4. If the alarm persists, go to Step Step 3.
NOTICE
A loopback causes service interruptions.
Figure 7-44 Locating the fault that causes the P_LOS alarm by performing a loopback
(1)
Direction of the Signal
P_LOS
Electrical Electrical
signal input D O O D signal output
T L L T
D IB D D IB D
U U U U
F F F F
If... Then...
The P_LOS alarm is cleared after the The upstream equipment is faulty. Rectify
selfloop is performed the fault on the upstream equipment.
The P_LOS alarm persists after the Release the selfloop at the DDF. Go to the
selfloop is performed next step.
2. As shown in Figure 7-44, perform a hardware inloop for the service in the alarm path at
the interface board.
If... Then...
The P_LOS alarm is cleared after The signal cable fails to be properly
the inloop is performed connected. Go to Step Step 4.
The P_LOS alarm persists after the Release the inloop at the interface board. Go
inloop is performed to the next step.
3. As shown in Figure 7-45, perform a software inloop for the service in the alarm path at
the interface board.
Figure 7-45 Locating the fault that causes the P_LOS alarm by performing a loopback
(2)
Direction of the Signal
P_LOS
Electrical Electrical
signal input D O O D signal output
T L L T
D IB D D IB D
U U U U
F F F F
4. For the operations of looping back a board, see the Supporting Tasks.
Setting a Loopback on an SDH Optical Interface Board
Setting a Loopback on a PDH Electrical Interface Board
Setting a Loopback on an Ethernet Port
Setting a Loopback on an ATM Board Port
Setting Loopback on the IF Board
If... Then...
The P_LOS alarm is The interface board is faulty. Reseat or replace the interface
cleared after the board. For details on how to reseat a board, see Removing the
inloop is performed Boards in the Installation Reference and Installing the Boards
in the Installation Reference. For details on how to replace a
board, see Replacing Boards Onsite in the Supporting Tasks.
Check whether the P_LOS alarm is cleared. If the alarm
persists, contact Huawei technical support engineers to
handle the alarm.
The P_LOS alarm Release the software inloop at the interface board. Go to the
persists after the next step.
inloop is performed
5. As shown in Figure 7-45, perform a software inloop for the service in the alarm path at
the tributary processing unit.
If... Then...
The P_LOS alarm is Contact Huawei technical support engineers to handle the
cleared after the alarm.
inloop is performed
If... Then...
The P_LOS alarm The tributary board is faulty. Reseat or replace the tributary
persists after the board. For details on how to reseat a board, see Removing
inloop is performed the Boards in the Installation Reference and Installing the
Boards in the Installation Reference. For details on how to
replace a board, see in the Parts Replacement.
Check whether the P_LOS alarm is cleared. If the alarm
persists, contact Huawei technical support engineers to
handle the alarm.
Step 4 Cause 3: The cable connecting the DDF and equipment is faulty.
1. As shown in Figure 7-43, check the length of the cable that connects the local DDF and
the equipment.
If... Then...
The length is more than Adjust the location of the equipment, so that the cable
70 m length can be shortened to less than 50 m. Check whether
the P_LOS alarm is cleared. If the alarm persists, go to the
next step.
2. In the case of the cable that connects the DDF and the equipment, check whether it is
aged, peels off, is improperly grounded. If the cable is faulty, replace the cable. Then,
check whether the P_LOS alarm is cleared.
3. If the alarm persists, contact Huawei technical support engineers to handle the alarm.
----End
Related Information
None.
7.51 POWER_ABNORMAL
Description
The POWER_ABNORMAL alarm is an alarm indicating a power supply failure. The alarm
occurs when the power supply of a board becomes abnormal.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1 In the case of a tributary board, line board, or optical amplifier board, the
value is always 0x01 and this parameter is meaningless.
In the case of a cross-connect board, this parameter indicates the number of
the faulty power supply. If a bit is 1, it indicates an alarm. If a bit is 0, it
indicates no alarms.
In the case of the PIU board, the meanings of the parameters are as follows:
l 0x01: -48 V channel A (by default, the PIU in the slot with a smaller ID)
voltage
l 0x0D: failed lightning protection voltage for channel A
l 0x11: -48 V channel B (by default, the PIU in the slot with a larger ID)
voltage
l 0x12: failed lightning protection voltage for channel B
In the case of the GSCC board, the meanings of the parameters are as follows:
l 0x02: 5 V voltage
l 0x03: 3.6 V voltage
l 0x04: 3.3 V voltage
l 0x05: 3.3 V backup voltage of the system (AUX/SAP)
l 0x06: 3 V voltage of the auxiliary board (AUX/EOW/SAP)
l 0x07: 2.5 V voltage
l 0x08: 1.8 V voltage
l 0x0A: 1.5 V voltage
l 0x0B: 1.2 V voltage
l 0x0E: V3.3 Bakin voltage
l 0x13: Battery voltage on the SCC board
In the case of the SAN/Video board, parameter 1 is always 0x01 and this
parameter is meaningless.
For an auxiliary board, the meanings of the parameter are as follows:
l For an AUX board, the value is always 0x01 and the parameter is
meaningless.
l For other auxiliary boards, this parameter indicates the voltage type.
0x02: 5 V voltage
0x03: 3.6 V voltage of the power supply module on an R1AMU board
0x04: 3.3 V voltage of the power supply module on a Q2SAP board or
the working power supply on an R1AMU board
0x05: 3.3 V voltage of the standby power supply
0x08: 1.8 V voltage
0x0C: absolute address of the -5 V voltage (not supported by the
Q2SAP/R1AMU board)
Name Meaning
Parameter 2, In the case of a tributary or auxiliary board, these parameters indicate the path
Parameter 3 number. For example, when Parameter 2 = 0x00 and Parameter 3 = 0x01, the
POWER_ABNORMAL alarm is reported by path 1 of the board.
In the case of a line board, the value is always 0x01. Parameter 2 indicates the
most significant byte and Parameter 3 indicates the least significant byte.
In the case of a cross-connect board, this parameter indicates the number of
the faulty power supply. If a bit is 1, there is an alarm. If a bit is 0, there is no
alarm.
In the case of the PIU and GSCC boards, Parameter 2 is always 0x00 and
Parameter 3 is always 0x01. In this case, the two parameters are meaningless.
In the case of the SAN/Video board, parameter 2 is always 0x00, and
Parameter 3 is always 0x01. In this case, the two parameters indicate the path
number.
Name Meaning
Parameter 4, In the case of the N2PQ1, N2PQ3, N2PD3, N2PL3, N2PL3A, R2PD1,
Parameter 5 N1PD3, N1PL3, N1PL3A, N1PQM, N1PQ1, R1PL1, and R1PD1 boards:
l If Parameter 4 = 0x01 and Parameter 5 = 0x04, the active and standby
power supplies are switched.
l If Parameter 4 = 0x01 and Parameter 5 = 0x01, the 3.3 V active power
supply becomes faulty.
l If Parameter 4 = 0x01 and Parameter 5 = 0x02, the 3.3 V standby power
supply becomes faulty.
l If Parameter 4 = 0x02 and Parameter 5 = 0x00, the 1.8 V power supply
becomes faulty.
l If Parameter 4 = 0x02 and Parameter 5 = 0x08, the 2.5 V power supply
becomes faulty.
When Parameter 4 = 0x01, Parameter 5 differentiates the faulty power supply
by bit position. If the bit corresponding to Parameter 5 is 1, the
POWER_ABNORMAL alarm occurs. If the bit corresponding to Parameter 5
is 0, the POWER_ABNORMAL alarm does not occur. Multiple bits can take
effect simultaneously.
Name Meaning
Parameter 4, In the case of the other line boards and tributary boards and optical amplifier
Parameter 5 boards:
Parameter 4 and Parameter 5 differentiate the faulty power supply by bit
position. If the bit corresponding to the parameter is 1, the
POWER_ABNORMAL alarm occurs. If the bit corresponding to the
parameter is 0, the POWER_ABNORMAL alarm does not occur. Multiple
bits can take effect simultaneously.
The meanings of Parameter 4 are as follows:
l bit[0]: 3.3 V voltage
l bit[1]: 1.8 V voltage
l bit[2]: 5 V voltage
l bit[3]: 2.5 V voltage
l bit[4]: 1.5 V voltage
l bit[5]: -5 V voltage
The meanings of Parameter 5 are as follows:
l bit[0]: output of the 3.6 V power supply module
l bit[1]: output of the standby 3.6 V power supply module
l bit[2]: standby power supply being used
l bit[3]: 1.0 V voltage
l bit[4]: 1.0 V standby power supply
l bit[5]: 1.2 V voltage
l bit[6]: 1.3 V voltage
Parameter 4, In the case of the PIU and GSCC boards, Parameter 4 indicates the working
Parameter 5 state of the power supply.
l 0x00: undervoltage
l 0x01: overvoltage
l 0xFF: default value; meaningless
In the case of the PIU and GSCC boards, Parameter 5 is reserved for future
use.
Name Meaning
Parameter 4, For MST4 board, The meanings of Parameter 4 and Parameter 5 are as
Parameter 5 follow:
l If the bit corresponding to Parameter 4 is 1, the POWER_ABNORMAL
alarm occurs. If the bit corresponding to Parameter 4 is 0, the
POWER_ABNORMAL alarm does not occur.
bit[0]: 3.3 V voltage
bit[1]: 1.8 V voltage
bit[2]: 5 V voltage
bit[3]: 2.5 V voltage
bit[4]: 1.5 V voltage
bit[5]: -5 V voltage
l Parameter 5 is meaningful only for the bit[0] of Parameter 4, that is, the
3.3 V power supply.
bit[0]: output of the power supply module
bit[1]: output of the standby power supply
bit[2]: 3.3 V standby power supply being used
Name Meaning
If this section does not describe the common fault symptom or the actual fault symptom is not contained
in the description of this section, handle the POWER_ABNORMAL alarm by following the steps
provided in Handling Procedure.
Table 7-29 lists the common fault symptoms of the POWER_ABNORMAL alarm.
No alarms are reported on the PIU board in the Cause 2 (board): The external power
main subrack. The POWER_ABNORMAL supply is abnormal. For example, the
alarm is reported on the PIU board in the external power supply may has the
extended subrack, and Parameter 1 = 0x0F/ undervoltage problem or fluctuates
0x10. Generally, this situation occurs if the sharply.
jumper on the XCE board in the extended
subrack is incorrectly set.
Possible Causes
If the POWER_ABNORMAL alarm is reported on the board, the possible causes are as
follows:
If the POWER_ABNORMAL alarm is reported on the ODU, the possible cause is as follows:
Procedure
Step 1 On the NMS, query the current alarms and determine the board that reports the
POWER_ABNORMAL alarm. For details, see Viewing the Current Alarms in the Supporting
Tasks.
Step 2 Cause 1 (board): The jumper on the SCC board is incorrectly set.
1. If the jumper on the SCC board that specifies the input voltage is incorrectly set, the
POWER_ABNORMAL alarm is reported. Check whether the jumper of the SCC board
is correctly set. If not, modify the jumper setting according to the input voltage. For
details on the jumper setting of the SCC board, see the Hardware Description.
Jumper of the CXL1
Jumper of the CXL4
Jumper of the CXL16
Jumper of the CXLLN
Jumper of the CXLD41
Jumper of the CXLQ41
2. Check whether the POWER_ABNORMAL alarm is cleared. If the alarm persists, go to
Step Step 3.
Step 3 Cause 2 (board): The external power supply is abnormal. For example, the external power
supply may has the undervoltage problem or fluctuates sharply.
1. Check the number of PIU boards that are installed on the equipment.
If... Then...
Two PIU boards are Access the power supply to the other PIU board. For
installed, whereas only one details, see the Quick Installation Guide. Check whether
power supply is accessed the POWER_ABNORMAL alarm is cleared. If the
alarm persists, go to the next step.
2. If the circuit breaker for the input power supply of the subrack is turned off, the power
cables on the subrack are incorrectly connected, or the connector of the power cable is
loose or firmly inserted, the NE detects that the voltage is abnormal and thus reports the
POWER_ABNORMAL alarm. Check in order whether the circuit breaker on the subrack
is turned on, whether the power cables are properly connected to the external power
supply device, DC power distribution unit, and power board on the equipment, and
whether the connector of the power cable is firmly inserted. For details, see the Quick
Installation Guide.
3. Check whether the POWER_ABNORMAL alarm is cleared. If the alarm persists,
measure the input voltage of the power cable.
4. Switch off the DC power distribution unit. Connect the positive terminal of the
multimeter to NEG (-) of the DC power distribution unit, and connect the negative
terminal of the multimeter to RTN (+) of the DC power distribution unit. Then, measure
the voltage between RTN (+) and NEG (-).
If... Then...
The standard voltage of the input power supply is -48 V, and Go to the next step.
the measured value is not in the range of -41 V to -60 V
The standard voltage of the input power supply is -60 V, and Go to the next step.
the measured value is not in the range of -51 V to -72 V
5. Replace the UPM that provides the stable DC power supply or DC PDU. Check whether
the POWER_ABNORMAL alarm is cleared. If the alarm persists, contact power
engineers to rectify the external power fault.
Step 4 Cause 3 (board): The power module on the local board is faulty.
1. Perform a cold reset on the board that reports the POWER_ABNORMAL alarm by using
the NMS, or directly reseat this board. For details on how to perform a cold reset, see
Resetting Boards in the Supporting Tasks. For details on how to reseat a board, see
Removing the Boards in the Installation Reference and Installing the Boards in the
Installation Reference.
NOTICE
If the service on the board is not protected, a cold reset on the board causes service
interruptions.
The PIU board does not support hot-swapping. Hence, ensure that the circuit breaker for
the power distribution unit is turned off before you remove or insert a PIU board.
Step 5 Cause 4 (board): The system backup power module on the auxiliary board is faulty.
1. Check whether the auxiliary board is properly connected to the backplane.
If... Then...
The board is not Reseat the board. For details on how to reseat a board, see
firmly inserted Removing the Boards in the Installation Reference and Installing
the Boards in the Installation Reference.
Check whether POWER_ABNORMAL alarm is cleared. If the
alarm persists, go to Step Step 5.3.
If... Then...
2. Perform a cold reset on the auxiliary board by using the NMS, or directly reseat this
board. For the operations on the NMS, see Resetting Boards in the Supporting Tasks. For
details on how to reseat a board, see Removing the Boards in the Installation Reference
and Installing the Boards in the Installation Reference. Check whether the
POWER_ABNORMAL alarm is cleared.
NOTICE
If the overvoltage or undervoltage alarm occurs on the 3.3 V active power supply, do not
reseat any auxiliary boards.
3. If the alarm persists, replace the faulty auxiliary board. For details, see Replace Auxiliary
Board in the Parts Replacement.
4. Check whether the POWER_ABNORMAL alarm is cleared. If the alarm persists,
contact Huawei technical support engineers to handle the alarm.
----End
Related Information
None.
7.52 POWER_FAIL
Description
The POWER_FAIL is an alarm indicating that the status of the power supply on the SCC
board is abnormal (for example, the battery on the SCC board has no charge).
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
If this section does not describe the common fault symptom or the actual fault symptom is not contained
in the description of this section, handle the POWER_FAIL alarm by following the steps provided in
Handling Procedure.
None.
Possible Causes
The possible cause of the POWER_FAIL alarm is follows:
Procedure
Step 1 Cause 1: The jumper on the SCC board is incorrectly set.
1. The POWER_FAIL alarm is reported if the jumper on the SCC board that specifies
whether the battery is enabled is incorrectly set. Contact the local representative office of
Huawei and check whether the jumper on the SCC board is correctly set.
2. If the jumper is incorrectly set, modify the setting. For details on the jumper setting of
the SCC board, see the Hardware Description.
Jumper of the CXL1
Jumper of the CXL4
Jumper of the CXL16
Jumper of the CXLLN
Jumper of the CXLD41
Jumper of the CXLQ41
3. Check whether the POWER_FAIL alarm is cleared. If the alarm persists, go to Step Step
2.
----End
Related Information
None.
7.53 R_LOF
Description
The R_LOF is an alarm indicating loss of frames on the receive side of the line. When the
correct A1 and A2 bytes are not contained in five consecutive frames received at the receive
optical interface of the local station, the R_LOF alarm is reported.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
Name Meaning
Parameter 1 Indicates the actual number of the interface on the board that reports the alarm.
If this section does not describe the common fault symptom or the actual fault symptom is not contained
in the description of this section, handle the R_LOF alarm by following the steps provided in Handling
Procedure.
None.
Possible Causes
The possible causes of the R_LOF alarm are as follows:
l Cause 1: Two boards at different rates are interconnected (in the case of the optical
interface board).
l Cause 2: The transmit cable is faulty, and the fiber connector is loose or contaminated (in
the case of the optical interface board).
l Cause 3: Other alarms trigger the R_LOF alarm (in the case of the IF board).
l Cause 4: The receive board at the local station is faulty, and thus the frame structure is
lost.
l Cause 4: The transmit board (including the cross-connect board) at the opposite station is
faulty, and thus the frame structure is lost.
Procedure
Step 1 On the NMS, query the alarms. Based on the alarm parameters, determine the port that reports
the alarm. For details, see Viewing the Current Alarms in the Supporting Tasks.
Step 2 Cause 1: Two boards at different rates are interconnected (in the case of the optical interface
board).
1. The improper fiber connection may cause that two boards at different rates are
interconnected. In this case, the R_LOF alarm is reported. Check whether the fiber is
improperly connected. If yes, modify the improper fiber connection. For details, see
Checking the Fiber Connection of the SDH Network in the Commissioning Guide.
Check whether the R_LOF alarm is cleared.
2. If the alarm persists, check whether the types of the two interconnected boards are the
same. For example, when the board that supports the FEC function is interconnected
with the board that does not support the FEC function, the two boards are at different
rates and the interconnection fails. In this case, the R_LOF alarm is reported. The FEC
function of the two boards should be both enabled or disabled according to the actual
situation. For details, see Configuring the FEC Function in the Supporting Tasks.
NOTE
For details on the board that supports the FEC function, see "Function and Feature" of each board
in the Hardware Description.
3. Check whether the R_LOF alarm is cleared. If the alarm persists, go to Step Step 3.
Step 3 Cause 2: The transmit cable is faulty, and the fiber connector is loose or contaminated (in the
case of the optical interface board).
1. Check whether the transmit optical power of the board connected to the board that
reports the alarm is within the normal range. For details on the optical power of the
board, see Specifications of the Boards in the Technical Specifications Reference. For
details, see Querying the Optical Power in the Supporting Tasks.
NOTE
For details on the manufacturer information about the optical module, see Querying the Board
Manufacturer Information Report in the Supporting Tasks or Bar Code in the Hardware
Description.
If... Then...
The transmit optical power of the opposite board is abnormal Go to Step Step 6.
The transmit optical power of the opposite board is normal Go to the next step.
2. On the NMS, check whether the receive optical power of the local board is within the
normal range.
If... Then...
The receive optical power of the local board is very low Go to the next step.
The receive optical power of the local board is very high Go to Step Step 5.
3. Check whether the bend radius of the fiber jumper is within the normal range. If the bend
radius is less than 6 cm, roll the fiber jumper again. Check whether the R_LOF alarm is
cleared.
4. If the alarm persists, check whether the optical interface on the board is firmly connected
to the fiber jumper. Ensure that the fiber connector is firmly connected. Then, check
whether the R_LOF alarm is cleared.
5. If the alarm persists, check whether the fiber connector is contaminated. For details on
how to check the fiber connector, see Checking the Optical Fiber Connector in the
Supporting Tasks. For details on how to clean the fiber connectors, see the Supporting
Tasks.
Using the Fiber Cleaner to Clean the Optical Fiber Connector
Step 4 Cause 3: Other alarms trigger the R_LOF alarm (in the case of the IF board).
1. On the NMS, check whether the MW_FEC_UNCOR alarm occurs. If yes, clear the
alarm first.
2. Check whether the R_LOF alarm is cleared. If the alarm persists, go to Step Step 5.
Step 5 Cause 4: The receive board at the local station is faulty, and thus the frame structure is lost.
1. Perform a hardware inloop for the transmit and receive interfaces of the port that reports
the alarm at the local station. For details, see Hardware Loopback in the Supporting
Tasks.
NOTICE
A loopback causes service interruptions. In the case of a hardware inloop, the optical
power should not exceed the threshold. Add an optical attenuator to the optical interface
according to the optical power specifications of the board.
If... Then...
The R_LOF alarm persists The local board is faulty. Go to the next step.
2. Replace the board that reports the R_LOF alarm at the local station. If the board supports
the pluggable optical module, replace the pluggable optical module. For details, see
Replacing a Pluggable Optical Module in the Parts Replacement. Otherwise, replace the
faulty board. For details, see Replacing Boards Onsite in the Supporting Tasks.
3. Check whether the R_LOF alarm is cleared. If the alarm persists, go to Step Step 6.
Step 6 Cause 4: The transmit board (including the cross-connect board) at the opposite station is
faulty, and thus the frame structure is lost.
1. Replace the opposite board connected to the board that reports the R_LOF alarm. If the
board supports the pluggable optical module, replace the pluggable optical module. For
details, see Replacing a Pluggable Optical Module in the Parts Replacement. Otherwise,
replace the faulty board. For details, see Replacing Boards Onsite in the Supporting
Tasks. Check whether the R_LOF alarm is cleared.
2. If the alarm persists, replace the cross-connect and timing board at the opposite station.
For details, see Replacing a CXL Board in the Parts Replacement.
3. Check whether the R_LOF alarm is cleared. If the alarm persists, contact Huawei
technical support engineers to handle the alarm.
----End
Related Information
None.
7.54 R_OOF
Description
The R_OOF is an alarm indicating the out-of-frame event on the receive side of the line.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1 Indicates the actual number of the optical interface on the board that reports
the alarm.
If this section does not describe the common fault symptom or the actual fault symptom is not contained
in the description of this section, handle the R_OOF alarm by following the steps provided in Handling
Procedure.
None.
Possible Causes
The possible causes of the R_OOF alarm are as follows:
l Cause 1: The transmit cable is faulty, and the fiber connector is loose or contaminated.
l Cause 2: The receive board at the local station is faulty.
l Cause 3: The transmit board (including the cross-connect and timing board) at the
opposite station is faulty.
Procedure
Step 1 On the NMS, query the alarms. Based on the alarm parameters, determine the port that reports
the alarm. For details, see Viewing the Current Alarms in the Supporting Tasks.
Step 2 Cause 1: The transmit cable is faulty, and the fiber connector is loose or contaminated.
1. Check whether the transmit optical power of the board connected to the board that
reports the alarm is within the normal range. For details on the optical power of the
board, see Specifications of the Boards in the Technical Specifications Reference. For
details, see Querying the Optical Power in the Supporting Tasks.
NOTE
For details on the manufacturer information about the optical module, see Querying the Board
Manufacturer Information Report in the Supporting Tasks or Bar Code in the Hardware
Description.
If... Then...
The transmit optical power of the opposite board is abnormal Go to Step Step 4.
The transmit optical power of the opposite board is normal Go to the next step.
2. On the NMS, check whether the receive optical power of the local board is within the
normal range.
If... Then...
The receive optical power of the local board is very low Go to the next step.
The receive optical power of the local board is very high Go to Step Step 3.
3. Check whether the bend radius of the fiber jumper is within the normal range. If the bend
radius is less than 6 cm, roll the fiber jumper again. Check whether the R_OOF alarm is
cleared.
4. If the alarm persists, check whether the optical interface on the board is firmly connected
to the fiber jumper. Ensure that the fiber connector is firmly connected. Then, check
whether the R_LOS alarm is cleared.
5. If the alarm persists, check whether the fiber connector is contaminated. For details on
how to check the fiber connector, see Checking the Optical Fiber Connector in the
Supporting Tasks. For details on how to clean the fiber connectors, see the Supporting
Tasks.
Using the Fiber Cleaner to Clean the Optical Fiber Connector
Using the Lens Tissue to Clean the Optical Fiber Connector
Using the Dust-Free Cotton Bar to Clean the Optical Fiber Adapter
6. Check whether the optical cable is aged, damaged, or pressed. If yes, replace the optical
cable. Check whether the R_OOF alarm is cleared. If the alarm persists, go to Step Step
3.
Step 3 Cause 2: The receive board at the local station is faulty.
1. Perform a hardware inloop for the transmit and receive interfaces of the port that reports
the alarm at the local station. For details, see Hardware Loopback in the Supporting
Tasks.
NOTICE
A loopback causes service interruptions. In the case of a hardware inloop, the optical
power should not exceed the threshold. Add an optical attenuator to the optical interface
according to the optical power specifications of the board.
If... Then...
The R_OOF alarm persists The local board is faulty. Go to the next step.
2. Replace the board that reports the R_OOF alarm at the local station. If the board supports
the pluggable optical module, replace the pluggable optical module. For details, see
Replacing a Pluggable Optical Module in the Parts Replacement. Otherwise, replace the
faulty board. For details, see Replacing Boards Onsite in the Supporting Tasks.
3. Check whether the R_OOF alarm is cleared. If the alarm persists, go to Step Step 4.
Step 4 Cause 3: The transmit board (including the cross-connect and timing board) at the opposite
station is faulty.
1. Replace the opposite board connected to the board that reports the R_OOF alarm. If the
board supports the pluggable optical module, replace the pluggable optical module. For
details, see Replacing a Pluggable Optical Module in the Parts Replacement. Otherwise,
replace the faulty board. For details, see Replacing Boards Onsite in the Supporting
Tasks. Check whether the R_OOF alarm is cleared.
2. If the alarm persists, replace the cross-connect and timing board at the opposite station.
For details, see Replacing a CXL Board in the Parts Replacement.
3. Check whether the R_OOF alarm is cleared. If the alarm persists, contact Huawei
technical support engineers to handle the alarm.
----End
Related Information
None.
7.55 R_LOS
Description
The R_LOS is an alarm indicating loss of signals on the receive side of the line.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1 Indicates the actual number of the interface on the board that reports the alarm.
If this section does not describe the common fault symptom or the actual fault symptom is not contained
in the description of this section, handle the R_LOS alarm by following the steps provided in Handling
Procedure.
None.
Possible Causes
The possible causes of the R_LOS alarm are as follows:
Optical Interface Board
l Cause 1: The local optical interface is not in use (in the case of the optical interface
board).
l Cause 2: The opposite laser is shut down, and thus no optical signals are accessed (in the
case of the optical interface board).
l Cause 4: The signal modes of both ends are different (in the case of the STM-1 electrical
interface board).
IF Board
l Cause 5: Other alarms trigger the R_LOS alarm (in the case of the IF board).
Common Cause
Procedure
Step 1 On the NMS, query the alarms. Based on the alarm parameters, determine the port that reports
the alarm. For details, see Viewing the Current Alarms in the Supporting Tasks.
Step 2 Cause 1: The local optical interface is not in use (in the case of the optical interface board).
1. Check whether the port that reports the R_LOS alarm is in use or whether the optical
interface of this port is connected to the fiber that is not in use. If the fiber is not in use,
perform a selfloop for the transmit and receive optical interfaces by using fibers.
If... Then...
The port is not in use or You need not handle the R_LOS alarm. To clear the R_LOS
connected to fibers alarm, suppress it on the NMS or perform a selfloop for the
transmit and receive interfaces of the port by using fibers.
NOTE
Suppression of the R_LOS alarm may trigger the reporting of other
alarms.
NOTICE
In the case of a hardware loopback at the optical interface, the
optical power should not exceed the threshold.
Step 3 Cause 2: The opposite laser is shut down, and thus no optical signals are accessed (in the case
of the optical interface board).
1. Check whether the laser of the opposite port connected to the port that reports the
R_LOS alarm is shut down.
If... Then...
The laser is shut down Start up the laser. For details, see Enabling/Disabling Lasers
in the Supporting Tasks. Check whether the R_LOS alarm is
cleared. If the alarm persists, go to Step Step 6.
Step 4 Cause 4: The signal modes of both ends are different (in the case of the STM-1 electrical
interface board).
1. Check whether the signal mode of the opposite board connected to the board that reports
the R_LOS alarm is correctly set. If the board supports both the optical interface and
electrical interface, the actual signal mode of a port should be the same as the preset
Working Mode. If they are not the same, modify the setting of Working Mode. For
details on the setting of the SDH board series, see Checking Board Parameters in the
Configuration Guide.
2. Check whether the R_LOS alarm is cleared. If the alarm persists, go to Step Step 7.
Step 5 Cause 5: Other alarms trigger the R_LOS alarm (in the case of the IF board).
1. On the NMS, check whether the MW_FEC_UNCOR alarm is reported on the IF board.
If yes, clear the alarm first.
2. Check whether the R_LOS alarm is cleared. If the alarm persists, go to Step Step 8.
Step 6 Cause 3: A fiber cut occurs or the performance of the line declines. (in the case of the optical
interface board)
1. Check whether the transmit optical power of the board connected to the board that
reports the alarm is within the normal range. For details on the optical power of the
board, see Specifications of the Boards in the Technical Specifications Reference. For
details on how to query the transmit optical power of a board, see Querying the Optical
Power in the Supporting Tasks.
NOTE
For details on the manufacturer information about the optical module, see Querying the Board
Manufacturer Information Report in the Supporting Tasks or Bar Code in the Hardware
Description.
If... Then...
The transmit optical power of the opposite board is abnormal Go to Step Step 9.
The transmit optical power of the opposite board is normal Go to the next step.
2. Perform a hardware inloop for the transmit and receive interfaces on the local receive
board. For details, see Hardware Loopback in the Supporting Tasks.
NOTICE
A loopback causes service interruptions. In the case of a hardware loopback at the
optical interface, the optical power should not exceed the threshold. In the case of a
hardware inloop, the optical power should not exceed the threshold. Add an optical
attenuator to the optical interface according to the optical power specifications of the
board.
If... Then...
The R_LOS alarm is Repeat Steps Step 6.3 to Step 6.6 to check the fiber
cleared jumpers and fiber connectors at the local and opposite
stations.
3. Check whether the bend radius of the fiber jumper is within the normal range. If the bend
radius is less than 6 cm, roll the fiber jumper again. Check whether the R_LOS alarm is
cleared.
4. If the alarm persists, check whether the fiber jumper is properly connected to the optical
interface. For details, see the Quick Installation Guide.
If... Then...
The fiber jumper is Reconnect the fiber jumpers between the optical boards
improperly connected in the subrack according to the actual networking.
Check whether the R_LOS alarm is cleared. If the alarm
persists, go to the next step.
5. Check whether the optical interface on the board is firmly connected to the fiber jumper.
Ensure that the fiber connector is firmly connected. Then, check whether the R_LOS
alarm is cleared.
6. If the alarm persists, check whether the fiber connector is contaminated. For details on
how to check the fiber connector, see Checking the Optical Fiber Connector in the
Supporting Tasks. For details on how to clean the fiber connectors, see the Supporting
Tasks.
Using the Fiber Cleaner to Clean the Optical Fiber Connector
Using the Lens Tissue to Clean the Optical Fiber Connector
Using the Dust-Free Cotton Bar to Clean the Optical Fiber Adapter
Check whether the R_LOS alarm is cleared. If the alarm persists, go to the next step.
7. Use the optical time-domain reflectometer (OTDR) to check whether a fiber cut occurs
and locate the fiber cut if any according to the displayed attenuation curve of the line.
For details on the usage of the OTDR, see the operation instructions.
If... Then...
A fiber cut occurs on the line Replace the fiber. Then, check whether the R_LOS
alarm is cleared. If the alarm persists, go to Step Step
8.
Step 7 Cause 3: A fiber cut occurs or the performance of the line declines. (in the case of the STM-1
electrical interface board)
1. Exchange the cables that are possibly faulty in the receive and transmit directions to
locate the fault.
If... Then...
The R_LOS alarm changes after the cables are exchanged Go to the next step.
The R_LOS alarm does not change after the cables are Go to other causes.
exchanged
2. Check whether the cable is grounded properly and whether the cable connector and cable
are damaged. If the cable is faulty, replace the cable. Check whether the R_LOS alarm is
cleared. If the alarm persists, go to Step Step 8.
Step 8 Cause 6: The receive board at the local station is faulty, and thus the signal fails to be received
on the line.
1. Replace the board that reports the R_LOS alarm at the local station. If the board supports
the pluggable optical module, replace the pluggable optical module. For details, see
Replacing a Pluggable Optical Module in the Parts Replacement. Otherwise, replace the
faulty board. For details, see Replacing Boards Onsite in the Supporting Tasks.
2. Check whether the R_LOS alarm is cleared. If the alarm persists, go to Step Step 9.
Step 9 Cause 7: The transmit board (including the cross-connect and timing board) at the opposite
station is faulty, and thus the signal fails to be transmitted on the line.
1. Replace the opposite board connected to the board that reports the R_LOS alarm. If the
board supports the pluggable optical module, replace the pluggable optical module. For
details, see Replacing a Pluggable Optical Module in the Parts Replacement. Otherwise,
replace the faulty board. For details, see Replacing Boards Onsite in the Supporting
Tasks. Check whether the R_LOS alarm is cleared.
2. If the alarm persists, replace the cross-connect and timing board at the opposite station.
For details, see Replacing a CXL Board in the Parts Replacement.
3. Check whether the R_LOS alarm is cleared. If the alarm persists, contact Huawei
technical support engineers to handle the alarm.
----End
Related Information
None.
7.56 SLAVE_WORKING
Description
The SLAVE_WORKING is an alarm indicating that the protection board is working. This
alarm occurs when the service bus of the service board selects the protection cross-connect
board and the slave clock is selected as the system clock.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1 For the cross-connect, SDH, PDH (including DDN), ATM, RPR, and IF
boards, the value of Parameter 1 is always 0x01.
For the WDM boards, Parameter 1 indicates the port ID and the value is
always 0x01.
For the EFT8 and EFT8A boards, Parameter 1 indicates the working mode of
the standby board.
l 0x00: cross-connect bus.
l 0x01: clock board.
l 0x02: SCC board.
l 0x03: service chip bus.
For the EoS board, Parameter 1 indicates the port ID and the value is always
0x01.
Name Meaning
Parameter 2 For the cross-connect, SDH, PDH (including DDN), ATM, RPR, and IF
boards, Parameter 1 indicates the switching mode of the active and standby
cross-connect boards and the value is always 0x00.
For the WDM boards, Parameter 2 and Parameter 3 indicate the path ID and
the value is always 0x01.
For the EFT8 and EFT8A boards, Parameter 2 has different meanings when
Parameter 1 takes different values.
l If Parameter 1 is 0x00 or 0x03, Parameter 2 indicates the bus number.
l If Parameter 1 is 0x01 or 0x02, Parameter 2 is always 0x01.
For the EGS2, EFS0, and EFS4 boards, Parameter 2 indicates the path ID and
the value is 0x0E. That is, the programmable logic component is faulty.
For the EMS4, EGS4, and EAS2 boards, Parameter 2 and Parameter 3 are
meaningless and the value is always 0x01.
Parameter 3 For the cross-connect, SDH, PDH (including DDN), ATM, RPR, and IF
boards, Parameter 3 indicates the slot ID of the cross-connect board and the
value is always 0x01.
For the EFT8 and EFT8A boards, Parameter 3 indicates the slot ID of the
standby board.
If this section does not describe the common fault symptom or the actual fault symptom is not contained
in the description of this section, handle the SLAVE_WORKING alarm by following the steps provided
in Handling Procedure.
None.
Possible Causes
The possible causes of the SLAVE_WORKING alarm are as follows:
l Cause 1: The working cross-connect and timing board is not in position.
l Cause 2: The working cross-connect and timing board is faulty.
l Cause 3: A certain service board is faulty.
Procedure
Step 1 Cause 1: The working cross-connect and timing board is not in position.
1. Check whether the working cross-connect and timing board is firmly inserted. If not, re-
insert the working cross-connect and timing board. For details, see Installing the Boards
in the Installation Reference.
2. Check whether the SLAVE_WORKING alarm is cleared. If the alarm persists, go to Step
Step 2.
NOTICE
If there is no protection cross-connect and timing board, performing a cold reset on the
working cross-connect and timing board may cause service interruptions.
2. Check whether the SLAVE_WORKING alarm is cleared. If the alarm persists, replace
the working cross-connect and timing board. For details, see Replacing a CXL Board in
the Parts Replacement.
3. Check whether the SLAVE_WORKING alarm is cleared. If the alarm persists, go to Step
Step 3.
NOTICE
If the service on the board is not protected, a cold reset on the board causes service
interruptions.
2. Check whether the SLAVE_WORKING alarm is cleared. If the alarm persists, replace
the board that reports the alarm. For details, see Replacing Boards Onsite in the
Supporting Tasks.
Check whether the SLAVE_WORKING alarm is cleared. If the alarm persists, contact
Huawei technical support engineers to handle the alarm.
----End
Related Information
The working cross-connect board refers to the cross-connect board installed in the slot with a
smaller ID.
The protection cross-connect board refers to the cross-connect board installed in the slot with
a larger ID.
7.57 SYN_BAD
Description
The SYN_BAD indicates that the quality of the synchronization source declines. This alarm
occurs when the quality of the clock synchronization source traced by the equipment declines.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
If this section does not describe the common fault symptom or the actual fault symptom is not contained
in the description of the common fault symptom, handle the SYN_BAD alarm by following the steps
provided in Handling Procedure.
Table 7-30 lists the common fault symptoms of the SYN_BAD alarm.
Only one cross-connect and timing board Cause 4: The cross-connect and timing
reports the SYN_BAD alarm. board works abnormally.
Possible Causes
The possible causes of the SYN_BAD alarm are as follows:
Procedure
Step 1 Query the clock source that the equipment currently traces. For details, see Viewing Clock
Synchronization Status in the Feature Description.
If... Then...
The external clock source reports the alarm, as indicated by the ID Go to Step Step 2.
The line clock source reports the alarm, as indicated by the ID Go to Step Step 3.
The tributary clock source reports the alarm, as indicated by the ID Go to Step Step 4.
Step 2 Cause 1: The quality of the traced external clock source declines.
1. According to the clock signal flow, check whether the SYN_BAD alarm is reported on
the upstream station.
If... Then...
The SYN_BAD alarm occurs Locate the station where the SYN_BAD alarm
first occurs.
2. Check whether the input mode of the external clock signal matches the type of the
external clock signal. For details, see the handling procedures of the EXT_SYNC_LOS
alarm. Check whether the SYN_BAD alarm is cleared. If the alarm persists, go to the
next step.
3. Check whether the external clock cable is loose, pressed, or damaged. If yes, reinstall the
connector of the cable or replace the faulty cable. Check whether the SYN_BAD alarm
is cleared. If the alarm persists, go to the next step.
4. Check whether the external clock is usable. Contact Huawei technical support engineers
to check the DA value of the external clock. If the external clock is unusable, replace the
external clock source equipment.
5. Check whether the SYN_BAD alarm is cleared. If the alarm persists, go to Step Step 5.
Step 3 Cause 2: The quality of the traced line clock source declines.
1. According to the clock signal flow, check whether the SYN_BAD alarm is reported on
the upstream station.
If... Then...
The SYN_BAD alarm occurs Locate the station where the SYN_BAD alarm
first occurs.
2. If the line performance of the traced clock source declines, the precision of the clock
source decreases and the quality of the output clock signal becomes poor. On the NMS,
check whether any higher-level bit error alarms or performance events are reported on
the line board where the clock source resides.
If... Then...
The B1_EXC or B1_SD alarm, or See the handling procedures of these alarms
the RSBBE performance event is and performance events to clear the clock
reported alarm caused by bit errors.
Check whether the SYN_BAD alarm is
cleared. If the alarm persists, go to the next
step.
3. Perform a cold reset on the line board by using the NMS, or directly reseat this board.
For details on how to perform a cold reset, see Resetting Boards in the Supporting Tasks.
For details on how to reseat a board, see Removing the Boards in the Installation
Reference and Installing the Boards in the Installation Reference.
NOTICE
If the service on the board is not protected, a cold reset on the board causes service
interruptions.
4. After five minutes, check whether the SYN_BAD alarm is cleared. If the alarm persists,
replace the line board. For details, see Replacing an SDH Board in the Parts
Replacement.
5. Check whether the SYN_BAD alarm is cleared. If the alarm persists, go to Step Step 5.
Step 4 Cause 3: The quality of the traced tributary clock source declines.
1. According to the clock signal flow, check whether the SYN_BAD alarm is reported on
the upstream station.
If... Then...
The SYN_BAD alarm occurs Locate the station where the SYN_BAD alarm
first occurs.
2. Check whether the cable connected to the tributary board where the clock source resides
is loose, pressed, or damaged. If yes, reinstall the connector of the cable or replace the
faulty cable. Then, check whether the SYN_BAD alarm is cleared. If the alarm persists,
go to the next step.
3. Perform a cold reset on the tributary board by using the NMS, or directly reseat this
board. For details on how to perform a cold reset, see Resetting Boards in the Supporting
Tasks. For details on how to reseat a board, see Removing the Boards in the Installation
Reference and Installing the Boards in the Installation Reference.
NOTICE
If the service on the board is not protected, a cold reset on the board causes service
interruptions.
4. After five minutes, check whether the SYN_BAD alarm is cleared. If the alarm persists,
replace the tributary board. For details, see in the Parts Replacement.
5. Check whether the SYN_BAD alarm is cleared. If the alarm persists, go to Step Step 5.
Step 5 Cause 4: The cross-connect and timing board works abnormally.
If... Then...
The SYN_BAD alarm is reported on the The protection board may be faulty.
protection cross-connect and timing board Perform a cold reset on or reseat this board.
Go to Step Step 5.2.
1. Switch the working and protection cross-connect and timing boards. For details, see
Replacing a CXL Board in the Parts Replacement.
If... Then...
After the switching is complete, the The original working cross-connect and
original protection board does not timing board may be faulty. Perform a cold
report the SYN_BAD alarm reset on or reseat this board. Go to the next
step.
2. Perform a cold reset on the cross-connect and timing board by using the NMS, or
directly reseat this board. For details on how to perform a cold reset, see Resetting
Boards in the Supporting Tasks. For details on how to reseat a board, see Removing the
Boards in the Installation Reference and Installing the Boards in the Installation
Reference.
3. Check whether the SYN_BAD alarm is cleared. If the alarm persists, replace the relevant
cross-connect and timing board. For details, see Replacing a CXL Board in the Parts
Replacement.
4. Check whether the SYN_BAD alarm is cleared. If the alarm persists, contact Huawei
technical support engineers to handle the alarm.
----End
Related Information
None.
7.58 SUBCARD_ABN
Description
The SUBCARD_ABN alarm indicates that the type of the subcard configured for the SCC
board does not match the type of the installed interface board. In the case of an interface
board, if the type of the physical board does not match the type of the logical board, or if the
interface board cannot be detected, the SUBCARD_ABN alarm is reported.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 2, Indicate the slot number of the interface board. Parameter 2 has a fixed
Parameter 3 value of 0x00.
For Parameter 3:
l 0x01: interface board in the slot with a smaller ID
l 0x02: interface board in the slot with a larger ID
If there is no fault symptom or the actual fault symptom is not included in this section, handle the alarm
by following the steps provided in Handling Procedure.
Table 7-31 lists the common fault symptoms of the SUBCARD_ABN alarm.
Possible Causes
The possible causes of the SUBCARD_ABN alarm are as follows:
l Cause 1: In the case of an interface board, the type of the logical board does not match
the type of the physical board.
l Cause 2: The type of the interface board does not match the type of the processing board.
l Cause 3: The interface board cannot be detected.
l Cause 4: The board is faulty.
Procedure
Step 1 Cause 1: In the case of an interface board, the type of the logical board does not match the
type of the physical board.
1. According to the actual networking, check the type of the physical interface board.
2. On the NMS, check the type of the logical interface board. In the Main Topology,
double-click the SDH NE icon. Then, the NE panel is displayed.
If... Then...
The physical interface On the NMS, delete the original logical interface board
board is of the correct type and then add a new logical board. For details, see
Adding Boards in the Configuration Guide.
The logical interface board Replace the corresponding physical interface board. For
is of the correct type details, see Replacing Boards Onsite in the Supporting
Tasks.
3. Check whether the SUBCARD_ABN alarm is cleared. If the alarm persists, go to step
Step 2.
Step 2 Cause 2: The type of the interface board does not match the type of the processing board.
1. Check whether the type of the interface board matches the type of the processing board.
For details about the mapping relationship between the processing board and the
interface board, see "Interface Boards and Switching and Bridging Boards" in the
Hardware Description.
2. If the type of the interface board does not match the type of the processing board, use the
proper interface board according to the type of the processing board. For details, see
Replacing Boards Onsite in the Supporting Tasks.
3. Check whether the SUBCARD_ABN alarm is cleared. If the alarm persists, go to step
Step 4.
If... Then...
The interface In the Main Topology, double-click the SDH NE icon. Then, the
board is not NE panel is displayed. On the NMS, check the type of the logical
installed interface board.
According to the type of the logical board, see Step Step 3.2 to
insert the proper interface board.
The interface Check the status of the board. If the board is not firmly inserted,
board is installed see Step Step 3.2 to re-insert the interface board.
2. For details about how to insert a board, see Installing the Boards in the Installation
Reference. Check whether the SUBCARD_ABN alarm is cleared. If the alarm persists,
go to step Step 4.
----End
Related Information
A physical board refers to the board that is actually installed in the current subrack. A logical
board refers to the board that is created on the NMS and is stored on the SCC board. When
the equipment works normally, the physical board and the logical board need to be consistent
with each other.
7.59 TEMP_ALARM
Description
The TEMP_ALARM is an alarm indicating that the ambient temperature of a board crosses
the threshold. This alarm occurs when a board detects that the ambient temperature crosses
the specified threshold.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
If this section does not describe the common fault symptom or the actual fault symptom is not contained
in the description of this section, handle the TEMP_ALARM alarm by following the steps provided in
Handling Procedure.
Table 7-32 lists the common fault symptoms of the TEMP_ALARM alarm.
Possible Causes
The possible causes of the TEMP_ALARM alarm are as follows:
l Cause 1: The ambient temperature of the board is very high.
l Cause 2: The ambient temperature of the board is very low.
Procedure
Step 1 On the NMS, query the alarms and determine the board that reports the TEMP_ALARM
alarm. For details, see Viewing the Current Alarms in the Supporting Tasks.
Step 2 Cause 1: The ambient temperature of the board is very high.
If... Then...
The alarm is reported on the Take appropriate measures (for example, installing a
ODU sunshade) to control the temperature.
Check whether the TEMP_ALARM alarm is cleared. If the
alarm persists, go to the next step.
1. Replace the ODU. For details, see Replacing the ODU in the Microwave User Guide.
Then, check whether TEMP_ALARM alarm is cleared. If the alarm persists, contact
Huawei technical support engineers to handle the alarm.
2. Check the operation status of the fan in the subrack. For details, see the handling
procedure of the FAN_FAIL alarm.
3. Check whether the TEMP_ALARM alarm is cleared. If the alarm persists, replace the
faulty board. For details, see Replacing Boards Onsite in the Supporting Tasks.
4. Check whether the TEMP_ALARM alarm is cleared. If the alarm persists, contact
Huawei technical support engineers to handle the alarm.
Step 3 Cause 2: The ambient temperature of the board is very low.
1. The problem may be caused by the faulty temperature detection circuit of board.
If... Then...
The alarm is Replace the ODU. For details, see Replacing the ODU in the
reported on the Microwave User Guide.
ODU
Check whether the TEMP_ALARM alarm is cleared. If the
alarm persists, contact Huawei technical support engineers to
handle the alarm.
The alarm is Replace the faulty board. For details, see Replacing Boards
reported on the Onsite in the Supporting Tasks.
service board
Check whether the TEMP_ALARM alarm is cleared. If the
alarm persists, contact Huawei technical support engineers to
handle the alarm.
----End
Related Information
None.
7.60 TEMP_OVER
Description
The TEMP_OVER is an alarm indicating that the operating temperature of the board crosses
the threshold. This alarm occurs when the system detects that the operating temperature of the
board is higher than the upper threshold or lower than the lower threshold.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
Name Meaning
parameter 3 Indicates the threshold-crossing type of the board operating temperature for
EoS boards.
l 0x01: The operating temperature of the alarmed board is higher than the
upper threshold.
l 0x02: The operating temperature of the alarmed board is lower than the
lower threshold.
For other boards, Parameter 3 has a fixed value of 0x01.
Parameter 4 Indicates the threshold-crossing type of the board operating temperature for
cross-connect and system control boards, SDH boards, and PDH boards.
l 0x01: The operating temperature of the alarmed board is higher than the
upper threshold.
l 0x02: The operating temperature of the alarmed board is lower than the
lower threshold.
If this section does not describe the common fault symptom or the actual fault symptom is not contained
in the description of this section, handle the TEMP_OVER alarm by following the steps provided in
Handling Procedure.
None.
Possible Causes
The possible causes of the TEMP_OVER alarm are as follows:
Procedure
Step 1 Cause 1: The air filter is covered with dust.
1. Check whether the air filter is covered with dust, which causes the problem of heat
dissipation. You can feel the wind and the temperature of the wind at the air exhaust
vent.
2. If heat dissipation is impeded due to the dusty air filter, remove the air filter and clean it.
For details, see Cleaning the Air Filter in the Routine Maintenance.
3. Check whether the TEMP_OVER alarm is cleared. If the alarm persists, go to Step Step
2.
Step 2 Cause 2: The fan stops working.
1. Check the operation status of the fan in the subrack. For details, see the handling
procedure of the FAN_FAIL alarm.
2. Check whether the TEMP_OVER alarm is cleared. If the alarm persists, go to Step Step
3.
Step 3 Cause 3: The ambient temperature is very high or very low due to a fault on the cooler or
heater equipment.
1. Check the ambient temperature of the telecommunications room. If the temperature is
higher than 45C or lower than 0C, use a cooler or heater to decrease or increase the
ambient temperature.
NOTE
The TEMP_OVER alarm is cleared when the temperature of the board is 5C lower than the upper
threshold or 5C higher than the lower threshold. This can prevent jitters caused by transient
alarms.
2. Check whether the TEMP_OVER alarm is cleared. If the alarm persists, go to Step Step
4.
Step 4 Cause 4: A certain board is faulty.
1. Check whether the temperature chip of the board is damaged by checking whether the
CHIP_ABN alarm is reported. If the CHIP_ABN alarm occurs, replace the board that
reports the alarm. For details, see Replacing Boards Onsite in the Supporting Tasks.
2. Check whether the TEMP_OVER alarm is cleared. If the alarm persists, contact Huawei
technical support engineers to handle the alarm.
----End
Related Information
None.
7.61 TF
Description
The TF is an alarm of laser transmission failure. This alarm occurs when a board detects that
the output optical power of the laser exceeds the preset failure alarm threshold.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1 Indicates the actual number of the optical interface on a board where
the alarm occurs.
Parameter 2, Indicates the causes of the alarm. Parameter 2 is always 0x00, and
Parameter 3 Parameter 3 is always 0x01. The values indicate that the alarm is
caused by the output optical power.
If this section does not describe the common fault symptom or the actual fault symptom is not contained
in the description of this section, handle the TF alarm by following the steps provided in Handling
Procedure.
None.
Possible Causes
The possible causes of the TF alarm are as follows:
Procedure
Step 1 On the NMS, query the alarms and determine the board that reports the TF alarm. For details,
see Viewing the Current Alarms in the Supporting Tasks.
----End
Related Information
None.
7.62 T_LOSEX
Description
The T_LOSEX is an alarm indicating that a board has detected the loss of signal in the service
bus of the backplane. The T_LOSEX alarm is reported if a board has detected that the service
bus of the backplane is in the LOS status.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1 In the case of SDH boards and Ethernet boards, the value is always 0x01
and this parameter is meaningless.
In the case of N1 and R1 series PDH boards, this parameter indicates the
serial number of the input on the backplane bus. Each bit indicates a
backplane bus.
In the case of N1, R2, and R3 series PDH boards, this parameter indicates
the ID of the optical interface. The value is always 0x01.
Parameter 2, In the case of PDH boards, this parameter indicates the path number. The
Parameter 3 value of Parameter 2 is always 0x00 and the value of Parameter 3 is always
0x01.
Name Meaning
Parameter 4 In the case of PDH boards, this parameter indicates the slot ID of the cross-
connect board of the bus.
l bit[0]: The bus on the cross-connect board that has a smaller slot ID is
faulty.
l bit[1]: The bus on the cross-connect board that has a larger slot ID is
faulty.
Parameter 2, In the case of SDH boards and Ethernet boards, the value of Parameter 2 is
Parameter 3 always 0x00, and Parameter 3 indicates the slot ID of the cross-connect
board of the service bus.
l 0x01: The cross-connect board has a smaller slot ID.
l 0x02: The cross-connect board has a larger slot ID.
Parameter 4, In the case of SDH boards and Ethernet boards, each bit indicates a
Parameter 5 backplane bus that is damaged. Parameter 4 indicates the least significant
byte, and Parameter 5 indicates the most significant byte.
l If bit[0] of Parameter 4 is in value 1, the first bus is damaged.
l If bit[0] of Parameter 5 is in value 1, the ninth bus is damaged.
If this section does not describe the common fault symptom or the actual fault symptom is not contained
in the description of this section, handle the T_LOSEX alarm by following the steps provided in
Handling Procedure.
None.
Possible Causes
The possible causes of the T_LOSEX alarm are as follows:
l Cause 1: The service board and the corresponding cross-connect board are inserted
improperly.
l Cause 2: The board hardware is faulty.
l Cause 3: Certain pins on the backplane are bent.
Procedure
Step 1 Check the alarm on the NMS, determine the service board that reports the alarm, and then
confirm the corresponding cross-connect board according to the alarm parameters. For details,
see Viewing the Current Alarms in the Supporting Tasks.
Step 2 Cause 1: The service board and the corresponding cross-connect board are inserted
improperly.
1. Check whether the service board that reports the alarm and the corresponding cross-
connect board are inserted firmly to the backplane.
If... Then...
The boards are not Reseat the boards. For details on how to reseat a board, see
inserted firmly Removing the Boards in the Installation Reference and
Installing the Boards in the Installation Reference.
Check whether the alarm is cleared. If the alarm persists, go to
Step Step 3.
If... Then...
----End
Related Information
None.
7.63 TU_AIS
Description
The TU_AIS is a TU alarm indication signal. If a board detects that the signals in the TU path
are all "1"s, the TU_AIS alarm is reported.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1 Indicates the number of the optical interface that reports the alarm, in the
case of the PQM board or data board.
Indicates the service mode in the case of the other tributary boards.
l 0x01: The transmitted service is a traditional PDH service.
l 0x40: The N2PQ1 board works in MUX/SERVER mode (E13/M13
Function).
l 0x21: The R2PD1 board works in MUX/SERVER mode (E13/M13
Function).
l 0x0d: The N2PQ3 board works in DEMUX/SERVER mode (E13/M13
Function).
l 0x07: The N2PD3 board works in DEMUX/SERVER mode (E13/M13
Function).
l 0x04: The N2PL3 or N2PL3A board works in DEMUX/SERVER mode
(E13/M13 Function).
Parameter 2 Indicate the number of the path that reports the alarm. Parameter 2 indicates
and the most significant byte and Parameter 3 indicates the least significant byte.
Parameter 3
For example, when Parameter 2 = 0x00 and Parameter 3 = 0x01, the
TU_AIS alarm is reported by path 1 of the board.
When the N2PQ1 or R2PD1 board works in MUX mode, the path number is
indicated from the value of 0x40. That is, the TU_AIS alarm occurs in the
first VC-3 path.
If this section does not describe the common fault symptom or the actual fault symptom is not contained
in the description of this section, handle the TU_AIS alarm by following the steps provided in Handling
Procedure.
Table 7-33 lists the common fault symptoms of the TU_AIS alarm.
The higher level alarms listed in Table 7-34 Cause 1: The alarm that occurs on the
occur on the upstream NE. upstream NE causes AIS insertion at the
downstream NE.
The TU_AIS alarm is reported by all lower Cause 3: The transmit board (including
paths on multiple boards of the NE. The alarm the cross-connect and timing board) at
may be caused by the fault of the clock unit. the opposite NE is faulty.
Possible Causes
The possible causes of the TU_AIS alarm are as follows:
l Cause 1: The alarm that occurs on the upstream NE causes AIS insertion at the
downstream NE.
NE1 NE2
TU_AIS
Adding lower order services Dropping lower order services
TU [VC4-1:48(VC12)] TU
[VC4-1:49(VC12)]
l Cause 3: The transmit board (including the cross-connect and timing board) at the
opposite NE is faulty.
l Cause 4: The receive board (including the cross-connect and timing board) at the local
NE is faulty.
Procedure
Step 1 On the NMS, query the alarms and determine the board that reports the alarm. Then,
determine the path that reports the alarm according to alarm parameters. For details, see
Viewing the Current Alarms in the Supporting Tasks.
Step 2 Cause 1: The alarm that occurs on the upstream NE causes AIS insertion at the downstream
NE.
1. According to the signal flow, check whether any higher level alarms that can cause
TU_AIS insertion occur on the local NE and upstream NE.
If... Then...
Any of the alarms listed in Table Clear these alarms first. Check whether the
7-34 occurs TU_AIS alarm is cleared. If the alarm persists,
go to Step Step 3.
If... Then...
Step 4 Perform loopbacks to locate the NE that first reports the TU_AIS alarm according to the
signal flow. For the loopback capabilities of the boards, see Loopback Capability of the
Boards in the Hardware Description.
NOTICE
A loopback causes service interruptions. If the other services on the upstream NE use the
same VC-4 path as the path that reports the alarm on the local NE, do not perform a loopback
at the upstream NE.
BER
Tester LU: Line unit
TU: Tributary unit
XCS: Cross-connect unit
1. As shown in Figure 7-48, if the local NE (NE4) reports the TU_AIS alarm, perform an
inloop at the VC-4 path that corresponds to the east line board of NE1. For details on
how to loop back a board, see the Supporting Tasks.
Setting a Loopback on an SDH Optical Interface Board
Setting a Loopback on a PDH Electrical Interface Board
Setting a Loopback on an Ethernet Port
Setting a Loopback on an ATM Board Port
Setting Loopback on the IF Board
2. Check whether the bit errors occur in the signal received at the BER tester.
If... Then...
Bit errors occur The fault occurs on the NE that is looped back, such as NE1.
Release the loopback, and then go to Step Step 5.
No bit errors The fault occurs on the upstream NE, such as NE2, NE3, or NE4.
occur Release the loopback, and then go to the next step.
3. According to the signal flow, perform inloops in turn at the VC-4 paths that correspond
to the east line boards of the downstream NEs until the NE that first reports the TU_AIS
alarm is located. Then, release the loopback, and go to Step Step 5.
4. When performing an inloop at the VC-4 path that corresponds to the east line board of
NE3, check whether the bit errors occur in the signal received at the BER tester.
If... Then...
Bit errors occur The fault occurs on NE3. Release the loopback, and then go to
Step Step 5.
No bit errors occur The fault occurs on the east line board of NE3 or NE4. Release
the loopback, and then go to the next step.
5. Perform a hardware inloop at the optical interface on the east line board of NE3. For
details, see Hardware Loopback in the Supporting Tasks. Check whether the bit errors
occur in the signal received at the BER tester.
NOTICE
A loopback causes service interruptions. In the case of a hardware inloop, the optical
power should not exceed the threshold. Add an optical attenuator to the optical interface
according to the optical power specifications of the board.
If... Then...
Bit errors occur The fault occurs on the east line board of NE3. Release the
loopback, and then go to Step Step 6.
No bit errors occur The fault occurs on NE4. Release the loopback, and then go to
Step Step 5.
Step 5 Locate the board that first reports the TU_AIS alarm.
If... Then...
The NE that first reports the TU_AIS alarm is Perform an outloop at the PDH
the source of the PDH service. As shown in electrical interface of the tributary
Figure 7-48, NE1 is the source of the PDH board on NE1, and then go to Step
service. Step 5.1.
The NE that first reports the TU_AIS alarm is Perform an outloop at the west line
the sink of the PDH service. As shown in Figure board of NE4, and then go to Step
7-48, NE4 is the sink of the PDH service. Step 5.2.
The NE that first reports the TU_AIS alarm is Perform an outloop at the west line
not the source or sink of the SDH service, for board of the NE. Go to Step Step 5.3.
example, NE2 or NE3
1. Check whether the bit errors occur in the signal received at the BER tester (source of the
PDH service).
If... Then...
Bit errors occur The fault occurs on the tributary unit of this NE. Release the
loopback, and then go to Step Step 6.
No bit errors The fault occurs on the SDH unit or cross-connect unit of this NE.
occur Release the loopback, and then go to Step Step 6.
2. Check whether the bit errors occur in the signal received at the BER tester (sink of the
PDH service).
If... Then...
Bit errors occur The fault occurs on the west line board of this NE. Release the
loopback, and then go to Step Step 7.
No bit errors The fault occurs on the PDH unit or cross-connect unit of this NE.
occur Release the loopback, and then go to Step Step 7.
3. Check whether the bit errors occur in the signal received at the BER tester (source and
sink of the non-PDH service).
If... Then...
Bit errors occur The fault occurs on the west line board of this NE. Release the
loopback, and then go to Step Step 6.
No bit errors The fault occurs on the east line board or cross-connect unit of this
occur NE. Release the loopback, and then go to Step Step 6.
Step 6 Cause 3: The transmit board (including the cross-connect and timing board) at the opposite
NE is faulty.
1. Replace the transmit board on the NE that first reports the TU_AIS alarm. For details on
how to replace a tributary unit, see in the Parts Replacement. For details on how to
replace a line unit, see Replacing an SDH Board in the Parts Replacement.
2. Check whether the TU_AIS alarm is cleared. If the alarm persists, replace the cross-
connect and timing board of this NE. For details, see Replacing a CXL Board in the
Parts Replacement.
3. Check whether the TU_AIS alarm is cleared. If the alarm persists, go to Step Step 7.
Step 7 Cause 4: The receive board (including the cross-connect and timing board) at the local NE is
faulty.
1. Replace the tributary unit on the NE that reports the TU_AIS alarm. For details, see in
the Parts Replacement.
2. Check whether the TU_AIS alarm is cleared. If the alarm persists, replace the line unit of
this NE. For details, see Replacing an SDH Board in the Parts Replacement.
3. Check whether the TU_AIS alarm is cleared. If the alarm persists, replace the cross-
connect and timing board of this NE. For details, see Replacing a CXL Board in the
Parts Replacement.
4. Check whether the TU_AIS alarm is cleared. If the alarm persists, contact Huawei
technical support engineers to handle the alarm.
----End
Related Information
AU_LOP HP_LOM
7.64 TU_LOP
Description
The TU_LOP is an alarm of TU pointer loss. This alarm occurs if a board detects that the TU-
PTR value is an invalid pointer or NDF reversion in eight consecutive frames.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
Name Meaning
Parameter 1 Indicates the number of the optical interface that reports the alarm, in the
case of the PQM board or data board.
Indicates the service mode in the case of the other tributary boards.
l 0x01: The transmitted service is a traditional PDH service.
l 0x40: The N2PQ1 board works in MUX/SERVER mode (E13/M13
Function).
l 0x21: The R2PD1 board works in MUX/SERVER mode (E13/M13
Function).
l 0x0d: The N2PQ3 board works in DEMUX/SERVER mode (E13/M13
Function).
l 0x07: The N2PD3 board works in DEMUX/SERVER mode (E13/M13
Function).
l 0x04: The N2PL3 or N2PL3A board works in DEMUX/SERVER mode
(E13/M13 Function).
Parameter 2, Indicate the number of the path that reports the alarm. Parameter 2 indicates
Parameter 3 the most significant byte and Parameter 3 indicates the least significant byte.
For example, when Parameter 2 = 0x00 and Parameter 3 = 0x01, the
TU_LOP alarm is reported by path 1 of the board.
Remarks:
When the N2PQ1 or R2PD1 board works in MUX mode, the path number is
indicated from the value of 0x40. That is, the TU_LOP alarm occurs in the
first VC-3 path.
If this section does not describe the common fault symptom or the actual fault symptom is not contained
in the description of this section, handle the TU_LOP alarm by following the steps provided in Handling
Procedure.
None.
Possible Causes
The possible causes of the TU_LOP alarm are as follows:
l Cause 1: Excessive bit errors are received at the local station.
l Cause 2: The cross-connect configuration of the service at the local station is incorrect.
l Cause 3: The transmit board (including the cross-connect and timing board) at the
opposite station is faulty.
l Cause 4: The receive board (including the cross-connect and timing board) at the local
station is faulty.
Procedure
Step 1 On the NMS, query the alarms and determine the board and path that report the alarm. For
details, see Viewing the Current Alarms in the Supporting Tasks.
Step 2 Cause 1: Excessive bit errors are received at the local station.
1. Along the signal flow, check whether any higher level alarms occur on the local station
and upstream station.
If... Then...
The R_LOS, R_LOF, AU_AIS, Clear these alarms first. Check whether the
or bit error alarm occurs TU_LOP alarm is cleared. If the alarm persists, go
to Step Step 3.
Step 3 Cause 2: The cross-connect configuration of the service at the local station is incorrect.
1. Along the signal flow, check whether the cross-connect configuration of the service is
correct.
If... Then...
Step 4 Cause 3: The transmit board (including the cross-connect and timing board) at the opposite
station is faulty. Cause 4: The receive board (including the cross-connect and timing board) at
the local station is faulty.
1. Perform loopbacks to locate the faulty board. For details, see the handling method of the
TU_AIS alarm.
2. Perform a cold reset on the faulty board by using the NMS, or directly reseat this board.
For details on how to perform a cold reset, see Resetting Boards in the Supporting Tasks.
For details on how to reseat a board, see Removing the Boards in the Installation
Reference and Installing the Boards in the Installation Reference.
NOTICE
If the service on the board is not protected, a cold reset on the board causes service
interruptions.
3. Check whether the TU_LOP alarm is cleared. If the alarm persists, replace the faulty
board.
l For details on how to replace a tributary unit, see in the Parts Replacement.
l For details on how to replace a line unit, see Replacing an SDH Board in the Parts
Replacement.
l For details on how to replace a cross-connect and timing unit, see Replacing a CXL
Board in the Parts Replacement.
4. Check whether the TU_LOP alarm is cleared. If the alarm persists, contact Huawei
technical support engineers to handle the alarm.
----End
Related Information
None.
7.65 UP_E1_AIS
Description
The UP_E1_AIS is an alarm indicating the upstream 2 Mbit/s signals. This alarm is reported
if a tributary board has detected that the upstream E1 signals are all "1"s.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 2, Indicates the path number. Parameter 2 is the higher byte, and Parameter 3
Parameter 3 is the lower byte.
For example, Parameter 2 = 0x00, Parameter 3 = 0x01. In this case, the
UP_E1_AIS alarm is reported from Path 1 of the board.
If this section does not describe the common fault symptom or if the actual fault symptom is not
contained in the description of the common fault symptom, handle the UP_E1_AIS alarm by following
the steps provided in Handling Procedure.
Table 7-35 lists the common fault symptoms of the UP_E1_AIS alarm.
In the service direction, the tributary unit at the Cause 1: The TU_LOP, TU_AIS, or
opposite end reports an alarm (such as the DOWN_E1_AIS alarm is generated on
TU_AIS, TU_LOP, or DOWN_E1_AIS alarm) the tributary board that interconnects
indicating lower order signals. with the tributary board at the local end.
In the service direction, the tributary board that Cause 2: The T_ALOS alarm is
is located at the interconnected NE and accesses generated on the tributary board that is
the 2 Mbit/s signals reports an alarm (such as located at the interconnected NE and
the T_ALOS alarm) indicating that the accessed accesses the 2 Mbit/s signals.
signals are lost.
In the service direction, a hardware fault alarm, Cause 3: A hardware fault alarm, such
such as the PLL_FAIL or CHIP_FAIL alarm, is as the PLL_FAIL or CHIP_FAIL alarm,
generated on the board that is located at the is generated on the tributary board that
interconnected tributary unit. interconnects with the tributary board at
the local end.
Possible Causes
The possible causes of the UP_E1_AIS alarm are as follows:
l Cause 1: The TU_LOP, TU_AIS, or DOWN_E1_AIS alarm is generated on the tributary
board that interconnects with the tributary board at the local end.
As shown in Figure 7-49, tributary unit 2 of NE1 interconnects with tributary unit 3 of
NE2. Tributary unit 2 detects the TU_LOP alarm and inserts all "1"s to a lower-level
trail. Tributary unit 3 accesses the PDH service over the transmission network. Tributary
unit 3 also detects and reports the UP_E1_AIS alarm.
TU_LOP UP_E1_AIS
T X T X X
T L Network L T
... U C U
U
C
U U
C
U
(1) S (2) S S
Adding NE1
lower order (Interconnected
services end)
l Cause 2: The T_ALOS alarm is generated on the tributary board that is located at the
interconnected NE and accesses the 2 Mbit/s signals.
As shown in Figure 7-49, tributary unit 1 of NE1 accesses the 2 Mbit/s signals.
Tributary unit 1 detects the T_ALOS alarm and inserts all "1"s to a lower-level trail.
Tributary unit 3 accesses the PDH service over the transmission network. Tributary unit
3 also detects and reports the UP_E1_AIS alarm.
T_ALOS UP_E1_AIS
T X T X X
T L Network L T
... U C U
U
C
U U
C
U
(1) S (2) S S
Adding NE1
lower order (Interconnected
services end)
PLL_FAIL UP_E1_AIS
T X T X X
T L Network L T
... U C U
U
C
U U
C
U
(1) S (2) S S
Adding NE1
lower order (Interconnected
services end)
T X T X X
T L Network L T
... U C U
U
C
U U
C
U
(1) S (2) S S
Adding NE1
lower order (Interconnected
services end)
Procedure
Step 1 Check the alarm on the NMS, and then determine the board where the alarm is generated. For
details, see Viewing the Current Alarms in the Supporting Tasks.
Step 2 Cause 1: The TU_LOP, TU_AIS, or DOWN_E1_AIS alarm is generated on the tributary
board that interconnects with the tributary board at the local end.
1. Check whether a lower order alarm is generated on the tributary board that interconnects
with the tributary board at the local end.
If... Then...
An alarm such as the TU_LOP, Clear the alarm immediately, and then check
TU_AIS, or DOWN_E1_AIS alarm is whether the UP_E1_AIS alarm is cleared. If
generated the UP_E1_AIS alarm persists, go to Step
Step 3.
Step 3 Cause 2: The T_ALOS alarm is generated on the tributary board that is located at the
interconnected NE and accesses the 2 Mbit/s signals.
1. Check whether the tributary unit that is located at the interconnected NE and accesses the
2 Mbit/s signals reports an alarm indicating that the accessed signals are lost.
If... Then...
An alarm such as the T_ALOS alarm is Clear the alarm immediately, and then
generated check whether the UP_E1_AIS alarm is
cleared. If the UP_E1_AIS alarm persists,
go to Step Step 4.
Step 4 Cause 3: A hardware fault alarm, such as the PLL_FAIL or CHIP_FAIL alarm, is generated
on the tributary board that interconnects with the tributary board at the local end.
1. Check whether a hardware fault alarm is generated on the tributary board that
interconnects with the tributary board at the local end.
If... Then...
An alarm such as the PLL_FAIL Clear the alarm immediately, and then check
or CHIP_FAIL alarm is generated whether the UP_E1_AIS alarm is cleared. If the
UP_E1_AIS alarm persists, go to Step Step 5.
NOTICE
If the service on the board is not protected, a cold reset on the board causes service
interruption.
2. Check whether the alarm is cleared. If the alarm persists, replace the tributary board that
reports the alarm. For details, see in the Parts Replacement.
3. Check whether the alarm is cleared. If the alarm persists, contact Huawei technical
support engineers to handle the alarm.
----End
Related Information
None.
7.66 W_R_FAIL
Description
The W_R_FAIL is an alarm indicating the failure of reading and writing the chip register.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
If this section does not describe the common fault symptom or the actual fault symptom is not contained
in the description of this section, handle the W_R_FAIL alarm by following the steps provided in
Handling Procedure.
None.
Possible Causes
The possible causes of the W_R_FAIL alarm are as follows:
Procedure
Step 1 On the NMS, query the alarms and determine the board that reports the W_R_FAIL alarm.
For details, see Viewing the Current Alarms in the Supporting Tasks.
NOTICE
If the service on the board is not protected, a cold reset on the board causes service
interruptions.
2. Check whether the W_R_FAIL alarm is cleared. If the alarm persists, replace the board
that reports the alarm. For details, see Replacing Boards Onsite in the Supporting Tasks.
3. Check whether the W_R_FAIL alarm is cleared. If the alarm persists, go to Step Step 3.
Step 3 Cause 2: The cross-connect and timing board is faulty.
1. Perform a cold reset on the cross-connect and timing board by using the NMS, or
directly reseat this board. For details on how to perform a cold reset, see Resetting
Boards in the Supporting Tasks. For details on how to reseat a board, see Removing the
Boards in the Installation Reference and Installing the Boards in the Installation
Reference.
NOTICE
If there is no protection cross-connect and timing board, performing a cold reset on the
working cross-connect and timing board may cause service interruptions.
2. Check whether the W_R_FAIL alarm is cleared. If the alarm persists, replace the cross-
connect and timing board. For details, see Replacing a CXL Board in the Parts
Replacement.
3. Check whether the W_R_FAIL alarm is cleared. If the alarm persists, contact Huawei
technical support engineers to handle the alarm.
----End
Related Information
None.
This chapter describes how to clear common alarms that have microwave features.
l Handle the root alarms first and then the non-root alarms.
According to the relation of common alarms, handle the root alarms caused by a fault or
an abnormal event first. Then, handle the non-root alarms caused by the root alarms.
l Check the NMS first and then the NE; check the external factors and then the
internal factors.
On the NMS, remotely check and analyze the alarms and performance events on the
equipment. Then, check the configuration and operations on the NE. Afterwards, check
the links between NEs. Finally, check the hardware of the NE on site.
l Check the common causes and then the special causes.
According to the experience in handling alarms and the information about other alarms,
check the common causes of the alarms, and then the special causes.
l Check the software first and then the hardware.
If the alarm is caused by the fault of the equipment, reset the board to rectify the
software fault and then replace the board to rectify the hardware fault.
l Operation environment
In the telecommunications room, the temperature and humidity do not meet the
requirements for long-time and short-time operations. For example, the environment is
not clean or the ventilation is poor.
l Voltage of power supply
The voltage of power supply is not the DC that supports the normal operation of the
equipment. The voltage fluctuates sharply and is more than 20% of the normal value.
l Grounding
The grounding resistance of the equipment is higher than 1 ohm. Hence, the equipment
can be easily damaged by lightening.
l Heat dissipation
The heat dissipation of the equipment is poor. For example, the exhaust vents are
blocked, the air filter is dirty, and the fans work abnormally.
For specific requirements on the operation environment, see "Operation Environment
Requirements" in the Installation Reference.
Precautions
NOTICE
The operations of reseating a board and performing a cold reset mentioned in this document
cause service interruptions. If the services are not protected, implement the operations with
caution.
NOTICE
Performing a self-loop for the first VC-4 path may affect the ECC communication. Thus, try
to avoid looping back the service of the first VC-4 path. If the loopback method cannot be
used to locate the fault, modify the configuration or use the substitution method to locate the
fault.
All the fault locating methods have advantages and disadvantages. The maintenance
personnel should use various methods to handle the alarm. For common fault handling
methods, see "Common Methods of Locating Faults" in the Troubleshooting.
NOTE
l The alarm parameters listed in this document are those displayed on the NMS. When you browse an
alarm on the NMS, select the alarm. In the Alarm Details field, the related parameters of the alarm
are displayed.
l If the methods provided in this document cannot clear the alarm, contact Huawei technical support
engineers to handle the alarm.
8.1 CONFIG_NOSUPPORT
8.2 IF_CABLE_OPEN
8.3 IF_INPWR_ABN
8.4 MW_BER_EXC
8.5 MW_BER_SD
8.6 MW_FEC_UNCOR
8.7 MW_LIM
8.8 MW_LOF
8.9 MW_RDI
8.10 NP1_MANUAL_STOP
8.11 NP1_SW_FAIL
8.12 NP1_SW_INDI
8.13 RADIO_MUTE
8.14 RADIO_RSL_HIGH
8.15 RADIO_RSL_LOW
8.16 RADIO_TSL_HIGH
8.17 RADIO_TSL_LOW
8.18 RPS_INDI
8.19 VOLT_LOS
8.1 CONFIG_NOSUPPORT
Description
The CONFIG_NOSUPPORT alarm indicates that the parameter settings of the ODU are not
supported. This alarm is reported when the ODU detects that the parameter settings do not
match the specifications of the ODU.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1 Indicates the parameter setting that does not meet the specified requirement.
Possible Causes
The possible causes of the CONFIG_NOSUPPORT alarm are as follows:
l Cause 1: The parameters of the ODU are set incorrectly.
Determination method: Check the parameter settings on the OptiX iManager network
management system (NMS).
Procedure
l Query the alarms on the NMS, and then determine the ODU that reports the alarm. For
details, see Viewing the Current Alarms in the Supporting Tasks.
l Cause 1: The parameters of the ODU are set incorrectly.
a. Determine the configuration data of the ODU interface or IF interface, which does
not meet the specified requirements, according to the values of the alarm
parameters.
NOTE
If the equipment is configured with 1+1 HSB/SD protection, you need to check only the
parameters of the ODU interface on the main ODU and the parameters of the IF interface on
the main IF board. Otherwise, you need to check the parameters of the ODU interface on the
ODU that reports the alarm and the parameters of the IF interface on the corresponding IF
board.
If... Then...
Parameter 1 = 0x01 - 0x03 Proceed to the next step.
Parameter 1 = 0x04 - 0x06 Proceed to step 3 of cause 1.
Parameter 1 = 0x07-0x08 The values 0x07 and 0x08 are reserved currently. If
this parameter is used, configure Tx high/low
stations and ODU types (SDH or PDH) as required.
b. Check whether the parameters of the ODU interface shown in parameter 1 meet the
requirements specified in the network planning and design document.
If... Then...
Yes Perform the operations required when the alarm is generated due to cause 2.
No Modify the parameters of the ODU interface. For details, see Configuring
Parameters of ODU Interfaces in the Microwave User Guide.
Check whether the alarm is cleared. If the alarm persists, perform the
operations that are required for clearing the alarm generated due to cause 2.
c. Check whether the parameters of the IF interface shown in parameter 1 meet the
requirements specified in the network planning and design document.
If... Then...
Yes Replace the IF board.
If... Then...
No Modify the parameters of the IF interface. For details, see Configuring
Parameters of IF Ports in Microwave User Guide.
Check whether the alarm is cleared. If the alarm persists, go to cause 2.
Related Information
None.
8.2 IF_CABLE_OPEN
Description
The IF_CABLE_OPEN alarm indicates that the IF cable is disconnected.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1 Indicates the ID of the IF port that reports the alarm. For example, 0x01
indicates that the alarm is reported by IF port 1 of the related board.
Possible Causes
The possible causes of the IF_CABLE_OPEN alarm are as follows:
l Cause 1: The IF cable is loose or faulty.
Determination method: Check whether the IF cable by checking whether the surface of
the IF cable is broken or damaged, or by using a tester.
l Cause 2: The IF port on the IF board is damaged.
Determination method: Check the IF port by using the fault exclusion method or by
referring to the record of previous similar cases.
l Cause 3: The power module of the ODU is faulty.
Determination method: Check the power module by using the fault exclusion method or
by referring to the record of previous similar cases.
Procedure
l Check the IF_CABLE_OPEN alarm on the U2000 to determine the board that reports
the alarm. For details, see Viewing the Current Alarms in the Supporting Tasks.
l Cause 1: The IF cable is loose or faulty.
a. Check whether the connector of the IF cable is loose or whether the connector is not
prepared according to the requirement.
The connectors to be checked refer to the connector between the IF fiber jumper
and the IF board, the connector between the IF fiber jumper and the IF cable, and
the connector between the IF cable and the ODU.
If... Then...
The connector is Switch off the ODU of the IF board. Tighten or reconnect
loose the connector. Switch on the ODU and then check whether
the alarm is cleared. If the alarm persists, proceed to the
next step.
If... Then...
The cable does not meet Replace the cable. Check whether the alarm is
the specified requirement cleared. If the alarm persists, perform the
operations that are required for clearing the alarm
generated due to cause 2.
The cable meets the Perform the operations required when the alarm is
specified requirement generated due to cause 2.
l Cause 2: The IF port on the IF board is damaged.
a. Replace the board that reports the IF_CABLE_OPEN alarm.
b. Check whether the alarm is cleared. If the alarm persists, perform the operations
that are required for clearing the alarm generated due to cause 3.
----End
Related Information
None.
8.3 IF_INPWR_ABN
Description
The IF_INPWR_ABN alarm indicates that the input IF power of the ODU is abnormal.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Possible Causes
The possible causes of the IN_PWR_ABN alarm are as follows:
l Cause 1: The IF cable is faulty.
Determination method: Check the IF cable using the fault exclusion method or by
referring to the record of previous similar cases.
l Cause 2: The IF board is faulty.
Determination method: Check the IF board by using the fault exclusion method or by
referring to the record of previous similar cases.
l Cause 3: The power module of the ODU is faulty.
Determination method: Check the power module by using the fault exclusion method or
by referring to the record of previous similar cases.
Procedure
l Check the IF_INPWR_ABN alarm on the U2000 to determine the board that reports the
alarm. For details, see Viewing the Current Alarms in the Supporting Tasks.
l Cause 1: The IF cable is faulty.
a. Check whether the connector of the IF cable is loose or whether the connector is not
made properly.
The connectors to be checked are the connector between the IF fiber jumper and the
IF board, the connector between the IF fiber jumper and the IF cable, and the
connector between the IF cable and the ODU.
If... Then...
The connector is Turn off the ODU switch on the IF board. Tighten or
loose reconnect the connector. Turn on the power switch of the
ODU and then check whether the alarm is cleared. If not,
proceed to the next step.
The connector is Obtain a new IF cable connector. For details, see
not made properly "Terminating the IF Cable with Connectors" in the ODU
Installation Guide. Check whether the alarm is cleared. If
not, proceed to the next step.
None of the above Proceed to the next step.
b. Check whether the surface of the IF cable is damaged. Test the connectivity of the
IF cable by using a multimeter. For details, see "Testing the Connectivity of the IF
Cable" in the ODU Installation Guide.
If... Then...
The cable does not meet the Replace the cable. Check whether the alarm is
specified requirement cleared. If not, perform the operations that are
required for clearing the alarm generated due to
cause 2.
The cable meets the Perform the operations required when the alarm is
specified requirement generated due to cause 2.
l Cause 2: The IF board is faulty.
a. Replace the IF board connected to the ODU that reports the alarm.
b. Check whether the alarm is cleared. If not, perform the operations that are required
for clearing the alarm generated due to cause 4.
l Cause 3: The power module of the ODU is faulty.
a. Replace the ODU that reports the alarm. For details, see Replacing the ODU in the
Microwave User Guide.
----End
Related Information
Generally, the input IF power of the ODU should range from -22 dB to 5 dB.
8.4 MW_BER_EXC
Description
The MW_BER_EXC alarm indicates that there are excessive bit errors on the radio link. This
alarm is reported if the BER on the radio link exceeds the specified threshold (10-3 by
default).
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1 Indicates the ID of the line port that reports the alarm. For example,
0x01 indicates that the alarm is reported by port 1 of the related board.
Parameter 2, Indicate the ID of the path that reports the alarm. For example, in the
Parameter 3 case of Parameter 2 = 0x00 and Parameter 3 = 0x01, the alarm is
reported from path 1 of the board.
Possible Causes
The possible causes of the MW_BER_EXC alarm are as follows:
l Cause 1: Signal attenuation on the radio link is too heavy.
Determination method: Query the alarms on the NMS.
l Cause 2: There is link interference.
Determination method: Query the alarms on the NMS or measure the interference with
instruments.
Procedure
l Cause 1: Signal attenuation on the radio link is too heavy. Cause 2: There is link
interference.
a. Check whether the local site reports the MW_FEC_UNCOR alarm. The
MW_FEC_UNCOR alarm may be caused by signal attenuation on the radio link,
co-channel interference, and adjacent channel interference. Handle the problem
according to the handling procedure of the MW_FEC_UNCOR alarm.
b. Then, check whether the MW_BER_EXC alarm is cleared. If the MW_BER_EXC
alarm persists, proceed to cause 3.
l Cause 3: The local IF board is faulty.
a. Replace the local IF board. Check whether the alarm is cleared. If the alarm
persists, replace the opposite IF board.
b. Then, check whether the MW_BER_EXC alarm is cleared. If the MW_BER_EXC
alarm persists, proceed to cause 4.
l Cause 4: The transmit unit on the opposite site is faulty.
a. Rectify the fault of the transmit unit on the opposite site.
----End
Related Information
None.
8.5 MW_BER_SD
Description
The MW_BER_SD alarm indicates that signals deteriorate on the radio link. This alarm is
reported if the BER on the radio link exceeds the specified threshold (10-6 by default) but
does not reach the MW_BER_EXC alarm threshold (10-3 by default).
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
Name Meaning
Parameter 1 Indicates the ID of the line port that reports the alarm. For example,
0x01 indicates that the alarm is reported by port 1 of the related board.
Parameter 2, Indicate the ID of the path that reports the alarm. For example, in the
Parameter 3 case of Parameter 2 = 0x00 and Parameter 3 = 0x01, the alarm is
reported from path 1 of the board.
Possible Causes
The possible cause of the MW_BER_SD alarm is as follows:
l Cause 1: Signal attenuation on the radio link is too heavy.
Determination method: Query the alarms on the NMS.
l Cause 2: There is link interference.
Determination method: Query the alarms on the NMS or measure the interference with
instruments.
l Cause 3: The local IF board is faulty.
Determination method: Check the local IF board by using exclusion method or empirical
method.
l Cause 4: The transmit unit on the opposite site is faulty.
Determination method: Check the transmit unit by using exclusion method or empirical
method.
Procedure
l Cause 1: Signal attenuation on the radio link is too heavy. Cause 2: There is link
interference.
a. Check whether the local site reports the MW_FEC_UNCOR alarm. The
MW_FEC_UNCOR alarm may be caused by signal attenuation on the radio link,
co-channel interference, and adjacent channel interference. Handle the problem
according to the handling procedure of the MW_FEC_UNCOR alarm.
b. Then, check whether the MW_BER_EXC alarm is cleared. If the MW_BER_EXC
alarm persists, proceed to cause 3.
l Cause 3: The local IF board is faulty.
a. Replace the local IF board. Check whether the alarm is cleared. If the alarm
persists, replace the opposite IF board.
b. Then, check whether the MW_BER_EXC alarm is cleared. If the MW_BER_EXC
alarm persists, proceed to cause 4.
----End
Related Information
None.
8.6 MW_FEC_UNCOR
Description
The MW_FECUNCOR alarm indicates that the microwave frame forward error correction
(FEC) function cannot correct the incorrect codes. This alarm is reported when uncorrectable
bit errors occur in the FEC code at the local station.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1 Indicates the ID of the IF port that reports the alarm. For example, 0x01
indicates that the alarm is reported by port 1 of the related board.
Possible Causes
The possible causes of the MW_FEC_UNCOR alarm are as follows:
Procedure
l Query the MW_FEC_UNCOR alarm on the NMS and determine the board that reports
the alarm. For details, see Viewing the Current Alarms in the Supporting Tasks.
l Cause 1: The receive power of the ODU is abnormal.
a. Check whether the history performance data of the RSL of the ODU at the local end
is abnormal.
If... Then...
The RSL is lower than Check whether the direction of the antenna is proper and
the receiver sensitivity check whether any obstacle (for example, a building) exists.
Follow the steps:
1. Check whether the azimuth angle of the antenna meets the
requirement of the network planning. If the azimuth angle
of the antenna does not meet the requirement, adjust the
azimuth angle of the antenna properly.
2. Check the direction of the antenna. Check whether the
received signal is transmitted from the main lobe. If the
direction of the antenna does not meet the requirement,
adjust the antenna in a wide range.
3. Check whether the setting of the polarization direction of
the antenna is correct. If the polarization direction of the
antenna is set incorrectly, adjust the incorrect polarization
direction. For details, see "Setting the Antenna
Polarization" in the ODU Installation Guide.
4. Check whether the antenna gain at both the transmit and
receive stations meets the specifications. If the antenna
gain at both the transmit and receive stations does not
meet the specifications, replace the antennas that do not
meet the requirement.
5. Check whether any obstacle (for example, a building or a
mountain) exists in the transmit direction. If any obstacle
exists in the transmit direction, contact the network
planning department for proper modification of the
planning design, hence preventing the block of the
mountain or building obstacle.
Check whether the alarm is cleared. If the alarm persists,
perform the operations that are required for clearing the alarm
generated due to the other causes.
If... Then...
The RSL is higher Slow up fading occurs. Check whether any co-channel
than the specified interference occurs. Perform the operations required when the
RSL of the network. alarm is generated due to cause 2.
The offset value is
more than decibels,
and the duration is
from more than ten
seconds to several
hours
The RSL is lower than Slow down fading occurs. Generally, the microwave link may
the specified RSL of be faulty at both sides, because slow fading is imposed by the
the network. The transmission path. Contact the network planning department
offset value is more to modify the networking planning and design. For example,
than decibels, and the increase the antenna gain, or reduce the transmission
duration is from more distance.
than ten seconds to
several hours l Increase the installation height of the antenna.
l Reduce the transmission distance.
l Increase the antenna gain.
l Increase the transmit power.
Check whether the alarm is cleared. If the alarm persists,
perform the operations that are required for clearing the alarm
generated due to the other causes.
The RSL is lower than Fast fading occurs. Generally, the microwave link may be
or higher than the faulty in both directions, because fast fading is imposed by
specified RSL of the the transmission path. Contact the network planning
network, and the department to modify the networking planning and design.
duration is from For example, adjust the position of the antenna, or
several milliseconds to reconfigure the link.
more than ten seconds
l Adjust the position of the antenna to block the reflected
wave or make the reflection point fall on the ground that
has a small reflection coefficient, thus reducing the
multipath fading.
l If the links are not in the 1+1 SD configuration, adjust the
RF configuration to make the links in the 1+1 SD
configuration.
l If the links are in the 1+1 SD configuration, adjust the
height offset between two antennas to make the receive
power of one antenna much stronger than the receive
power of the other antenna.
l Increase the fading margin.
Check whether the alarm is cleared. If the alarm persists,
perform the operations that are required for clearing the alarm
generated due to the other causes.
If... Then...
The receive power You can infer that there is co-channel interference that
exceeds -90 dBm may affect the long-term availability and errored-second
performance of the system. Go to Step 8.
The receive power is Check whether any adjacent channel interference occurs.
a bit higher than -90 Record the receive frequency and the value of channel
dBm spacing in Work Mode. Then, proceed to the next step.
c. Set Work Mode and change the value of the radio work mode of the local station to
the minimum value of channel spacing.
d. Decrease the received frequency at the local location by half of channel spacing.
e. Query and record the RSL.
f. Increase the received frequency at the local end, with a step length of 0.5 MHz or 1
MHz, and record the RSL accordingly until the received frequency is equal to the
original received frequency plus a half of the channel spacing.
g. Compare the recorded RSLs. If the RSL in a certain spectrum is abnormal if the
received frequency is within the permitted range.
h. Use a spectrum analyzer to analyze the interference source.
i. Contact the spectrum management department to clear the interference spectrum or
change plans to minimize the interference.
j. Check whether the alarm is cleared. If the alarm persists, perform the operations
that are required for clearing the alarm generated due to the other causes.
l Cause 3: The transmit unit of the opposite station is faulty.
a. Perform inloop on the IF port on the IF board at the opposite station. For details,
see Setting Loopback on the IF Board in the Microwave User Guide.
If... Then...
The MW_FEC_UNCOR is reported after Replace the IF board of the
the loopback is performed on the opposite opposite station. Then, check
station. whether the alarm is cleared. If
the alarm persists, proceed to the
next step.
The MW_FEC_UNCOR is not reported Proceed to the next step.
after the loopback is performed on the
opposite station.
b. Check whether the connector of the IF cable is loose or whether the connector is
prepared according to the requirement at the opposite station.
The connectors to be checked are the connector between the IF fiber jumper and the
IF board, the connector between the IF fiber jumper and the IF cable, and the
connector between the IF cable and the ODU.
If... Then...
The connector is loose Switch off the ODU on the IF board of the opposite
station. Tighten or reconnect the connector. Switch on
the ODU and then check whether the alarm is cleared. If
the alarm persists, proceed to the next step.
The connector is not Obtain a new IF cable connector of the opposite station.
prepared according to For details, see "Terminating the IF Cable with
the requirement Connectors" in the ODU Installation Guide. Then, check
whether the alarm is cleared. If the alarm persists,
proceed to the next step.
None of the preceding Proceed to the next step.
occur
c. Check whether the IF cables are wet, broken, or pressed at the opposite station. Test
the connectivity of the IF cable by using a multimeter. For details, see "Testing the
Connectivity of the IF Cable" in the ODU Installation Guide.
If... Then...
The cable does not meet the Replace the cable of the opposite station.
specified requirement Then, check whether the alarm is cleared. If the
alarm persists, proceed to the next step.
The cable meets the specified Proceed to the next step.
requirement
d. Replace the ODU of the opposite station. For details, see Replacing the ODU in the
Microwave User Guide.
e. Check whether the alarm is cleared. If the alarm persists, perform the operations
that are required for clearing the alarm generated due to the other causes.
l Cause 4: The receive unit of the local station is faulty.
a. Perform inloop on the IF port of the IF board at the local station. For details, see
Setting Loopback on the IF Board in the Microwave User Guide.
If... Then...
The MW_FEC_UNCOR alarm Replace the IF board of the local station.
persists after the loopback Check whether the alarm is cleared. If
the alarm persists, proceed to the next
step.
The MW_FEC_UNCOR is not Proceed to the next step.
reported after the loopback
b. Check whether the connector of the IF cable is loose or whether the connector is
prepared according to the requirement.
The connectors to be checked are the connector between the IF fiber jumper and the
IF board, the connector between the IF fiber jumper and the IF cable, and the
connector between the IF cable and the ODU.
If... Then...
The connector is loose Switch off the ODU on the IF board of the local station.
Tighten or reconnect the connector. Switch on the ODU
and then check whether the alarm is cleared. If the alarm
persists, proceed to the next step.
The connector is not Obtain a new IF cable connector of the local station. For
prepared according to details, see "Terminating the IF Cable with Connectors"
the requirement in the ODU Installation Guide. Check whether the alarm
is cleared. If the alarm persists, proceed to the next step.
None of the preceding Proceed to the next step.
occur
c. Check whether the IF cable of the local station is wet, broken, or pressed. Test the
connectivity of the IF cable by using a multimeter. For details, see "Testing the
Connectivity of the IF Cable" in the ODU Installation Guide.
If... Then...
The cable does not meet the Replace the cable of the local station. Check
specified requirement whether the alarm is cleared. If the alarm
persists, proceed to the next step.
The cable meets the specified Proceed to the next step.
requirement
d. Replace the ODU of the local station. For details, see Replacing the ODU in the
Microwave User Guide.
e. Check whether the alarm is cleared. If the alarm persists, perform the operations
that are required for clearing the alarm generated due to the other causes.
----End
Related Information
The fading mode is categorized into the following types according to the RSL.
l An up fading situation
In the case of up fading situation, the fading of the RSL is higher than the fading of the
RSL in an empty space and the offset value is more than ten decibels.
l A down fading situation
In the case of down fading situation, the fading of the RSL is lower than the fading of the
RSL in an empty space and the offset value is more than ten decibels.
The fading mode is categorized into the following types according to the fading duration.
l A slow fading situation
The fading duration ranges from more than ten seconds to several hours.
l A fast fading situation
The fading duration ranges from several milliseconds to more than ten seconds.
External interference is classified into co-channel interference and adjacent channel.
l Co-channel interference
Co-channel interference is crosstalk from two different radio transmitters that use the
same frequency channel. Therefore, the entire spectrum may be impaired.
l Adjacent channel interference
Adjacent channel interference is signal impairment to one frequency due to presence of
another signal on a nearby frequency. Therefore, a part of the spectrum is impaired.
For information about main lobe and side lobe, see Microwave User GuideMain Lobe and
Side Lobe.
8.7 MW_LIM
Description
The MW_LIM alarm indicates that a mismatched radio link identifier is detected. This alarm
is reported if an IF board detects that the link ID in the microwave frame overheads is
inconsistent with the specified link ID.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1 Indicates the ID of the IF port that reports the alarm. For example, 0x01
indicates that the alarm is reported by port 1 of the related board.
Possible Causes
The possible causes of the MW_LIM alarm are as follows:
l Cause 1: The link ID of the local station does not match the link ID of the opposite
station.
Determination method: Check the configuration on the NMS.
l Cause 2: The receive frequency of the radio link at the local station does not match the
transmit frequency of the radio link at the opposite station.
Determination method: Check the configuration on the NMS.
l Cause 3: The antenna receives the microwave from the other stations, because the
direction of the antenna is set incorrectly.
Determination method: Check the azimuth of the antenna.
Procedure
l Check the MW_LIM alarm on the NMS to determine the board that reports the alarm.
For details, see Viewing the Current Alarms in the Supporting Tasks.
l Causes 1 and 2: The link ID of the local station does not match the link ID of the
opposite station. The receive frequency of the radio link at the local station does not
match the transmit frequency of the radio link at the opposite station.
a. Check whether the link ID in the microwave information of the local station is
consistent with the link ID in the microwave information of the opposite station.
For details, see Configuring the IF/ODU Information of a Radio Link in the
Microwave User Guide.
If... Then...
No Set the link ID of the local station and opposite station to the same value
according to the requirements of the network planning and design. Then,
check whether the alarm is cleared. If the alarm persists, proceed to the next
step.
Yes Proceed to the next step.
b. Check whether the receive/transmit frequencies of the radio link at the local station
match the receive/transmit frequencies of the radio link at the opposite station. For
details, see Configuring the IF/ODU Information of a Radio Link in the Microwave
User Guide.
If... Then...
No Set the transmit frequency and T/R spacing of the local station and opposite
station to the other values according to the requirements of the network
planning and design. Ensure that the transmit frequency of the local station is
the same as the receive frequency of the opposite station, and ensure that the
receive frequency of the local station is the same as the transmit frequency of
the opposite station. Then, check whether the alarm is cleared. If the alarm
persists, perform the operations that are required for clearing the alarm
generated due to cause 3.
Yes Perform the operations required when the alarm is generated due to cause 3.
l Cause 3: The antenna receives the microwave from the other stations, because the
direction of the antenna is set incorrectly.
a. Adjust the direction of the antenna and ensure that the direction is aligned properly
with the antenna of the opposite station. See the MicroWave User Guide. In the case
of different types of antenna, the operations are as follows:
n Aligning the Single-Polarized Antennas
Related Information
Link ID
Link ID is the identifier of a radio link. The transmit station transmits the link ID
continuously. The receive station checks whether it is in the sustained connection status with
the specified transmit station according to the received link ID. If the receive station detects
that the received link ID does not match, the relevant IF port generates the MW_LIM alarm.
When the MW_LOF alarm is generated on the radio link, the received link ID is a random
value. In this case, the link ID is invalid, and the MW_LIM alarm is suppressed by the
MW_LOF alarm.
8.8 MW_LOF
Description
The MW_LOF alarm indicates that the microwave frames are lost.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1 Indicates the ID of the IF port that reports the alarm. For example, 0x01
indicates that the alarm is reported by port 1 of the related board.
Possible Causes
The possible causes of the MW_LOF alarm are as follows:
l Cause 1: The working mode of the IF board at the local station is inconsistent with the
working mode of the IF board at the opposite station, or the working frequency of the
ODU at the local station is inconsistent with the working frequency of the ODU at the
opposite station.
Determination method: Check the alarm and configuration on the NMS.
l Cause 2: The ODU of the opposite station is muted.
Determination method: Query the alarms on the NMS.
l Cause 3: The receive power of the ODU is abnormal.
Determination method: Query the performance events about the receive power on the
NMS.
l Cause: Interference occurs on the frequency channel.
Determination method: Query the parameters such as the receive power on the NMS.
l Cause 5: The transmit unit of the opposite station is faulty.
Determination method: Query the alarms on the NMS and perform loopbacks.
l Cause 6: The receive unit of the local station is faulty.
Determination method: Query the alarms on the NMS and perform loopbacks.
Procedure
l Check the MW_LOF alarm on the NMS to determine the board that reports the alarm.
For details, see Viewing the Current Alarms in the Supporting Tasks.
l Cause 1: The working mode of the IF board at the local station is inconsistent with the
working mode of the IF board at the opposite station, or the working frequency of the
ODU at the local station is inconsistent with the working frequency of the ODU at the
opposite station.
a. Check whether the working mode of the IF board at the local station is consistent
with the working mode of the IF board at the opposite station. If the working mode
of the IF board at the local station is not consistent with the working mode of the IF
board at the opposite station, set the parameters of the IF interface to the other
values according to the requirements of the network planning. Ensure that the
working mode of the IF board at the local station is not consistent with the working
mode of the IF board at the opposite station. See the CONFIG_NOSUPPORT
alarm and perform the operations. Then, check whether the MW_LOF alarm is
cleared.
b. If the alarm persists, check whether the ODUs of the local station and opposite
station are of the same type.
If... Then...
No Replace the ODU. For details, see Replacing the ODU in the Microwave
User Guide. Then, check whether the alarm is cleared. If the alarm persists,
proceed to the next step.
d. If the alarm persists, perform the operations that are required for clearing the alarm
generated due to the other causes.
l Cause 2: The ODU of the opposite station is muted.
a. Check whether the transmitter at the opposite station is set to "Mute". See the
RADIO_MUTE alarm and perform the operations. Then, check whether the
MW_LOF alarm is cleared.
b. If the alarm persists, perform the operations that are required for clearing the alarm
generated due to the other causes.
l Causes 3 and 4: The receive power of the ODU is abnormal. Interference occurs on the
frequency channel.
a. See the MW_FEC_UNCOR alarm to clear the MW_LOF alarm.
b. Check whether the MW_LOF alarm is cleared. If the alarm persists, perform the
operations that are required for clearing the alarm generated due to the other causes.
l Cause 5: The transmit unit of the opposite station is faulty.
a. Check whether any board at the opposite station is faulty or the voltage is
abnormal. Clear the alarm by using the method of clearing the following alarms:
n HARD_BAD
n VOLT_LOS
n BD_STATUS
n RADIO_TSL_HIGH or RADIO_TSL_LOW
n TEMP_ALARM
b. After the preceding alarms are cleared, check whether the MW_LOF alarm is
cleared. If the MW_LOF alarm persists, locate the fault by performing loopbacks.
To be specific, perform an inloop on the opposite IF port. For details, see Setting
Loopback on the IF Board in the Microwave User Guide. Check whether the
MW_LOF alarm persists on the opposite IF port after it is looped back.
If... Then...
The opposite end reports the Replace the opposite IF board. Check whether
MW_LOF alarm the alarm is cleared. If the alarm persists, go to
the next step.
The opposite end does not Release the loop and go to the next step.
report the MW_LOF alarm
c. Check whether any IF cable or IF interface at the opposite station is faulty. See the
IF_CABLE_OPEN alarm and perform the operations.
d. Check whether the MW_LOF alarm is cleared. If the alarm persists, perform the
operations that are required for clearing the alarm generated due to the other causes.
l Cause 6: The receive unit of the local station is faulty.
a. Check whether any board is faulty or the voltage is abnormal at the local station.
Clear the alarm by using the method of clearing the following alarms:
n HARD_BAD
n VOLT_LOS
n BD_STATUS
n RADIO_RSL_LOW
n TEMP_ALARM
b. After the preceding alarms are cleared, check whether the MW_LOF alarm is
cleared. If the MW_LOF alarm persists, locate the fault by performing loopbacks.
Perform an inloop on the local IF port and then check whether the fault is rectified.
If... Then...
The MW_LOF alarm Replace the local IF board. Check whether the alarm
persists is cleared. If the alarm persists, go to the next step.
The MW_LOF alarm is Release the loop and go to the next step.
cleared
c. Check whether any IF cable or IF interface at the local station is faulty. See the
IF_CABLE_OPEN alarm and perform the operations.
d. Check whether the MW_LOF alarm is cleared. If the alarm persists, perform the
operations that are required for clearing the alarm generated due to the other causes.
----End
Related Information
None.
8.9 MW_RDI
Description
The MW_RDI alarm indicates that there are defects at the remote end of a radio link. When
the sink end (the receiver) detects that an alarm is generated in the service due to the fault of
the radio link, the sink end returns the RDI message to the source end (the transmitter). This
alarm is reported if an IF board detects an RDI in the microwave frame overheads.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1 Indicates the ID of the IF port that reports the alarm. For example, 0x01
indicates that the alarm is reported by port 1 of the related board.
Possible Causes
The possible cause of the MW_RDI alarm is as follows:
Cause 1: The sink end detects that an alarm is generated in the service due to the fault of the
radio link.
Procedure
l Check the MW_RDI alarm on the NMS to determine the board that reports the alarm.
For details, see Viewing the Current Alarms in the Supporting Tasks.
l Cause 1: The sink end detects that an alarm is generated in the service due to the fault of
the radio link.
a. Check whether any of the following alarms are generated at the sink end. If any
alarms are generated, ensure that they are cleared immediately.
n R_LOC
n R_LOF
n R_LOS
n MW_LOF
----End
Related Information
Reverse switching
When any alarm is generated in the service of the active and standby microwave IF boards at
the sink end, the alarm is reported to the source end by sending the MW_RDI alarm in the
microwave frames. If the source end is in the locked or forced switching state, or if the current
standby equipment is faulty, the reverse switching is not performed. Otherwise, when the
reverse switching function is enabled at the source end, the HSB switching is performed after
the timer for the reverse switching at the source end times out. The HSB switching is not,
however, performed at the sink end.
8.10 NP1_MANUAL_STOP
Description
The NP1_MANUAL_STOP alarm indicates that the N+1 protection protocol is stopped
manually.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1 Indicates the ID of the protection group that reports the alarm. For example,
0x01 indicates that the alarm is reported by protection group 1.
Possible Causes
The possible cause of the NP1_MANUAL_STOP alarm is as follows:
Cause 1: The N+1 protection protocol is stopped manually.
Procedure
l Query the NP1_MANUAL_STOP alarm on the NMS, and determine the ID of the
protection group according to parameter 1. For details, see Viewing the Current Alarms
in the Supporting Tasks.
l Cause 1: The N+1 protection protocol is stopped manually.
a. Restart the N+1 protection protocol. For details, see Starting/Stopping the N+1
Protection Protocol in the Microwave User Guide.
----End
Related Information
None.
8.11 NP1_SW_FAIL
Description
The NP1_SW_FAIL alarm indicates that the N+1 protection switching fails.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1 Indicates the ID of the protection group that reports the alarm. For example,
0x01 indicates that the alarm is reported by protection group 1.
Possible Causes
The possible causes of the NP1_SW_FAIL alarm are as follows:
Procedure
l Query the NP1_SW_FAIL alarm on the NMS, and determine the ID of the protection
group according to parameter 1. For details, see Viewing the Current Alarms in the
Supporting Tasks.
l Cause 1: The parameters of the N+1 protection are set incorrectly.
a. Check whether the parameters of the N+1 protection are set correctly according to
the requirements of the network protection planning. For details, see Checking the
IF N+1 Protection Group Information in the Microwave User Guide.
b. If the parameters are set incorrectly, set the parameters to the correct values. For
details, see Creating an N+1 Protection Group in the Microwave User Guide.
NOTE
When modifying the current parameters, delete the current protection group before adding a
protection group.
c. Check whether the alarm is cleared. If the alarm persists, perform the operations
that are required for clearing the alarm generated due to cause 2.
----End
Related Information
None.
8.12 NP1_SW_INDI
Description
The NP1_SW_INDI alarm indicates that the N+1 protection switching is detected.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1 Indicates the ID of the protection group that reports the alarm. For example,
0x01 indicates that the alarm is reported by protection group 1.
l When the services are switched from the working path to the protection path, the extra
services on the protection path are interrupted.
l When the services are switched from the protection path to the working path, the extra
services on the protection path are recovered.
Possible Causes
The possible causes of the NP1_SW_INDI alarm are as follows:
l Cause 1: External switching occurs.
Determination method: Query the switching command on the NMS.
l Cause 2: Automatic switching occurs.
Determination method: Query the alarms on the NMS.
Procedure
l Query the NP1_SW_INDI alarm on the NMS, and determine the ID of the protection
group according to parameter 1. For details, see Viewing the Current Alarms in the
Supporting Tasks.
l Cause 1: External switching occurs.
a. Query whether an external switching command is run to trigger the protection
switching on the NMS. Select the NE in the NE Explorer. Choose Configuration >
Link Configuration from the Function Tree.
b. Click the N+1 Protection tab, and then click Query.
c. Query Switching Status of Device in Protection Group. If the switching status is
Force Switching or Manual Switching, you can infer that an external switching
command is issued on the NMS.
l Cause 2: Automatic switching occurs.
a. Automatic switching may be triggered, because the hardware of the ODU or IF
equipment is faulty, or because certain problems occur in the services. Query
whether any of the following faults or alarms are reported by an NE. If any faults or
alarms are reported, ensure that they are cleared immediately.
n The hardware of the IF equipment is faulty, or the hardware of the ODU is
faulty. For example, the HARD_BAD alarm is reported.
n R_LOC, R_LOF, R_LOS, or MW_LOF
n MS_AIS, B2_EXC or B2_SD
NOTE
If an NE is in the switching status and if the working path recovers, the services can be
automatically switched from the protection path to the working path only when the preset wait to
restore (WTR) time is reached. In this case, the alarm can be cleared only when the NE releases
the switching and changes to the idle status.
----End
Related Information
None.
8.13 RADIO_MUTE
Description
The RADIO_MUTE alarm indicates that radio transmitter is muted. This alarm is reported
when the output of the transmitter is shut down.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Possible Causes
The possible causes of the RADIO_MUTE alarm are as follows:
l Cause 1: The transmitter of the local station is muted manually.
Determination method: Check the configuration on the NMS.
l Cause 2: The data configuration of the ODU is incorrect.
Determination method: Check the alarm and configuration on the NMS.
l Cause 3: The output of the transmitter is abnormal, because the IF unit or the ODU is
faulty.
Determination method: Query the alarm on the NMS or identify the cause by using the
exclusion method.
Procedure
l Check the RADIO_MUTE alarm on the NMS and determine the board that reports the
alarm. For details, see Viewing the Current Alarms in the Supporting Tasks.
l Cause 1: The transmitter of the local station is muted manually.
a. Check whether the ODU that reports the alarm at the local station mutes the
transmitter.
If... Then...
Yes Unmute the transmitter. Set TX Status of the ODU to "mute". For details,
see Setting the Transmit Status of the ODU in the Microwave User Guide.
Then, check whether the alarm is cleared. If the alarm persists, perform the
operations that are required for clearing the alarm generated due to cause 2.
No Perform the operations required when the alarm is generated due to cause 2.
----End
Related Information
None.
8.14 RADIO_RSL_HIGH
Description
The RADIO_RSL_HIGH alarm indicates that the radio receive power is very high. This
alarm is reported if the detected receive power is equal to or higher than the upper threshold
of the ODU (-20 dBm).
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Possible Causes
The possible causes of the RADIO_RSL_HIGH alarm are as follows:
Procedure
l Query the RADIO_RSL_HIGH alarm on the NMS and determine the board that reports
the alarm. For details, see Viewing the Current Alarms in the Supporting Tasks.
l Cause 1: The transmit power of the opposite ODU is very high.
a. Query whether the RADIO_TSL_HIGH alarm is generated at the opposite station.
If... Then...
Yes See RADIO_TSL_HIGH and perform the operations. Check whether the
RADIO_RSL_HIGH alarm is cleared. If the alarm persists, perform the
operations that are required for clearing the alarm generated due to cause 2.
No Proceed to the next step.
b. According to the networking requirements, check whether the transmit power of the
ODU at the opposite station is set to a high value. If the value does not meet the
specified requirement, set the transmit power of the ODU at the opposite station to
a proper value. For details, see Configuring the IF/ODU Information of a Radio
Link in the Microwave User Guide.
c. Check whether the alarm is cleared. If the alarm persists, perform the operations
that are required for clearing the alarm generated due to cause 2.
l Cause 2: The local ODU is faulty.
a. Replace the ODU that reports the alarm. For details, see Replacing the ODU in the
Microwave User Guide.
b. Check whether the alarm is cleared. If the alarm persists, perform the operations
that are required for clearing the alarm generated due to cause 3.
l Cause 3: There is a strong interference source nearby.
a. Check whether there is co-channel interference or adjacent channel interference.
Use a spectrum analyzer to check whether any nearby signal source transmits
signals whose frequency is close to the specified range. For details, see the handling
procedure of MW_FEC_UNCOR.
b. If a station is found, determine whether it needs to be shut down or removed
according to the situation. If the station cannot be shut down or removed, contact
the network planning department for replanning the frequency.
----End
Related Information
None
8.15 RADIO_RSL_LOW
Description
The RADIO_RSL_HIGH alarm indicates that the radio receive power is very low. This alarm
is reported if the detected receive power is equal to or less than the lower threshold of the
ODU (-90 dBm).
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Possible Causes
The possible causes of the RADIO_RSL_LOW alarm are as follows:
Procedure
l Query the RADIO_RSL_LOW alarm on the NMS and determine the board that reports
the alarm. For details, see Viewing the Current Alarms in the Supporting Tasks.
l Cause 1: The transmit power of the opposite station is very low.
a. Check whether the transmitter at the opposite station is set to "Mute". See
RADIO_MUTE to clear the alarm.
b. Check whether the transmit power is abnormal due to incorrect settings of the
parameters of the ODU interfaces at the opposite station. See the
CONFIG_NOSUPPORT alarm and perform the operations.
c. Check whether the RADIO_TSL_LOW or BD_STATUS alarm is generated by the
ODU at the opposite station. If the RADIO_TSL_LOW or BD_STATUS alarm is
generated, replace the ODU at the opposite station. For details, see Replacing the
ODU in the Microwave User Guide.
d. Check whether the RADIO_RSL_LOW alarm is cleared at the local station. If the
RADIO_RSL_LOW alarm persists, perform the operations that are required for
clearing the alarm generated due to cause 2.
l Cause 2: The local ODU is faulty.
a. Replace the ODU that reports the alarm. For details, see Replacing the ODU in the
Microwave User Guide.
b. Check whether the alarm is cleared. If the RADIO_RSL_LOW alarm persists,
perform the operations that are required for clearing the alarm generated due to
cause 3.
l Cause 3: Signal attenuation on the radio link is very high.
a. Query the history alarms on the NMS. For details, see Viewing the History Alarms
in the Supporting Tasks. Check the frequency of the signals when the alarm is
generated.
If... Then...
The RADIO_RSL_LOW alarm Proceed to the next step.
persists
The RADIO_RSL_LOW alarm is Contact the network planning department
generated occasionally to change the design to increase the anti-
fading performance.
b. Check whether the antennas at both the local and opposite stations are adjusted
properly.
If... Then...
No Correct the polarization direction of the antennas. See the MicroWave User
Guide. In the case of different types of antennas, the operations are as
follows:
l Aligning the Single-Polarized Antennas
l Aligning the Dual-Polarized Antennas
Check whether the alarm is cleared. If the alarm persists, proceed to the next
step.
If... Then...
Yes Proceed to the next step.
c. Check whether the polarization direction of the antenna, ODU, and hybrid coupler
is set correctly.
If... Then...
No Correct the polarization direction. For details, see "Setting the Antenna
Polarization" in the ODU Installation Guide.
Check whether the alarm is cleared. If the alarm persists, proceed to the next
step.
If... Then...
Yes Replace the unit that is wet, damp, or damaged. Then, check whether the
alarm is cleared. If the alarm persists, proceed to the next step.
----End
Related Information
Main lobe and side lobe
For the information about the main lobe and side lobe, see the MicroWave User GuideMain
Lobe and Side Lobe.
8.16 RADIO_TSL_HIGH
Description
The RADIO_TSL_HIGH alarm indicates that the radio transmit power is very high. This
alarm is reported if the detected transmit power is higher than the upper power threshold of
the ODU.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Possible Causes
The possible cause of the RADIO_TSL_HIGH alarm is as follows:
Cause 1: The local ODU is faulty.
Procedure
l Query the RADIO_TSL_HIGH alarm on the NMS and determine the board that reports
the alarm. For details, see Viewing the Current Alarms in the Supporting Tasks.
l Cause 1: The local ODU is faulty.
a. Replace the ODU that reports the alarm. For details, see Replacing the ODU in the
Microwave User Guide.
----End
Related Information
For the transmit power of the ODU, see the "Transceiver Performance" part in the MicroWave
User Guide.
The transmit power is normal when the offset value between the transmit power and the
specified power is within the range of 1 dB.
8.17 RADIO_TSL_LOW
Description
The RADIO_TSL_LOW alarm indicates that the radio transmit power is very low. This alarm
is reported if the detected transmit power is less than the lower power threshold of the ODU.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Possible Causes
The possible causes of the RADIO_TSL_LOW alarm are as follows:
Cause 1: The local ODU is faulty.
Procedure
l Query the RADIO_TSL_LOW alarm on the NMS and determine the board that reports
the alarm. For details, see Viewing the Current Alarms in the Supporting Tasks.
l Cause 1: The local ODU is faulty.
a. Replace the ODU that reports the alarm. For details, see Replacing the ODU in the
Microwave User Guide.
----End
Related Information
For the transmit power of the ODU, see the "Transceiver Performance" part in the MicroWave
User Guide.
The transmit power is normal when the offset value between the transmit power and the
specified power is within the range of 1 dB.
8.18 RPS_INDI
Description
The RPS_INDI alarm indicates that the 1+1 HSB microwave protection switching is detected.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 2 Indicates the mode of HSB protection switching. The value is always 0x01.
Possible Causes
The possible causes of the RPS_INDI alarm are as follows:
l Cause 1: External switching occurs.
Determination method: Query the switching command on the NMS.
l Cause 2: Automatic switching occurs.
Determination method: Query the alarms on the NMS.
l Cause 3: Reverse switching occurs.
Determination method: Query the alarms on the NMS.
Procedure
l Query the RPS_INDI alarm on the NMS, and determine the ID of the protection group
according to parameter 1. For details, see Viewing the Current Alarms in the Supporting
Tasks.
If... Then...
Revertive Mode is If the working path recovers, the services can be
set to Revertive automatically switched from the protection path to the
working path only when the preset wait to restore (WTR)
time is reached. After the switching is successful, the
RPS_INDI alarm is cleared.
Revertive Mode is When the working path recovers, the services are not
set to Non- automatically switched to the working path, and the
Revertive RPS_INDI alarm persists. To clear the RPS_INDI alarm,
proceed to the next step.
c. Switch the services from the protection path to the working path manually. For
details, see Performing the IF 1+1 Switching in the Microwave User Guide. After
the manual switching is successful, the RPS_INDI alarm is cleared.
l Cause 3: Reverse switching occurs.
a. If the reverse switching function of the HSB protection group is enabled, the HSB
switching is triggered when the MW_RDI alarm is reported by the working and
protection IF boards. After the MW_RDI alarm is cleared, the RPS_INDI alarm is
cleared accordingly.
----End
Related Information
Reverse switching
When any alarm is generated in the service of the active and standby microwave IF boards at
the sink end, the alarm is reported to the source end by sending the MW_RDI alarm in the
microwave frames. If the source end is in the locked or forced switching state, or if the current
standby equipment is faulty, the reverse switching is not performed. Otherwise, when the
reverse switching function is enabled at the source end, the HSB switching is performed after
the timer for the reverse switching at the source end times out. The HSB switching is not,
however, performed at the sink end.
8.19 VOLT_LOS
Description
The VOLT_LOS alarm indicates that the voltage signals of the IF board are lost.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1 Indicates the type of the power that reports the alarm.
l 0x01: -48 V/+24 V power output
l 0x01: -48 V/+24 V power output
l 0x03: +5 V power output
l 0x03: +3.3V power output
l 0x05: lightning
Possible Causes
The possible causes of the VOLT_LOS alarm are as follows:
Procedure
l Query the alarms on the NMS. Determine the type of the power that reports the alarm
according to the value of parameter 1, and then determine the board that reports the
alarm. For details, see Viewing the Current Alarms in the Supporting Tasks.
In the case of parameter 1=0x01, 0x03, or 0x04, perform the operations that are
required for clearing the alarm generated due to cause 1.
In the case of parameter 1=0x02, perform the operations that are required for
clearing the alarm generated due to cause 2.
In the case of parameter 1=0x05, perform the operations that are required for
clearing the alarm generated due to cause 3.
l Cause 1: The output power is abnormal.
a. Check whether the power switch of the ODU is on.
If... Then...
The power switch is off Switch on the ODU. Then, check whether the alarm is
cleared. If the alarm persists, proceed to the next step.
The power switch is on Proceed to the next step.
b. Check the IF fiber jumper, IF Cable, and ODU section by section to see whether
any short circuit exists. For details, see "Testing the Connectivity of the IF Cable" in
the ODU Installation Guide.
If... Then...
A short circuit exists Proceed to the next step.
No short circuit exists Replace the board that reports the alarm.
c. Replace the short-circuit components and the IF board that is damaged due to the
short circuit. For the method of replacing the ODU, see Replacing the ODU in the
Microwave User Guide.
NOTICE
If the alarm is generated due to a short circuit, replace the short-circuited cable or
ODU, and then replace the IF board. Otherwise, the new IF board may be damaged
again.
Related Information
Protection area of a lightning arrestor
The ODU should be located in the protection area of a lightning arrestor.
l In a plain area, the protection area of a lightning arrestor is within the range of 45
downward tilt from the top of the lightning arrestor.
l In the mountainous and lightning areas, the protection area of a lightning arrestor is
within the range of 30 downward tilt from the top of the lightning arrestor.
l Handle the root alarms first and then the non-root alarms.
According to the relation of common alarms, handle the root alarms caused by a fault or
an abnormal event first. Then, handle the non-root alarms caused by the root alarms.
l Check the NMS first and then the NE; check the external factors and then the
internal factors.
On the NMS, remotely check and analyze the alarms and performance events on the
equipment. Then, check the configuration and operations on the NE. Afterwards, check
the links between NEs. Finally, check the hardware of the NE on site.
l Check the common causes and then the special causes.
According to the experience in handling alarms and the information about other alarms,
check the common causes of the alarms, and then the special causes.
l Check the software first and then the hardware.
If the alarm is caused by the fault of the equipment, reset the board to rectify the
software fault and then replace the board to rectify the hardware fault.
l Operation environment
In the telecommunications room, the temperature and humidity do not meet the
requirements for long-time and short-time operations. For example, the environment is
not clean or the ventilation is poor.
l Voltage of power supply
The voltage of power supply is not the DC that supports the normal operation of the
equipment. The voltage fluctuates sharply and is more than 20% of the normal value.
l Grounding
The grounding resistance of the equipment is higher than 1 ohm. Hence, the equipment
can be easily damaged by lightening.
l Heat dissipation
The heat dissipation of the equipment is poor. For example, the exhaust vents are
blocked, the air filter is dirty, and the fans work abnormally.
For specific requirements on the operation environment, see "Operation Environment
Requirements" in the Installation Reference.
Precautions
NOTICE
The operations of reseating a board and performing a cold reset mentioned in this document
cause service interruptions. If the services are not protected, implement the operations with
caution.
NOTICE
Performing a self-loop for the first VC-4 path may affect the ECC communication. Thus, try
to avoid looping back the service of the first VC-4 path. If the loopback method cannot be
used to locate the fault, modify the configuration or use the substitution method to locate the
fault.
All the fault locating methods have advantages and disadvantages. The maintenance
personnel should use various methods to handle the alarm. For common fault handling
methods, see "Common Methods of Locating Faults" in the Troubleshooting.
NOTE
l The alarm parameters listed in this document are those displayed on the NMS. When you browse an
alarm on the NMS, select the alarm. In the Alarm Details field, the related parameters of the alarm
are displayed.
l If the methods provided in this document cannot clear the alarm, contact Huawei technical support
engineers to handle the alarm.
9.1 A_LOC
9.2 AD_CHECK_FAIL
9.3 ALM_ALS
9.4 ALM_AU3AIS
9.5 ALM_AU3B3OVER
9.6 ALM_AU3B3SD
9.7 ALM_AU3LOP
9.8 ALM_AU3RDI
9.9 ALM_AU3REI
9.10 ALM_AU3SLM
9.11 ALM_AU3TIM
9.12 ALM_AU3UNEQ
9.13 ALM_E1AIS
9.14 ALM_HANGUP
9.15 ALM_IMA_LIF
9.16 ALM_IMA_LINK_LCD
9.17 ALM_IMA_LODS
9.18 ALM_IMA_RE_RX_UNUSABLE
9.19 ALM_IMA_RE_TX_UNUSABLE
9.20 ALM_IMA_RFI
9.21 APS_MANUAL_STOP
9.22 AU_CMM
9.23 B3_EXC_VC3
9.24 B3_EXC_VC4
9.25 B3_SD_VC3
9.26 B3_SD_VC4
9.27 BD_NOT_INSTALLED
9.28 BD_AT_LOWPOWER
9.29 BDID_ERROR
9.30 BEFFEC_SD
9.31 BIP8_ECC
9.32 BIOS_STATUS
9.33 BOOTROM_BAD
9.34 C2_PDI
9.35 C2_VCAIS
9.36 C4_R_LAISD
9.37 C4_T_LAISD
9.38 CC_LOC
9.39 CFCARD_FULL
9.40 CFCARD_FAILED
9.41 CFCARD_OFFLINE
9.42 CFCARD_W_R_DISABLED
9.43 CFGBD_FAIL
9.44 CHCS
9.45 CHIP_ABN
9.46 CHIP_FAIL
9.47 CLK_NO_TRACE_MODE
9.48 COOL_CUR_OVER
9.49 CRC4_ERR_OVER
9.50 CRC6_ERR_OVER
9.51 CTS
9.52 DBMS_ERROR
9.53 DBMS_PROTECT_MODE
9.54 DCC_CHAN_LACK
9.55 DCD
9.56 DDN_AIS
9.57 DDN_ALOS
9.58 DDN_CRC4_ERR_OVER
9.59 DDN_LFA
9.60 DDN_LMFA
9.61 DDN_LOOP_ALM
9.62 DDN_RFA
9.63 DDN_RMFA
9.64 DLAG_PROTECT_FAIL
9.65 DOWN_T1_AIS
9.66 DS3_IDLE
9.67 DSR
9.68 DTR
9.69 E1_LOC
9.70 ETH_NO_FLOW
9.71 ETHOAM_DISCOVER_FAIL
9.72 ETHOAM_RMT_CRIT_FAULT
9.73 ETHOAM_RMT_LOOP
9.74 ETHOAM_RMT_SD
9.75 ETHOAM_SELF_LOOP
9.76 ETHOAM_VCG_SELF_LOOP
9.77 EX_ETHOAM_CC_LOS
9.78 EX_ETHOAM_MPID_CNFLCT
9.79 EXT_LOS
9.80 EXT_TIME_LOC
9.81 FEC_LOF
9.82 FEC_OOF
9.83 FLOW_OVER
9.84 FPGA_ABN
9.85 FSELECT_STG
9.86 FUSE_ALARM
9.87 HARD_ERR
9.88 HP_CROSSTR
9.89 HP_REI
9.90 IN_PWR_FAIL
9.91 K1_K2_M
9.92 K2_M
9.93 LAN_LOC
9.94 LASER_MOD_ERR
9.95 LASER_SHUT
9.96 LCAS_BAND_DECREASED
9.97 LCAS_FOPR
9.98 LCAS_FOPT
9.99 LCAS_PLCR
9.100 LCAS_PLCT
9.101 LCAS_TLCR
9.102 LCAS_TLCT
9.103 LCD
9.104 LCS_DAYS_OF_GRACE
9.105 LCS_EXPIRED
9.106 LCS_FILE_NOT_EXIST
9.107 LFA
9.108 LMFA
9.109 LOCK_CUR_FAIL
9.110 LOOP_ALM
9.111 LP_CROSSTR
9.112 LP_R_FIFO
9.113 LP_RDI_VC12
9.114 LP_RDI_VC3
9.115 LP_REI
9.116 LP_REI_VC12
9.117 LP_REI_VC3
9.118 LP_RFI
9.119 LP_SIZE_ERR
9.120 LP_SLM
9.121 LP_SLM_VC12
9.122 LP_SLM_VC3
9.123 LP_T_FIFO
9.124 LP_TIM
9.125 LP_TIM_VC12
9.126 LP_TIM_VC3
9.127 LP_UNEQ_VC12
9.128 LP_UNEQ_VC3
9.129 LPS_UNI_BI_M
9.130 LSR_COOL_ALM
9.131 LSR_INVALID
9.132 LSR_NO_FITED
9.133 LTEMP_OVER
9.134 M_S_SW
9.135 MDL_ALARM
9.136 MOD_TYPE_MISMATCH
9.137 MS_APS_INDI_EX
9.138 MS_CROSSTR
9.139 MSAD_CROSSTR
9.140 MS_REI
9.141 MSSW_DIFFERENT
9.142 NE_CFG_CONFLICT
9.143 NE_POWER_OVER
9.144 NESF_LOST
9.145 NESTATE_INSTALL
9.146 NO_BD_PARA
9.147 NO_BD_SOFT
9.148 NO_LSR_PARA_FILE
9.149 OCD
9.150 ODU_AIS
9.151 ODU_LCK
9.152 ODU_OCI
9.153 OH_LOOP
9.154 OTH_BD_STATUS
9.155 OTH_HARD_FAIL
9.156 OTU_AIS
9.157 OTU_LOF
9.158 OTU_LOM
9.159 OUT_PWR_ABN
9.160 OUT_PWR_HIGH
9.161 OUT_PWR_LOW
9.162 P_AIS
9.163 P_LOF
9.164 P_RAI
9.165 PASSWORD_NEED_CHANGE
9.166 PATCH_ACT_TIMEOUT
9.167 PATCH_ERR
9.168 PATCH_DEACT_TIMEOUT
9.169 PATCH_PKGERR
9.170 PATCH_NOT_CONFIRM
9.171 PATCHFILE_NOTEXIST
9.172 PLL_FAIL
9.173 P_FFM
9.174 PM_BDI
9.175 PM_BEI
9.176 PM_BIP8_OVER
9.177 PM_BIP8_SD
9.178 PM_TIM
9.179 PORT_MODULE_OFFLINE
9.180 PORTMODE_MISMATCH
9.181 PRBS_TEST
9.182 PROTOCOL_MM
9.183 PS
9.184 PUM_BCM_ALM
9.185 PUM_TEM_ALM
9.186 PUMP_COOL_EXC
9.187 PWD_ENCRYPT_RISK
9.188 PWR_MAJ_ALM
9.189 R_FIFO_E
9.190 R_LOC
9.191 R_LOSYNC
9.192 REG_MM
9.193 RELAY_ALARM
9.194 RELAY_ALARM_CRITICAL
9.195 RELAY_ALARM_IGNORE
9.196 RELAY_ALARM_MAJOR
9.197 RELAY_ALARM_MINOR
9.198 RELAY_FAIL
9.199 RFA
9.200 RINGMAPM_MM
9.201 RMFA
9.202 RPR_DUPLICATE_MAC
9.203 RPR_ECHO_DLOC
9.204 RPR_ECHO_LOC
9.205 RPR_MISCONFIG
9.206 RPR_NB_INCONSIS
9.207 RPR_PM_INCONSIS
9.208 RPR_PS_CHANGE
9.209 RPR_STATIONS_EXCEED
9.210 RPR_SUM_A0_EXCEED
9.211 RTC_FAIL
9.212 RTS
9.213 RS_CROSSTR
9.214 S1_SYN_CHANGE
9.215 SECU_ALM
9.216 SEC_RADIUS_FAIL
9.217 SERVCHIP_ABN
9.218 SM_BDI
9.219 SM_BEI
9.220 SM_BIP8_OVER
9.221 SM_BIP8_SD
9.222 SM_IAE
9.223 SM_TIM
9.224 SPARE_PATH_ALM
9.225 SPEED_OVER
9.226 SQUTABM_MM
9.227 SSL_CERT_NOENC
9.228 STORM_CUR_QUENUM_OVER
9.229 SUM_INPWR_HI
9.230 SUM_INPWR_LOW
9.231 SUM_OUTPWR_HI
9.232 SUM_OUTPWR_LOW
9.233 SWDL_ACTIVATED_TIMEOUT
9.234 SWDL_AUTOMATCH_INH
9.235 SWDL_CHGMNG_NOMATCH
9.236 SWDL_COMMIT_FAIL
9.237 SWDL_INPROCESS
9.238 SWDL_NEPKGCHECK
9.239 SWDL_PKG_NOBDSOFT
9.240 SWITCH_DISABLE
9.241 SWDL_ROLLBACK_FAIL
9.242 SYNC_C_LOS
9.243 SYNC_F_M_SWITCH
9.244 SYNC_FAIL
9.245 SYNC_LOCKOFF
9.246 SYSLOG_COMM_FAIL
9.247 T_ALOS
9.248 T_FIFO_E
9.249 T_LOC
9.250 T_LOS
9.251 TC_DEG
9.252 TC_EXC
9.253 TC_INCAIS
9.254 TC_LTC
9.255 TC_ODI
9.256 TC_OEI
9.257 TC_RDI
9.258 TC_REI
9.259 TC_TIM
9.260 TC_UNEQ
9.261 TD
9.262 TEM_HA
9.263 TEM_LA
9.264 TEST_STATUS
9.265 TIME_LOS
9.266 TIME_FORCE_SWITCH
9.267 TIME_NO_TRACE_MODE
9.268 TIME_NOT_SUPPORT
9.269 TPS_ALM
9.270 TR_LOC
9.271 TS16_AIS
9.272 TU_AIS_VC12
9.273 TU_AIS_VC3
9.274 TU_LOP_VC12
9.275 TU_LOP_VC3
9.276 UHCS
9.277 UP_T1AIS
9.278 V5_VCAIS
9.279 VC_AIS
9.280 VC_RDI
9.281 VC3_CROSSTR
9.282 VCAT_LOA
9.283 VCAT_LOM_VC12
9.284 VCAT_LOM_VC3
9.285 VCAT_LOM_VC4
9.286 VCAT_SQM_VC12
9.287 VCAT_SQM_VC3
9.288 VCAT_SQM_VC4
9.289 VCTRUNK_NO_FLOW
9.290 VCG_MM
9.291 VP_AIS
9.292 VP_RDI
9.293 VPG_MM
9.294 W_OFFLINE
9.295 WORK_CUR_OVER
9.296 WRG_BD_TYPE
9.1 A_LOC
Description
The A_LOC is an alarm indicating the loss of clock in the upstream direction of the bus.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1 Indicates the optical interface number. The value is always 0x01.
Parameter 2, Indicates the path number. Parameter 2 is the higher byte, and
Parameter 3 Parameter 3 is the lower byte.
For example, Parameter 2 = 0x00, Parameter 3 = 0x01. In this case,
the A_LOC alarm is reported from path 1 of the board.
Possible Causes
The possible causes of the A_LOC alarm are as follows:
l The PDH equipment interconnected to the service path is faulty.
l The service type is incorrectly configured.
l The service cross-connection is incorrectly configured.
l The board hardware is faulty.
l The cross-connect and timing board is faulty.
Procedure
Step 1 Check whether the PDH equipment interconnected to the service path is faulty. If yes, take
priority to remove the fault, and then check whether the A_LOC alarm is cleared.
Step 2 View the A_LOC alarm on the U2000, and then confirm the path number according to the
alarm parameters.
Step 3 Check whether the service configuration of the path is correct. Make sure that the service type
at the local end is consistent with that at the remote end, and the cross-connection is correctly
configured. Then check whether the A_LOC alarm is cleared.
Step 4 If the alarm persists, check whether any hardware of the board that reports the A_LOC alarm
is faulty on the U2000. If yes, perform a cold reset on the board. Then check whether the
A_LOC alarm is cleared.
NOTICE
If the services travel through the board are not configured with protection, the services are
interrupted after the cold reset of the board.
Step 6 If the alarm persists, perform a cold reset on the cross-connect and timing board. Then check
whether the A_LOC alarm is cleared.
NOTICE
If there is not a standby cross-connect board that properly functions for protection, cold reset
of a cross-connect board may entirely interrupt the services.
Step 7 If the alarm persists, check whether the cross-connect and timing board is faulty. If yes,
replace the cross-connect and timing board. Then the A_LOC alarm is automatically cleared.
----End
Related Information
None.
9.2 AD_CHECK_FAIL
Description
The AD_CHECK_FAIL alarm indicates that the self-check of the AD chip fails. This alarm is
reported when the AD chip on the board is faulty.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1 Indicates the serial number of the AD chip. For example, 0x01
indicates the first chip.
Possible Causes
The possible cause of the AD_CHECK_FAIL alarm is as follows:
Cause 1: The board hardware is faulty.
Procedure
l Query the AD_CHECK_FAIL alarm on the NMS and determine the board that reports
the alarm. For details, see Viewing the Current Alarms in the Supporting Tasks.
l Cause 1: The board hardware is faulty.
a. Replace the board that reports the AD_CHECK_FAIL alarm. For details, see
Replacing a Raman Amplifier Board in the Parts Replacement.
----End
Related Information
None.
9.3 ALM_ALS
Description
The ALM_ALS is an automatic laser shutdown (ALS) alarm. When a board enables the ALS
function and the R_LOS alarm occurs at the optical interface, the laser is shut down
automatically. In this case, the board reports the ALM_ALS alarm.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Possible Causes
The possible cause of the ALM_ALS alarm is as follows:
Procedure
Step 1 When the ALS function is disabled, the alarm is cleared automatically.
----End
Related Information
None.
9.4 ALM_AU3AIS
Description
The ALM_AU3AIS is an AU-3 AIS alarm. When the received AU-3 pointer value is all "1"s
on the receive side of the local optical interface, the ALM_AU3AIS alarm is reported.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 2, Indicates the AU-3 path number. Parameter 2 is the higher byte, and
Parameter 3 Parameter 3 is the lower byte.
For example, Parameter 1 = 0x01, Parameter 2 = 0x00, Parameter 3 =
0x01. In this case, the ALM_AU3AIS alarm is reported from AU-3
path 1 of optical interface 1 on the board.
Possible Causes
The possible causes of the ALM_AU3ALS alarm are as follows:
Procedure
Step 1 Based on the service configuration, trace back to the upstream station, and find the position
where the MS_AIS, R_LOS, R_LOF, B2_EXC, B3_EXC, AU_AIS or ALM_AU3AIS alarm
occurs. When any alarm occurs, take priority to clear it, and then check whether the
ALM_AU3AIS alarm at the local station is cleared.
Step 2 If the alarm at the local station persists, check whether the transmit board at the opposite
station is faulty. If yes, perform a cold reset on the relevant line board at the opposite station,
and then check whether the alarm is cleared.
NOTICE
If the services travel through the board are not configured with protection, the services are
interrupted after the cold reset of the board.
Step 3 If the alarm persists, replace the relevant line board at the opposite station, and then check
whether the alarm is cleared.
Step 4 If the alarm persists, check whether the cross-connect board at the opposite station is faulty. If
yes, perform a cold reset on the cross-connect board, and then check whether the alarm is
cleared.
NOTICE
If there is not a standby cross-connect board that properly functions for protection, cold reset
of a cross-connect board may entirely interrupt the services.
Step 5 If the alarm persists, replace the cross-connect board at the opposite station, and then check
whether the alarm is cleared.
Step 6 If the alarm persists, check whether the receive board at the local station is faulty. If yes,
perform a cold reset on the relevant line board. Then check whether the alarm is cleared.
NOTICE
If the services travel through the board are not configured with protection, the services are
interrupted after the cold reset of the board.
Step 7 If the alarm persists, replace the relevant line board at the local station, and then check
whether the alarm is cleared.
----End
Related Information
None.
9.5 ALM_AU3B3OVER
Description
The ALM_AU3B3OVER indicates the alarm that the number of AU-3 B3 bit errors crosses
the threshold. If a board has detected that the number of B3 bit errors in the AU-3 path
exceeds the specified threshold value, the ALM_AU3B3OVER alarm is reported.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 2, Indicates the AU-3 path number. Parameter 2 is the higher byte, and
Parameter 3 Parameter 3 is the lower byte.
For example, Parameter 1 = 0x01, Parameter 2 = 0x00, Parameter 3 =
0x01. In this case, the ALM_AU3B3OVER alarm is reported from
AU-3 path 1 of optical interface 1 on the board.
Possible Causes
The possible causes of the ALM_AU3B3OVER alarm are as follows:
l A higher-level bit error alarm, such as the B1_EXC, B2_EXC, B3_EXC, B1_SD,
B2_SD or B3_SD, occurs in the system.
l The received signals are heavily attenuated.
l The fiber connector is dirty.
l The fiber connector is loose.
l The receive unit at the local station is faulty.
Procedure
Step 1 Check whether any higher-level bit error alarm, such as the B1_EXC, B2_EXC, B3_EXC,
B1_SD, B2_SD or B3_SD alarm, is detected at the local station and the upstream station. If
yes, take priority to clear it, and then check whether the ALM_AU3B3OVER alarm is
cleared.
Step 2 If the alarm persists, check whether the received optical power of the alarm board is within
the specified value range.
l If yes, go to Step 3.
l If not, follow the steps:
1. Insert the fiber connector firmly, and then check whether the alarm is cleared.
2. Check whether the attenuation value specified in the fiber attenuator is proper. If not,
adjust it to a proper value, and then check whether the alarm is cleared.
3. Clean the fiber connector at the local station and the receive optical interface on the line
board, and then check whether the alarm is cleared.
4. Check whether the flange is correctly connected to the optical attenuator at the local
station, and whether the attenuation value specified in the optical attenuator is proper.
After making sure that the flange and optical attenuator are used properly, check whether
the alarm is cleared.
5. Check whether the launched optical power at the opposite station is within the specified
value range.
If not, replace the optical module, and then check whether the alarm is cleared. If
not, replace the line board at the opposite station, and then check whether the alarm
is cleared.
If the launched optical power is within the specified value range, clean the fiber
connector at the opposite station, and then check whether the alarm is cleared.
6. Check whether the flange is correctly connected to the optical attenuator at the opposite
station, and whether the attenuation value specified in the optical attenuator is proper.
After making sure the flange and optical attenuator are used properly, check whether the
alarm is cleared.
Step 3 If the alarm persists, check whether the transmit board at the opposite station is faulty. If yes,
perform a cold reset on the transmit board, and then check whether the alarm is cleared.
NOTICE
If the services travel through the board are not configured with protection, the services are
interrupted after the cold reset of the board.
Step 4 If the alarm persists, replace the transmit board at the opposite station, and then check whether
the alarm is cleared.
Step 5 If the alarm persists, check whether the receive board at the local station is faulty. If yes,
perform a cold reset on the receive board, and then check whether the alarm is cleared.
NOTICE
If the services travel through the board are not configured with protection, the services are
interrupted after the cold reset of the board.
Step 6 If the alarm persists, replace the receive board at the local station, and then check whether the
alarm is cleared.
----End
Related Information
None.
9.6 ALM_AU3B3SD
Description
The ALM_AU3B3SD indicates the alarm that the AU-3 B3 signals are degraded. If a board
has detected that the number of B3 bit errors in the AU-3 path exceeds the specified threshold
value, the ALM_AU3B3SD alarm is reported.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 2, Indicates the AU-3 path number. Parameter 2 is the higher byte, and
Parameter 3 Parameter 3 is the lower byte.
For example, Parameter 1 = 0x01, Parameter 2 = 0x00, Parameter 3 =
0x01. In this case, the ALM_AU3B3SD alarm is reported from AU-3
path 1 of optical interface 1 on the board.
Possible Causes
The possible causes of the ALM_AU3B3SD alarm are as follows:
l A higher-level bit error alarm, such as the B1_EXC, B2_EXC, B3_EXC, B1_SD,
B2_SD or B3_SD, occurs in the system.
l The received signals are heavily attenuated.
l The fiber connector is dirty.
l The fiber connector is loose.
l The receive unit at the local station is faulty.
l The transmit unit at the opposite station is faulty.
Procedure
Step 1 Check whether any higher-level bit error alarm, such as the B1_EXC, B2_EXC, B3_EXC,
B1_SD, B2_SD or B3_SD alarm, is detected at the local station and the upstream station. If
yes, take priority to clear it. Moreover, clean the fiber connector, and make sure the fiber
connector is inserted firmly. Then check whether the ALM_AU3B3SD alarm at the local
station is cleared.
Step 2 If the alarm persists, check whether the receive board at the local station is faulty. If yes,
perform a cold reset on the receive board. Then check whether the alarm is cleared.
NOTICE
If the services travel through the board are not configured with protection, the services are
interrupted after the cold reset of the board.
Step 3 If the alarm persists, replace the receive board at the local station, and then check whether the
alarm is cleared.
Step 4 If the alarm persists, check whether the transmit board at the opposite station is faulty. If yes,
perform a cold reset on the transmit board, and then check whether the alarm is cleared.
NOTICE
If the services travel through the board are not configured with protection, the services are
interrupted after the cold reset of the board.
Step 5 If the alarm persists, replace the transmit board at the opposite station, and then check whether
the alarm is cleared.
----End
Related Information
None.
9.7 ALM_AU3LOP
Description
The ALM_AU3LOP is an alarm indicating the loss of AU-3 pointer. When eight NDF frames
or invalid pointer values are consecutively received in the AU-3 path on the receive side of
the local optical interface, the ALM_AU3LOP alarm is reported.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 2, Indicates the AU-3 path number. Parameter 2 is the higher byte, and
parameter 3 Parameter 3 is the lower byte.
For example, Parameter 1 = 0x01, Parameter 2 = 0x00, Parameter 3 =
0x01. In this case, the ALM_AU3LOP alarm is reported from AU-3
path 1 of optical interface 1 on the board.
Possible Causes
The possible causes of the ALM_AU3LOP alarm are as follows:
l The local station is configured with the AU-3 services. The opposite station is, however,
not configured with the AU-3 services or is configured with other services rather than the
AU-3 services.
l The number of bit errors received at the local station exceeds the specified value.
l The transmit unit at the opposite station is faulty.
l The receive unit at the local station is faulty.
Procedure
Step 1 Check whether the opposite station is correctly configured with the AU-3 services. If not,
configure it with the proper AU-3 services, and then check whether the ALM_AU3LOP alarm
is cleared.
Step 2 If the alarm persists, check whether any bit error alarm, such as the B1_EXC, B2_EXC,
B3_EXC, B1_SD, B2_SD or B3_SD alarm, is detected at the local station. If yes, clear it, and
then check whether the ALM_AU3LOP alarm is cleared.
Step 3 If the alarm persists, check whether the transmit board at the opposite station is faulty. If yes,
perform a cold reset on the transmit board, and then check whether the alarm is cleared.
NOTICE
If the services travel through the board are not configured with protection, the services are
interrupted after the cold reset of the board.
Step 4 If the alarm persists, replace the transmit board at the opposite station, and then check whether
the alarm is cleared.
Step 5 If the alarm persists, perform a cold reset on the line board that generates the alarm at the
local station, and then check whether the alarm is cleared.
NOTICE
If the services travel through the board are not configured with protection, the services are
interrupted after the cold reset of the board.
Step 6 If the alarm persists, replace the receive board at the local station, and then check whether the
alarm is cleared.
----End
Related Information
None.
9.8 ALM_AU3RDI
Description
The ALM_AU3RDI is a remote defect indication in the AU-3 path.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 2, Indicates the AU-3 path number. Parameter 2 is the higher byte, and
Parameter 3 Parameter 3 is the lower byte.
For example, Parameter 1 = 0x01, Parameter 2 = 0x00, Parameter 3 =
0x01. In this case, the ALM_AU3RDI alarm is reported from AU-3
path 1 of optical interface 1 on the board.
Possible Causes
The possible cause of the ALM_AU3RDI alarm is as follows:
When a board at the opposite station receives the ALM_AU3AIS or ALM_AU3LOP alarm in
the AU-3 path, it returns the G1 byte to the local station, showing the ALM_AU3RDI alarm.
Procedure
Step 1 Clear the ALM_AU3AIS or ALM_AU3LOP alarm at the opposite end. Then the
ALM_AU3RDI is cleared automatically.
----End
Related Information
None.
9.9 ALM_AU3REI
Description
The ALM_AU3REI is a remote error indication in the AU-3 path.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 2, Indicates the AU-3 path number. Parameter 2 is the higher byte, and
Parameter 3 Parameter 3 is the lower byte.
For example, Parameter 1 = 0x01, Parameter 2 = 0x00, Parameter 3 =
0x01. In this case, the ALM_AU3REI alarm is reported from AU-3
path 1 of optical interface 1 on the board.
Possible Causes
The possible cause of the ALM_AU3REI alarm is as follows:
When a board at the opposite station has detected any B3 bit error, it returns the G1 byte to
the local station, showing the FEBBE performance event. Consequently, the ALM_AU3REI
alarm occurs on the board.
Procedure
Step 1 Clear the ALM_AU3B3SD and ALM_AU3B3OVER alarm at the opposite station. Then the
ALM_AU3REI is cleared automatically.
----End
Related Information
None.
9.10 ALM_AU3SLM
Description
The ALM_AU3SLM is a signal label mismatch alarm in the AU-3 path. This alarm shows
that the service type is incorrectly configured or the C2 byte is incorrectly configured.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 2, Indicates the AU-3 path number. Parameter 2 is the higher byte, and
Parameter 3 Parameter 3 is the lower byte.
For example, Parameter 1 = 0x01, Parameter 2 = 0x00, Parameter 3 =
0x01. In this case, the ALM_AU3SLM alarm is reported from AU-3 path
1 of optical interface 1 on the board.
Possible Causes
The possible causes of the ALM_AU3SLM alarm are as follows:
l The type of services in the path is inconsistent with that shown by the value of the C2
byte.
l The value of the C2 byte to be transmitted in the services configured at the opposite
station is inconsistent with that of the C2 byte to be received at the local station.
Moreover, the value of the C2 byte to be transmitted and that of the expected C2 value
are neither 0xFF or 0x00.
Procedure
Step 1 Refer to Table 9-1, and make sure that the service types map the value of the C2 byte to be
transmitted.
Step 2 Check the value of the C2 byte to be received at the local station. Configure the services at the
opposite station, and make sure that the service types are consistent with those mapping the
value of the C2 byte to be received at the local station. Then check whether the
ALM_AU3SLM alarm is cleared.
----End
Related Information
02 TUG structure.
03 Locked TU.
13 ATM mapping.
15 FDDI.
9.11 ALM_AU3TIM
Description
The ALM_AU3TIM is a trace identifier mismatch alarm in the AU-3 path. This alarm shows
that the AU-3 services are incorrectly configured or the J1 byte is incorrectly configured.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 2, Indicates the AU-3 path number. Parameter 2 is the higher byte, and
Parameter 3 Parameter 3 is the lower byte.
For example, Parameter 1 = 0x01, Parameter 2 = 0x00, Parameter 3 =
0x01. In this case, the ALM_AU3TIM alarm is reported from AU-3
path 1 of optical interface 1 on the board.
Possible Causes
The possible causes of the ALM_AU3TIM alarm are as follows:
Procedure
Step 1 Check whether the service cross-connections are correctly configured. If not, configure the
correct service cross-connections, and then check whether the ALM_AU3TIM alarm is
cleared.
Step 2 Check whether the J1 byte to be transmitted at the remote end is consistent with the J1 byte to
be received at the local end. If not, configure the correct J1 byte.
Step 3 Check whether the J1 byte to be received at the local end is consistent with the received J1
byte. If not, configure the correct J1 byte.
----End
Related Information
None.
9.12 ALM_AU3UNEQ
Description
The ALM_AU3UNEQ is an alarm indicating that no services are loaded in the AU-3 path. In
this case, the received C2 byte is 0x00.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 2, Indicates the AU-3 path number. Parameter 2 is the higher byte, and
Parameter 3 Parameter 3 is the lower byte.
For example, Parameter 1 = 0x01, Parameter 2 = 0x00, Parameter 3 =
0x01. In this case, the ALM_AU3UNEQ alarm is reported from AU-3
path 1 of optical interface 1 on the board.
Possible Causes
The possible cause of the ALM_AU3UNEQ alarm is as follows:
The non-loaded AU-3 services are accessed, and the C3 byte is 0x00.
Procedure
Step 1 Access the loaded AU-3 services. Then the ALM_AU3UNEQ alarm is automatically cleared.
----End
Related Information
None.
9.13 ALM_E1AIS
Description
The ALM_E1AIS is an alarm indication signal in the E1 link. This alarm shows that the
payload in the E1 link is all "1"s.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 2, Indicates the VC-12 path number. The value range is 163. That is,
Parameter 3 Parameter 2 is always in value 0x00, and Parameter 3 is in the value
range of 0x010x3F.
Parameter 4, Indicates the number of the VCTRUNK port of the VC-12 path.
Parameter 5 Parameter 4 is always 0x80, and Parameter 5 is in the value range of
0x010x42.
Possible Causes
The possible causes of the ALM_E1AIS alarm are as follows:
l The VC-12 path ring of the E1 link fails to work. For example, the cross-connection is
not configured or incorrectly configured.
l The TU_AIS or TU_LOP alarm occurs in the relevant VC-12 path.
l The VC-12 processing chip of the ATM board is faulty.
Procedure
Step 1 Check whether the cross-connection is correctly configured on the U2000. If not, configure
the correct service cross-connection, and then check whether the ALM_E1AIS alarm is
cleared.
Step 2 If the alarm persists, check whether the TU_AIS or TU_LOP alarm occurs on the U2000. If
yes, take priority to clear it, and then check whether the ALM_E1AIS alarm is cleared.
Step 3 If the alarm persists, the VC-12 processing chip of the board may be faulty. In this case,
perform a cold reset on the board. Then check whether the ALM_E1AIS alarm is cleared.
NOTICE
If the services travel through the board are not configured with protection, the services are
interrupted after the cold reset of the board.
Step 4 If the alarm persists, replace the board that generates the ALM_E1AIS alarm.
----End
Related Information
None.
9.14 ALM_HANGUP
Description
The ALM_HANGUP is an alarm indicating that the orderwire phone is in the off-hook state
for a long time. This alarm occurs when the orderwire phone is in the off-hook state for a long
time.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 3, Parameter 4, The value is always 0xFF, and these parameters are
Parameter 5 meaningless.
Possible Causes
The possible causes of the ALM_HANGUP alarm are as follows:
l The orderwire phone is in the off-hook state for a long time.
l The hardware is faulty.
Procedure
Step 1 Check whether the orderwire phone is hung up. If not, hang up the phone. Then, check
whether the ALM_HANGUP alarm is cleared.
Step 2 If the ALM_HANGUP alarm persists, the board hardware may be faulty. Replace the
R1EOW and R1AMU boards. For details, refer to "Replacing a Board."
----End
Related Information
None.
9.15 ALM_IMA_LIF
Description
The ALM_IMA_LIF is an out-of-frame alarm in the IMA link. This alarm shows the failure
of delimitating the frames received in the local IMA link.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 2, Indicates the VC-12 path number. The value range is 1-63. That is,
Parameter 3 Parameter 2 is always in value 0x00, and Parameter 3 is in the value
range of 0x01-0x3F.
Parameter 4, Indicates the number of the VCTRUNK port of the VC-12 path.
Parameter 5 Parameter 4 is always 0x80, and Parameter 5 is in the value range of
0x01-0x42.
Possible Causes
The possible causes of the ALM_IMA_LIF alarm are as follows:
l Some other SDH alarms occur in the path of the IMA link.
l The VC-12 path of the IMA link is damaged.
l The inconsistent configuration for the IMA protocol results in the failure of receiving
signals in the remote IMA link.
l The inconsistent configuration for the IMA protocol results in the failure of transmitting
signals from the local IMA link.
Procedure
Step 1 View the ALM_IMA_LIF alarm on the U2000, and then confirm the path number according
to the alarm parameters.
Step 2 Check whether any other SDH alarm, such as the HP_AIS, HP_LOP, TU_LOP, TU_AIS,
LP_SLM, LFA or ALM_E1AIS, occurs in the path of the IMA link. If yes, clear it, and then
check whether the ALM_IMA_LIF alarm is cleared.
Step 3 If the alarm persists, check the property of the IMA group at the two ends on the U2000.
Make sure that the property of the IMA group is in a correct value, and then check whether
the ALM_IMA_LIF alarm is cleared.
l Version of the IMA protocol: Make sure that the version of the IMA protocol at the local
end is consistent with that at the remote end.
l Length of the frames transmitted from the IMA group: Make sure that the length of the
frames transmitted from the IMA group at the local end is consistent with that at the
remote end.
l Configuration mode of the IMA group: Make sure that the symmetry mode of the IMA
group at the local end is consistent with that at the remote end.
Step 4 If the alarm persists, check the status of the IMA group at the two ends on the U2000. Then
check whether the negotiation is successful in the IMA group. If the IMA group at the local or
remote end is not in the Operable status, the negotiation is successful. In this case, deactivate
the IMA group, and then activate it again. Then check whether the ALM_IMA_LIF alarm is
cleared.
Step 5 If the alarm persists, check whether the configuration is correct for the cross-connection and
line path of the IMA link on the U2000. If not, configure the correct cross-connection, and
then check whether the ALM_IMA_LIF alarm is cleared.
----End
Related Information
None.
9.16 ALM_IMA_LINK_LCD
Description
The ALM_IMA_LINK_LCD is an alarm indicating the loss of cell delimitation in the IMA
link. This alarm shows the failure of delimitating the cells received in the local IMA link.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 2, Indicates the VC-12 path number. The value range is 1-63. That is,
Parameter 3 Parameter 2 is always in value 0x00, and Parameter 3 is in the value
range of 0x01-0x3F.
Parameter 4, Indicates the number of the VCTRUNK port of the VC-12 path.
Parameter 5 Parameter 4 is always 0x80, and Parameter 5 is in the value range of
0x01-0x42.
Possible Causes
The possible causes of the ALM_IMA_LINK_LCD alarm are as follows:
l Some other SDH alarms occur in the path of the IMA link.
l The VC-12 path of the IMA link is damaged.
l The inconsistent configuration for the IMA protocol results in the failure of receiving
signals in the remote IMA link.
l The inconsistent configuration for the IMA protocol results in the failure of transmitting
signals from the local IMA link.
Procedure
Step 1 View the ALM_IMA_LINK_LCD alarm on the U2000, and then confirm the path number
according to the alarm parameters.
Step 2 Check whether any other SDH alarm, such as HP_AIS, HP_LOP, TU_LOP, TU_AIS,
LP_SLM, LFA or ALM_E1AIS, occurs in the path of the IMA link. If yes, clear it, and then
check whether the ALM_IMA_LINK_LCD alarm is cleared.
Step 3 If the alarm persists, check the property of the IMA group at the two ends on the U2000.
Make sure that the property of the IMA group is in a correct value, and then check whether
the ALM_IMA_LINK_LCD alarm is cleared.
l Version of the IMA protocol: Make sure that the version of the IMA protocol at the local
end is consistent with that at the remote end.
l Length of the frames transmitted from the IMA group: Make sure that the length of the
frames transmitted from the IMA group at the local end is consistent with that at the
remote end.
l Configuration mode of the IMA group: Make sure that the symmetry mode of the IMA
group at the local end is consistent with that at the remote end.
Step 4 If the alarm persists, check the status of the IMA group at the two ends on the U2000. Then
check whether the negotiation is successful in the IMA group. If the IMA group at the local or
remote end is not in the Operable status, the negotiation is successful. In this case, deactivate
the IMA group, and then activate it again. Then check whether the ALM_IMA_LINK_LCD
alarm is cleared.
Step 5 If the alarm persists, check whether the configuration is correct for the cross-connection and
line path of the IMA link on the U2000. If not, configure the correct cross-connection, and
then check whether the ALM_IMA_LINK_LCD alarm is cleared.
----End
Related Information
None.
9.17 ALM_IMA_LODS
Description
The ALM_IMA_LODS is an alarm indicating that the differential delay in the IMA link
crosses the threshold. This alarm shows that the maximum differential delay between the
receive links in the local IMA group crosses the threshold.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 2, Indicates the VC-12 path number. The value range is 1-63. That is,
Parameter 3 Parameter 2 is always in value 0x00, and Parameter 3 is in the value
range of 0x01-0x3F.
Name Meaning
Parameter 4, Indicates the number of the VCTRUNK port of the VC-12 path.
Parameter 5 Parameter 4 is always 0x80, and Parameter 5 is in the value range of
0x01-0x42.
Possible Causes
The possible causes of the ALM_IMA_LODS alarm are as follows:
l Some other SDH alarms occur in the path of the IMA link.
l The VC-12 path of the IMA link is damaged.
l The inconsistent configuration for the IMA protocol results in the failure of receiving
signals in the remote IMA link.
l The inconsistent configuration for the IMA protocol results in the failure of transmitting
signals from the local IMA link.
Procedure
Step 1 View the ALM_IMA_LODS alarm on the U2000, and then confirm the path number
according to the alarm parameters.
Step 2 Check whether any other SDH alarm, such as the HP_AIS, HP_LOP, TU_LOP, TU_AIS,
LP_SLM, LFA or ALM_E1AIS, occurs in the path of the IMA link. If yes, clear it, and then
check whether the ALM_IMA_LODS alarm is cleared.
Step 3 If the alarm persists, check the property of the IMA group at the two ends on the U2000.
Make sure that the property of the IMA group is in a correct value, and then check whether
the ALM_IMA_LODS alarm is cleared.
l Version of the IMA protocol: Make sure that the version of the IMA protocol at the local
end is consistent with that at the remote end.
l Length of the frames transmitted from the IMA group: Make sure that the length of the
frames transmitted from the IMA group at the local end is consistent with that at the
remote end.
l Configuration mode of the IMA group: Make sure that the symmetry mode of the IMA
group at the local end is consistent with that at the remote end.
Step 4 If the alarm persists, check the status of the IMA group at the two ends on the U2000. Then
check whether the negotiation is successful in the IMA group. If the IMA group at the local or
remote end is not in the Operable status, the negotiation is successful. In this case, deactivate
the IMA group, and then activate it again. Then check whether the ALM_IMA_LODS alarm
is cleared.
Step 5 If the alarm persists, check whether the configuration is correct for the cross-connection and
line path of the IMA link on the U2000. If not, configure the correct cross-connection, and
then check whether the ALM_IMA_LODS alarm is cleared.
----End
Related Information
Differential Delay
Differential delay indicates the delay difference of the services among the E1 links. A buffer
of 1024 cells is provided for delay in each E1 link. The maximum differential delay is 256 ms.
9.18 ALM_IMA_RE_RX_UNUSABLE
Description
The ALM_IMA_RE_RX_UNUSABLE is an alarm indicating the failure of receiving signals
in the remote IMA link. This alarm shows that the remote IMA link fails to receive signals
and is unavailable.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 2, Indicates the VC-12 path number. The value range is 1-63. That is,
Parameter 3 Parameter 2 is always in value 0x00, and Parameter 3 is in the value
range of 0x01-0x3F.
Parameter 4, Indicates the number of the VCTRUNK port of the VC-12 path.
Parameter 5 Parameter 4 is always 0x80, and Parameter 5 is in the value range of
0x01-0x42.
If the service bandwidth configured for the IMA group is greater than that of the
activated E1 links in the IMA group, a congestion event occurs at the IMA port.
Consequently, the user cells are lost.
l After the ALM_IMA_RE_RX_UNUSABLE alarm is cleared, the relevant E1 link in the
IMA group is automatically activated.
Possible Causes
The possible causes of the ALM_IMA_RE_RX_UNUSABLE alarm are as follows:
l Some other SDH alarms occur in the path of the IMA link.
l The VC-12 path of the IMA link is damaged.
l The inconsistent configuration for the IMA protocol results in the failure of receiving
signals in the remote IMA link.
l The inconsistent configuration for the IMA protocol results in the failure of transmitting
signals from the local IMA link.
Procedure
Step 1 View the ALM_IMA_RE_RX_UNUSABLE alarm on the U2000, and then confirm the path
number according to the alarm parameters.
Step 2 Check whether any other SDH alarm, such as the HP_AIS, HP_LOP, TU_LOP, TU_AIS,
LP_SLM, LFA or ALM_E1AIS, occurs in the path of the IMA link. If yes, clear it, and then
check whether the ALM_IMA_RE_RX_UNUSABLE alarm is cleared.
Step 3 If the alarm persists, check the property of the IMA group at the two ends on the U2000.
Make sure that the property of the IMA group is in a correct value, and then check whether
the ALM_IMA_RE_RX_UNUSABLE alarm is cleared.
l Version of the IMA protocol: Make sure that the version of the IMA protocol at the local
end is consistent with that at the remote end.
l Length of the frames transmitted from the IMA group: Make sure that the length of the
frames transmitted from the IMA group at the local end is consistent with that at the
remote end.
l Configuration mode of the IMA group: Make sure that the symmetry mode of the IMA
group at the local end is consistent with that at the remote end.
Step 4 If the alarm persists, check the status of the IMA group at the two ends on the U2000. Then
check whether the negotiation is successful in the IMA group. If the IMA group at the local or
remote end is not in the Operable status, the negotiation is successful. In this case, deactivate
the IMA group, and then activate it again. Then check whether the
ALM_IMA_RE_RX_UNUSABLE alarm is cleared.
Step 5 If the alarm persists, check whether the configuration is correct for the cross-connection and
line path of the IMA link on the U2000. If not, configure the correct cross-connection, and
then check whether the ALM_IMA_RE_RX_UNUSABLE alarm is cleared.
----End
Related Information
None.
9.19 ALM_IMA_RE_TX_UNUSABLE
Description
The ALM_IMA_RE_TX_UNUSABLE is an alarm indicating the failure of transmitting
signals in the remote IMA link. This alarm shows that the remote IMA link fails to transmit
signals and is unavailable.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 2, Indicates the VC-12 path number. The value range is 1-63. That is,
Parameter 3 Parameter 2 is always in value 0x00, and Parameter 3 is in the value
range of 0x01-0x3F.
Parameter 4, Indicates the number of the VCTRUNK port of the VC-12 path.
Parameter 5 Parameter 4 is always 0x80, and Parameter 5 is in the value range of
0x01-0x42.
Possible Causes
The possible causes of the ALM_IMA_RE_TX_UNUSABLE alarm are as follows:
l Some other SDH alarms occur in the path of the IMA link.
Procedure
Step 1 View the ALM_IMA_RE_TX_UNUSABLE alarm on the U2000, and then confirm the path
number according to the alarm parameters.
Step 2 Check whether any other SDH alarm, such as the HP_AIS, HP_LOP, TU_LOP, TU_AIS,
LP_SLM, LFA or ALM_E1AIS, occurs in the path of the IMA link. If yes, clear it, and then
check whether the ALM_IMA_RE_TX_UNUSABLE alarm is cleared.
Step 3 If the alarm persists, check the property of the IMA group at the two ends on the U2000.
Make sure that the property of the IMA group is in a correct value, and then check whether
the ALM_IMA_RE_TX_UNUSABLE alarm is cleared.
l Version of the IMA protocol: Make sure that the version of the IMA protocol at the local
end is consistent with that at the remote end.
l Length of the frames transmitted from the IMA group: Make sure that the length of the
frames transmitted from the IMA group at the local end is consistent with that at the
remote end.
l Configuration mode of the IMA group: Make sure that the symmetry mode of the IMA
group at the local end is consistent with that at the remote end.
Step 4 If the alarm persists, check the status of the IMA group at the two ends on the U2000. Then
check whether the negotiation is successful in the IMA group. If the IMA group at the local or
remote end is not in the Operable status, the negotiation is successful. In this case, deactivate
the IMA group, and then activate it again. Then check whether the
ALM_IMA_RE_TX_UNUSABLE alarm is cleared.
Step 5 If the alarm persists, check whether the configuration is correct for the cross-connection and
line path of the IMA link on the U2000. If not, configure the correct cross-connection, and
then check whether the ALM_IMA_RE_TX_UNUSABLE alarm is cleared.
----End
Related Information
None.
9.20 ALM_IMA_RFI
Description
The ALM_IMA_RFI is an out-of-frame alarm in the remote IMA link. This alarm shows the
failure of delimitating the frames received in the remote IMA link.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 2, Indicates the VC-12 path number. The value range is 1-63. That is,
Parameter 3 Parameter 2 is always in value 0x00, and Parameter 3 is in the value
range of 0x01-0x3F.
Parameter 4, Indicates the number of the VCTRUNK port of the VC-12 path.
Parameter 5 Parameter 4 is always 0x80, and Parameter 5 is in the value range of
0x01-0x42.
Possible Causes
The possible causes of the ALM_IMA_RFI alarm are as follows:
l Some other SDH alarms occur in the path of the IMA link.
l The VC-12 path of the IMA link is damaged.
l The inconsistent configuration for the IMA protocol results in the failure of receiving
signals in the remote IMA link.
l The inconsistent configuration for the IMA protocol results in the failure of transmitting
signals from the local IMA link.
Procedure
Step 1 View the ALM_IMA_RFI alarm on the U2000, and then confirm the path number according
to the alarm parameters.
Step 2 Check whether any other SDH alarm, such as the HP_AIS, HP_LOP, TU_LOP, TU_AIS,
LP_SLM, LFA or ALM_E1AIS, occurs in the path of the IMA link. If yes, clear it, and then
check whether the ALM_IMA_RFI alarm is cleared.
Step 3 If the alarm persists, check the property of the IMA group at the two ends on the U2000.
Make sure that the property of the IMA group is in a correct value, and then check whether
the ALM_IMA_RFI alarm is cleared.
l Version of the IMA protocol: Make sure that the version of the IMA protocol at the local
end is consistent with that at the remote end.
l Length of the frames transmitted from the IMA group: Make sure that the length of the
frames transmitted from the IMA group at the local end is consistent with that at the
remote end.
l Configuration mode of the IMA group: Make sure that the symmetry mode of the IMA
group at the local end is consistent with that at the remote end.
Step 4 If the alarm persists, check the status of the IMA group at the two ends on the U2000. Then
check whether the negotiation is successful in the IMA group. If the IMA group at the local or
remote end is not in the Operable status, the negotiation is successful. In this case, deactivate
the IMA group, and then activate it again. Then check whether the ALM_IMA_RFI alarm is
cleared.
Step 5 If the alarm persists, check whether the configuration is correct for the cross-connection and
line path of the IMA link on the U2000. If not, configure the correct cross-connection, and
then check whether the ALM_IMA_RFI alarm is cleared.
----End
Related Information
None.
9.21 APS_MANUAL_STOP
Description
The APS_MANUAL_STOP is an alarm indicating that the MSP protocol is manually
stopped.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Possible Causes
The possible cause of the APS_MANUAL_STOP alarm is as follows:
The MSP protocol of the corresponding MSP group is manually stopped.
Procedure
Step 1 View on the U2000 and confirm the MSP subnet where the protocol is stopped.
Step 2 Restart the MSP protocol of the protection group, and the APS_MANUAL_STOP alarm is
cleared.
----End
Related Information
None.
9.22 AU_CMM
Description
The AU_CMM is an alarm of pointer concatenation mismatch. This alarm indicates that the
rates of the configured services and the actual services are the same, but the service types are
different.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
Name Meaning
Parameter 2, Parameter 3 Indicates the AU-4 path number. Parameter 2 is the higher byte,
and Parameter 3 is the lower byte.
Possible Causes
The possible causes of the AU_CMM alarm are as follows:
l The type of services transmitted from the opposite station is incorrect.
l The service type configured at the local station is incorrect.
l Fibers are incorrectly connected.
Procedure
Step 1 According to the alarm parameters, confirm the optical interface that reports the AU_ALM
alarm and the corresponding AU-4 path.
Step 2 Check whether the service type configured in the AU-4 path is consistent with the planned
one. If not, configure the services at the local station again.
Step 3 Modify the service type transmitted from the upstream, and then check whether the
AU_CMM alarm is cleared.
Step 4 If the alarm persists, check whether the corresponding fibers are incorrectly connected.
----End
Related Information
None.
9.23 B3_EXC_VC3
Description
The B3_EXC_VC3 is an alarm indicating that the number of B3 bit errors in the lower order
path VC-3 crosses the threshold. If a board has detected that the number of B3 bit errors
exceeds the specified threshold value (default value: 10-3), the B3_EXC_VC3 alarm is
reported.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 2, Indicates the number of the path in which the alarm occurs. Parameter 2 is the
parameter 3 higher byte, and Parameter 3 is the lower byte.
For example, Parameter 2 = 0x00, Parameter 3= 0x01. In this case, the
B3_EXC_VC3 alarm is reported from path 1 of the board.
Note:
For the N2PQ1 or R2PD1 board in the MUX mode, the path number is
reported from 0x40, which indicates the first VC3 path.
For the Ethernet boards, indicates the number of the VC-3 order path.
Name Meaning
Possible Causes
The possible causes of the B3_EXC_VC3 alarm are as follows:
Procedure
Step 1 Check whether any higher-level alarm, such as the B1_EXC, B1_SD, B2_EXC, B2_SD,
B3_EXC or B3_SD, is detected at the local station and at the upstream station. If yes, take
priority to clear it, and then check whether the B3_EXC_VC3 alarm is cleared.
Step 2 If the alarm persists, check whether the received optical power of the alarm board is within
the specified value range.
l If yes, go to Step 3.
l If not, follow the steps:
1. Insert the fiber connector firmly, and then check whether the alarm is cleared.
2. Check whether the attenuation value specified in the fiber attenuator is proper. If not,
adjust it to a proper value, and then check whether the alarm is cleared.
3. Clean the fiber connector at the local station and the receive optical interface on the line
board, and then check whether the alarm is cleared.
4. Check whether the flange is correctly connected to the optical attenuator at the local
station, and whether the attenuation value specified in the optical attenuator is proper.
After making sure that the flange and optical attenuator are used properly, check whether
the alarm is cleared.
5. Check whether the launched optical power at the opposite station is within the specified
value range.
6. If the launched optical power is beyond the specified value range, replace the optical
module, and then check whether the alarm is cleared. If not, replace the line board at the
opposite end, and then check whether the alarm is cleared.
7. If the launched optical power is within the specified value range, clean the fiber
connector at the remote station, and then check whether the alarm is cleared.
8. Check whether the flange is correctly connected to the optical attenuator at the opposite
station, and whether the attenuation value specified in the optical attenuator is proper.
After making sure that the flange and optical attenuator are used properly, check whether
the alarm is cleared.
Step 3 If the alarm persists, replace the board that generates the B3_EXC_VC3 alarm.
----End
Related Information
None.
9.24 B3_EXC_VC4
Description
The B3_EXC_VC4 is an alarm indicating that the number of B3 bit errors in the VC-4 path
crosses the threshold. If a board has detected that the number of B3 bit errors in the VC-4 path
exceeds the specified threshold value, the B3_EXC_VC4 alarm is reported.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1 Indicates the optical interface number. The value is always 0x01.
Possible Causes
The possible causes of the B3_EXC_VC4 alarm are the same as those of the B3_EXC alarm.
Procedure
Step 1 Refer to the procedure for handling the B3_EXC alarm.
----End
9.25 B3_SD_VC3
Description
The B3_SD_VC3 is an alarm indicating that the number of VC-3 B3 bit errors crosses the
threshold. If a board has detected that the number of VC-3 B3 bit errors exceeds the specified
B3_SD alarm threshold value (default value: 10-6), the B3_SD_VC3 alarm is reported.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Name Meaning
Parameter 2, Indicates the number of the path in which the alarm occurs. Parameter 2 is the
Parameter 3 higher byte, and Parameter 3 is the lower byte.
For example, Parameter 2 = 0x00, Parameter 3= 0x01. In this case, the
B3_SD_VC3 alarm is reported from path 1 of the board.
Note:
For the N2PQ1 or R2PD1 board in the MUX mode, the path number is
reported from 0x40, which indicates the first VC3 path.
For the Ethernet boards, indicates the number of the VC-3 order path.
Possible Causes
The possible causes of the B3_SD_VC3 alarm are as follows:
l Higher-level bit alarms occur in the system.
l The received signals are heavily attenuated.
l The fiber connector is dirty.
l The fiber connector is loose.
l The receive unit at the opposite station is faulty.
l The transmit unit at the local station is faulty.
Procedure
Step 1 Check whether any higher-level alarm, such as the B1_EXC, B1_SD, B2_EXC, B2_SD,
B3_EXC or B3_SD, is detected at the local station and at the upstream station. If yes, take
priority to clear it, and then check whether the B3_SD_VC3 alarm is cleared.
Step 2 If the alarm persists, check whether the received optical power of the alarm board is within
the specified value range.
l If yes, go to Step 3.
l If not, follow the steps:
1. Insert the fiber connector firmly, and then check whether the alarm is cleared.
2. Check whether the attenuation value specified in the fiber attenuator is proper. If not,
adjust it to a proper value, and then check whether the alarm is cleared.
3. Clean the fiber connector at the local station and the receive optical interface on the line
board, and then check whether the alarm is cleared.
4. Check whether the flange is correctly connected to the optical attenuator at the local
station, and whether the attenuation value specified in the optical attenuator is proper.
After making sure that the flange and optical attenuator are used properly, check whether
the alarm is cleared.
5. Check whether the launched optical power at the opposite station is within the specified
value range.
6. If the launched optical power is beyond the specified value range, replace the optical
module, and then check whether the alarm is cleared. If not, replace the line board at the
opposite end, and then check whether the alarm is cleared.
7. If the launched optical power is within the specified value range, clean the fiber
connector at the opposite station, and then check whether the alarm is cleared.
8. Check whether the flange is correctly connected to the optical attenuator at the opposite
station, and whether the attenuation value specified in the optical attenuator is proper.
After making sure that the flange and optical attenuator are used properly, check whether
the alarm is cleared.
Step 3 If the alarm persists, replace the board that generates the B3_SD_VC3 alarm.
----End
Related Information
None.
9.26 B3_SD_VC4
Description
The B3_SD_VC4 is an alarm indicating that the number of B3 bit errors in the VC-4 path
crosses the threshold. If a board has detected that the number of B3 bit errors in the VC-4 path
exceeds the specified threshold value, the B3_SD_VC4 alarm is reported.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1 Indicates the optical interface number. The value is always 0x01.
Possible Causes
The possible causes of the B3_SD_VC4 alarm are the same as those of the B3-SD alarm.
Procedure
Step 1 Refer to the procedure for handling the B3_SD alarm.
----End
9.27 BD_NOT_INSTALLED
Description
The BD_NOT_INSTALLED is an alarm indicating that the logical board is not installed in
the corresponding slot. This alarm occurs when a physical board is installed but no logical
board is created on the U2000.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1 Indicates the number of the slot that generates this alarm.
Possible Causes
The possible cause of the BD_NOT_INSTALLED is as follows:
A physical board is installed in the slot, but the corresponding logical board is not created on
the U2000.
Procedure
Step 1 View the BD_NOT_INSTALLED alarm on the U2000, and then confirm the slot number
according to Parameter 1.
Step 2 This alarm is cleared when the logical board is added to the corresponding slot on the U2000.
If the physical board is not in use, remove the board from the equipment to clear this alarm.
----End
Related Information
None.
9.28 BD_AT_LOWPOWER
Description
The BD_LOWPOWER is an alarm indicating that the board works in the low power
consumption state. This alarm occurs when the board works in the low power consumption
state.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Possible Causes
The possible causes of the BD_AT_LOWPOWER alarm are as follows:
l The logical board corresponding to the physical board of high power consumption is not
installed.
l The slot that houses the physical board of high power consumption is inconsistent with
the slot that houses the corresponding logical board.
l The software versions do not match.
l The board is faulty.
Procedure
Step 1 View the BD_AT_LOWPOWER alarm on the NMS. According to the alarm parameters,
confirm the slot number.
Step 2 Check whether the BD_NOT_INSTALLED alarm is reported. If the logical board is not
added, handle the problem by referring to the BD_NOT_INSTALLED alarm. After the
BD_NOT_INSTALLED alarm is cleared, check whether the BD_AT_LOWPOWER alarm is
cleared.
Step 3 If the alarm persists, check whether the NE also reports the WRG_BD_TYPE alarm. If the
physical board type does not match the logical board type, handle the problem by referring to
the WRG_BD_TYPE alarm. After the WRG_BD_TYPE alarm is cleared, check whether the
BD_AT_LOWPOWER alarm is cleared.
Step 4 If the alarm persists, check whether the software version of the alarmed board is the same as
the NE software version. If not, upgrade the earlier version to an appropriate version. Check
whether the alarm is cleared.
Step 5 If the alarm persists, perform a cold reset on the board or remove the board.
----End
Related Information
None.
9.29 BDID_ERROR
Description
The BDID_ERROR is an alarm of slot verification error. This alarm occurs when the board
parity check fails or when the board is not properly secured in its slot.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 2, Parameter 3 Indicates the path number. The values are always 0x01.
Possible Causes
The possible causes of the BDID_ERROR alarm are as follows:
Procedure
Step 1 View the BDID_ERROR alarm on the U2000 to confirm the relevant board.
Step 2 Remove the board to check whether there are any twisted pins on the backplane. If any pins
are twisted, fix them and then insert the board. Check whether the alarm is cleared.
----End
Related Information
None.
9.30 BEFFEC_SD
Description
The BEFFEC_SD is an alarm that forward error correction (FEC) signals are degraded.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Possible Causes
The possible causes of the BEFFEC_SD alarm are as follows:
Procedure
Step 1 Check whether any higher-level alarm, such as the R_LOS or FEC_LOF, occurs on the board.
If yes, take priority to clear it, and then check whether the BEFFEC_SD alarm is cleared.
Step 2 If the alarm persists, clean the fiber connector, and then check whether the BEFFEC_SD
alarm is cleared.
Step 3 If the alarm persists, check the input optical power. Moreover, you can add or remove some
optical attenuators so that the optical power is proper.
Step 4 If the alarm persists, check the launched optical power at the opposite end. If the optical
power is extremely low, replace the optical module on the board or the line board at the
opposite end.
Step 5 If the alarm persists, check whether the fiber is damaged. If yes, replace the fiber, and then
check whether the BEFFEC_SD alarm is cleared.
Step 6 If bit errors still occur, replace the line board that reports bit errors at the local station.
----End
Related Information
None.
9.31 BIP8_ECC
Description
The BIP8_ECC is an alarm indicating that BIP8 bit errors occur in the overhead line. When
the BIP8_ECC alarm occurs, the communication over the DCC channel fails.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 4 Bit[0]: The overhead comes from a board at the opposite end. 1: Some
errors are detected. 0: No errors are detected.
Bit[1]: The overhead is received from the working system control and
communication (SCC) board. 1: Some errors are detected. 0: No errors
are detected.
Bit[2]: The overhead comes received from the protection SCC board. 1:
Some errors are detected. 0: No errors are detected.
Possible Causes
The possible causes of the BIP8_ECC alarm are as follows:
l The clock quality is poor.
l The SCC board is faulty.
l The board hardware is faulty.
Procedure
Step 1 Check whether the clock is in a ring state. If yes, remove the ring, and then check whether the
BIP8_ECC alarm is cleared.
Step 2 If the alarm persists, check whether the SCC board is faulty. If yes, perform the switching
operation on the working and protection SCC boards, and then check whether the BIP8_ECC
alarm is cleared.
Step 3 If the alarm persists, check whether any board is faulty, and replace the line board that reports
the alarm at the local station. Then check whether the BIP8_ECC alarm is cleared.
Step 4 If the alarm persists, replace the SCC board at the local station, and then check whether the
BIP8_ECC alarm is cleared.
----End
Related Information
None.
9.32 BIOS_STATUS
Description
The BIOS_STATUS is an alarm indicating the BIOS status. By default, if loading of the board
software fails for three consecutive times within five minutes, the board enters the BIOS
status and the BIOS_STATUS alarm is reported.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
Name Meaning
Parameter 1 Indicates the slot number of the board where the BIOS_STATUS alarm is
generated.
Possible Causes
The possible causes of the BIOS_STATUS alarm are as follows:
l The software is lost.
l Incorrect software is loaded.
l Writing or reading the software becomes abnormal.
l The board hardware is faulty.
Procedure
Step 1 View the BIOS_STATUS alarm on the NMS, and then confirm the board where the
BIOS_STATUS alarm is generated.
Step 2 Perform warm reset for the board and then check whether the BIOS_STATUS alarm is
cleared.
Step 3 If the BIOS_STATUS alarm persists, perform cold reset for the board. Then check whether
the BIOS_STATUS alarm is cleared.
Step 4 If the BIOS_STATUS alarm persists, contact Huawei technical support engineers and ask
them to replace the board software. After the board software is replaced, check whether the
BIOS_STATUS alarm is cleared.
Step 5 If the alarm persists, replace the board and check whether the BIOS_STATUS alarm is
cleared.
----End
Related Information
None.
9.33 BOOTROM_BAD
Description
The BOOTROM_BAD is an alarm indicating the BOOTROM data check failure. During the
running of board software, the system periodically checks whether the BOOTROM data is
damaged. This alarm occurs when the BOOTROM data is detected damaged.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Possible Causes
The possible causes of the BOOTROM_BAD alarm are as follows:
Procedure
Step 1 View the BOOTROM_BAD alarm on the U2000 and confirm the relevant board.
Step 2 Replace the board. If the board has been started, do not replace the board. Replacing the board
can interrupt services, whereas the BOOTROM_BAD alarm does not affect the system or the
services.
----End
Related Information
None.
9.34 C2_PDI
Description
The C2_PDI is a C2 byte defect indication alarm. When the value of the C2 byte is
0xE1-0xFC in five frames consecutively received on the receive side of the local optical
station, the C2_PDI alarm is reported.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Possible Causes
The possible causes of the C2_PDI alarm are as follows:
l The service types are incorrectly configured.
l The value of the C2 bytes to be transmitted at the C2 byte overhead termination station
are incorrectly configured.
l The C2 byte overhead termination station transmits incorrect C2 bytes.
Procedure
Step 1 Trace back to the upstream station, and find the station at which lower order services are
provided. The source board at the station is the source of transmitting the C2 byte, and all the
intermediate nodes transmit the C2 byte transparently. In this way, you can find the station
from which the value of the C2 byte is received at the local station, and this station is regarded
as the termination station.
Step 2 Refer to Table 9-2, and check whether the service types configured at the termination station
map the value of the C2 byte to be transmitted. If not, modify the value of the C2 byte to be
transmitted, and then check whether the C2_PDI alarm is cleared.
Step 3 Refer to Table 9-2, and check whether the service types configured at the local station map
the value of the C2 byte to be received. If not, modify the value of the C2 byte to be received,
and then check whether the C2_PDI alarm is cleared.
Step 4 If the alarm persists, check whether the service types configured at the termination station are
consistent with those at the local station. If not, modify the configured services as required,
and then check whether the C2_PDI alarm is cleared.
Step 5 If the alarm persists, the termination station may fail to transmit the C2 byte. In this case,
perform a cold reset on the board at the termination station, and then check whether the
C2_PDI alarm is cleared.
NOTICE
If the services travel through the board are not configured with protection, the services are
interrupted after the cold reset of the board.
----End
Related Information
Transparent transmission and termination
Transparent transmission means that a service board directly transmits the higher order
overhead received from the transmit direction without processing it. The value of the
transmitted higher order overhead is the same as that transmitted from the cross-connect board
to the service board. Normally, higher order overhead is transparently transmitted in the
higher order services. For example, higher order overhead is transparently transmitted in the
VC-4 service.
Termination means that higher order overhead from the cross-connect board to the service
board is processed and transmitted to the transmit side of the optical interface. Then higher
order overhead is assigned a value to be transmitted. Higher order overhead needs to be
terminated in services (such as the VC-3 service and the VC-12 service) transmitted from the
lower order service sink.
C2 byte coding rule
02 TUG structure.
03 Locked TU.
13 ATM mapping.
15 FDDI.
9.35 C2_VCAIS
Description
The C2_VCAIS is a C2 byte alarm indication. If a board has detected that the value of the
received C2 byte is all "1"s, the C2_VCAIS alarm is reported.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1 l Indicates the actual optical interface number of the linear board.
l 0x40: The N2PQ1 board is in the MUX or SERVER mode (E13/M13
Function).
l 0x21: The R2PD1 board is in the MUX or SERVER mode (E13/M13
Function).
l 0x0d: The N2PQ3 board is in the DEMUX or SERVER mode (E13/M13
Function).
l 0x07: The N2PD3 board is in the DEMUX or SERVER mode (E13/M13
Function).
l 0x04: The N2PL3 or N2PL3A board is in the DEMUX or SERVER mode
(E13/M13 Function).
l For other tributary boards, the value is always 0x01.
Parameter 2, Indicates the number of the path in which the alarm occurs. Parameter 2
Parameter 3 indicates the higher byte, and Parameter 3 indicates the lower byte.
l For a tributary board, it indicates the VC-3 path number. For example,
Parameter 2 = 0x00, Parameter 3 = 0x01. In this case, the C2_VCAIS
alarm is reported from path 1 of the board.
l For a linear board, it indicates the AU-4 path number. For example,
Parameter 1 = 0x01, Parameter 2 = 0x00, Parameter 3 = 0x01. In this
case, the C2_VCAIS alarm is reported from path 1 of optical interface 1
on the board.
Possible Causes
The possible causes of the C2_VCAIS alarm are as follows:
The value of the C2 byte to be transmitted is incorrectly configured at the remote end.
Procedure
Step 1 Confirm the VC path that reports the alarm according to the alarm parameters.
Step 2 Check whether the value of the C2 byte to be transmitted is correctly configured at the remote
end. If not, modify it, and then check whether the C2_VCAIS alarm is cleared.
Step 3 If the alarm persists, replace the transmit board at the remote end.
----End
Related Information
None.
9.36 C4_R_LAISD
Description
C4_R_LAISD (Dropping 140 Mbit/s signal AIS) is an alarm indicating that the downstream
140 Mbit/s signals are all "1"s. When the downstream 140 Mbit/s signals are all "1"s, the
C4_R_LAISD alarm is reported.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Possible Causes
The possible causes of the C4_R_LAISD alarm are as follows:
Procedure
Step 1 Check whether the C4_T_LAISD or EXT_LOS alarm occurs on the board that reports the
C4_R_LAISD alarm on the U2000. If yes, take priority to clear it, and then check whether the
C4_R_LAISD alarm is cleared.
Step 2 If the alarm persists, check whether the board at the local station is faulty. If yes, perform a
cold reset on the board that reports the alarm, and then check whether the C4_R_LAISD
alarm is cleared.
NOTICE
If the services travel through the board are not configured with protection, the services are
interrupted after the cold reset of the board.
Step 3 If the alarm persists, replace the board that reports the alarm, and then check whether the
C4_R_LAISD alarm is cleared.
Step 4 If the alarm persists, check whether the cross-connect and timing board is faulty. If yes,
perform a cold reset on the cross-connect and timing board, and then check whether the
C4_R_LAISD alarm is cleared.
NOTICE
If there is not a standby cross-connect board that properly functions for protection, cold reset
of a cross-connect board may entirely interrupt the services.
Step 5 If the alarm persists, remove the cross-connect and timing board and insert it again, and then
check whether the C4_R_LAISD alarm is cleared.
Step 6 If the alarm persists, replace the cross-connect and timing board at the local station, and then
check whether the C4_R_LAISD alarm is cleared.
----End
Related Information
None.
9.37 C4_T_LAISD
Description
C4_T_LAISD (Dropping 140 Mbit/s signal AIS) is an alarm indicating that the upstream 140
Mbit/s signals are all "1"s. When the upstream 140 Mbit/s signals are all "1"s, the
C4_T_LAISD alarm is reported.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Possible Causes
The possible causes of the C4_T_LAISD alarm are as follows:
l The AIS alarm occurs at the input port of the 140 Mbit/s signals.
l The cable is faulty.
l The board at the local station is faulty.
l The board at the opposite end is faulty.
Procedure
Step 1 Query the C4_T_LAISD alarm on the U2000. Check whether the 140 Mbit/s service signals
accessed by the board that reports the alarm are correct, and whether the AIS alarm occurs.
After making sure that the accessed 140 Mbit/s service signals are correct, check whether the
C4_T_LAISD alarm is cleared.
Step 2 At the digital distribution frame (DDF), perform service self-loop to the relevant path
(namely, performing hardware inloop).
NOTICE
The loopback causes service interruption.
l If the alarm is cleared, the equipment at the opposite end is faulty. After removing the
fault of the equipment, check whether the C4_T_LAISD alarm is cleared.
l If the alarm persists, the trunk cable is faulty, or the board is faulty. Go to the next step.
Step 3 If the alarm persists, perform self-loop to the path (namely, performing hardware inloop) at
the interface board.
NOTICE
The loopback causes service interruption.
l If the alarm is cleared, the signal cable connection is faulty. After removing the faulty
connection, check whether the C4_T_LAISD alarm is cleared.
l If the alarm persists, the interface board is faulty, or the tributary board is faulty. Go to
the next step.
Step 4 If the alarm persists, perform inloop to the path on the U2000.
NOTICE
The loopback causes service interruption.
l If the alarm is cleared, the interface board is faulty. In this case, remove the interface
board and insert it again, or replace the interface board.
l If the alarm persists, the alarm board is faulty. Go to the next step.
Step 5 If the alarm persists, replace the relevant board that generates the alarm, and then check
whether the C4_T_LAISD alarm is cleared.
----End
Related Information
None.
9.38 CC_LOC
Description
The CC_LOC is an alarm indicating the loss of continuity check (CC) cells. After the CC sink
of a connection is activated, and if no user cells and CC cells are received within 3.5 seconds,
the CC_LOC alarm is reported, showing that the connection is not continuously successful.
NOTE
If user cells rather than CC cells are received at this time, the CC_LOC alarm is not reported.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 2, Indicates the connection ID and the connection direction. The value is the
Parameter 3 remainder derived from the formula [(ConnID - 1) x 2 + ConnDir]/2048.
ConnDir indicates the connection direction. The value 1 refers to the
forward direction, and the value 2 refers to the backward direction. ConnId
indicates the connection ID. An odd value means that ConnDir is 1. An even
value means that ConnDir is 2.
Parameter 4 Indicates the group number. The connection ID and connection direction are
derived from a round-up-to integer value based on the formula ((ConnId - 1)
x 2 + ConnDir)/2048. That is, the relevant unidirectional connections are
divided into different groups.
Parameter 5 Indicates the source ATM port of the unidirectional connection based on the
connection ID and the connection direction.
l For the N1IDQ1 and N1IDL4 boards, the value range is 0x01 - 0x4A (1 -
74). 0x01 - 0x04 (1 - 4) is the number of an external optical interface,
and 0x05 - 0x4A (5 - 74) is the number of an internal VCTRUNK port.
l For the N1ADQ1 and N1ADL4 boards, the value range is 0x01 - 0x14.
0x01 - 0x04 (1 - 4) is the number of an external optical interface, and
0x05 - 0x14 (5 - 20) is the number of an internal VCTRUNK port.
Note: The number of an external VCTRUNK port is the actual ID of the
VCTRUNK port, and is derived from the formula (VCTRUNK port ID -
0x8001 + 0x0005).
the CC_LOC alarm is reported from the connection. The services are not interrupted, but
are unavailable in the connection.
l In other cases, the services have been interrupted when the CC_LOC alarm occurs.
l When the CC_LOC alarm occurs, the AIS cells are automatically inserted at the
downstream station.
Possible Causes
The possible causes of the CC_LOC alarm are as follows:
l An NE of the upstream connection fails to receive signals at the SDH layer. For example,
an SDH alarm, such as the R_LOS, R_LOF, MS_AIS, AU_AIS, AU_LOP, TU_AIS or
TU_LOP, occurs at the NE.
l The LCD alarm occurs at an ATM port of the upstream connection.
l The CC source test is not activated in the upstream connection, and no user cells are
received because the current bandwidth is 0.
l The ATM processing chip of the board is faulty.
Procedure
Step 1 View the CC_LOC alarm on the U2000, and then confirm the relevant connection according
to Parameters 2 and 3.
Step 2 Check whether any alarm, such as the R_LOS, R_LOF, MS_AIS, AU_AIS, AU_LOP,
TU_AIS or TU_LOP, occurs in the relevant SDH path of an upstream NE, which connects to
the ATM port. If yes, clear it, and then check whether the CC_LOC alarm is cleared.
Step 3 If the alarm persists, check whether the LCD alarm occurs at the ATM port on the ATM board
of the upstream NE. If yes, clear it, and then check whether the CC_LOC alarm is cleared.
Step 4 If the alarm persists, check whether the relevant CC source is activated in an upstream
connection. If not, activate it, and then check whether the CC_LOC alarm is cleared.
Step 5 If the alarm persists, the ATM processing chip of the board may be faulty. In this case,
perform a cold reset on the board. Then check whether the CC_LOC alarm is cleared.
NOTICE
If the services travel through the board are not configured with protection, the services are
interrupted after the cold reset of the board.
Step 6 If the alarm persists, replace the board that generates the CC_LOC alarm.
----End
Related Information
None.
9.39 CFCARD_FULL
Description
The CFCARD_FULL is an alarm indicating that all capacity of the CF card is used.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1 Indicates the slot number of the board where the CFCARD_FULL
alarm is generated.
Parameter 4, Reserved.
Parameter 5
Possible Causes
The possible cause of the CFCARD_FULL alarm is as follows:
Used capacity of partitions of the CF card crosses the threshold, which is 80% of the capacity.
Procedure
----End
Related Information
None.
9.40 CFCARD_FAILED
Description
The CFCARD_FAILED is an alarm of CF card operation failure.
Attribute
Alarm Severity Alarm Type
Parameters
None.
Possible Causes
The possible causes of the CFCARD_FAILED alarm are as follows:
l Creating the file system of the CF card fails.
l The file system of the CF card does not match.
l The hardware initialization of the CF card fails.
Procedure
Step 1 Replace the CF card and then check whether the CFCARD_FAILED alarm is cleared.
Step 2 If the alarm persists, replace the SCC board.
----End
Related Information
None.
9.41 CFCARD_OFFLINE
Description
The CFCARD_OFFLINE is an alarm of CF card offline.
Attribute
Parameters
None.
Possible Causes
The possible cause of the CFCARD_OFFLINE alarm is as follows:
Procedure
Step 1 Check whether the CF card is installed.
l If not, install the CF card. Check whether the alarm is cleared.
l If yes, replace the CF card. Check whether the alarm is cleared.
----End
Related Information
None.
9.42 CFCARD_W_R_DISABLED
Description
The CFCARD_W_R_DISABLED is an alarm indicating that reading and writing the CF card
are disabled.
Attribute
Parameters
None.
Possible Causes
The possible cause of the CFCARD_W_R_DISABLED alarm is as follows:
Keep pressing the button on the CF card for more than five seconds.
Procedure
Step 1 Press the button on the CF card again.
----End
Related Information
None.
9.43 CFGBD_FAIL
Description
The CFGBD_FAIL is an alarm indicating that the board protection attributes are not in
accordance with the board mode. This alarm occurs if inner board protection is configured for
a board that is in the single fed and single receiving mode.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Possible Causes
The possible cause of the CFGBD_FAIL alarm is as follows:
The board protection attributes are not in accordance with the board type.
Procedure
Step 1 View the CFGBD_FAIL alarm on the U2000 to confirm the relevant board.
Step 2 Check whether the protection attributes set for the board is in accordance with the protection
type that the board actually supports. If not, change the protection settings or replace the
board with the one that supports the protection. If the protection attributes of the board is in
accordance with the board type, the alarm is automatically cleared.
----End
Related Information
None.
9.44 CHCS
Description
The CHCS is an alarm indicating the correctable cell error. This alarm shows that a
correctable bit error occurs in the cell header.
NOTE
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 4, Indicates the VCTRUNK port ID. The value range is 0x8001 -
Parameter 5 0x8046. That is, Parameter 4 is always in value 0x80, and Parameter 5
is in the value range of 0x01 - 0x46.
Possible Causes
The possible causes of the CHCS alarm are as follows:
l Some bit errors occur in the relevant SDH receive path of the ATM port. That is, some
bit error alarms, such as the B1_SD, B2_ SD or B3_ SD, occur in the relevant SDH path
of the port.
Procedure
Step 1 View the CHCS alarm on the U2000, and then confirm the port number according to the
alarm parameters.
Step 2 On the U2000, check whether any bit error alarm, such as the B1_SD, B2_ SD or B3_ SD,
occurs in the relevant SDH path of the port. If yes, clear it, and then check whether the CHCS
alarm is cleared.
Step 3 If the alarm persists, the ATM processing chip of the board may be faulty. In this case,
perform a cold reset on the board, or replace the board. This operation is not suggested,
however, because the services may be interrupted. Moreover, the services are not affected
when the CHCS alarm occurs.
----End
Related Information
None.
9.45 CHIP_ABN
Description
The CHIP_ABN is an alarm of temperature chip failure. This alarm occurs when the
temperature chip fails.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1 Indicates the failed chip number. The 0x01 value indicates the temperature
chip.
Possible Causes
The possible cause of the CHIP_ABN alarm is as follows:
Procedure
Step 1 Check whether the equipment has another cross-connect board that is functioning properly. If
yes, perform a cold reset for the board that reports the CHIP_ABN alarm. After a successful
cold reset, check whether the alarm is cleared.
----End
Related Information
None.
9.46 CHIP_FAIL
Description
The CHIP_FAIL is a failure alarm of a key chip. This alarm occurs when a key chip of the
equipment fails.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1 Parameters 1 and 2 indicate the number of the failed chip in the case of cross-
connect and timing boards.
Indicates the optical interface number in the case of line boards.
The value is always 0x01 in the case of digital data network (DDN) boards and
tributary boards.
Name Meaning
Parameter 2 Parameters 2 and 3 indicate the path number in the case of line boards.
Parameters 2 and 3 indicate the type of the failed chip in the case of DDN
boards.
In the case of N1 or R1 series 2 Mbit/s tributary boards (for example, N1PQ1,
N1PQM, R1PL1, and R1PD1), the value of Parameter 2 is always 0x00, and
certain meanings of Parameter 3 are as follows:
l 0x10: An error occurs in slot check.
l 0x11: The phase-locked loop fails.
l 0x12: The board chip register fails.
l 0x13: Reading and writing the FPGA fails.
l 0x14: The bus clock in the downstream service direction is lost.
l 0x15: The bus clock in the upstream service direction is lost.
Indicates the path number in the case of N1 or R2/R3 series 2 Mbit/s tributary
boards (for example, N2PQ1, R2PD1, and R3PD1). The value of Parameter 2
is always 0x00, and certain meanings of Parameter 3 are as follows:
l 0x0F: An error occurs in slot check.
l 0x10: The phase-locked loop fails.
l 0x11: The board chip register fails.
l 0x12: Reading and writing the FPGA fails.
l 0x13: The bus clock in the downstream service direction is lost.
In the case of N2 series 34 Mbit/s tributary boards (for example, N2PL3,
N2PL3A, N2PQ3, and N2PD3), the value of Parameter 2 is always 0x00, and
certain meanings of Parameter 3 are as follows:
l 0x0A: An error occurs in slot check.
l 0x0B: The phase-locked loop fails.
l 0x0C: The board chip register fails.
l 0x0D: Reading and writing the FPGA fails.
l 0x0E: The bus clock in the upstream service direction is lost.
Parameters 2 and 3 indicate the path number in the case of the other tributary
boards.
Parameter 3 Parameters 3 and 4 indicate the clock fault number in the case of cross-connect
and timing boards.
Name Meaning
Parameter 4 Indicates the extended parameter bit in the case of DDN boards.
l 0x00: No alarm is generated.
l 0x01: Certain alarms are generated.
In the case of DDN boards, the value of Parameter 4 is always 0xFF if no
extended parameter bit exists.
Indicates the alarm type in the case of line boards.
l bit[1]: An error occurs in the slot check.
l bit[2]: The phase-locked loop fails.
l bit[3]: The chip fails.
Indicates the path number in the case of N1 or R1 series 2 Mbit/s tributary
boards. The values of Parameters 4 and 5 correspond to the values of
Parameters 2 and 3, but the meanings are different from each other. Certain
meanings of Parameters 4 and 5 are as follows:
l If the value of Parameter 3 is 0x13, Parameters 4 and 5 indicate the FPGA
number.
l If the value of Parameter 3 ranges from 0x14 to 0x15, Parameters 4 and 5
indicate the chip number.
Indicates the path number in the case of N1 or R2/R3 series 2 Mbit/s tributary
boards. The values of Parameters 4 and 5 correspond to the values of
Parameters 2 and 3, but the meanings are different from each other. Certain
meanings of Parameters 4 and 5 are as follows:
l If the value of Parameter 3 ranges from 0x0E to 0x12, Parameters 4 and 5
are meaningless.
l If the value of Parameter 3 is 0x13, Parameters 4 and 5 indicate the chip
number.
Indicates the path number in the case of N2 series 34 Mbit/s tributary boards.
The values of Parameters 4 and 5 correspond to the values of Parameters 2 and
3, but the meanings are different from each other. Certain meanings of
Parameters 4 and 5 are as follows:
l If the value of Parameter 3 ranges from 0x0A to 0x0C, Parameters 4 and 5
are meaningless.
l If the value of Parameter 3 is 0x0E, Parameters 4 and 5 indicate the chip
number.
In the case of other tributary boards, the values of Parameters 4 and 5 are
always 0xFF, which are meaningless.
Parameter 5 In the case of DDN boards and line boards, the value of Parameters 5 is always
0xFF, which is meaningless.
In the case of cross-connect and timing boards, if the value of Parameter 5 is
not 0xFF, it indicates the clock fault number.
Possible Causes
The possible cause of the APS_FAIL alarm is as follows:
Procedure
Step 1 View the CHIP_FAIL alarm on the U2000 to confirm the relevant board.
Step 2 Perform a cold reset for the board. After a successful cold reset, check whether the alarm is
cleared.
NOTICE
If the services travel through the board are not configured with protection, the services are
interrupted after the cold reset of the board.
----End
Related Information
Bad Indication
The meaning of a bad indication (that is, the board is indicated as bad) is that, internally, the
board detects and reports an alarm through software to indicate a board failure.
9.47 CLK_NO_TRACE_MODE
Description
The CLK_NO_TRACE_MODE is an alarm indicating that the clock enters into a non-tracing
running mode. This alarm occurs when the current clock does not trace any line clock source,
tributary clock source, or external clock source.
Attribute
Alarm Severity Alarm Type
Parameters
None.
Possible Causes
The possible causes of the CLK_NO_TRACE_MODE alarm are as follows:
l A priority table is not manually set for the system, and NEs use their own default priority
tables.
l A priority table is set, but only the internal clock source in the priority table can be
traced.
Procedure
Step 1 Query the current priority table of the system. If there is only the internal clock source in the
priority table, set the clock source priority table to include other available clock sources. After
the setting, the alarm is automatically cleared.
Step 2 In the current priority table, if the internal clock source is not the only available source, find
out why other clock sources cannot be traced. Common causes are as follows:
l The existence status of the clock source is lost. In this case, the system generates a
SYNC_C_LOS alarm. After the SYNC_C_LOS alarm is cleared, the system clock traces
any one clock source other than the internal clock source, and then the
CLK_NO_TRACE_MODE alarm is automatically cleared.
l The local station enables the SSM protocol, while the upstream station does not enable
the SSM protocol. In this case, enable the SSM protocol at the upstream station. When
the system clock traces any one clock source other than the internal clock source, the
CLK_NO_TRACE_MODE alarm is automatically cleared.
----End
Related Information
None.
9.48 COOL_CUR_OVER
Description
The COOL_CUR_OVER is an alarm indicating that the cooling current is over the threshold.
The COA board reports this alarm when the cooling current crosses the threshold.
Attribute
Parameters
None.
Possible Causes
The possible causes of the COOL_CUR_OVER alarm are as follows:
Procedure
Step 1 Check whether the external power supply of the equipment is normal. Make sure that the
external power supply is normal. Then, check whether the COOL_CUR_OVER alarm is
cleared.
Step 2 If the COOL_CUR_OVER alarm persists, check whether the working temperature of the
equipment is too high. If yes, lower the temperature until it is proper for the operation of the
equipment. Then, check whether the alarm is cleared.
Step 3 If the alarm still persists, the EDFA may be faulty. In this case, replace the COA board.
----End
Related Information
None.
9.49 CRC4_ERR_OVER
Description
The CRC4_ERR_OVER is an alarm indicating that the errors of CRC4 check for the E1
services cross the threshold. This alarm occurs when the accumulated number of CRC4 check
errors for the E1 services reaches or exceeds 12000 per minute.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Possible Causes
The possible causes of the CRC4_ERR_OVER alarm are as follows:
l The transmit unit of the opposite station is faulty. Accordingly, errors occur in the CRC4
check for the E1 services accessed to the local end.
l The hardware fault of the board causes errors to occur in the CRC4 check for the E1
services.
Procedure
Step 1 View the CRC4_ERR_OVER alarm on the U2000, and then confirm the path number
according to the alarm parameters.
Step 2 Make sure that the accessed E1 services in the path are correct and no CRC4 check errors
occur. Then check whether the CRC4_ERR_OVER alarm is cleared.
Step 3 If the alarm persists, replace the board that generates the alarm.
----End
Related Information
None.
9.50 CRC6_ERR_OVER
Description
The CRC4_ERR_OVER is an alarm indicating that the errors of CRC6 check for the T1
services cross the threshold. This alarm occurs when the accumulated number of CRC6 check
errors for the T1 services reaches or exceeds 12000 per minute.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1 The value is always 0x01, and this parameter is meaningless.
Parameter 2, Indicates the path number.
Parameter 3
For example, Parameter 2 = 0x00 and Parameter 3 = 0x01. In this
case, the alarm is reported from path 1 of the board.
Possible Causes
l The transmit unit of the opposite station is faulty. Accordingly, errors occur in the CRC6
check for the T1 services accessed to the local end.
l The hardware fault of the board causes errors to occur in the CRC6 check for the T1
services.
Procedure
Step 1 View the CRC6_ERR_OVER alarm on the U2000, and then confirm the path number
according to the alarm parameters.
Step 2 Make sure that the accessed T1 services in the path are correct and no CRC6 check errors
occur. Then check whether the CRC6_ERR_OVER alarm is cleared.
Step 3 If the alarm persists, replace the board that generates the alarm.
----End
Related Information
None.
9.51 CTS
Description
The CTS is an alarm indicating that the data terminal equipment (DTE, namely, the DDN
service board) at the local station has detected the abnormal Clear To Send status.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 2, Indicates the path number. Parameter 2 is the higher byte, and
Parameter 3 Parameter 3 is the lower byte.
For example, Parameter 2 = 0x00, Parameter 3 = 0x01. In this case,
the CTS alarm is reported from path 1 of the board.
Possible Causes
The possible cause of the CTS alarm is as follows:
The data circuit-terminal equipment (DCE) at the opposite station works abnormally. For this
reason, the DTE at the local station is not in the Clear To Send status.
Procedure
Step 1 Check whether the DCE at the opposite station works well by following the actions:
1. Check whether the cable is faulty. If yes, remove the fault.
2. Check whether the service configuration is correct, including the settings of DTE and
DCE, inter, slave or exter. Make sure that the service configuration is correct.
After making sure that the DCE at the opposite station works well, the CTS alarm is
automatically cleared.
----End
Related Information
None.
9.52 DBMS_ERROR
Description
The DBMS_ERROR is an alarm of database file check failure.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1 Indicates the alarm type. The value is the error code that causes the
DBMS_ERROR alarm.
Name Meaning
Parameter 3 Indicates the ID of the database that has errors. Currently, the value
can only be 0 - 255 (0x00 - 0xFF).
l 0: Entire storage area
l 1 - 255: Specific database
Parameter 4, 0xFF
Parameter 5
Possible Causes
The possible causes of the DBMS_ERROR alarm are as follows:
Procedure
Step 1 When the DBMS_ERR alarm occurs, contact the engineers of Huawei.
----End
Related Information
The DBMS_ERR alarm is used for the R&D personnel to locate the system abnormality.
When the DBMS_ERR alarm occurs, contact the engineers of Huawei.
9.53 DBMS_PROTECT_MODE
Description
The DBMS_PROTECT_MODE is an alarm indicating that the NE database enters the
protection mode.
Attribute
Parameters
None.
When the NE database is in the protection mode, the database cannot be performed the
backup.
Possible Causes
The possible cause of the DBMS_PROTECT_MODE alarm is as follows:
Procedure
Step 1 Find out the cause for the repeated resetting of the NE software and handle it.
Step 2 After the fault is removed, reset the NE software. Accordingly, the database exits the
protection mode.
----End
Related Information
None.
9.54 DCC_CHAN_LACK
Description
The DCC_CHAN_LACK is an alarm indicating that the DCC channel resource is insufficient.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1 Indicates the slot number of the board where the DCC_CHAN_LACK alarm is
reported.
Parameter 2 Indicates the number of the optical interface where the DCC_CHAN_LACK
alarm is reported.
Parameter 3 Indicates the DCC channel mode in which the CPU resource fails to be
obtained.
l 0x01: One byte of the DCC channel resources fail to be obtained.
l 0x03: Three bytes of the DCC channel resources fail to be obtained.
l 0x09: Nine bytes of the DCC channel resources fail to be obtained.
l 0x0C: Twelve bytes of the DCC channel resources fail to be obtained.
l 0x20: Thirty-two bytes of the DCC channel resources fail to be obtained.
l 0x60: Ninety-six bytes of the DCC channel resources fail to be obtained.
Possible Causes
The possible causes of the DCC_CHAN_LACK alarm are as follows:
The CPU does not have enough resources to be allocated to the optical channel of the
corresponding type.
For example, if the channel type of optical interface 1 is D1 - D3, the CPU cannot allocate
three bytes of the channel resources to this optical interface.
Procedure
Step 1 View the DCC_CHAN_LACK alarm on the U2000 to determine the board where the alarm is
generated. According to Parameter 2, determine the number of the optical interface where the
alarm is generated.
Step 2 Delete the channel of the optical interface that cannot obtain the CPU resources, or set the
enabling state of the DCC communication of the optical interface to be disabled. Then, check
whether the alarm is cleared.
NOTICE
Do not delete the optical inteface that is being used. For the DCC channel of the D1 - D3 or
D4 - D12 type, the DCC communication of the optical interface should be disabled or enabled
at the same time. If the optical interface is incorrectly shut down, the NE may be out of the
control of the U2000, or the ASON TE link may be downgraded.
----End
Related Information
None.
9.55 DCD
Description
The DCD is an alarm indicating that the data terminal equipment (DTE, namely, the DDN
service board) at the local station has detected the abnormal Digital Carrier Detector status.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 2, Indicates the path number. Parameter 2 is the higher byte, and
Parameter 3 Parameter 3 is the lower byte.
For example, Parameter 2 = 0x00, Parameter 3 = 0x01. In this case,
the DCD alarm is reported from path 1 of the board.
Possible Causes
The possible causes of the DCD alarm are as follows:
Procedure
Step 1 Check whether the DCE at the opposite station works well by following the actions:
1. Check whether the cable is faulty. If yes, remove the fault.
2. Check whether the service configuration is correct, including the settings of DTE and
DCE, inter, slave or exter. Make sure that the service configuration is correct.
After making sure that the DCE at the opposite station works well, the DCD alarm is
automatically cleared.
----End
Related Information
None.
9.56 DDN_AIS
Description
The DDN_AIS is an alarm indication signal at the DDN port. If a board has detected that the
signals at the DDN port are all "1"s, the DDN_AIS alarm is reported.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Name Meaning
Parameter 2, Indicates the path number. Parameter 2 is the higher byte, and
Parameter 3 Parameter 3 is the lower byte.
For example, Parameter 2 = 0x00, Parameter 3 = 0x01. In this case,
the DDN_AIS alarm is reported from path 1 of the board.
Possible Causes
The possible causes of the DDN_AIS alarm are as follows:
l The AIS alarm is inserted in the services in the upstream DDN equipment connected to
the electrical interface on the DDN board.
l The receive unit of the board at the local station is faulty.
Procedure
Step 1 View the DDN_AIS alarm on the U2000 to confirm the relevant board.
Step 2 Check whether the accessed E1 signals of the board are reported normally. After making sure
that the accessed E1 service signals are correct, check whether the DDN_AIS alarm is
cleared.
----End
Related Information
None.
9.57 DDN_ALOS
Description
The DDN_ALOS is an alarm indicating the loss of signal at the DDN port. If no service is
input at the DDN port, the DDN_ALOS alarm is reported.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 2, Indicates the path number. Parameter 2 is the higher byte, and
Parameter 3 Parameter 3 is the lower byte.
For example, Parameter 2 = 0x00, Parameter 3 = 0x01. In this case,
the DDN_ALOS alarm is reported from path 1 of the board.
Possible Causes
The possible causes of the DDN_ALOS alarm are as follows:
l The DDN service is not accessed.
l The DDN equipment interconnected to the path is faulty.
l The output port of the DDN interface on the DDF side is disconnected or loose.
l The input port of the DDN interface at the local station is disconnected or loose.
l The board is faulty.
l The cable is faulty.
Procedure
Step 1 View the DDN_ALOS alarm on the U2000 to confirm the relevant board. According to the
alarm parameters, confirm the path number.
Step 2 Check whether the board is properly connected to the cable of the interconnected equipment,
and whether the cable is faulty. If no fault is found, check whether the interconnected
equipment works well by performing loopback to the equipment cable. If any fault is found,
take priority to remove it, and then check whether the DDN_ALOS alarm is cleared.
Step 3 Check whether the DDN service in the path of the board is accessed. If not, access the DDN
service, and then check whether the DDN_ALOS alarm is cleared.
Step 4 If the alarm persists, perform service self-loop (namely, hardware inloop) to the path at the
DDF.
NOTICE
The loopback causes service interruption.
l If the alarm is cleared, the equipment at the opposite station is faulty. After removing the
fault, check whether the DDN_ALOS alarm is cleared.
l If the alarm persists, go to the next step.
Step 5 Perform self-loop (namely, hardware inloop) to the path at the interface board.
NOTICE
The loopback causes service interruption.
l If the alarm is cleared, the signal cable connection is faulty. After removing the faulty
connection, check whether the DDN_ALOS alarm is cleared.
l If the alarm persists, go to the next step.
NOTICE
The loopback causes service interruption.
l If the alarm is cleared, the interface board is faulty. In this case, remove the interface
board and insert it again, or replace the interface board.
l If the alarm persists, the board is faulty. After replacing the board that reports the alarm,
check whether the DDN_ALOS alarm is cleared.
----End
Related Information
None.
9.58 DDN_CRC4_ERR_OVER
Description
The DDN_CRC4_ERR_OVER is an alarm indicating that the number of CRC4 check errors
in the 2 Mbit/s services on the electrical interface side crosses the threshold. For the 2 Mbit/s
services, if the accumulated number of CRC check errors per second reaches or exceeds
12000, the DDN_CRC4_ERR_OVER is reported.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 2, Indicates the path number. Parameter 2 is the higher byte, and Parameter
Parameter 3 3 is the lower byte.
For example, Parameter 2 = 0x00, Parameter 3 = 0x01. In this case, the
DDN_CRC4_ERR_OVER alarm is reported from path 1 of the board.
Possible Causes
The possible causes of the DDN_CRC4_ERR_OVER alarm are as follows:
l CRC4 check errors occur in the accessed E1 services.
l The board hardware is faulty.
Procedure
Step 1 View the DDN_CRC4_ERR_OVER alarm on the U2000, and then confirm the path number
according to the alarm parameters.
Step 2 Make sure that the accessed E1 services in the path are correct and no CRC4 check errors
occur. Then check whether the DDN_CRC4_ERR_OVER alarm is cleared.
Step 3 If the alarm persists, replace the board that generates the DDN_CRC4_ERR_OVER alarm.
----End
Related Information
None.
9.59 DDN_LFA
Description
The DDN_LFA is an alarm indicating the loss of frame alignment in the PDH framed E1
services on the electrical interface side. When the electrical interface side fails to receive the
frame alignment signals in the framed E1 services, the DDN_LFA alarm is reported.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 2, Indicates the path number. Parameter 2 is the higher byte, and
Parameter 3 Parameter 3 is the lower byte.
For example, Parameter 2 = 0x00, Parameter 3 = 0x01. In this case,
the DDN_LFA alarm is reported from path 1 of the board.
Possible Causes
The possible causes of the DDN_LFA alarm are as follows:
l The DDN equipment interconnected to the path is faulty.
l The service frame format is incorrectly configured.
l The board hardware is faulty.
Procedure
Step 1 View the DDN_LFA alarm on the U2000 to confirm the relevant board.
Step 2 Check whether the interconnected DDN equipment works well by performing loopback to the
equipment cable. If any fault is found, take priority to remove it, and then check whether the
DDN_LFA alarm is cleared.
Step 3 Check whether the frame format of the E1 signals transmitted from the opposite end is
consistent with that specified at the local end. Make sure that the service configuration is
correct, and that the frame format of the E1 signals matches each other at the two ends. Then
check whether the DDN_LFA alarm is cleared.
Step 4 If the alarm persists, perform a cold reset on the board. Then check whether the DDN_LFA
alarm is cleared.
NOTICE
If the services travel through the board are not configured with protection, the services are
interrupted after the cold reset of the board.
Step 5 If the alarm persists, the board is faulty. Replace the board. Then the DDN_LFA alarm is
automatically cleared.
----End
Related Information
None.
9.60 DDN_LMFA
Description
The DDN_LMFA is an alarm indicating the loss of mulitframe alignment in the PDH framed
E1 services on the DDN side. When the DNN side fails to receive the multiframe alignment
signals in the framed E1 services, the DDN_LMFA alarm is reported.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 2, Indicates the path number. Parameter 2 is the higher byte, and
Parameter 3 Parameter 3 is the lower byte.
For example, Parameter 2 = 0x00, Parameter 3 = 0x01. In this case,
the DDN_LMFA alarm is reported from path 1 of the board.
Possible Causes
The possible causes of the DDN_LMFA alarm are as follows:
Procedure
Step 1 View the DDN_LMFA alarm on the U2000 to confirm the relevant board.
Step 2 Check whether the interconnected DDN equipment works well by performing loopback to the
equipment cable. If any fault is found, take priority to remove it, and then check whether the
DDN_LFA alarm is cleared.
Step 3 Check whether the frame format of the E1 signals transmitted from the opposite end is
consistent with that specified at the local end. Make sure that the service configuration is
correct, and that the frame format of the E1 signals matches each other at the two ends. Then
check whether the DDN_LMFA alarm is cleared.
Step 4 If the alarm persists, perform a cold reset on the board. Then check whether the DDN_LMFA
alarm is cleared.
NOTICE
If the services travel through the board are not configured with protection, the services are
interrupted after the cold reset of the board.
Step 5 If the alarm persists, the board is faulty. Replace the board. Then the DDN_LMFA alarm is
automatically cleared.
----End
Related Information
None.
9.61 DDN_LOOP_ALM
Description
The DDN_LOOP_ALM is an alarm indicating that a loopback event occur at the DDN port.
If the port on the DDN side of a board is in the loopback status, the DDN_LOOP_ALM alarm
is reported.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 2, Indicates the path number. Parameter 2 is the higher byte, and
Parameter 3 Parameter 3 is the lower byte.
For example, Parameter 2 = 0x00, Parameter 3 = 0x01. In this case,
the DDN_LOOP_ALM alarm is reported from path 1 of the board.
Possible Causes
The possible cause of the DDN_LOOP_ALM alarm is as follows:
Procedure
Step 1 View the DDN_LOOP_ALM alarm on the U2000 to confirm the relevant board.
Step 2 After you cancel the loopback settings of the board that reports the alarm, the
DDN_LOOP_ALM alarm is automatically cleared.
----End
Related Information
None.
9.62 DDN_RFA
Description
The DDN_RFA is a remote frame alignment alarm of the framed E1 services on the DDN
side of a board. When the RDI bit is set to 1 for the E1 signals received on the DDN side of a
board from the opposite end, the DDN_RFA alarm is reported.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 2, Indicates the path number. Parameter 2 is the higher byte, and
Parameter 3 Parameter 3 is the lower byte.
For example, Parameter 2 = 0x00, Parameter 3 = 0x01. In this case,
the DDN_RFA alarm is reported from path 1 of the board.
Possible Causes
The possible cause of the DDN_RFA alarm is as follows:
Procedure
Step 1 After you clear the DDN_LFA alarm received at the opposite end, the DDN_RFA alarm is
automatically cleared.
----End
Related Information
None.
9.63 DDN_RMFA
Description
The DDN_RMFA is a remote alarm of the framed E1 multiframe on the DDN side of a board.
If the E1 signals received on the DDN side occur in Z (Z is from two through five)
consecutive CAS multiframe cycles, the DDN_RMFA alarm is reported when all the CAS
multiframe remote alarm bits of the input signals are set to 1.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Possible Causes
The possible cause of the DDN_RMFA alarm is as follows:
Procedure
Step 1 After you clear the DDN_LMFA alarm received at the opposite end, the DDN_RMFA alarm
is automatically cleared.
----End
Related Information
None.
9.64 DLAG_PROTECT_FAIL
Description
The DLAG_PROTECT_FAIL is an alarm indicating that the DLAG protection fails. If
negotiation fails or any anomaly occurs during the DLAG protection, the
DLAG_PROTECT_FAIL alarm is reported.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 2, Indicate the ID of the LAG for which the protection fails. Parameter 2 is
Parameter 3 the higher byte, and Parameter 3 is the lower byte.
Name Meaning
Parameter 5 The values are always 0xFF, and the two parameters are meaningless.
Possible Causes
The possible causes of the DLAG_PROTECT_FAIL alarm are as follows:
Procedure
Step 1 View the DLAG_PROTECT_FAIL alarm on the U2000, and confirm the board where the
DLAG_PROTECT_FAIL alarm is generated. Confirm the ID of the LAG where the
DLAG_PROTECT_FAIL alarm is generated according to Parameter 1, and confirm the cause
of the DLAG_PROTECT_FAIL alarm at the port according to Parameter 4.
Step 2 If the value of Parameter 4 is 0x01, it indicates that the link becomes faulty or fails.
1. On the U2000, check whether the port in the LAG is enabled. If not enabled, enable the
port and then check whether the DLAG_PROTECT_FAIL alarm is cleared.
2. If the DLAG_PROTECT_FAIL alarm persists, check the link state of all the ports.
Rectify the fault of the port link, then check whether the DLAG_PROTECT_FAIL alarm
is cleared.
Step 3 If the value of Parameter 4 is 0x02, it indicates that the port fails to receive the LACP packets.
1. On the U2000, check whether the LAG is configured at the opposite end, and check
whether the port connected to the faulty port is added to the LAG at the opposite end.
Make sure the LAG is correctly configured, and then check whether the
DLAG_PROTECT_FAIL alarm is cleared.
2. If the DLAG_PROTECT_FAIL alarm persists, check whether the local port transmits
packets. If both ends can normally transmit and receive packets, check whether the
DLAG_PROTECT_FAIL alarm is cleared.
Step 4 If the value of Parameter 4 is 0x03, it indicates that the opposite equipment fails to enter the
LACP protocol synchronization status. Check the connection of the port, and LAG
configuration at the opposite equipment, and then check whether the
DLAG_PROTECT_FAIL alarm is cleared.
Step 5 If the value of Parameter 4 is 0x04, it indicates the port is in the self-loop status. Release the
loop and then check whether the DLAG_PROTECT_FAIL alarm is cleared.
Step 6 If the value of Parameter 4 is 0x05, it indicates that the communication between the active and
standby boards times out. Make sure the active and standby boards are in position, and the
communication between them is normal. Then check whether the DLAG_PROTECT_FAIL
alarm is cleared.
Step 7 If the value of Parameter 4 is 0x06, it indicates that the communication between the board and
the cross-connect board, or SCC board, times out. Make sure the software of the cross-
connect board and the SCC is normal. If the board normally communicates with the cross-
connect board or SCC board, check whether the DLAG_PROTECT_FAIL alarm is cleared.
Step 8 If the value of Parameter 4 is 0x07, it indicates that the active port selected by LACP is
inconsistent with the one selected by cross-connect board. Make sure the active port selected
by LACP is consistent with the one selected by cross-connect board, and then check whether
the DLAG_PROTECT_FAIL alarm is cleared.
----End
Related Information
None.
9.65 DOWN_T1_AIS
Description
The DOWN_T1_AIS is an indication alarm of the downstream 1.5 Mbit/s signals. If a
tributary board has detected that the value of the downstream T1 signals is all "1"s, the
DOWN_T1_AIS alarm is reported.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 2, Indicates the path number. Parameter 2 is the higher byte, and
Parameter 3 Parameter 3 is the lower byte.
For example, Parameter 2 = 0x00, Parameter 3 = 0x01. In this case, the
DOWN_T1_AIS alarm is reported from path 1 of the board.
Possible Causes
The possible causes of the DOWN_T1_AIS alarm are as follows:
l The UP_T1AIS or T_ALOS alarm occurs on the tributary board at the opposite station.
l The tributary board of the local station is faulty.
l The cross-connect and timing board of the local station is faulty.
Procedure
Step 1 View the DOWN_T1_AIS alarm on the U2000 to confirm the relevant board.
Step 2 On the U2000, check whether the UP_T1AIS or T_ALOS alarm is reported from the tributary
board of the opposite station. If yes, take priority to clear it, and then check whether the
DOWN_T1_AIS alarm is cleared.
Step 3 If the alarm persists, perform a cold reset on the tributary board that reports the alarm at the
opposite station. Then check whether the DOWN_T1_AIS alarm is cleared.
NOTICE
If the services travel through the board are not configured with protection, the services are
interrupted after the cold reset of the board.
Step 4 If the alarm persists, replace the tributary board that reports the alarm at the local station.
Then, check whether the DOWN_T1_AIS alarm is cleared.
Step 5 If the alarm persists, perform a cold reset on the cross-connect and timing board of the local
station. Then, check whether the DOWN_T1_AIS alarm is cleared.
NOTICE
If there is not a standby cross-connect board that properly functions for protection, cold reset
of a cross-connect board may entirely interrupt the services.
Step 6 If the alarm persists, replace the cross-connect and timing board of the local station. Then,
check whether the DOWN_T1_AIS alarm is cleared.
----End
Related Information
None.
9.66 DS3_IDLE
Description
The DS3_IDLE is an alarm indicating that the DS3 (that is, T3) payload signal is idle. In PDH
services, when the PATTERN signal is contained in DS3 framing signal, the DS3_IDLE alarm
is reported.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Name Meaning
Possible Causes
The possible causes of the DS3_IDLE alarm are as follows:
l The transmission line is faulty.
l The IDLE signal is output from the PDH equipment at the opposite station.
Procedure
Step 1 At the digital distribution frame (DDF), perform service self-loop to the relevant path
(namely, performing hardware inloop). If the alarm is cleared, the equipment at the opposite
station is faulty. After removing the fault of the equipment, check whether the DS3_IDLE
alarm is cleared.
NOTICE
The loopback causes service interruption.
Step 2 If the alarm persists, perform self-loop to the path (namely, performing hardware inloop) at
the interface board. If the alarm is cleared, the signal cable connection is faulty. After
removing the faulty connection, check whether the DS3_IDLE alarm is cleared.
NOTICE
The loopback causes service interruption.
Step 3 If the alarm persists, perform inloop to the path on the U2000. If the alarm is cleared, the
interface board is faulty. In this case, remove the interface board and insert it again, or replace
the interface board.
NOTICE
The loopback causes service interruption.
Step 4 If the alarm persists, replace the board that reports the alarm at the local station, and then
check whether the DS3_IDLE alarm is cleared.
----End
Related Information
PATTERN Signal
The PATTERN signal means that the sequence received in the framing signal is 11001100.
9.67 DSR
Description
The DSR is an alarm indicating that the DTE at the local end has detected the DCE at the
opposite station works abnormally. This is, the Data Set Ready status at the DCE is abnormal.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 2, Indicates the path number. Parameter 2 is the higher byte, and
Parameter 3 Parameter 3 is the lower byte.
For example, Parameter 2 = 0x00, Parameter 3 = 0x01. In this case,
the DSR alarm is reported from path 1 of the board.
Possible Causes
The possible cause of the DSR alarm is as follows:
The DCE at the opposite end works abnormally because the cable is improperly connected, or
the service configuration is incorrect.
Procedure
Step 1 Check whether the DCE at the opposite end works well by following the actions:
1. Check whether the cable is faulty. If yes, remove the fault.
2. Check whether the service configuration is correct, including the settings of DTE and
DCE, inter, slave or exter. Make sure that the service configuration is correct.
After making sure that the DCE at the opposite end works well, the DSR alarm is
automatically cleared.
----End
Related Information
None.
9.68 DTR
Description
The DTR is an alarm indicating that the DCE at the local end has detected the DTE at the
opposite end works abnormally. That is, the Data Terminal Ready status at the DTE is
abnormal.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 2, Indicates the path number. Parameter 2 is the higher byte, and
Parameter 3 Parameter 3 is the lower byte.
For example, Parameter 2 = 0x00, Parameter 3 = 0x01. In this case,
the DTR alarm is reported from path 1 of the board.
Possible Causes
The possible cause of the DTR alarm is as follows:
The DTE at the opposite end works abnormally because the cable is improperly connected, or
the service configuration is incorrect.
Procedure
Step 1 Check whether the DTE at the opposite end works well by following the actions:
1. Check whether the cable is faulty. If yes, remove the fault.
2. Check whether the service configuration is correct, including the settings of DTE and
DCE, inter, slave or exter. Make sure that the service configuration is correct.
After making sure that the DTE at the opposite end works well, the DTR alarm is
automatically cleared.
----End
Related Information
None.
9.69 E1_LOC
Description
The E1_LOC is an alarm indicating the loss of the upstream 2M clock. This alarm occurs
when the line board cannot extract the clock from the input E1 signal.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Possible Causes
The possible causes of the E1_LOC alarm are as follows:
Procedure
Step 1 Check whether there is any external interference that causes the abnormal waveform of the E1
signal. If yes, remove the external interference and check whether the E1_LOC alarm is
cleared.
Step 2 If the alarm persists, check whether the trunk cable is connected properly and whether the
trunk cable is damaged. After rectifying the problem of the trunk cable, check the E1_LOC
alarm is cleared.
Step 3 If the alarm persists, check whether the equipment at the opposite station is faulty. If yes,
replace the faulty board at the opposite station.
Step 4 If the alarm persists, replace the tributary board that reports the alarm at the local station.
----End
Related Information
None.
9.70 ETH_NO_FLOW
Description
The ETH_NO_FLOW is an alarm indicating that the ETH port has no traffic. When the ETH
port is enabled and in the Link Up state, this alarm is reported if the ETH port has no traffic.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Possible Causes
The possible causes of the ETH_NO_FLOW alarm are as follows:
l No services are configured when the ETH port is enabled and in the Link Up state.
l The services at the local end become abnormal or no packets are transmitted at the local
end when the ETH port is enabled and in the Link Up state.
l Services at the opposite end become abnormal or no packets are transmitted to the local
end when the ETH port is enabled and in the Link Up state.
Procedure
Step 1 View the ETH_NO_FLOW alarm on the U2000 to confirm the board where the
ETH_NO_FLOW alarm is generated. Confirm the specific MAC port number of the board
according to Parameter 1.
Step 2 Check whether any service is configured at the port. If not, check whether carelessness causes
the missing of service configuration.
Step 3 If yes, confirm the direction in which the traffic stops according to Parameter 4.
l If the traffic stops in the TX direction, check whether the local equipment works
normally.
l If the traffic stops in the RX direction, check whether the opposite equipment works
normally.
----End
Related Information
None.
9.71 ETHOAM_DISCOVER_FAIL
Description
The ETHOAM_DISCOVER_FAIL is an alarm indicating the point-to-point Ethernet OAM
discovery failure. When the OAM protocol is enabled at the port of a board and the
negotiation with the opposite equipment fails, this alarm occurs.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1 Indicates the number of the Ethernet port where the alarm occurs.
Name Meaning
Possible Causes
The possible causes of the ETHOAM_DISCOVER_FAIL alarm are as follows:
Procedure
Step 1 View the ETHOAM_DISCOVER_FAIL alarm on the U2000 and confirm the possible causes
of the alarm according to Parameter 3.
Step 2 When Parameter 4 is 0x01, it indicates that LinkFault occurs to the local end. Query board
level alarms on the U2000. Then remove the fault according to the specific link alarms such
as the ETH_LOS and LINK_ERR.
Step 3 When Parameter 4 is 0x02, it indicates that the local end fails to transmit the OAM message.
View the printed information of the serial port. The internal components are involved in the
problem. The fault location needs the assistance of the engineers on the related project teams.
Step 4 When Parameter 4 is 0x03, it indicates that the local end fails to receive the 3ahOAM
message sent by the opposite end in a user-defined time.
1. Check whether the MAC addresses of the interconnected ports are the same. If yes, set
different MAC addresses for the interconnected ports. Then check whether the alarm is
cleared.
2. Check whether the 3ahOAM protocol is enabled at the opposite end. If not, enable the
protocol at the opposite end. Then check whether the alarm is cleared.
3. If the alarm persists, the local end fails to receive the OAM message. Replace the board.
Step 5 When Parameter 4 is 0x04, it indicates that the OAM configurations of the opposite end,
including link event reporting ability and unidirectional operation ability, do not meet the
requirements of the local end. Query and modify the configurations of the opposite port on the
U2000. When the configurations meet the requirements of the local end, the alarm is
automatically cleared.
Step 6 When Parameter 4 is 0x05,it indicates that the OAM configurations of the local end do not
meet the requirements of the opposite end. Query and modify the configurations of the local
port on the U2000. When the configurations meet the requirements of the opposite end, the
alarm is automatically cleared.
----End
Related Information
None.
9.72 ETHOAM_RMT_CRIT_FAULT
Description
The ETHOAM_RMT_CRIT_FAULT is an alarm indicating that a critical fault occurs to the
remote end of point-to-point Ethernet OAM. When the port with the OAM protocol enabled
receives the OAM message that contains critical fault information from the opposite end, this
alarm occurs.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1 Indicates the number of the Ethernet port where the alarm occurs.
Name Meaning
Possible Causes
The possible cause of the ETHOAM_RMT_CRIT_FAULT alarm is as follows:
The port with the OAM protocol enabled receives the OAM message that contains critical
fault information from the opposite end, such as LinkFault and power failure.
Procedure
Step 1 If LinkFault occurs to the opposite port, query board level alarms on the U2000. Remove the
fault according to the specific link alarms such as the ETH_LOS and LINK_ERR. Check
whether the alarm is cleared.
Step 2 If irrecoverable problems such as power failure occur to the opposite end, remove the fault.
The alarm is automatically cleared.
Step 3 If other unknown faults occur, contact Huawei engineers.
----End
Related Information
None.
9.73 ETHOAM_RMT_LOOP
Description
The ETHOAM_RMT_LOOP is an alarm indicating the remote loopback of point-to-point
Ethernet OAM. This alarm only occurs to the port with the point-to-point OAM protocol
enabled. If the port is able to respond to loopback, it enters the loopback response state and
reports the loopback response alarm after it receives the remote loopback enabling command
sent by the opposite OAM port. The loopback initiator reports the loopback initiating alarm. If
the port receives the loopback disabling command, it exits the loopback response state and
ends the loopback response alarm. The loopback initiator end also ends the loopback initiating
alarm.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1 Indicates the number of the Ethernet port where the alarm occurs.
Possible Causes
The possible causes of the ETHOAM_RMT_LOOP alarm are as follows:
l A command is issued to enable the loopback at the local port, and the opposite end is the
loopback responder.
l A command is issued to enable the loopback at the opposite port, and the local end is the
loopback responder.
Procedure
Step 1 Disable the loopback. The ETHOAM_RMT_LOOP alarm is automatically cleared.
----End
Related Information
None.
9.74 ETHOAM_RMT_SD
Description
The ETHOAM_RMT_SD is an alarm indicating the remote SD of point-to-point Ethernet
OAM. When the port with the OAM protocol enabled receives the link event message from
the opposite end which indicates that the remote Ethernet performance degraded, this alarm
occurs.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1 Indicates the number of the Ethernet port where the alarm occurs.
Possible Causes
The possible cause of the ETHOAM_RMT_SD alarm is as follows:
The port with the OAM protocol enabled receives the link event message from the opposite
end.
Procedure
Step 1 Improve the link performance at the opposite end until the opposite end does not send link
event message to the local end, the ETHOAM_RMT_SD alarm at the local end is
automatically cleared.
Step 2 Modify the value of the link performance monitoring threshold at the opposite end. Then the
ETHOAM_RMT_SD alarm at the local end is automatically cleared.
Step 3 Disable the link event reporting at the opposite end. Then the ETHOAM_RMT_SD alarm at
the local end is automatically cleared.
----End
Related Information
None.
9.75 ETHOAM_SELF_LOOP
Description
The ETHOAM_SELF_LOOP is an alarm indicating loopback of the MAC port that receives
the OAM protocol packets in a point-to-point manner. If the MAC port of a board receives the
OAM protocol packets sent by itself or the board after detection of the loop is enabled, the
ETHOAM_SELF_LOOP alarm is reported.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Name Meaning
Possible Causes
The possible causes of the ETHOAM_SELF_LOOP alarm are as follows:
l Self-loop is performed for the port with a cable.
l Loopback is set among ports of the board.
l The PHY/MAC loopback of the port is manually set.
Procedure
Step 1 Check whether the transmit and receive ends of the port are connected with a cable. If yes,
connect the cable correctly, and then check whether the ETHOAM_SELF_LOOP alarm is
cleared.
Step 2 If the ETHOAM_SELF_LOOP alarm persists, check whether the transmit and receive ends of
the port are connected to those of other ports with cables. If yes, connect the cables correctly,
and then check whether the ETHOAM_SELF_LOOP alarm is cleared.
Step 3 If the ETHOAM_SELF_LOOP alarm persists, check whether any PHY/MAC layer loopback
is set for the port. If yes, release the loopback, or wait five minutes when the U2000
automatically releases the loopback. Then check whether the ETHOAM_SELF_LOOP alarm
is cleared.
----End
Related Information
None.
9.76 ETHOAM_VCG_SELF_LOOP
Description
The ETHOAM_VCG_SELF_LOOP is an alarm indicating loopback of the VCTRUNK port
that receives the OAM protocol packets in a point-to-point manner. If the VCTRUNK port of
a board receives the OAM protocol packets sent by itself or the board after detection of the
loop is enabled, the ETHOAM_VCG_SELF_LOOP alarm is reported.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 2, Indicate the VCG port number. Parameter 2 is the higher byte, and
Parameter 3 Parameter 3 is the lower byte.
Possible Causes
The possible causes of the ETHOAM_VCG_SELF_LOOP alarm are as follows:
l The links of the VCG port is configured into a loop.
l The links between VCG ports of the board is configured into a loop.
Procedure
Step 1 Check the ETHOAM_VCG_SELF_LOOP alarm on the U2000, and determine the VCG port
number according to Parameter 2.
Step 2 Check the link configuration of the VCG port to see whether the transmit and receive
directions of the port are connected. Make sure the link configuration is correct, and then
check if the ETHOAM_VCG_SELF_LOOP alarm is cleared.
Step 3 If the ETHOAM_VCG_SELF_LOOP alarm persists, check the link configuration of the VCG
port to see whether this VCG port is connected to another VCG port on the board in the
transmit and receive directions. Make sure the link configuration is correct. Then, the
ETHOAM_VCG_SELF_LOOP alarm is cleared.
----End
Related Information
None.
9.77 EX_ETHOAM_CC_LOS
Description
The EX_ETHOAM_CC_LOS is an alarm indicating the loss of the periodic continuity check
message. When the sink maintenance point receives the continuity check (CC) message from
the source maintenance point, the timer is started to periodically check the link between the
source and sink maintenance points. If the sink maintenance point does not receive the CC
message from the source maintenance point in one period (3.5 times of the time during which
the CC message is transmitted from the source maintenance point to the sink maintenance
point), this alarm occurs.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 2 Indicates the number of the Ethernet port where the EX_ETHOAM_CC_LOS
alarm is reported.
l MAC port number: 0x0001-0x0000 plus MAX_ETH_PORT.
l VCTRUNK port number: 0x8001-0x8000 plus MAX_ETH_VCTRUNK.
NOTE
l MAX_ETH_PORT indicates the maximum MAC port number supported by the
board.
l MAX_ETH_VCTRUNK indicates the maximum VCTRUNK port number supported
by the board.
Name Meaning
Parameter 6 Indicates the ID of the MP at the CC sink. The MP ID should be unique in the
entire network.
NOTE
The ID of the MP at the CC sink is the ID of the MP where the EX_ETHOAM_CC_LOS
alarm is reported. Parameter 1 and Parameter 6 carry the same information.
Possible Causes
The possible causes of the EX_ETHOAM_CC_LOS alarm are as follows:
l A software or hardware failure occurs to the services from the source maintenance point
to the sink maintenance point.
l Service congestion or service interruption occurs between the source maintenance point
and the sink maintenance point.
Procedure
Step 1 View the EX_ETHOAM_CC_LOS alarm on the U2000 and confirm the ID of the relevant
maintenance point according to the alarm parameter 1.
Step 3 Perform loopback (LB) and link trace (LT) test for the source and sink maintenance points, to
locate the fault in the services between the source maintenance point and the sink
maintenance point.
Step 4 Perform checks for the problem services, including software check, hardware check, and
traffic check. After the services restore, the alarm is automatically cleared. You may also
perform LB to confirm that the alarm is cleared.
----End
Related Information
None.
9.78 EX_ETHOAM_MPID_CNFLCT
Description
The EX_ETHOAM_MPID_CNFLCT is an alarm indicating the maintenance point ID
conflict. When a maintenance point receives the message sent by another maintenance point
with the same MPID in a maintenance domain, this alarm occurs.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Name Meaning
Parameter 5 Indicates the ID of the local MP. The MP ID should be unique in the entire
network.
NOTE
The ID of the local MP is the ID of the MP where the EX_ETHOAM_MPID_CNFLCT
alarm is reported. Parameter 1 and Parameter 5 carry the same information.
Possible Causes
The possible cause of the EX_ETHOAM_MPID_CNFLCT alarm is as follows:
Multiple maintenance points with the same MPID are created in a maintenance domain.
Procedure
Step 1 View the EX_ETHOAM_MPID_CNFLCT alarm on the U2000 and confirm the ID of the
relevant maintenance point according to the alarm parameter 1.
Step 2 Query the information of the maintenance point. Delete all the maintenance points with the
same MPID, then the alarm is automatically cleared.
----End
Related Information
None.
9.79 EXT_LOS
Description
The EXT_LOS is an alarm indicating loss of signal. When the 140 Mbit/s signals fail to be
detected, the EXT_LOS alarm is reported.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Possible Causes
The possible causes of the EXT_LOS alarm are as follows:
l No input signals.
l The input signals are not the 140 Mbit/s signals.
l The board is faulty.
Procedure
Step 1 At the digital distribution frame (DDF), perform hardware inloop to the path.
NOTICE
The loopback causes service interruption.
l If the alarm is cleared, the accessed signals may be incorrect. In this case, check whether
the accessed signals are the 140 Mbit/s service signals.
l If the alarm persists, the trunk cable is faulty, or the board is faulty. Go to the next step.
Step 2 At the interface board, perform hardware inloop to the path.
NOTICE
The loopback causes service interruption.
l If the alarm is cleared, the signal trunk cable is faulty. Check whether the trunk cable
contacts the connector firmly, and whether the trunk cable is cut. After removing these
problems, remove the inloop, and then check whether the EXT_LOS alarm is cleared.
l If the alarm persists, the interface board is faulty, or the tributary board is faulty. Go to
the next step.
Step 3 Perform inloop to the path on the U2000.
NOTICE
The loopback causes service interruption.
l If the alarm is cleared, the interface board is faulty. In this case, remove the interface
board and insert it again, or replace the interface board.
l If the alarm persists, the alarm board is faulty. Go to the next step.
Step 4 Replace the board that reports the alarm, and then check whether the EXT_LOS alarm is
cleared.
----End
Related Information
None.
9.80 EXT_TIME_LOC
Description
The EXT_TIME_LOC alarm indicates that the external time source is lost. This alarm is
reported when the input function of the external time port is enabled but no board receives the
input signals of the external time.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Possible Causes
The possible cause of the EXT_TIME_LOC alarm is as follows:
The input function of the external time port is enabled, but no external time signals are input.
Procedure
Step 1 Check whether the cable is connected properly. If any abnormalities occur, ensure that they
are be cleared. For example, the abnormality may be that the cable is not connected to the
corresponding external time interface, or the cable is disconnected because it is damaged.
Step 2 Check the status of the external time equipment, and clear the abnormalities.
----End
Related Information
None.
9.81 FEC_LOF
Description
The FEC_LOF is an alarm indicating loss of FEC frame.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Possible Causes
The possible causes of the FEC_LOF alarm are as follows:
Procedure
Step 1 View the FEC_LOF alarm on the U2000 to confirm the relevant board.
Step 2 View the received optical power of the board on the U2000. If the received optical power is
extremely low, clean the fiber head and the connector. If the received optical power is
extremely high, provide more optical attenuators. After making sure that the received optical
power is proper, check whether the FEC_LOF alarm is cleared.
Step 3 If the alarm persists, check whether the upstream service is the FEC service at the same rate.
If not, configure the FEC service at a correct rate, and then check whether the FEC_LOF
alarm is cleared.
Step 4 If the alarm persists, check whether the upstream service is supported by the board. If not,
configure a correct service, and then check whether the FEC_LOF alarm is cleared.
Step 5 If the alarm persists, check whether the clocks in the local NE and the opposite NE are
synchronous with those in the network. If not, set the clock tracing function, and then check
whether the FEC_LOF alarm is cleared.
Step 6 If the alarm persists, the board hardware may be faulty. In this case, replace the board that
reports the alarm at the local station.
Step 7 If the alarm persists, the board at the opposite station may be faulty. In this case, replace the
board.
----End
Related Information
None.
9.82 FEC_OOF
Description
The FEC_OOF is an alarm indicating that the FEC frame is out of frame.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Possible Causes
The possible causes of the FEC_OOF alarm are as follows:
Procedure
Step 1 View the FEC_OOF alarm on the U2000 to confirm the relevant board.
Step 2 View the received optical power of the board on the U2000. If the received optical power is
extremely low, clean the fiber head and the connector. If the received optical power is
extremely high, provide more optical attenuators. After making sure that the received optical
power is proper, check whether the FEC_OOF alarm is cleared.
Step 3 If the alarm persists, check the launched optical power at the opposite end. If the launched
optical power is extremely low, replace the board at the opposite end.
Step 4 If the alarm persists, check whether the clocks in the local NE and the opposite NE are
synchronous with those in the network. If not, set the clock tracing function, and then check
whether the FEC_OOF alarm is cleared.
Step 5 If the alarm persists, check whether the fiber works well. If yes, replace the board that
generates the alarm.
Step 6 If the alarm persists, replace the cross-connect and timing board at the local station.
Step 7 If the alarm persists, replace the line board at the opposite end.
Step 8 If the alarm persists, replace the cross-connect and timing board at the opposite end.
----End
Related Information
None.
9.83 FLOW_OVER
Description
The FLOW_OVER alarm indicates that the inflow at the Ethernet port crosses the threshold.
This alarm is reported when the received traffic at the Ethernet port exceeds the expected
traffic.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1 Indicates the number of the port. The value ranges are different
from board to board.
Parameter 2, Parameter Indicates the number of the optical interface number. Parameter 2
3 is always 0x00, and Parameter 3 is always 0x01.
Possible Causes
The possible cause of the FLOW_OVER alarm is as follows:
The traffic received by the port is larger than the preset traffic of the port.
Procedure
Step 1 View the FLOW_OVER alarm on the U2000, and confirm the relevant board and port
according to Parameter 1.
Step 2 View the parameters of the configured bandwidth, the actual traffic of the port, and the traffic
tolerance of the port.
l If the actual traffic of the port is higher than the traffic tolerance of the port, proceed to
the next step.
l If the actual traffic of the port is lower than the traffic tolerance of the port, go to step 5.
Step 3 Check whether the traffic tolerance of the port can be increased.
l If the traffic tolerance of the port can be increased, increase the bandwidth.
l If the traffic tolerance of the port cannot be increased, enable the flow control function,
or decrease the data traffic that is transmitted by the opposite station.
Step 4 If the actual traffic of the port is lower than the traffic tolerance of the port, the packets are
transmitted normally. Query whether the FLOW_OVER alarm is cleared. If the alarm persists,
proceed to the next step.
Step 5 Check whether the expected traffic of the port can be increased.
l If the expected traffic of the port can be increased, increase the threshold traffic to clear
the alarm.
NOTE
The channel numbers to be added should have the same rate as the original channel members.
The expected traffic of the port should be lower than the traffic tolerance of the port.
l If the expected traffic of the port cannot be increased, decrease the data traffic that is
transmitted by the opposite station to clear the alarm.
Step 6 If the actual traffic of the port is lower than the bandwidth threshold of the port, the alarm is
cleared.
----End
Related Information
None.
9.84 FPGA_ABN
Description
The FPGA_ABN is an alarm indicating the failure of reading and writing the FPGA.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 2, Parameter 3 The value is always 0x01. Parameter 2 is the higher byte, and
Parameter 3 is the lower byte.
Parameter 4, Parameter 5 The value is 0xFF. Currently, these parameters are not used.
When the alarm occurs, the board fails to function. If the board is reset, the services may be
interrupted.
Possible Causes
The possible cause of the FPGA_ABN alarm is as follows:
Procedure
Step 1 Download the FPGA of the board again and then check whether the FPGA_ABN alarm is
cleared.
----End
Related Information
None.
9.85 FSELECT_STG
Description
The FSELECT_STG is an alarm indicating that the clock board is forcibly selected.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Possible Causes
The possible cause of the FSELECT_STG alarm is as follows:
Procedure
Step 1 After the command of forcibly selecting the clock board is cancelled, the FSELECT_STG
alarm is automatically cleared.
----End
Related Information
None.
9.86 FUSE_ALARM
Description
The FUSE_ALARM is an alarm indicating output offline. This alarm occurs when the fuse of
the CAU board is faulty.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 2, Indicates the type of the faulty fuse. Parameter 2 is the higher byte, and
Parameter 3 Parameter 3 is the lower byte.
The value of Parameter 2 is always 0x00. The values of Parameter 3 are
as follows:
l 0x01: Battery fuse
l 0x02: Battery discharge
l 0x03: Load fuse 1
l 0x04: Load fuse 2
Parameter 4, Parameter 4 is the higher byte, and Parameter 5 is the lower byte.
Parameter 5
The value of Parameter 4 is always 0x00. The value of Parameter 5 is
always 0x01, and indicates open circuits.
Possible Causes
The possible causes of the FUSE_ALARM alarm are as follows:
Procedure
Step 1 View the FUSE_ALARM alarm on the U2000. Confirm the type of the faulty load fuse
according to Parameter 3.
l If the battery fuse is faulty, replace the fuse. Then, check whether the FUSE_ALARM
alarm is cleared.
l If the load fuse 1 is faulty, replace the fuse. Then, check whether the FUSE_ALARM
alarm is cleared.
l If the load fuse 2 is faulty, replace the fuse. Then, check whether the FUSE_ALARM
alarm is cleared.
----End
Related Information
None.
9.87 HARD_ERR
Description
The HARD_ERR is a hardware error alarm. This alarm occurs when some minor faults occur
to the hardware.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1 Indicates the type of the fault that causes the alarm.
l 0x01: Clock chip fault
l 0x02: Self-check fault of a certain component
l 0x03: Self-check fault of the chip
l 0x04: Port fault
l 0x06: Digital phase locked loop abnormality
l 0x0F: Chip fault
l 0x12: Clock component fault
l 0x14: Power component fault
l 0x15: Other equipment alarm
Parameter 2, Indicate the name of the component that has the fault indicated by
Parameter 3 Parameter 1. For example, when Parameter = 0x14, 0x0200 indicates the
-5.2 V power.
Possible Causes
The board hardware is faulty.
Procedure
Step 1 Replace the faulty board.
----End
Related Information
None.
9.88 HP_CROSSTR
Description
The HP_CROSSTR is an alarm indicating that the number of the higher order path bit errors
crosses the threshold.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1 Indicates the optical interface number where the excessive higher
order path bit errors occur.
Parameter 2, Indicates the path number where the excessive higher order path bit
Parameter 3 errors occur.
Name Meaning
Parameter 4 The higher two bits indicate the performance monitoring period.
l 01: 15-minute performance monitoring
l 02: 24-hour performance monitoring
The lower six bits together with Parameter 5 indicate the
performance event ID.
Possible Causes
The possible causes of the HP_CROSSTR alarm are as follows:
l The laser performance at the opposite station is degraded.
l The received optical power at the local station is too high or too low.
l The clock performance at the local station or the opposite station is degraded.
l The fiber performance is degraded.
Procedure
Step 1 Perform an inloop on the board that reports the HP_CROSSTR alarm at the local station.
NOTICE
The loopback causes service interruption.
NOTICE
The loopback causes service interruption.
1. If the alarm is cleared, it indicates that the fault occurs to the local station. Go to Step 3.
2. If the alarm persists, it indicates that the fiber performance is degraded or the fiber
jumper connector is dirty. Go to Step 5.
Step 4 Replace the board that reports the HP_CROSSTR alarm at the local station.
1. If the alarm is cleared, the fault is removed. The alarm handling ends.
2. If the alarm persists, replace the cross-connect and timing board at the local station. The
alarm handling ends.
Step 5 Clean the fiber jumper connectors at both the local and opposite stations.
1. If the alarm is cleared, the fault is removed. The alarm handling ends.
2. If the alarm persists, it indicates that the fault occurs to the fiber cables. Remove the
fault, and the alarm handling ends.
----End
Related Information
None.
9.89 HP_REI
Description
The HP_REI is a remote error indication in the higher order path.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Name Meaning
Possible Causes
The possible cause of the HP_REI alarm is as follows:
The HP_REI alarm is an accompanying alarm. When an intermediate station has detected an
alarm (such as the B3_EXC or B3_SD) of B3 bit errors, it returns an HP_REI alarm to the
local station.
Procedure
Step 1 After you clear the B3_EXC or B3_SD alarm that occurs at an intermediate station, the
HP_REI alarm is automatically cleared.
----End
Related Information
None.
9.90 IN_PWR_FAIL
Description
The IN_PWR_FAIL is an alarm indicating that the optical amplifier board detects no input
power at its input optical interface.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
Name Meaning
If any optical signals that carry services must be amplified through this optical interface, and
the service path is not protected by MSP or SNCP, the relevant services are interrupted.
Possible Causes
The possible causes of the IN_PWR_FAIL alarm are as follows:
Procedure
Step 1 Use the OTDR to test whether the optical cable is cut.
Step 2 Clean the fiber jumper connector at the local station and the receive optical interface on the
line board, and then check whether the IN_PWR_FAIL alarm is cleared.
Step 3 Make sure that the flange of the local station is correctly connected, and then check whether
the alarm is cleared.
Step 4 Check whether the optical power transmitted by the opposite station is normal. If the optical
power transmitted by the opposite station is normal, the receive module of the board at the
local station is faulty. Replace the board of the local station.
Step 5 If the optical power transmitted by the opposite station is abnormal, clean the fiber jumper
connector at the opposite station, and then check whether the alarm is cleared.
Step 6 Make sure that the flange of the opposite station is correctly connected, and then check
whether the alarm is cleared.
Step 7 If the optical power transmitted by the opposite station is still abnormal, the transmit optical
module of the board at the opposite station is faulty. Replace the board of the opposite station.
----End
Related Information
None.
9.91 K1_K2_M
Description
The K1_K2_M is an alarm indicating the mismatch between the K1 and K2 bytes. This alarm
occurs, when the path numbers indicated in the transmitted K1 byte and the received K2 byte
are inconsistent and the inconsistency lasts for a time period (160 ms by default).
Attribute
Alarm Severity Alarm Type
Parameters
None.
Possible Causes
The possible causes of the K1_K2_M alarm are as follows:
l Fibers are misconnected.
l The service board is faulty.
l The cross-connect board is faulty.
Procedure
Step 1 View the K1_K2_M alarm on the NMS, and then confirm the linear MSP group ID.
Step 2 Make sure that the fibers of the MSP are correctly connected, and that the logical and physical
configurations of fibers are consistent. Check whether the alarm is cleared.
Step 3 If the alarm persists, check whether the service boards configured with the MSP at the local
and opposite ends are faulty. After replacing faulty service boards, check whether the alarm is
cleared.
Step 4 If the alarm persists, check whether the cross-connect boards at the local and opposite ends
are faulty. After replacing faulty cross-connect boards, check whether the alarm is cleared.
----End
Related Information
None.
9.92 K2_M
Description
The K2_M is an alarm of K2 byte mismatch. This alarm occurs, when the opposite end
protection mode indicated by the fifth bit (counted from the highest bit to the lowest bit) of
the K2 byte is inconsistent with the local end protection mode, and when the inconsistency
lasts for a time period (2s by default).
Attribute
Alarm Severity Alarm Type
Parameters
None.
Possible Causes
The possible causes of the K2_M alarm are as follows:
Procedure
Step 1 Make sure that the local and opposite NEs have consistent MSP configurations. After
updating the MSP configurations, check whether the K2_M alarm is cleared.
Step 2 If the alarm persists, check whether the service boards configured with the MSP at the local
and opposite ends are faulty. After replacing faulty service boards, check whether the alarm is
cleared.
Step 3 If the alarm persists, check whether the cross-connect boards at the local and opposite ends
are faulty. After replacing faulty cross-connect boards, check whether the alarm is cleared.
----End
Related Information
None.
9.93 LAN_LOC
Description
The LAN_LOC is an alarm indicating the Ethernet communication failure.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1 Indicates the network port ID. For example, 0x01 indicates network
port 1 and 0x02 indicates network port 2.
Parameter 2, Indicates the number of the path on which the alarm is reported.
Parameter 3
Parameter 2 is the higher byte, and the value is always 0x00.
Parameter 3 is the lower byte, and the value is always 0x01.
Possible Causes
The possible causes of the LAN_LOC alarm are as follows:
l The cable is not connected to the ETH port of the AUX/SAP/EOW board.
l The ETH port of the AUX/SAP/EOW board is faulty.
l The cable is faulty.
l The SCC board is faulty.
Procedure
Step 1 View the alarm on the NMS. Determine the network port ID according to the alarm parameter
1.
Step 2 Check whether the cable of the network port is loose or no cable is connected. Properly
connect the NMS to the ETH port. The LINK indicator is in green. Then, check whether the
alarm is cleared.
Step 3 If the alarm persists, the cable may be faulty. Replace the faulty cable, and then check whether
the alarm is cleared.
Step 4 If the fault persists, check whether the network port is faulty. Replace the AUX/SAP/EOW
board. Then, check whether the alarm is cleared.
Step 5 If the alarm persists, replace the SCC board.
----End
Related Information
None.
9.94 LASER_MOD_ERR
Description
The LASER_MOD_ERR is an alarm indicating mismatch of optical modules. When the type
of the optical module inserted does not match the type supported by the board, this alarm
occurs.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Possible Causes
The possible causes of the LASER_MOD_ERR alarm are as follows:
l The rate of the optical module inserted does not match the rate of the optical interface of
the board.
l The type of the inserted optical module and the type of the port on the actual board
mismatch.
Procedure
Step 1 View the LASER_MOD_ERR alarm on the U2000 and confirm the relevant board.
Step 2 Replace the optical module. The alarm is automatically cleared.
----End
Related Information
None.
9.95 LASER_SHUT
Description
The LASER_SHUT is an alarm indicating that the laser of the board is shut down.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Possible Causes
The possible cause of the LASER_SHUT alarm is as follows:
The user uses the U2000 or Navigator and performs the operation to shut down the laser.
Procedure
Step 1 If the user cancels the setting of laser shutdown, the LASER_SHUT alarm is automatically
cleared.
----End
Related Information
None.
9.96 LCAS_BAND_DECREASED
Description
The LCAS_BAND_DECREASED is an alarm indicating that the LCAS service bandwidth
has decreased. This alarm occurs when the LCAS function is enabled, part or all of the
physical paths that are bound with the VCTRUNK are in the idle state and carry no payload,
because the path are not successfully added or the paths fail after being added.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1 Indicates the optical port, and the value is always 0x01.
Parameter 2, Parameter 3 Indicates the number of the VCTRUNK where the alarm occurs.
Parameter 2 is the higher byte, and Parameter 3 is the lower byte.
Name Meaning
Possible Causes
The possible causes of the LCAS_BAND_DECREASED alarm are as follows:
l The failure in the physical paths bound with the VCTRUNK causes the alarms such as
the AIS, LOP, UNEQ, LOM, and SD.
l The number of the upstream or downstream timeslots bound with the VCTRUNK is
inconsistent with the number of the downstream or upstream timeslots bound with the
corresponding opposite VCTRUNK.
l The cross-connection is incorrectly bound.
Procedure
Step 1 View the LCAS_BAND_DECREASED alarm on the U2000 and confirm the relevant
VCTRUNK according to the alarm parameters.
Step 2 Check whether there are the alarms such as the AIS, LOP, UNEQ, and LOM that enable the
LCAS operation of protecting members. If yes, clear these alarms. Check whether the alarm is
cleared.
Step 3 Check whether the number of the upstream or downstream timeslots bound with the
VCTRUNK is consistent with the number of the downstream or upstream timeslots bound
with the corresponding opposite VCTRUNK. If not, increase or reduce the timeslots to make
the number of the timeslots at both ends consistent. Check whether the alarm is cleared.
Step 4 If the alarm persists, check whether the cross-connection is bound correctly. If not, re-bind the
cross-connection. Check whether the alarm is cleared.
Step 5 If the alarm persists, maybe the wait-to-restore (WTR) time is too long and the members are
still not restored. Check the WTR time. Wait for a period, and then check whether the alarm is
cleared.
Step 6 If the alarm persists, disable and then enable the LCAS function of the VCTRUNK. Check
whether the alarm is cleared.
Step 7 If the alarm persists, delete and then re-bind all the physical paths of the VCTRUNK. Check
whether the alarm is cleared.
Step 8 If the alarm persists, perform a cold reset for the board.
NOTICE
If the services travel through the board are not configured with protection, the services are
interrupted after the cold reset of the board.
----End
Related Information
None.
9.97 LCAS_FOPR
Description
The LCAS_FOPR is an alarm indicating the failure of the LCAS protocol in the receive
direction. When the sink end of the LCAS module detects abnormalities, the LCAS
negotiation is unavailable or incorrect and this alarm occurs.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 2, Parameter 3 Indicates the number of the VCTRUNK where the alarm occurs.
Parameter 2 is the higher byte, and Parameter 3 is the lower byte.
Possible Causes
The possible causes of the LCAS_FOPR alarm are as follows:
l The downstream VCG receives repeated sequence numbers due to wrong configurations
or link bit errors.
l The LCAS function of the opposite VCG is disabled.
l The downstream VCG simultaneously receives the FIXED and other LCAS control
bytes due to wrong configurations or link bit errors.
l The cross-connection is incorrectly bound.
Procedure
Step 1 View the LCAS_FOPR alarm on the U2000 and confirm the relevant VCTRUNK according
to the alarm parameters.
Step 2 Check whether the LCAS protocol is enabled at the opposite end. If not, enable the LCAS
protocol at the opposite end. Check whether the alarm is cleared.
Step 3 If the alarm persists, check whether the configurations are correct. Especially, check whether
the cross-connection is bound correctly. If not, modify the wrong configurations. Check
whether the alarm is cleared.
Step 4 If the alarm persists, disable and then enable the LCAS function at both ends. Check whether
the alarm is cleared.
----End
Related Information
None.
9.98 LCAS_FOPT
Description
The LCAS_FOPT is an alarm indicating the failure of the LCAS protocol in the transmit
direction. When the source end of the LCAS module detects abnormalities, the LCAS
negotiation is unavailable or incorrect and this alarm occurs.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 2, Parameter 3 Indicates the number of the VCTRUNK where the alarm occurs.
Parameter 2 is the higher byte, and Parameter 3 is the lower byte.
Possible Causes
The possible cause of the LCAS_FOPT alarm is as follows:
l There is the persistent and unexpected MST due to wrong configurations or link bit
errors. For example, the member that transmits IDLE always receives MST=OK.
l The downstream VCG simultaneously receives the FIXED and other LCAS control
bytes due to wrong configurations or link bit errors.
Procedure
Step 1 View the LCAS_FOPT alarm on the U2000 and confirm the relevant VCTRUNK according
to the alarm parameters.
Step 2 Check whether the service cross-connection of the VCTRUNK is bound correctly. If not,
modify the wrong configurations. Check whether the alarm is cleared.
----End
Related Information
None.
9.99 LCAS_PLCR
Description
The LCAS_PLCR is an alarm indicating partial loss of capacity in the LCAS receive
direction. When the LCAS function of the VCTRUNK is enabled, in the receive direction, the
number of paths that carry load is less than the number of paths configured and is not zero.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 2, Parameter 3 Indicates the number of the VCTRUNK where the alarm occurs.
Parameter 2 is the higher byte, and Parameter 3 is the lower byte.
Possible Causes
The possible causes of the LCAS_PLCR alarm are as follows:
l Bidirectional services are not configured.
l The number of members in the upstream of the opposite end is less than that in the
downstream of the local end.
l The path communication fails because the cross-connection is wrong or the physical link
is improperly connected.
Procedure
Step 1 Check whether there are other alarms such as the AIS, LOP, UNEQ, and LOM. If yes, clear
these alarms first. Check whether the alarm is cleared.
Step 2 Ensure that the physical link is available. Check whether bidirectional services are configured.
If not, configure bidirectional services.
Step 3 If the alarm persists, check on the U2000 whether the number of downstream timeslots bound
with the VCTRUNK at the local end is consistent with that of upstream timeslots bound with
the VCTRUNK at the opposite end. If not, increase or reduce the timeslots to make the
number of the timeslots at both ends consistent. Check whether the alarm is cleared.
Step 4 Check whether the cross-connection is bound from the transmit direction to the opposite end.
If not, re-bind the cross-connection. Check whether the alarm is cleared.
Step 5 If the alarm persists, maybe the wait-to-restore (WTR) time is too long and the members are
still not restored. Check the WTR time. Wait for a period, and then check whether the alarm is
cleared.
Step 6 If the alarm persists, disable and then enable the LCAS function of the VCTRUNK. Check
whether the alarm is cleared.
Step 7 If the alarm persists, delete and then re-bind all the physical paths of the VCTRUNK. Check
whether the alarm is cleared.
Step 8 If the alarm persists, perform a cold reset for the board, or remove and insert the board.
NOTICE
If the services travel through the board are not configured with protection, the services are
interrupted after the cold reset of the board.
----End
Related Information
None.
9.100 LCAS_PLCT
Description
The LCAS_PLCT is an alarm indicating partial loss of capacity in the LCAS transmit
direction. When the LCAS function of the VCTRUNK is enabled, in the transmit direction,
the number of paths that carry load is less than the number of paths configured and is not zero.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 2, Parameter 3 Indicates the number of the VCTRUNK where the alarm occurs.
Parameter 2 is the higher byte, and Parameter 3 is the lower byte.
Possible Causes
The possible causes of the LCAS_PLCT alarm are as follows:
Procedure
Step 1 View the LCAS_PLCT alarm on the U2000 and confirm the relevant VCTRUNK according
to the alarm parameters.
Step 2 Check whether the LCAS_PLCR alarm is present at the opposite station. If yes, clear the
LCAS_PLCR alarm first. Check whether the alarm is cleared.
Step 3 If the alarm persists, check whether bidirectional services are configured. If not, configure
bidirectional services. Check whether the alarm is cleared.
Step 4 If the alarm persists, check on the U2000 whether the number of upstream timeslots bound
with the VCTRUNK at the local end is consistent with that of downstream timeslots bound
with the VCTRUNK at the opposite end. If not, increase or reduce the timeslots to make the
number of the timeslots at both ends consistent. Check whether the alarm is cleared.
Step 5 If the alarm persists, the cross-connection is not bound from the transmit direction to the
opposite end. Re-bind the cross-connection. The alarm is automatically cleared.
Step 6 If the alarm persists, maybe the wait-to-restore (WTR) time is too long and the members are
still not restored. Check the WTR time. Wait for a period, and then check whether the alarm is
cleared.
Step 7 If the alarm persists, disable and then enable the LCAS function of the VCTRUNK. Check
whether the alarm is cleared.
Step 8 If the alarm persists, delete and then re-bind all the physical paths of the VCTRUNK. Check
whether the alarm is cleared.
Step 9 If the alarm persists, perform a cold reset for the board.
NOTICE
If the services travel through the board are not configured with protection, the services are
interrupted after the cold reset of the board.
----End
Related Information
None.
9.101 LCAS_TLCR
Description
The LCAS_TLCR is an alarm indicating the total loss of capacity in the LCAS receive
direction. When the LCAS function of the VCTRUNK is enabled, in the receive direction, the
number of paths that carry load is zero, whereas the number of paths configured is not zero.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 2, Parameter 3 Indicates the number of the VCTRUNK where the alarm occurs.
Parameter 2 is the higher byte, and Parameter 3 is the lower byte.
Possible Causes
The possible causes of the LCAS_TLCR alarm are as follows:
Procedure
Step 1 View the LCAS_TLCR alarm on the U2000 and confirm the relevant VCTRUNK according
to the alarm parameters.
Step 2 Check whether there are other alarms such as the AIS, LOP, UNEQ, and LOM. If yes, clear
these alarms first. Check whether the alarm is cleared.
Step 3 Check whether bidirectional services are configured. If not, configure bidirectional services.
Check whether the alarm is cleared.
Step 4 If the alarm persists, check whether the upstream of the opposite end is bound with timeslots.
If not, bind the timeslots in the corresponding direction. Check whether the alarm is cleared.
Step 5 If the alarm persists, the cross-connection is not bound from the transmit direction to the local
end. Re-bind the cross-connection. The alarm is automatically cleared.
Step 6 If the alarm persists, disable and then enable the LCAS function of the VCTRUNK. Check
whether the alarm is cleared.
Step 7 If the alarm persists, delete and then re-bind all the physical paths of the VCTRUNK. Check
whether the alarm is cleared.
Step 8 If the alarm persists, perform a cold reset for the board, or remove and insert the board.
NOTICE
If the services travel through the board are not configured with protection, the services are
interrupted after the cold reset of the board.
----End
Related Information
None.
9.102 LCAS_TLCT
Description
The LCAS_TLCT is an alarm indicating total loss of capacity in the LCAS transmit direction.
When the LCAS function of the VCTRUNK is enabled, in the transmit direction, the number
of paths that carry load is zero, whereas the number of paths configured is not zero.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 2, Parameter 3 Indicates the number of the VCTRUNK where the alarm occurs.
Parameter 2 is the higher byte, and Parameter 3 is the lower byte.
Possible Causes
The possible causes of the LCAS_TLCT alarm are as follows:
l The downstream of the opposite end is not bound with members.
l The path communication fails because the cross-connection is wrong or other alarms are
present.
Procedure
Step 1 View the LCAS_TLCT alarm on the U2000 and confirm the relevant VCTRUNK according
to the alarm parameters.
Step 2 Check whether the LCAS_TLCR alarm is present at the opposite station. If yes, clear the
LCAS_TLCR alarm first. Check whether the alarm is cleared.
Step 3 Check whether there are other alarms such as the AIS, LOP, UNEQ, and LOM. If yes, clear
these alarms first. Check whether the alarm is cleared.
Step 4 If the alarm persists, check whether the downstream of the opposite end is bound with
timeslots. If not, bind the timeslots in the corresponding direction. Check whether the alarm is
cleared.
Step 5 If the alarm persists, check whether the cross-connection is correctly bound from the transmit
direction to the opposite end. If not, re-bind the cross-connection. Check whether the alarm is
cleared.
Step 6 If the alarm persists, disable and then enable the LCAS function of the VCTRUNK. Check
whether the alarm is cleared.
Step 7 If the alarm persists, delete and then re-bind all the physical paths of the VCTRUNK. Check
whether the alarm is cleared.
Step 8 If the alarm persists, perform a cold reset for the board.
NOTICE
If the services travel through the board are not configured with protection, the services are
interrupted after the cold reset of the board.
----End
Related Information
None.
9.103 LCD
Description
The LCD is an alarm indicating the loss of cell delimitation. If the OCD alarm continuously
occurs within the transmission period of n cells, the LCD alarm is reported. The letter n
indicates the LCD alarm threshold value, and it varies with the port. For details, refer to
Related Information.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 4, Indicates the VCTRUNK port ID. The value range is 0x8001 -
Parameter 5 0x8046. That is, Parameter 4 is always in value 0x80, and Parameter 5
is in the value range of 0x01 - 0x46.
Possible Causes
The possible causes of the LCD alarm are as follows:
l The SDH path connected to the ATM port fails to receive signals. For example, an SDH
alarm, such as the R_LOS, R_LOF, MS_AIS, AU_AIS, AU_LOP, TU_AIS or TU_LOP,
occurs.
l A great number of bit errors occur in the relevant SDH receive path of the ATM port.
That is, some bit error alarms, such as the B1_SD, B2_ SD or B3_ SD, occur in the
relevant SDH path of the port.
l The ATM processing chip of the board is faulty.
Procedure
Step 1 View the LCD alarm on the U2000, and then confirm the relevant optical interface according
to the alarm parameters.
Step 2 Check whether any alarm, such as the R_LOS, R_LOF, MS_AIS, AU_AIS, AU_LOP,
TU_AIS or TU_LOP, occurs in the relevant SDH path of an upstream NE, which connects to
the ATM port. If yes, clear it, and then check whether the LCD alarm is cleared.
Step 3 If the alarm persists, check whether any bit error alarm, such as the B1_EXC, B2_EXC or
B3_EXC, is detected at the local station on the U2000. If yes, clear it, and then check whether
the LCD alarm is cleared.
Step 4 If the alarm persists, the ATM processing chip of the board may be faulty. In this case,
perform a cold reset on the board. Then check whether the LCD alarm is cleared.
NOTICE
If the services travel through the board are not configured with protection, the services are
interrupted after the cold reset of the board.
Step 5 If the alarm persists, replace the board that generates the LCD alarm.
----End
Related Information
End and Segment
As shown in Figure 9-1, the end point refers to the termination point in the chain network,
and it is used to monitor the whole virtual connection. The segment point is, generally, used to
monitor a segment of the whole link.
A B C D E
Segment Segment
9.104 LCS_DAYS_OF_GRACE
Description
The LCS_DAYS_OF_GRACE is an alarm indicating that a license file remains in the grace
period. This alarm is reported when the license file is ineffective, the version does not match,
or a feature expires but remains in the grace period of the license file.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 3, Indicates the number of remaining days in the grace period of the
Parameter 4 license file.
Possible Causes
The possible causes of the LCS_DAYS_OF_GRACE alarm are as follows:
l Cause 1: The license file is ineffective, and the NE remains in the grace period of 60
days.
l Cause 2: The license file, ESN, or V/R version does not match, and the NE remains in
the grace period of 60 days.
l Cause 3: The feature expires but remains in the grace period of 60 days.
Procedure
Step 1 Cause 1: The license file is ineffective, and the NE remains in the grace period of 60 days.
Cause 2: The license file, ESN, or V/R version does not match, and the NE remains in the
grace period of 60 days.
Cause 3: The feature expires but remains in the grace period of 60 days.
1. Contact Huawei engineers to install a correct license file on the NE.
----End
Related Information
Definitions of States
Normal state
In normal state, all the check items of the license file pass the check, and the equipment can
properly implement all the functions specified in the license file.
Trial state
In trial state, the equipment can still properly implement all the functions specified in the
license file.
The license grace period refers to the number of days reserved for a license file. By default,
the license grace period lasts for 60 days.
Default state
In default state, the services whose functions are added can run continuously, but cannot be
configured any more. For example, a service cannot be added or modified.
Transition of States
The following figure shows the transition of the basic states of a license file on an NE.
Normal
State
Default Trial
State State
LCS_EXPIRED LCS_DAYS_OF_GRACE
Table 9-3 provides the major trigger conditions of state transition of a license file.
Normal state Trial state l The equipment serial number (ESN) or V/R
version number specified in the license file
does not match the ESN or V/R version
number of the equipment, but the license file
remains in the grace period.
l The installation of the license file is later than
the end date, but the license file remains in the
grace period.
Default state The installation of the license file is later than the
end date and the grace period of the license file
expires.
Default state The installation of the license file is later than the
end date and the grace period of the license file
expires.
Default state Trial state l The equipment serial number (ESN) or V/R
version number specified in the license file
does not match the ESN or V/R version
number of the equipment, but the license file
remains in the grace period.
l The installation of the license file is later than
the end date, but the license file remains in the
grace period.
9.105 LCS_EXPIRED
Description
The LCS_EXPIRED is an alarm indicating that a license file expires. This alarm is reported
when a license file is beyond its probation period.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1, Indicates the number of days after the license file expires.
Parameter 2
Name Meaning
Possible Causes
The possible causes of the LCS_EXPIRED alarm are as follows:
l Cause 1: The license file is ineffective, and the NE operates continuously beyond the
probation period of the license file.
l Cause 2: The license file, ESN, or V/R version does not match, and the NE operates
continuously beyond the probation period of the license file.
Procedure
Step 1 Cause 1: The license file is ineffective, and the NE operates continuously beyond the
probation period of the license file.Cause 2: The license file, ESN, or V/R version does not
match, and the NE operates continuously beyond the probation period of the license file.
1. Contact Huawei engineers to install a correct license file on the NE.
----End
Related Information
Definitions of States
Normal state
In normal state, all the check items of the license file pass the check, and the equipment can
properly implement all the functions specified in the license file.
Trial state
In trial state, the equipment can still properly implement all the functions specified in the
license file.
License grace period
The license grace period refers to the number of days reserved for a license file. By default,
the license grace period lasts for 60 days.
Default state
In default state, the services whose functions are added can run continuously, but cannot be
configured any more. For example, a service cannot be added or modified.
Transition of States
The following figure shows the transition of the basic states of a license file on an NE.
Normal
State
Default Trial
State State
LCS_EXPIRED LCS_DAYS_OF_GRACE
Table 9-4 provides the major trigger conditions of state transition of a license file.
Normal state Trial state l The equipment serial number (ESN) or V/R
version number specified in the license file
does not match the ESN or V/R version
number of the equipment, but the license file
remains in the grace period.
l The installation of the license file is later than
the end date, but the license file remains in the
grace period.
Default state The installation of the license file is later than the
end date and the grace period of the license file
expires.
Default state The installation of the license file is later than the
end date and the grace period of the license file
expires.
Default state Trial state l The equipment serial number (ESN) or V/R
version number specified in the license file
does not match the ESN or V/R version
number of the equipment, but the license file
remains in the grace period.
l The installation of the license file is later than
the end date, but the license file remains in the
grace period.
9.106 LCS_FILE_NOT_EXIST
Description
The LCS_FILE_NOT_EXIST is an alarm indicating that the license file is not installed on the
NE. This alarm is reported when the equipment is under control of a license file but is not
installed with the relevant license file.
Attribute
Alarm Severity Alarm Type
Parameters
None.
Possible Causes
The possible cause of the LCS_FILE_NOT_EXIST alarm is as follows:
Cause 1: The equipment is started up, but the relevant license file does not exist in the system.
Procedure
Step 1 Cause 1: The equipment is started up, but the relevant license file does not exist in the system.
1. Contact Huawei engineers to install a correct license file on the NE.
----End
Related Information
Definitions of States
Normal state
In normal state, all the check items of the license file pass the check, and the equipment can
properly implement all the functions specified in the license file.
Trial state
In trial state, the equipment can still properly implement all the functions specified in the
license file.
License grace period
The license grace period refers to the number of days reserved for a license file. By default,
the license grace period lasts for 60 days.
Default state
In default state, the services whose functions are added can run continuously, but cannot be
configured any more. For example, a service cannot be added or modified.
Transition of States
The following figure shows the transition of the basic states of a license file on an NE.
Normal
State
Default Trial
State State
LCS_EXPIRED LCS_DAYS_OF_GRACE
Table 9-5 provides the major trigger conditions of state transition of a license file.
Normal state Trial state l The equipment serial number (ESN) or V/R
version number specified in the license file
does not match the ESN or V/R version
number of the equipment, but the license file
remains in the grace period.
l The installation of the license file is later than
the end date, but the license file remains in the
grace period.
Default state The installation of the license file is later than the
end date and the grace period of the license file
expires.
Default state The installation of the license file is later than the
end date and the grace period of the license file
expires.
Default state Trial state l The equipment serial number (ESN) or V/R
version number specified in the license file
does not match the ESN or V/R version
number of the equipment, but the license file
remains in the grace period.
l The installation of the license file is later than
the end date, but the license file remains in the
grace period.
9.107 LFA
Description
The LFA is an alarm indicating the loss of E1 basic frame alignment. This alarm shows the
failure of delimitating the frames received in the local IMA link.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 4, Parameter 5 Indicates the number of the VCTRUNK port of the VC-12 path.
l For the VCTRUNK link that is bound with one VC-12 path, if the LFA alarm occurs, the
services are interrupted.
l After the LFA alarm is cleared, the relevant E1 link in the IMA group is automatically
activated.
Possible Causes
The possible causes of the LFA alarm are as follows:
l Abnormal service traffic from the cross-connection side causes the failure for the E1 de-
frame functional block of the IMA board to delimitate the frames. Consequently, the loss
of cell delimitation alarm is reported. For example, the cross-connections are not
configured, or some alarms, such as the ALM_E1AIS, TU_LOP or TU_AIS, occur.
l The E1 mapping chip of the ATM board is faulty.
Procedure
Step 1 If the alarm persists, check whether the ALM_E1AIS, TU_LOP or TU_AIS alarm occurs on
the U2000. If yes, take priority to clear it, and then check whether the LFA alarm is cleared.
Step 2 If the alarm persists, check whether the VC-12 cross-connections are correctly configured on
the U2000. If not, configure the correct service VC-12 cross-connections, and then check
whether the LFA alarm is cleared.
Step 3 If the alarm persists, the E1 mapping chip of the board may be faulty. In this case, perform a
cold reset on the board. Then check whether the LFA alarm is cleared.
NOTICE
If the services travel through the board are not configured with protection, the services are
interrupted after the cold reset of the board.
Step 4 If the alarm persists, replace the board that generates the LFA alarm.
----End
Related Information
Internal Optical Interface
The internal optical interface is a logical interface, which contains eight internal VC-4 paths.
9.108 LMFA
Description
The LMFA is an alarm indicating the loss of multiframe alignment. This alarm shows the
failure of delimitating the CRC-4 multiframes received in the local IMA link. The local end
expects to receive the CRC-4 multiframes, but it actually receives the basic frames. In this
case, the LMFA alarm is reported.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 4, Parameter 5 Indicates the number of the VCTRUNK port of the VC-12 path.
Possible Causes
The possible causes of the LMFA alarm are as follows:
l The E1 frame format at the E1 service processing board (namely, the PQ1 board) is
inconsistent with that at the IMA board. The frame format at the E1 service processing
board is of the basic frame format, and that at the IMA board is of the multiframe format.
l The E1 mapping chip of the ATM board is faulty.
Procedure
Step 1 On the U2000, check whether the E1 frame format at the tributary board interconnected with
the local IMA board is for base frames. If yes, modify it as required so that it is consistent at
the two boards. Then check whether the LMFA alarm is cleared.
Step 2 If the alarm persists, the E1 mapping chip of the board may be faulty. In this case, perform a
cold reset on the board, or replace the board. This operation is not suggested, however,
because services may be interrupted. Moreover, the services are not affected when the LMFA
alarm occurs.
----End
Related Information
Basic Frame
According to ITU-T G.704 Recommendation, a basic frame shows the format in which the
frame synchronization sequence (FAS) is carried in the even frames, and the non frame
synchronization sequence (NFAS) is carried in the odd frames.
Multiframe
A multiframe contains 16 basic frames, and it can be checked in the cyclic redundancy check
(CRC) mode.
9.109 LOCK_CUR_FAIL
Description
The LOCK_CUR_FAIL is an alarm of working current locking failure. This alarm occurs
when the working current is abnormal.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1 Indicates the optical interface number that generates the alarm. For
example, 0x01 indicates optical interface 1.
Parameter 2, Parameter Indicates the pump laser number that generates the alarm, which is
3 of two bytes. For example, 0x00 0x01 indicates the pump laser 1.
Possible Causes
The possible causes of the LOCK_CUR_FAIL alarm are as follows:
Procedure
Step 1 Perform the warm reset on the faulty board on the U2000.
----End
Related Information
None.
9.110 LOOP_ALM
Description
The LOOP_ALM is a loopback alarm. This alarm occurs when service loopback is set.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1 For the SDH, PDH, EoS/EoP, ODU, ATM, SAN, and RPR boards, Parameter
1 indicates the port ID.
For a board that does not provide any optical port, the value is always 0x01.
For example, if the N1EFT8 board (an EoS board) reports the alarm, the
value of Parameter 1 is 0x01.
Name Meaning
Parameter 2, For the SDH, PDH, EoS/EoP, ODU, ATM, SAN, and RPR boards:
Parameter 3
l These parameters indicate the path ID if the board provides optical ports.
0x1: The optical port is looped.
l These parameters indicate the path ID or port ID if the board does not
provide any optical port.
For example, if the N1EFT8 board (an EoS board) reports the alarm and the
value of Parameter 4 is 0x00 or 0x01, Parameter 2 and Parameter 3 indicate
the ID of the alarmed Ethernet port. If the value of Parameter 4 is 0x02 or
0x03, Parameter 2 and Parameter 3 indicate the ID of the alarmed Ethernet
path.
Parameter 4 For the SDH, PDH, EoS/EoP, ODU, ATM, SAN, and RPR board, Parameter
4 indicates the loop type.
For the line boards, the values are as follows:
l 0x00: Optical/electrical port inloop.
l 0x01: Optical/electrical port outloop.
l 0x02: Path inloop.
l 0x03: Path outloop.
l 0x04: Loopback on the user side.
l 0x05: Loopback on the combination wave side.
l 0x06: SPI inloop.
l 0x07: SPI outloop.
l 0x08: ATM layer inloop.
l 0x09: ATM layer outloop.
l 0x0A: PHY layer inloop.
l 0x0B: PHY layer outloop.
l 0x0C: MAC layer inloop.
l 0x0D: MAC layer outloop.
l 0x0E: VC-4 timeslot inloop.
l 0x0F: VC-4 timeslot outloop.
l 0x10: VC-3 timeslot inloop.
l 0x11: VC-3 timeslot outloop.
l 0x12: VC-12 timeslot inloop.
l 0x13: VC-12 timeslot outloop.
l 0x14: IF outloop.
l 0x15: IF inloop.
l 0x16: RF inloop.
l 0xFF: Any of the preceding loopback modes.
Possible Causes
The possible cause of the LOOP_ALM alarm is as follows:
The board loopback is manually configured.
Procedure
Step 1 After you manually cancel the loopback configuration, the LOOP_ALM alarm is
automatically cleared.
----End
Related Information
None.
9.111 LP_CROSSTR
Description
The LP_CROSSTR is an alarm indicating that the number of the lower order path bit errors
crosses the threshold.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1 Indicates the optical interface number where the excessive lower
order path bit errors occur.
Parameter 2, Indicates the path number where the excessive lower order path bit
Parameter 3 errors occur.
Name Meaning
Parameter 4 The higher two bits indicate the performance monitoring period.
l 01: 15-minute performance monitoring
l 02: 24-hour performance monitoring
The lower six bits together with Parameter 5 indicate the
performance event ID.
Possible Causes
The possible causes of the LP_CROSSTR alarm are as follows:
l The laser performance at the opposite station is degraded.
l the received optical power at the local station is over high or over low.
l The clock performance at the local station or the opposite station is degraded.
l The fiber performance is degraded.
Procedure
Step 1 Perform an inloop on the board that reports the LP_CROSSTR alarm at the local station.
NOTICE
The loopback causes service interruption.
NOTICE
The loopback causes service interruption.
1. If the alarm is cleared, it indicates that the fault occurs to the opposite station. Go to Step
3.
2. If the alarm persists, it indicates that the fiber performance is degraded or the fiber
jumper connector is dirty. Go to Step 5.
Step 4 Replace the board that reports the LP_CROSSTR alarm at the local station.
1. If the alarm is cleared, the fault is removed. The alarm handling ends.
2. If the alarm persists, replace the cross-connect and timing board at the local station. The
alarm handling ends.
Step 5 Clean the fiber jumper connectors at both the local and opposite stations.
1. If the alarm is cleared, the fault is removed. The alarm handling ends.
2. If the alarm persists, it indicates that the fault occurs to the fiber cables. Remove the
fault, and the alarm handling ends.
----End
Related Information
None.
9.112 LP_R_FIFO
Description
The LP_R_FIFO is an alarm indicating that the FIFO messages on the receive side of the
lower order path overflow.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Name Meaning
Parameter 2, Indicates the path number. Parameter 2 is the higher byte, and
Parameter 3 Parameter 3 is the lower byte.
For example, Parameter 2 = 0x00, Parameter 3 = 0x01. In this case,
the LP_R_FIFO alarm is reported from path 1 of the board.
Possible Causes
The possible causes of the LP_R_FIFO alarm are as follows:
Procedure
Step 1 View the LP_R_FIFO alarm on the U2000, and then confirm the path number according to
the alarm parameters.
Step 2 Check whether the service configuration of the path is correct. Make sure that the service type
at the local end is consistent with that at the opposite end, and that the cross-connection is
correctly configured. Then the LP_R_FIFO alarm is automatically cleared.
----End
Related Information
None.
9.113 LP_RDI_VC12
Description
The LP_RDI_VC12 is a remote defect indication alarm in the lower order path. If a board has
detected that bit 8 of the V5 byte in the VC-12 lower order path is 1, the LP_RDI_VC12
alarm is reported.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1 Indicates the actual number of the optical interface on a board where the
alarm occurs.
Parameter 2, Indicates the AU-4 path number. Parameter 2 is the higher byte, and
Parameter 3 Parameter 3 is the lower byte.
For the Ethernet boards, indicates the number of the VC-12 order path.
Possible Causes
The possible cause of the LP_RDI_VC12 alarm is as follows:
The LP_RDI_VC12 alarm is an accompanying alarm. When the relevant path of a tributary
board at the opposite station reports the TU_AIS_VC12 or TU_LOP_VC12 alarm, it returns
the LP_RDI_VC12 alarm to the local station.
Procedure
Step 1 After you clear the TU_AIS_VC12 or TU_LOP_VC12 alarm reported from the relevant path
of a tributary board at the opposite station, the LP_RDI_VC12 alarm is automatically cleared.
----End
Related Information
None.
9.114 LP_RDI_VC3
Description
The LP_RDI_VC3 is a remote defect indication in the VC-3 lower order path. If a board has
detected that bit 5 of the G1 byte in the VC-3 lower order path is 1, the LP_RDI_VC3 alarm
is reported.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1 Indicates the actual optical interface number of the board that generates
the alarm.
Parameter 2, Indicates the AU-4 path number. Parameter 2 is the higher byte, and
Parameter 3 Parameter 3 is the lower byte.
For the Ethernet boards, indicates the number of the VC-3 order path.
Possible Causes
The possible cause of the LP_RDI_VC3 alarm is as follows:
The LP_RDI_VC3 alarm is an accompanying alarm. When the relevant path of a tributary
board at the opposite station reports TU_AIS_VC3 or TU_LOP_VC3 alarm, it returns the
LP_RDI_VC3 alarm to the local station, showing the TU_AIS_VC3 or TU_LOP_VC3 alarm
is received at the opposite station.
Procedure
Step 1 After you clear the TU_AIS_VC3 or TU_LOP_VC3 alarm reported from the relevant path of
a tributary board at the opposite station, the LP_RDI_VC3 alarm is automatically cleared.
----End
Related Information
None.
9.115 LP_REI
Description
The LP_REI is a remote error indication alarm in the lower order path. When a board has
detected that bit 3 of the V5 byte is 1 or any of bits 1 - 4 of the G1 byte is 1, the LP_REI
alarm is reported.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 2, Indicates the number of the path in which the alarm occurs. Parameter 2 is
Parameter 3 the higher byte, and Parameter 3 is the lower byte.
Note:
For the N2PQ1 or R2PD1 board in the MUX mode, the path number is
reported from 0x40, which indicates the first VC-3 path.
Possible Causes
The possible cause of the LP_REI alarm is as follows:
The LP_REI alarm is an accompanying alarm. When an tributary board at the opposite station
has detected a bit error alarm, such as the BIP_SD, BIP_EXC, B3_SD or B3_EXC, it returns
an LP_REI alarm to the local station.
Procedure
Step 1 According to the procedure of handling the BIP_SD, BIP_EXC, B3_SD or B3_EXC alarm,
clear the bit error alarm at the opposite station. Then the LP_REI alarm is automatically
cleared.
----End
Related Information
None.
9.116 LP_REI_VC12
Description
The LP_REI_VC12 is a remote error indication alarm in the lower order path. If a board has
detected that bit 3 of the V5 byte is 1, the LP_REI_VC12 alarm is reported.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1 Indicates the actual number of the optical interface on a board where the
alarm occurs.
Parameter 2, Indicates the AU-4 path number. Parameter 2 is the higher byte, and
Parameter 3 Parameter 3 is the lower byte.
For the Ethernet boards, indicates the number of the VC-12 order path.
Possible Causes
The possible cause of the LP_REI_VC12 alarm is as follows:
The LP_REI_VC12 alarm is an accompanying alarm. When a tributary board at the opposite
station has detected the BIP_SD or BIP_EXC alarm, it returns an LP_REI_VC12 alarm to the
local station.
Procedure
Step 1 After you clear the BIP_SD or BIP_EXC alarm that occurs at the opposite end, the
LP_REI_VC12 alarm is automatically cleared.
----End
Related Information
None.
9.117 LP_REI_VC3
Description
The LP_REI_VC3 is a remote error indication alarm in the lower order path. When a board
has detected that any of bits 1-4 in the G1 byte is 1, the LP_REI_VC3 alarm is reported.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1 Indicates the actual number of the optical interface on a board where the
alarm occurs.
Possible Causes
The possible cause of the LP_REI_VC3 alarm is as follows:
The LP_REI_VC3 alarm is an accompanying alarm. When a tributary board at the opposite
station has detected the B3_SD_VC3 or B3_EXC_VC3 alarm, it returns an LP_REI_VC3
alarm to the local station.
Procedure
Step 1 After you clear the B3_SD_VC3 or B3_EXC_VC3 alarm that occurs at the opposite end, the
LP_REI_VC3 alarm is automatically cleared.
----End
Related Information
None.
9.118 LP_RFI
Description
The LP_RFI is a remote failure indication alarm in the lower order path. If a board has
detected that bit 4 of the V5 byte is 1, the LP_RFI alarm is reported.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 2, Indicates the number of the path in which the alarm occurs. Parameter 2 is
Parameter 3 the higher byte, and Parameter 3 is the lower byte.
For example, Parameter 2 = 0x00, Parameter 3= 0x01. In this case, the
LP_RFI alarm is reported from path 1 of the board.
Note: For the N2PQ1 or R2PD1 board in the MUX mode, the path number
is reported from 0x40, which indicates the first VC3 path.
Possible Causes
The possible cause of the LP_RFI alarm is as follows:
The LP_RFI alarm is an accompanying alarm. When a tributary board at the opposite station
has detected the BIP_EXC alarm, it returns an LP_RFI alarm to the local station.
Procedure
Step 1 After you clear the BIP_EXC alarm that occurs at the opposite end, the LP_RFI alarm is
automatically cleared.
----End
Related Information
None.
9.119 LP_SIZE_ERR
Description
The LP_SIZE_ERR is a TU specification error alarm. When the mapping structure of the TU
services received at the board is inconsistent with that specified for the board, the
LP_SIZE_ERR alarm is reported.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 2, Indicates the number of the path on which the alarm occurs. Parameter 2
Parameter 3 is the higher byte, and Parameter 3 is the lower byte.
For example, Parameter 1 = 0x01, Parameter 2 = 0x00, Parameter 3 =
0x01. In this case, the LP_SIZE_ERR alarm is reported from path 1 of
the board.
Possible Causes
The possible cause of the LP_SIZE_ERR alarm is as follows:
Procedure
Step 1 View the LP_SIZE_ERR alarm on the U2000, and then confirm the path number according to
the alarm parameters.
Step 2 After you configure the correct mapping structure of services in the lower order path, the
LP_SIZE_ERR alarm is automatically cleared.
----End
Related Information
None.
9.120 LP_SLM
Description
The LP_SLM is a signal label mismatch alarm in the lower order path. If a board has detected
that the signal label mismatch event occurs in the V5 or C2 byte, the LP_SLM alarm is
reported.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 2, Indicates the number of the path in which the alarm occurs. Parameter 2 is
Parameter 3 the higher byte, and Parameter 3 is the lower byte.
Note:
For the N2PQ1 or R2PD1 board in the MUX mode, the path number is
reported from 0x40, which indicates the first VC3 path.
Possible Causes
The possible causes of the LP_SLM alarm are as follows:
l The signal label configuration for the lower order path at the local station is inconsistent
with that at the opposite station.
l The service type is incorrectly configured.
Procedure
Step 1 View the LP_SLM alarm on the U2000 to confirm the relevant board and path.
Step 2 Check whether the signal label byte for the relevant lower order path of the board at the
opposite station is consistent with that at the local station. If not, modify it, and then check
whether the LP_SLM alarm is cleared.
Step 3 If the alarm persists, check whether the service configuration of the board that reports the
alarm is correct. After modifying the incorrect configuration, check whether the LP_SLM
alarm is cleared.
Step 4 If the alarm persists, replace the board at the opposite station.
Step 5 If the alarm persists, replace the board at the local station.
----End
Related Information
None.
9.121 LP_SLM_VC12
Description
The LP_SLM_VC12 is a signal label mismatch alarm in the VC-12 lower order path. If a
board has detected that the signal label mismatch event occurs in the V5 byte, the
LP_SLM_VC12 alarm is reported.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
Name Meaning
Possible Causes
The possible causes of the LP_SLM_VC12 alarm are as follows:
l The type of the received signals does not match that of the signals to be received. That is,
the signal label byte V5 (b5-b7) in the lower order path at the local station is inconsistent
with the received V5 (b5-b7) byte.
l The service type is incorrectly configured.
Procedure
Step 1 View the LP_SLM_VC12 alarm on the U2000, and then confirm the path number according
to the alarm parameters.
Step 2 Check whether the type of the received signals is consistent with that of the signals to be
received. If not, modify it, and then check whether the LP_SLM_VC12 alarm is cleared.
Step 3 If the alarm persists, check whether the service configuration is correct. After modifying the
incorrect configuration, check whether the LP_SLM_VC12 alarm is cleared.
----End
Related Information
None.
9.122 LP_SLM_VC3
Description
The LP_SLM_VC3 is a signal label mismatch alarm in the VC-3 lower order path. If a board
has detected that the signal label mismatch event occurs in the C2 byte, the LP_SLM_VC3
alarm is reported.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Possible Causes
The possible causes of the LP_SLM_VC3 alarm are as follows:
l The type of the received signals does not match that of the signals to be received. That is,
the signal label byte C2 in the lower order path is inconsistent with the received C2 byte.
l The service type is incorrectly configured.
Procedure
Step 1 View the LP_SLM_VC3 alarm on the U2000, and then confirm the path number according to
the alarm parameters.
Step 2 Check whether the signal label byte in the lower order path of the tributary board at the
opposite station is consistent with that in the lower order path of the line board at the local
station. If not, modify it, and then check whether the LP_SLM_VC3 alarm is cleared.
Step 3 If the alarm persists, check whether the service configuration of the path is correct. After
modifying the incorrect configuration, check whether the LP_SLM_VC3 alarm is cleared.
Step 4 If the alarm persists, replace the line board at the local station.
Step 5 If the alarm persists, replace the tributary board at the opposite station.
----End
Related Information
None.
9.123 LP_T_FIFO
Description
The LP_T_FIFO is an alarm indicating that the FIFO messages on the transmit side of the
lower order path overflow.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 2, Indicates the number of the path on which the alarm occurs.
Parameter 3
For example, Parameter 2 = 0x00, Parameter 3= 0x01. In this case,
the LP_T_FIFO alarm is reported from path 1 of the board.
Possible Causes
The possible causes of the LP_T_FIFO alarm are as follows:
Procedure
Step 1 View the LP_T_FIFO alarm on the U2000. Then check whether the service configuration is
correct for both the board that generates the alarm and the relevant NE. After modifying the
incorrect configuration, check whether the alarm is cleared.
Step 2 If the alarm persists, check whether the services accessed to the board are correct. After
making sure that the accessed services are correct, check whether the alarm is cleared.
----End
Related Information
None.
9.124 LP_TIM
Description
The LP_TIM is a trace identifier mismatch alarm in the lower order path. If a board has
detected that the J2 or J1 byte does not match, the LP_TIM alarm is reported.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 2, Indicates the number of the path in which the alarm occurs. Parameter 2 is
Parameter 3 the higher byte, and Parameter 3 is the lower byte.
Note:
For the N2PQ1 or R2PD1 board in the MUX mode, the path number is
reported from 0x40, which indicates the first VC3 path.
Possible Causes
The possible causes of the LP_TIM alarm are as follows:
l The trace identifier of the lower order path at the local station is inconsistent with that at
the opposite station.
l The service cross-connection configuration is incorrect.
Procedure
Step 1 View the LP_TIM alarm on the U2000, and then confirm the path number according to the
alarm parameters.
Step 2 View the LP_TIM alarm on the U2000, and then check whether the trace identifier of the
relevant lower order path of the tributary board at the opposite station is consistent with that
of the lower order path of the line board at the local station. If not, modify it, and then check
whether the LP_TIM alarm is cleared.
Step 3 If the alarm persists, check whether the service cross-connection configuration of the relevant
path of the tributary board that reports the alarm is correct. After modifying the incorrect
configuration, check whether the LP_TIM alarm is cleared.
Step 4 If the alarm persists, replace the line board at the local station.
Step 5 If the alarm persists, replace the tributary board at the opposite station.
----End
Related Information
None.
9.125 LP_TIM_VC12
Description
The LP_TIM_VC12 is a trace identifier mismatch alarm in the VC-12 lower order path. If a
board has detected that the J2 byte does not match, the LP_TIM_VC12 alarm is reported.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Possible Causes
The possible causes of the LP_TIM_VC12 alarm are as follows:
Procedure
Step 1 View the LP_TIM_VC12 alarm on the U2000, and then confirm the path number according to
the alarm parameters.
Step 2 Check whether the trace identifier configuration of the lower order path at the opposite station
is consistent with that of the lower order path of the line board at the local station. If not,
modify the configuration, and then check whether the LP_TIM_VC12 alarm is cleared.
Step 3 If the alarm persists, check whether the service cross-connection configuration is correct.
After modifying the incorrect configuration, check whether the LP_TIM_VC12 alarm is
cleared.
Step 4 If the alarm persists, replace the line board at the local station.
Step 5 If the alarm persists, replace the tributary board at the opposite station.
----End
Related Information
None.
9.126 LP_TIM_VC3
Description
The LP_TIM_VC3 is a trace identifier mismatch alarm in the VC-3 lower order path. If a
board has detected that the J1 byte does not match, the LP_TIM_VC3 alarm is reported.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 4 Indicates the number of the VC-3 lower order path. For example,
Parameter 1 = 0x01, Parameter 2 = 0x00, Parameter 3=0x01, Parameter
4 = 0x01. In this case, the LP_TIM_VC3 alarm is reported from VC-3
lower order path 1 of AU-4 path 1 for optical interface 1 on the board.
Possible Causes
The possible causes of the LP_TIM_VC3 alarm are as follows:
l The received J1 byte does not match that to be received.
l The service cross-connection configuration is incorrect.
Procedure
Step 1 Check whether the trace identifier configuration in the lower order path of the tributary board
at the opposite station is consistent with that in the lower order path of the line board at the
local station. If not, modify the configuration, and then check whether the LP_TIM_VC3
alarm is cleared.
Step 2 Check whether the service cross-connection configuration is correct. After modifying the
incorrect configuration, check whether the LP_TIM_VC3 alarm is cleared.
Step 3 If the alarm persists, replace the line board at the local station.
Step 4 If the alarm persists, replace the tributary board at the opposite station.
----End
Related Information
None.
9.127 LP_UNEQ_VC12
Description
The LP_UNEQ_VC12 is an alarm indicating no payload is equipped in the lower order path.
If a board has detected that the signal label in the V5 byte is 0, the LP_UNEQ_VC12 alarm is
reported.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Possible Causes
The possible causes of the LP_UNEQ_VC12 alarm are as follows:
Procedure
Step 1 View the LP_UNEQ_VC12 alarm on the U2000, and then confirm the path number according
to the alarm parameters.
Step 2 Check whether the service type configuration is correct. After modifying the incorrect
configuration and making sure that the services are correctly accessed on the PDH side, check
whether the LP_UNEQ_VC12 alarm is cleared.
Step 3 If the alarm persists, check whether the property configuration of the relevant tributary board
is correct. After you modify the incorrect configuration, the LP_UNEQ_VC12 alarm is
automatically cleared.
----End
Related Information
None.
9.128 LP_UNEQ_VC3
Description
The LP_UNEQ_VC3 is an alarm indicating that no payload is equipped in the VC-3 lower
order path. If a board has detected that the signal label in the C2 byte is 0, the
LP_UNEQ_VC3 alarm is reported.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Possible Causes
The possible causes of the LP_UNEQ_VC3 alarm are as follows:
l The service type is incorrectly configured.
l The services on the PDH side are not accessed.
Procedure
Step 1 View the LP_UNEQ_VC3 alarm on the U2000, and then confirm the path number according
to the alarm parameters.
Step 2 Check whether the service type configuration is correct. After modifying the incorrect
configuration and making sure that the services are correctly accessed on the PDH side, check
whether the LP_UNEQ_VC3 alarm is cleared.
Step 3 If the alarm persists, check whether the property configuration of the relevant tributary board
is correct. After you modify the incorrect configuration, the LP_UNEQ_VC3 alarm is
automatically cleared.
----End
Related Information
None.
9.129 LPS_UNI_BI_M
Description
The LPS_UNI_BI_M is an alarm indicating the mismatch of the single-ended and dual-ended
modes in a linear MSP. This alarm is applicable to a linear MSP only. This alarm occurs,
when the opposite end single-ended/dual-ended mode indicated by the lower three bits of the
K2 byte is inconsistent with the local end single-ended/dual-ended mode, and when the
inconsistency lasts for a time period (2s by default).
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
Name Meaning
Possible Causes
The possible causes of the LPS_UNI_BI_M alarm are as follows:
Procedure
Step 1 Make sure that the local and opposite NEs have consistent MSP configurations. After
updating the MSP configurations, check whether the LPS_UNI_BI_M alarm is cleared.
Step 2 If the alarm persists, check whether the service boards configured with the MSP at the local
and opposite ends are faulty. After replacing faulty service boards, check whether the alarm is
cleared.
Step 3 If the alarm persists, check whether the cross-connect boards at the local and opposite ends
are faulty. After replacing faulty cross-connect boards, check whether the alarm is cleared.
----End
Related Information
Single-Ended/Dual-Ended mode
The single-ended/dual-ended mode refers to the revertive mode of the linear MSP switching.
This revertive mode can be either the single-ended mode or the dual-ended mode.
9.130 LSR_COOL_ALM
Description
The LSR_COOL_ALM is an alarm indicating that the cooling current of the laser crosses the
threshold.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Possible Causes
The possible causes of the ALM_ALS alarm are as follows:
Procedure
Step 1 Check whether the ambient temperature is extremely high. If yes, decrease it to a proper value
for the equipment to work well, and then check whether the LSR_COOL_ALM alarm is
cleared.
Step 2 If the alarm persists, the laser may be faulty. If the board supports a pluggable optical module,
replace the pluggable optical module. Otherwise, replace the board that generates the alarm,
and then check whether the alarm is cleared.
----End
Related Information
None.
9.131 LSR_INVALID
Description
The LSR_INVALID is an alarm indicating invalid optical module. It is generated when the
optical module cannot pass an authentication.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1 Indicates the optical interface number of the alarm board. For
example, 0x01 indicates that the alarm is reported from optical
interface 1 of the board.
Parameter 2, Indicates higher order path number. Parameter 2 is always 0x00, and
Parameter 3 Parameter 3 is always 0x01.
Possible Causes
The possible cause of the LSR_INVALID alarm is as follows:
Procedure
Step 1 Replace the optical module with another one with right license, and then re-check the license.
After successful check, the alarm is cleared.
----End
Related Information
None.
9.132 LSR_NO_FITED
Description
The LSR_NO_FITED is an alarm indicating that the laser is not installed. This alarm occurs
when the optical interface is enabled but not installed with the optical module.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1 Indicates the optical interface number of the board that generates
the alarm.
Parameter 2 and Parameter 2 is always 0x00, and Parameter 3 is always 0x01. These
Parameter 3 parameters are meaningless.
Possible Causes
The possible causes of the LSR_NO_FITED alarm are as follows:
l The enabled optical interface is not installed with the optical module.
l The optical module is faulty.
Procedure
Step 1 View the LSR_NO_FITED alarm on the U2000 to confirm the relevant board.
Step 2 Check whether the optical module is installed on the board that reports the alarm.
l If the optical module is not installed on the board, check the type of the optical module.
If the board supports a pluggable optical module, install a pluggable optical module
of the correct type on the board.
If the board does not support a pluggable optical module, replace the board
l If the optical module is installed on the board, go to the next step.
Step 3 If the board supports a pluggable optical module, replace the pluggable optical module.
Otherwise, replace the board. Then, the alarm is cleared automatically.
----End
Related Information
None.
9.133 LTEMP_OVER
Description
The LTEMP_OVER is an alarm indicating that the laser temperature crosses the threshold.
That is, when the temperature of the laser on the board is higher than the upper threshold
value or lower than the lower threshold value, the LTEMP_OVER alarm occurs.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1 Indicates the number of the optical interface at which the alarm occurs.
For example, 0x01 indicates optical interface 1.
Parameter 2, Indicates the number of the path in which the alarm occurs. This
Parameter 3 number contains two bytes, which are always 0x00 0x01, indicating
path 1 of the optical interface shown in Parameter 1.
Parameter 4 Indicates the threshold crossing type. For example, 0x01 means that the
temperature is more than the upper threshold value.
0x02 means that the temperature is less than the lower threshold value.
Possible Causes
The possible causes of the LTEMP_OVER alarm are as follows:
Procedure
Step 1 Check the ambient temperature of the board. For detail, refer to the "Product Description." If
the ambient temperature is improper, handle the LTEMP_OVER alarm according to the
method of handling the TEMP_ALARM alarm.
----End
Related Information
None.
9.134 M_S_SW
Description
The M_S_SW alarm indicates a switchover between active and standby main control boards,
cross-connect boards, or clock boards.
Attribute
Alarm Severity Alarm Type
Parameters
None
Possible Causes
Possible causes of this alarm are as follows:
l Cause 1: A main control board, cross-connect board, or clock board of the NE reporting
an M_S_SW alarm is being reseated.
l Cause 2: A forced switching command is issued to a main control board, cross-connect
board, or clock board of the NE reporting an M_S_SW alarm.
l Cause 3: A main control board, cross-connect board, or clock board of the NE reporting
an M_S_SW alarm is faulty.
Procedure
Step 1 Cause 1: A main control board, cross-connect board, or clock board of the NE reporting an
M_S_SW alarm is being reseated.
1. On the NMS, check whether the main control board, cross-connect board, or clock board
whose state is displayed as offline in the alarm information is online. If the board is
offline, it may be being reseated or in poor contact with the backplane. Then, insert the
board into the backplane securely. For details, see Installing the Boards in the
Installation Reference.
2. Check whether the alarm is cleared. If the alarm persists, go to Step 2.
Step 2 Cause 2: A forced switching command is issued to a main control board, cross-connect board,
or clock board of the NE reporting an M_S_SW alarm.
1. On the NMS, check whether a forced switching command is issued to a main control
board, cross-connect board, or clock board of the NE. If a forced switching command is
issued, cancel the forced switching operation.
2. Check whether the alarm is cleared. If the alarm persists, go to Step 3.
Step 3 Cause 3: A main control board, cross-connect board, or clock board of the NE reporting an
M_S_SW alarm is faulty.
1. Perform a cold reset on (using the NMS) or reseat the currently standby main control
board, cross-connect board, or clock board. For details, see Resetting Boards in the
Supporting Tasks. For information about how to reseat a board, see Removing the Boards
in the Installation Reference and Installing the Boards in the Installation Reference.
2. Check whether the alarm is cleared. If the alarm persists, replace the currently standby
board. For details, see the Part Replacement.
3. If the alarm persists, contact Huawei engineers to handle the alarm.
----End
Related Information
None
9.135 MDL_ALARM
Description
The MDL_ALARM is an alarm of power module faults. The system reports this alarm when
the power module of the CAU board is faulty.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 2, Indicates the type of the faulty power module. Parameter 2 is the higher
Parameter 3 byte, and Parameter 3 is the lower byte.
The value of Parameter 2 is always 0x00. The values of Parameter 3 are
as follows:
l 0x01: Power module 1
l 0x02: Power module 2
Name Meaning
Parameter 4, Indicates the causes for the faults of the power module. Parameter 4 is
Parameter 5 the higher byte, and Parameter 5 is the lower byte.
The value of Parameter 4 is always 0x00. The values of Parameter 5 are
as follows:
l 0x00: Communication failure
l 0x01: Power off
l 0x02: Fault
l 0x03: Protection
Possible Causes
The possible causes of the MDL_ALARM alarm are as follows:
l The Power Module is not in position.
l The cable connecting the Power Module to the equipment is faulty.
l The Power Module is faulty.
l The standby module of the Power Module is faulty.
Procedure
Step 1 View the MDL_ALARM alarm on the U2000. Confirm the cause for the fault of the power
module according to Parameter 5.
l In case of communication failure, detect the failure cause and troubleshoot it. Then,
check whether the MDL_ALARM alarm is cleared.
l In case of power off, power on the system. Then, check whether the MDL_ALARM
alarm is cleared.
l In case of hardware faults, replace the CAU board.
----End
Related Information
None.
9.136 MOD_TYPE_MISMATCH
Description
The MOD_TYPE_MISMATCH is an alarm indicating that a mismatched port module is
detected.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1 Indicates the ID of the port that reports the alarm. For example,
Parameter 1 = 0x01 indicates that the alarm is reported by port 1 of the
related board.
Possible Causes
The possible causes of the MOD_TYPE_MISMATCH alarm are as follows:
The type defined by the customer for the SFP module is different from the actual module
type.
Procedure
Step 1 Based on the alarm parameters, locate the port that reports the alarm.
Step 2 Verify the type of the SFP module that connects to the port.
If... Then...
The type defined for the SFP module Contact the technical support engineers of
is correct Huawei to replace the SFP module with an
appropriate one.
The type defined for the SFP module Go to the next step.
is wrong
----End
Related Information
None.
9.137 MS_APS_INDI_EX
Description
The MS_APS_INDI_EX is an extended alarm of multiplex section protection (MSP) status
indication. This alarm is reported when MSP switching occurs, indicating that services are in
the switching state.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1 Indicates the type of the protection group where switching occurs.
l 0x01: linear MSP
l 0x02: ring MSP
Parameter 4 Indicates the optical port ID on the board where switching occurs.
Possible Causes
The possible causes of the MS_APS_INDI_EX alarm are as follows:
Procedure
Step 1 Query this alarm on the NMS and identify the slot ID and optical port ID of the board where
MSP switching occurs.
Step 2 Check whether the MSP is in the manual, forced, or locked switching state. If the MSP is in
one of these states, clear the switching. Then, the alarm is cleared.
Step 3 If the MSP is in the automatic switching state, perform the following operations.
1. Check whether conditions that can trigger MSP automatic switching, such as R_LOS,
R_LOF, MS_AIS, HARD_BAD, B2_EXC, B2_SD, and cold reset of the board, occur on
service boards of the MSP. If one of these conditions occur, process it and check whether
the alarm is cleared. If the alarm persists, proceed to the next step.
2. Check whether service boards in the MSP are faulty. If the service boards are faulty,
replace them and check whether the alarm is cleared. If the alarm persists, proceed to the
next step.
3. Check whether cross-connect boards are faulty. If the cross-connect boards are faulty,
replace them.
----End
Related Information
After 1+1 single-ended non-revertive linear MSP switching occurs, if optical paths are
restored successfully, services will not be switched back to working channels automatically
and the MS_APS_INDI_EX alarm persists. At this point, manually switch services from
protection channels to working channels. After the switching succeeds, the
MS_APS_INDI_EX alarm will be cleared.
9.138 MS_CROSSTR
Description
The MS_CROSSTR alarm indicates that a performance indicator of the multiplex section
crosses the threshold. This alarm is reported if a board detects that the multiplex section bit
error performance indicator crosses the preset threshold.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1 Indicates the ID of the line port that reports the alarm. For example,
0x01 indicates that the alarm is reported by port 1 of the related board.
Parameter 4, The two most significant bits of parameter 4 indicate the performance
Parameter 5 monitoring period.
l 0x01: The monitoring period is 15 minutes.
l 0x02: The monitoring period is 24 hours.
The six least significant bits of parameter 4 and parameter 5 together
indicate the ID of a performance event.
Possible Causes
The possible causes of the MS_CROSSTR alarm are as follows:
l Cause 1: The other alarms are generated.
Determination method: Browse the alarms on the NMS.
l Cause 2: The performance threshold is set incorrectly.
Determination method: Query the bit error threshold on the NMS.
Procedure
l Check the MS_CROSSTR alarm on the U2000 to determine the board that reports the
alarm. For details, see Viewing the Current Alarms in the Supporting Tasks.
If... Then...
The B2_EXC or Ensure that the alarm is cleared immediately. If the
B2_SD alarm is MS_CROSSTR alarm persists, perform the operations
generated that are required for clearing the alarm generated due to
cause 2.
None of the above Perform the operations required when the alarm is
generated due to cause 2.
l Cause 2: The performance threshold is set incorrectly.
a. See Table 9-6. Check whether the performance threshold is set properly on the
NMS. For details, see Setting the Threshold for the SDH Performance Event in the
Supporting Tasks.
----End
Related Information
If the MSBBE, MSES, MSSES, MSCSES, or MSUAS performance events exceed the preset
threshold, the MS_CROSSTR alarm is generated.
MSES 50 20 100
MSSES 20 0 50
MSUAS 20 0 50
9.139 MSAD_CROSSTR
Description
The MSAD_CROSSTR alarm indicates that the adaptation performance indicator of the
multiplex section crosses the threshold. This alarm is reported if a board detects that an AU
pointer adaptation performance indicator crosses the preset threshold.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1 Indicates the ID of the line port that reports the alarm. For example,
0x01 indicates that the alarm is reported by port 1 of the related board.
Parameter 4, The two most significant bits of parameter 4 indicate the performance
Parameter 5 monitoring period.
l 0x01: The monitoring period is 15 minutes.
l 0x02: The monitoring period is 24 hours.
The six least significant bits of parameter 4 and parameter 5 together
indicate the ID of a performance event.
Possible Causes
The possible causes of the MSAD_CROSSTR alarm are as follows:
Procedure
l Check the MSAD_CROSSTR alarm on the U2000 to determine the board that reports
the alarm. For details, see Viewing the Current Alarms in the Supporting Tasks.
l Cause 1: Bit errors occur at the section layer.
a. Check whether any of the following alarms are generated on the board that reports
the MSAD_CROSSTR alarm on the NMS.
If... Then...
Any of the following alarms Ensure that the alarms are cleared immediately. If
are generated at the section the MSAD_CROSSTR alarm persists, perform
layer the operations that are required for clearing the
alarm generated due to cause 2.
l B1_EXC
l B1_SD
l B2_EXC
l B2_SD
None of the preceding occur Perform the operations required when the alarm is
generated due to cause 2.
l Cause 2: The clock on the ring deteriorates.
a. Check whether any of the following alarms are generated on the board that reports
the MSAD_CROSSTR alarm on the NMS.
If... Then...
Any of the following alarms are Ensure that the alarms are cleared
generated at the clock immediately. If the MSAD_CROSSTR
alarm persists, perform the operations that
l SYN_BAD are required for clearing the alarm
l EXT_SYNC_LOS generated due to cause 3.
l S1_SYN_CHANGE
l LTI
None of the preceding occur Perform the operations required when the
alarm is generated due to cause 3.
l Cause 3: The performance threshold is set incorrectly.
a. See Table 9-7. Check whether the performance threshold is set properly on the
NMS. For details, see Setting the Threshold for the SDH Performance Event in the
Supporting Tasks.
----End
Related Information
The MSAD_CROSSTR alarm may be generated when the AUPJCHIGH, AUPJCLOW, or
AUPJCNEW performance events exceed the preset threshold.
9.140 MS_REI
Description
The MS_REI is an indication alarm that indicates bit errors occur at the remote end of the
multiplex section. When the receive side of the local optical station receives the M1 byte,
which shows that the number of block bit errors detected by BIP-Nx24 (B2) at the opposite
station, the MS_REI alarm is reported.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Possible Causes
The possible cause of the MS_REI alarm is as follows:
The number of B2 bit errors received at the opposite station is beyond the specified value
range.
Procedure
Step 1 After you clear the B2_EXC or B2_SD alarm that occurs at the opposite station, the MS_REI
alarm is automatically cleared.
----End
Related Information
None.
9.141 MSSW_DIFFERENT
Description
The alarm indicates that the NE software versions on the working and protection SCC boards
are inconsistent.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 2, Indicates the number of the inconsistent file on the SCC boards.
Parameter 3
Name Meaning
Possible Causes
The causes for the alarm are as follows:
l The version of the software that is currently running on the working SCC is inconsistent
with hat on the protection SCC.
l The software versions in the working and the protection areas (OFS1 and OFS2) are
inconsistent.
l On the working and protection SCC boards, no file named after the board exists under
the peer board directory.
Procedure
Step 1 Contact Huawei engineers to reload the mapping software.
----End
Related Information
None.
9.142 NE_CFG_CONFLICT
Description
The NE_CFG_CONFLICT is an alarm indicating that NE configurations conflict. This alarm
is reported when the current NE configurations conflict.
Attribute
Parameters
None.
Possible Causes
The possible cause of the NE_CFG_CONFLIC alarm is as follows:
Procedure
Step 1 Cause 1: NE configurations (for example, sink ends of cross-connections) conflict.
1. Check whether the ASON feature is enabled.
If... Then...
The ASON feature is enabled Query the ASON services that traverse the NE. Then
go to the next step.
2. Downgrade the NE to an ordinary NE, and downgrade the ASON services that traverse
the NE to static services.
3. Upload the NE configuration data to the NMS, clear the databases on the SCC board,
perform a warm reset on the SCC board, and then download the configuration data from
the NMS to the NE.
4. According to service alarms (for example, HP_UNEQ and LP_UNEQ), determine the
cross-connect service in which a fault occurs, and then reconfigure the corresponding
cross-connect service.
5. Check whether the alarm is cleared.
If... Then...
The alarm persists Contact Huawei technical support engineers to handle the
alarm.
If... Then...
The alarm is cleared Enable the ASON feature of the NE whose ASON feature is
previously enabled, and then upgrade the corresponding
services to ASON services.
----End
Related Information
None.
9.143 NE_POWER_OVER
Description
The NE_POWER_OVER is an alarm indicating that the power consumption of an NE is over
the threshold.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1 Indicates the type of NE power consumption that crosses the associated
threshold.
l 0x01: The physical power consumption of the NE crosses the associated
threshold.
l 0x02: The logical power consumption of the NE crosses the associated
threshold.
Possible Causes
The possible causes of the NE_POWER_OVER alarm are as follows:
l The power consumptions of all the logical boards of the NE are over the threshold.
l The total power consumption of the boards inserted on the NE is over the threshold.
Procedure
Step 1 Delete the unused logical boards on the U2000.
----End
Related Information
None.
9.144 NESF_LOST
Description
The NESF_LOST alarm indicates that the NE software is lost. This alarm is reported when
the NE software of the SCC board is not available.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1, Indicate the file types that are absent in the board software. The value
parameter 2 range of the parameters varies from board to board.
If the value of parameter 1 is 0xFF, this parameter is meaningless.
Possible Causes
The possible causes of the NESF_LOST alarm are as follows:
Procedure
Step 1 View the alarms on the U2000 and determine the board that generates the alarm.
Step 2 Reload the NE software and perform a warm reset on the faulty board on the U2000. Then,
check whether the alarm is cleared.
Step 3 If the NESF_LOST alarm persists, replace the board that generates the alarm.
----End
Related Information
None.
9.145 NESTATE_INSTALL
Description
The NESTATE_INSTALL is an alarm indicating that the NE is in the installing state. This
alarm occurs when the NE is just delivered from the factory or when the user issues the
command to initialize the NE.
Attribute
Parameters
None.
NOTICE
If this alarm occurs, the NE data cannot be uploaded but only downloaded.
If the upload operation is performed after the NESTATUS_INSTALL alarm occurs, empty NE
data is uploaded. If the data is downloaded, the NE data is cleared. As a result, services are
interrupted.
Possible Causes
The possible causes of the NESTATE_INSTALL alarm are as follows:
l The user issues the command to initialize the NE. Verification, however, is not
performed.
l The NE is in the initializing state, and thus is configured with no data.
l The database on the SCC is faulty.
l If only one SCC exists, replace the SCC.
Procedure
Step 1 Issue the configuration data again and perform the verification. Then, check whether the
NESTATE_INSTALL alarm is cleared.
----End
Related Information
None.
9.146 NO_BD_PARA
Description
The NO_BD_PARA is an alarm indicating that the board parameters are not set. This alarm
occurs when the system cannot detect the parameter file of the board, that is, when the system
cannot detect the optical module parameters.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1 In the case of the LWX board, Parameter 1 indicates the actual number of
the optical interface on a board where the alarm occurs.
In the case of OBU1 boards, the indications are as follows:
l 0x01: The DSP parameter file is lost.
l 0x02: The current configuration files are lost.
In the case of other boards, if the value of Parameter 1 is 0xFF, the
parameter is meaningless.
Parameter 2, In the case of the LWX board, Parameter 2 is always 0x00, and Parameter
Parameter 3 3 is always 0x01. These parameters are meaningless.
Possible Causes
The possible causes of the NO_BD_PARA alarm are as follows:
Procedure
Step 1 View the NO_BD_PARA alarm on the U2000 to confirm the relevant board.
Step 2 Perform a cold reset on the board. Then, check whether the NO_BD_PARA alarm is cleared.
NOTICE
If the services travel through the board are not configured with protection, the services are
interrupted after the cold reset of the board.
----End
Related Information
None.
9.147 NO_BD_SOFT
Description
The NO_BD_SOFT alarm indicates that the board does not have the corresponding software.
This alarm is reported when the board does not have the required software or the board
software name is incorrect.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 5 Reserved.
l If the board that reports the alarm is not reset, the services and functions of the board are
not affected.
l If the board that reports the alarm is reset, the board may fail to start. If the processing
boards are not configured with protection, the services are interrupted. If the processing
boards are configured with protection, the services are switched.
Possible Causes
The possible causes of the NO_BD_SOFT alarm are as follows:
Procedure
Step 1 View the NO_BD_SOFT alarm on the NMS to determine the board that reports the alarm.
Confirm the lost software type of the board.
Step 2 Reload the board software and perform a warm reset on the faulty board on the NMS. Then,
check whether the NO_BD_SOFT alarm is cleared.
----End
Related Information
None.
9.148 NO_LSR_PARA_FILE
Description
The NO_LSR_PARA_FILE is an alarm indicating that EEPROM is empty.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Possible Causes
The possible cause of the NO_LSR_PARA_FILE alarm is as follows:
An optical module with an EEPROM is used, but no laser parameter files are found in the
EEPROM after the board is started.
Procedure
Step 1 Perform a cold reset on the board. Then check whether the NO_LSR_PARA_FILE alarm is
cleared.
Step 2 If the alarm persists, replace the board that generates the NO_LSR_PARA_FILE alarm.
----End
Related Information
None.
9.149 OCD
Description
The OCD is an alarm indicating the out-of-cell delimitation. When the cell delimitation state
machine is in the HUNT or PRESYN state, the OCD alarm is reported.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 4, Indicates the VCTRUNK port ID. The value range is 0x8001 -
Parameter 5 0x8046. That is, Parameter 4 is always in value 0x80, and Parameter 5
is in the value range of 0x01 - 0x46.
Possible Causes
The possible causes of the OCD alarm are as follows:
l The SDH path connected to the ATM port fails to receive signals. For example, the
R_OOF alarm occurs.
l A great number of bit errors occur in the relevant SDH receive path. That is, bit error
alarms, such as the B1_SD, B2_ SD or B3_ SD, occur in the relevant SDH path.
l The ATM processing chip of the board is faulty.
Procedure
Step 1 View the OCD alarm on the U2000, and then confirm the relevant optical interface according
to the alarm parameters.
Step 2 Check whether the R_OOF alarm occurs in the relevant SDH path of an upstream NE, which
connects to the ATM port. If yes, clear it, and then check whether the OCD alarm is cleared.
Step 3 If the alarm persists, check whether any bit error alarm, such as the B1_EXC, B2_EXC or
B3_EXC, is detected at the local station on the U2000. If yes, clear it, and then check whether
the OCD alarm is cleared.
Step 4 If the alarm persists, the ATM processing chip of the board may be faulty. In this case,
perform a cold reset on the board. Then check whether the OCD alarm is cleared.
NOTICE
If the services travel through the board are not configured with protection, the services are
interrupted after the cold reset of the board.
Step 5 If the alarm persists, replace the board that generates the OCD alarm.
----End
Related Information
Cell Delimitation State Machine
The cell delimitation state machine has three states: HUNT, PRESYNC and SYNC. In the
HUNT state, the state machine hunts the position of delimitating cells in the BYTE BY BYTE
manner. After finding a correct HCS, the state machine changes to the PRESYNC state. In the
PRESYNC state, the state machines locks the position of delimitating cells. After
consecutively receiving DELTA correct HCS cells, the state machine changes to the SYNC
state. In this case, the cell boundary is found. In the PRESYNC state, after receiving an
incorrect HCS cell, the state machine returns to the HUNT state. In the SYNC state, after
consecutively receiving ALPHA incorrect HCS cells, the state machine changes to the HUNT
state. Otherwise, it keeps in the SYNC state, as shown in the following figure.
9.150 ODU_AIS
Description
The ODU_AIS alarm is an ODU alarm indication signal.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Possible Causes
The possible causes of the ODU_AIS alarm are as follows:
l Alarms of higher levels exist at the local station, such as the R_LOS, FEC_LOF,
OTU_LOF and OTU_AIS.
l The upstream services are damaged.
l This board is faulty.
Procedure
Step 1 Check on the U2000 whether the alarms of higher levels such as the R_LOS, FEC_LOF,
OTU_LOF and OTU_AIS exist at the local station. If yes, clear these alarms and then check
whether the ODU_AIS alarm is cleared.
Step 2 If the ODU_AIS alarm persists, locate the fault in the upward direction. Find the station (FR
station) that is the first to receive the ODU_AIS alarm. Then follow step 1 to troubleshoot the
FR station.
Step 3 If the ODU_AIS alarm still persists, troubleshoot the upstream station (PR station) of the FR
station. Check whether any alarms of higher levels exist at the receive part of the PR station.
If yes, clear the alarms.
Step 4 If the ODU_AIS alarm still persists, perform loopback for the service output optical interfaces
of the stations from the FR station upward. Find the station (FL station) on which the
ODU_AIS or alarms of higher levels occur for the first time after the loopback. Troubleshoot
the FL station as follows:
1. Check the configuration at the FL station. If any fault exists, correct the connection and
configuration.
2. If the ODU_AIS alarm persists, replace the line boards at the FL station.
3. If the ODU_AIS alarm still persists, replace the cross-connect and timing board at the FL
station.
----End
Related Information
None.
9.151 ODU_LCK
Description
The ODU_LCK is an alarm indicating that the signals of the ODU path are locked.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Possible Causes
The possible causes of the ODU_LCK alarm are as follows:
Procedure
Step 1 Check whether the ODU channel test is performed. If yes, wait until the ODU channel test is
complete. Cancel the lockout. Then check whether the ODU_LCK alarm is cleared.
Step 2 If no ODU path test task exists, cancel the lockout and then check whether the ODU_LCK
alarm is cleared.
Step 3 If the alarm persists, the board hardware may be faulty. In this case, replace the board that
reports the alarm.
----End
Related Information
None.
9.152 ODU_OCI
Description
The ODU_OCI is the ODU open connection indication.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Possible Causes
The possible causes of the ODU_OCI alarm are as follows:
l Alarms of higher levels exist at the local station, such as the R_LOS, FEC_LOF,
OTU_LOF and OTU_AIS.
l The upstream services are damaged.
l This board is faulty.
Procedure
Step 1 Check on the U2000 whether the alarms of higher levels such as the R_LOS, FEC_LOF,
OTU_LOF and OTU_AIS exist at the local station. If yes, clear these alarms and then check
whether the ODU_OCI alarm is cleared.
Step 2 If the alarm persists, the upstream services may be damaged. Check the upstream equipment.
If it is the OptiX OSN equipment, replace the line boards. If it is other equipment, add a
cross-connection to the downstream ODU channel that receives the ODU_OCI alarm
according to the corresponding alarm troubleshooting documents.
Step 3 If the alarm still persists, the board at the local station may be faulty. In this case, replace the
board at the local station.
----End
Related Information
None.
9.153 OH_LOOP
Description
The OH_LOOP is an alarm of overhead bus loopback. This alarm occurs when the overhead
bus of a line board is loopbacked.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Possible Causes
The possible cause of the OH_LOOP alarm is as follows:
Procedure
Step 1 After the loopback is released, the OH_LOOP alarm is automatically cleared.
----End
Related Information
None.
9.154 OTH_BD_STATUS
Description
The OTH_BD_STATUS is an alarm indicating that the board detects the out-of-position status
of its paired board.
Attribute
Alarm Severity Alarm Type
Parameters
None.
Possible Causes
The paired board of the alarmed board is not in position.
Procedure
Step 1 View the OTH_BD_STATUS alarm on the U2000 to confirm the slot of the paired board,
according to the alarm_board. Remove the paired board and insert it again, and then check
whether the alarm is cleared.
----End
Related Information
None.
9.155 OTH_HARD_FAIL
Description
The OTH_HARD_FAIL is an alarm indicating that the board detects the failure of its paired
board.
Attribute
Parameters
None.
Possible Causes
The paired board of the alarmed board is faulty.
Procedure
Step 1 Confirm the slot of the paired board, according to the alarm board.
Step 2 Check whether the ejector levers on the front panel of the paired board are open. If yes, close
the ejector levers, and check whether the alarm is cleared.
Step 3 If the alarm persists, contact Huawei technical support engineers to handle the problem.
----End
Related Information
None.
9.156 OTU_AIS
Description
The OTU_AIS alarm is an OTU alarm indication signal.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Possible Causes
The possible causes of the OTU_AIS alarm are as follows:
l Alarms of higher levels such as the R_LOS and FEC_LOF exist at the local station.
l The upstream services are damaged.
l This board is faulty.
Procedure
Step 1 Check on the U2000 whether the alarms of higher levels such as the R_LOS and FEC_LOF
exist at the local station. If yes, clear these alarms and then check whether the OTU_AIS
alarm is cleared.
Step 2 If the OTU_AIS alarm persists, locate the fault in the upward direction. Find the station (FR
station) which is the first to receive the OTU_AIS alarm. Then follow step 1 to troubleshoot
the FR station.
Step 3 If the OTU_AIS alarm still persists, troubleshoot the upstream station (PR station) of the FR
station. Check whether any alarms of higher levels exist at the receive part of the PR station.
If yes, clear the alarms.
Step 4 If the OTU_AIS alarm persists, use fibers to perform loopbacks for the service output parts of
the upstream stations from the FR station upward. Find the station (FL point) at which the
OTU_AIS alarm occurs for the first time after the fiber loopback. Perform the following steps
to troubleshoot the FL station. Skip this step if the services cannot be interrupted. In this case,
directly replace the boards at the receive part of the FR station and the boards at the service
output part of the PR station.
1. Check the configuration at the FL station. If any fault exists, correct the connection and
configuration.
2. If the OTU_AIS alarm persists, replace the line boards at the FL station.
3. If the OTU_AIS alarm still persists, replace the cross-connect and timing board at the FL
station.
----End
Related Information
None.
9.157 OTU_LOF
Description
The OTU_LOF is an alarm indicating that the FAS frame of the OTU is lost.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Possible Causes
The possible causes of the OTU_LOF alarm are as follows:
Procedure
Step 1 View the OTU_LOF alarm on the U2000 to confirm the relevant board.
Step 2 View the received optical power of the board on the U2000. If the received optical power is
extremely low, clean the fiber head and the connector. If the received optical power is
extremely high, provide more optical attenuators. After making sure that the received optical
power is proper, check whether the OTU_LOF alarm is cleared.
Step 3 If the OTU_LOF alarm persists, check the launched optical power at the opposite station. If
the launched optical power is extremely low, replace the board at the opposite station.
Step 4 If the alarm persists, check whether the clocks in the local NE and the opposite NE are
synchronous with those in the network. If not, set the clock tracing function, and then check
whether the OTU_LOF alarm is cleared.
Step 5 If the alarm still persists, check whether the fiber works well. If yes, replace the board that
generates the alarm.
Step 6 If the alarm persists, replace the cross-connect and timing board at the local station.
Step 7 If the alarm persists, replace the line board at the opposite station.
Step 8 If the alarm persists, replace the cross-connect and timing board at the opposite station.
----End
Related Information
None.
9.158 OTU_LOM
Description
The OTU_LOM is an alarm indicating that the FAS frame of the OTU is out of multiframe.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Possible Causes
The possible causes of the OTU_LOM alarm are as follows:
Procedure
Step 1 View the OTU_LOM alarm on the U2000 to confirm the relevant board.
Step 2 View the received optical power of the board on the U2000. If the received optical power is
extremely low, clean the fiber head and the connector. If the received optical power is
extremely high, provide more optical attenuators. After making sure that the received optical
power is proper, check whether the OTU_LOM alarm is cleared.
Step 3 If the alarm persists, check the launched optical power at the opposite station. If the launched
optical power is extremely low, replace the board at the opposite station.
Step 4 If the alarm persists, check whether the clocks in the local NE and the opposite NE are
synchronous with those in the network. If not, set the clock tracing function, and then check
whether the OTU_LOM alarm is cleared.
Step 5 If the alarm persists, check whether the fiber works well. If yes, replace the board that
generates the alarm.
Step 6 If the OTU_LOM alarm still persists, replace the source board of the OUT path (excluding the
stations that transparently transmit the ODU path).
----End
Related Information
None.
9.159 OUT_PWR_ABN
Description
The OUT_PWR_ABN is an alarm indicating that the output optical power is abnormal.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Possible Causes
The possible causes of the OUT_PWR_ABN alarm are as follows:
l The output optical power is extremely high or low.
l The board is faulty.
Procedure
Step 1 Check whether the wavelength of the input optical signals is within the specified wavelength
range of the input optical signal of the boards, or check whether the boards report the
PUM_BCM_ALM alarm simultaneously. If the wavelength of the input optical signals is
beyond the specified wavelength range, adjust it to a proper value. Then, check whether the
OUT_PWR_ABN alarm is cleared.
Step 2 If the alarm persists, replace the board that generates the OUT_PWR_ABN alarm.
----End
Related Information
None.
9.160 OUT_PWR_HIGH
Description
The OUT_PWR_HIGH is an alarm of too high output power. This alarm occurs when a board
detects that the actual output power is higher than the upper threshold of the output power
reference value.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
Name Meaning
Parameter 1 Indicates the actual number of the optical interface on a board where
the alarm occurs.
For example, 0x01 indicates that the alarm is reported from optical
interface 1 of the board.
Possible Causes
The possible cause of the OUT_PWR_HIGH alarm is as follows:
Procedure
Step 1 View the OUT_PWR_HIGH alarm on the U2000 to confirm the relevant board.
----End
Related Information
None.
9.161 OUT_PWR_LOW
Description
The OUT_PWR_LOW is an alarm of too low output power. This alarm occurs when a board
detects that the actual output power is lower than the lower threshold of the output power
reference value.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1 Indicates the actual number of the optical interface on a board where
the alarm occurs.
For example, 0x01 indicates that the alarm is reported from optical
interface 1 of the board.
Possible Causes
The possible cause of the OUT_PWR_LOW alarm is as follows:
Procedure
Step 1 View the OUT_PWR_LOW alarm on the U2000 to confirm the relevant board.
----End
Related Information
None.
9.162 P_AIS
Description
The P_AIS is an alarm indication signal of the E3/T3 service at the PDH interface. If a
tributary board has detected that the input PDH signals in the E3/T13 service are all "1"s or
the detected T3 service is 1010..., the P_AIS alarm is reported.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 2, Indicates the number of the path in which the alarm occurs. Parameter 2 is
Parameter 3 the higher byte, and Parameter 3 is the lower byte.
For example, Parameter 2 = 0x00, Parameter 3= 0x01. In this case, the
P_AIS alarm is reported from path 1 of the board.
Note: For the N2PQ1 or R2PD1 board in the MUX mode, the path number
is reported from 0x40, which indicates the first VC3 path.
Possible Causes
The possible causes of the P_AIS alarm are as follows:
l The TU_AIS or TU_LOP alarm occurs in the relevant path of the board.
l The transmission line is faulty.
l The PDH equipment at the opposite station output the AIS signal.
Procedure
Step 1 View the P_AIS alarm on the U2000, and then confirm the path number according to the
alarm parameters.
Step 2 Check whether the TU_AIS or TU_LOP alarm is reported for the relevant path. If yes, clear
the it, and then check whether the P_AIS is cleared.
Step 3 If the alarm persists, perform service self-loop (namely, hardware inloop) to the alarm path at
the DDF.
NOTICE
The loopback causes service interruption.
l If the alarm is cleared, the equipment at the opposite station is faulty. After removing the
fault, check whether the P_AIS alarm is cleared.
l If the alarm persists, go to the next step.
Step 4 Perform self-loop (namely, hardware inloop) to the path at the interface board.
NOTICE
The loopback causes service interruption.
l If the alarm is cleared, the signal cable connection is faulty. After removing the faulty
connection, check whether the P_AIS alarm is cleared.
l If the alarm persists, go to the next step.
Step 5 Set self-loop for the path on the U2000.
NOTICE
The loopback causes service interruption.
l If the alarm is cleared, the interface board is faulty. In this case, remove the interface
board and insert it again, or replace the interface board.
l If the alarm persists, the board is faulty. In this case, replace the board that reports the
alarm.
----End
Related Information
None.
9.163 P_LOF
Description
The P_LOF is an alarm indicating the loss of frame in the E3/T3 service at the PDH interface.
If the PDH service fails to receive the frame alignment signal, the P_LOF alarm is reported.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 2, Indicates the number of the path in which the alarm occurs. Parameter 2 is
Parameter 3 the higher byte, and Parameter 3 is the lower byte.
For example, Parameter 2 = 0x00, Parameter 3= 0x01. In this case, the
P_LOF alarm is reported from path 1 of the board.
Note: For the N2PQ1 or R2PD1 board in the MUX mode, the path number
is reported from 0x40, which indicates the first VC3 path.
Possible Causes
The possible causes of the P_LOF alarm are as follows:
Procedure
Step 1 View the P_LOF alarm in the U2000, and then check whether the frame format of the PDH
signals accessed to the board is consistent with that specified for the board. Make sure that the
service configuration is correct and that the frame format of the PDH signals accessed to the
board is consistent with that specified for the board. Then check whether the P_LOF alarm is
cleared.
Step 2 If the alarm persists, replace the board that reports the P_LOF alarm.
----End
Related Information
None.
9.164 P_RAI
Description
The P_RAI is a remote alarm indication of the signals at the PDH interface. If the RAI bit of
the E3 service is 1 or if the X bit of the T3 service is 1, the P_RAI alarm is reported.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Name Meaning
Parameter 2, Indicates the number of the path in which the alarm occurs. Parameter 2 is
Parameter 3 the higher byte, and Parameter 3 is the lower byte.
For example, Parameter 2 = 0x00, Parameter 3= 0x01. In this case, the
P_RAI alarm is reported from path 1 of the board.
Note: For the N2PQ1 or R2PD1 board in the MUX mode, the path number
is reported from 0x40, which indicates the first VC3 path.
Possible Causes
The possible cause of the P_RAI alarm is as follows:
The opposite station has received the P_AIS or P_LOF alarm.
Procedure
Step 1 Check whether the P_AIS or P_LOF alarm at the opposite end is detected on the U2000. If
yes, clear it. Then the P_RAI alarm is automatically cleared.
----End
Related Information
None.
9.165 PASSWORD_NEED_CHANGE
Description
The PASSWORD_NEED_CHANGE alarm indicates that the default username and password
used to log in to an NE have not been changed.
Examples of default usernames and passwords include:
l Username: szhw; password: nesoft
l Username: root; password: password
l Username: lct; password: password
l Username: LCD; password: LCD
Attribute
Alarm Severity Alarm Type
Parameters
None
Possible Causes
The possible cause of the alarm is as follows:
l The default username and password have not been changed.
Procedure
Step 1 Change the default username and password, or delete the default account.
----End
Related Information
None
9.166 PATCH_ACT_TIMEOUT
Description
The PATCH_ACT_TIMEOUT is an alarm indicating the patch package activation timeout. If
the activation of the patch times out, you need to process the patch.
Attribute
Alarm Severity Alarm Type
Parameters
None.
the deactivated state. The functions of the patch do not exist or the bug corrected by the patch
appears again.
Possible Causes
The possible cause of the PATCH_ACT_TIMEOUT alarm is as follows:
When the patch is in the activation status, if the duration exceeds the specified value, the
alarm is reported.
Procedure
Step 1 If the patch is running normally and you need it to continue functioning, immediately issue a
command of running the patch. If the running of the patch is abnormal, immediately issue a
deactivation command.
----End
Related Information
None.
9.167 PATCH_ERR
Description
The PATCH_ERR is an alarm indicating that the automatic patch loading fails.
Attribute
Parameters
None.
Possible Causes
The possible cause of the PATCH_ERR alarm is as follows:
If a patch is running before the system reboots, the NE automatically loads and runs this patch
after the reboot. If any anomaly occurs at this time and thus the loading is failed, the
PATCH_ERR alarm is reported.
Procedure
Step 1 Reload the patch file. If the PATCH_ERR alarm is still reported after the loading, download
the correct patch file and then load the patch.
----End
Related Information
None.
9.168 PATCH_DEACT_TIMEOUT
Description
The PATCH_ACT_TIMEOUT is an alarm indicating the patch package deactivation timeout.
If the deactivation of the patch times out, you need to process the patch.
Attribute
Alarm Severity Alarm Type
Parameters
None.
Possible Causes
The possible cause of the PATCH_DEACT_TIMEOUT alarm is as follows:
When the patch is in the deactivation status, if the duration exceeds the specified value, the
alarm is reported.
Procedure
Step 1 To enable the patch, you need to activate the patch. If the patch is not necessary, delete the
package.
----End
Related Information
None.
9.169 PATCH_PKGERR
Description
The PATCH_PKGERR is an alarm indicating that the patch package file is abnormal.
Attribute
Alarm Severity Alarm Type
Minor Equipment alarm
Parameters
None.
NOTE
Possible Causes
The possible causes of the PATCH_PKGERR alarm are as follows:
l The patch package file is incorrect.
l The patch package file is damaged.
l The patch package file is deleted.
Procedure
Step 1 Re-load the correct patch package file.
----End
Related Information
None.
9.170 PATCH_NOT_CONFIRM
Description
The PATCH_NOT_CONFIRM is an alarm indicating that a patch is not confirmed after it is
activated.
Attribute
Parameters
None.
Possible Causes
The possible cause of the PATCH_NOT_CONFIRM alarm is as follows:
After a patch is activated, confirm whether to run or deactivate the patch after a certain period
of time. Otherwise, the PATCH_NOT_CONFIRM alarm is reported. In this case, the
functions of the patch disappear or the bug corrected by the patch appears again.
Procedure
Step 1 If you confirm that the patch runs normally, issue the command to run the patch in a timely
manner. After you confirm that the operation of the patch is abnormal, issue the command to
deactivate the patch in a timely manner.
----End
Related Information
None.
9.171 PATCHFILE_NOTEXIST
Description
The PATCHFILE_NOTEXIST is an alarm indicating that the patch file does not exist when
the patch is automatically loaded.
Attribute
Parameters
None.
Possible Causes
The possible cause of the PATCHFILE_NOTEXIST alarm is as follows:
If a patch is running before the NE reboots, the NE automatically loads and runs the patch
after the reboot. If any patch file is lost at this time, the PATCHFILE_NOTEXIST alarm is
reported.
Procedure
Step 1 Download the patch file again and then load it to the NE.
----End
Related Information
None.
9.172 PLL_FAIL
Description
The PLL_FAIL is an alarm indicating the failure of the phase locked loop.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Name Meaning
Parameter 2, Indicates the path number. Parameter 2 is the higher byte, and
Parameter 3 Parameter 3 is the lower byte.
For example, Parameter 2 = 0x00, Parameter 3= 0x01. In this case, the
PLL_FAIL alarm is reported from path 1 of the board.
Possible Causes
The possible cause of the PLL_FAIL alarm is as follows:
The phase locked loop of the service board fails.
Procedure
Step 1 View the PLL_FAIL alarm on the U2000 to confirm the relevant board.
Step 2 Perform a cold reset on the board that reports the alarm. Then check whether the PLL_FAIL
alarm is cleared.
Step 3 If the alarm persists, replace the board that reports the PLL_FAIL alarm.
----End
Related Information
None.
9.173 P_FFM
Description
The P_FFM is an alarm indicating the DS3 (T3) frame format mismatch. When the frame
formats of the received DS3 signal and the DS3 signal to be processed are inconsistent, this
alarm is reported.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
Name Meaning
Possible Causes
The possible cause of the P_FFM alarm is as follows:
The frame format of the received tributary DS3 signals and the frame format of the configured
tributary DS3 signals are inconsistent.
Procedure
Step 1 View the alarm on the U2000. Check whether the frame format of the received DS3 signals
and the frame format configured on the board are the same. If the frame formats are different,
set them to the same, and then the alarm is cleared.
----End
Related Information
None.
9.174 PM_BDI
Description
The PM_BDI is a PM back defect indication in the PM overhead at the optical demultiplexer
unit (ODU) layer. This alarm shows that ODUs are provided at the remote end or severe
alarms occur at an upper layer.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Possible Causes
The possible causes of the PM_BDI alarm are as follows:
Procedure
Step 1 Check whether any other higher-level ODU alarm occurs at the remote ODU termination
station. If yes, take priority to clear it, and then check whether the PM_BDI alarm is cleared.
Step 2 If the alarm at the remote end persists, perform an inloop to the local optical interface. If the
PM_BDI alarm occurs, check and modify the configuration.
NOTICE
The loopback causes service interruption.
Step 3 If the alarm persists, replace the board at the local station.
Step 4 If the alarm at the remote end persists and if the inloop is normally performed to the local
optical station, replace the board at the remote end.
----End
Related Information
None.
9.175 PM_BEI
Description
The PM_BEI is a PM back error indication in the PM overhead at the optical demultiplexer
unit (ODU) layer. This alarm shows that PM-BIP check bit errors occur at the remote end.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Possible Causes
The possible causes of the PM_BEI alarm are as follows:
Procedure
Step 1 Check whether any bit error occurs at the ODU termination station. After clearing the bit
error, check whether the PM_BEI alarm is cleared.
Step 2 If the alarm at the remote end persists, perform an inloop to the local optical interface. If the
PM_BEI alarm occurs, check and modify the configuration.
NOTICE
The loopback causes service interruption.
Step 3 If the alarm persists, replace the board at the local station.
Step 4 If the alarm at the remote end persists and if the inloop is normally performed to the local
optical station, replace the board at the remote end.
----End
Related Information
None.
9.176 PM_BIP8_OVER
Description
The PM_BIP8_OVER is an alarm indicating that the number of bit errors in the ODU PM
section crosses the threshold.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Possible Causes
The possible causes of the PM_BIP8_OVER alarm are as follows:
l The received signals are heavily attenuated.
l The fiber connector is dirty.
l The connector is incorrectly connected.
l The receive unit at the local station is faulty.
l The transmit unit at the opposite station is faulty.
Procedure
Step 1 Check whether any higher-level alarm, such as the R_LOS or R_LOF, is detected on the
U2000. If yes, take priority to clear it, and then check whether the PM_BIP8_OVER alarm is
cleared.
Step 2 Check whether the received optical power of the alarm board is within the specified value
range. If yes, go to Step 9.
Step 3 Clean the fiber connector at the local station and the receive optical interface on the line
board, and then check whether the alarm is cleared.
Step 4 Check whether the flange is correctly connected to the optical attenuator at the local station,
and whether the attenuation value specified in the optical attenuator is proper. After making
sure that the flange and optical attenuator are used properly, check whether the alarm is
cleared.
Step 5 Check whether the launched optical power at the opposite station is within the specified value
range. If not, replace the line board.
Step 6 If the launched optical power is within the specified value range, clean the fiber connector at
the opposite station, and then check whether the alarm is cleared.
Step 7 Check whether the flange is correctly connected to the optical attenuator at the opposite
station, and whether the attenuation value specified in the optical attenuator is proper. After
making sure that the flange and optical attenuator are used properly, check whether the alarm
is cleared.
Step 8 Check whether the fiber cable is faulty. If yes, remove the fault, and then check whether the
alarm is cleared.
Step 9 Replace the line board that reports the alarm at the local station, and then check whether the
alarm is cleared.
Step 10 Replace the cross-connect and timing board at the local station, and then check whether the
alarm is cleared.
Step 11 Replace the line board at the opposite station, and then check whether the alarm is cleared.
Step 12 Replace the cross-connect and timing board at the opposite station, and then check whether
the alarm is cleared.
----End
Related Information
None.
9.177 PM_BIP8_SD
Description
The PM_BIP8_SD is a PM BIP error signal degrade alarm in the ODU PM section.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Possible Causes
The possible causes of the PM_BIP8_SD alarm are as follows:
l The received signals are heavily attenuated.
l The fiber connector is dirty.
l The connector is incorrectly connected.
l The receive unit at the local station is faulty.
l The transmit unit at the opposite station is faulty.
Procedure
Step 1 Check whether any higher-level alarm, such as the R_LOS or R_LOF, is detected on the
U2000. If yes, take priority to clear it, and then check whether the PM_BIP8_SD alarm is
cleared.
Step 2 Check whether the received optical power of the alarm board is within the specified value
range. If yes, go to Step 9.
Step 3 Clean the fiber connector at the local station and the receive optical interface on the line
board, and then check whether the alarm is cleared.
Step 4 Check whether the flange is correctly connected to the optical attenuator at the local station,
and whether the attenuation value specified in the optical attenuator is proper. After making
sure that the flange and optical attenuator are used properly, check whether the alarm is
cleared.
Step 5 Check whether the launched optical power at the opposite station is within the specified value
range. If not, replace the line board.
Step 6 If the launched optical power is within the specified value range, clean the fiber connector at
the opposite station, and then check whether the alarm is cleared.
Step 7 Check whether the flange is correctly connected to the optical attenuator at the opposite
station, and whether the attenuation value specified in the optical attenuator is proper. After
making sure that the flange and optical attenuator are used properly, check whether the alarm
is cleared.
Step 8 Check whether the fiber cable is faulty. If yes, remove the fault, and then check whether the
alarm is cleared.
Step 9 Replace the line board that reports the alarm at the local station, and then check whether the
alarm is cleared.
Step 10 Replace the cross-connect and timing board at the local station, and then check whether the
alarm is cleared.
Step 11 Replace the line board at the opposite station, and then check whether the alarm is cleared.
Step 12 Replace the cross-connect and timing board at the opposite station, and then check whether
the alarm is cleared.
----End
Related Information
None.
9.178 PM_TIM
Description
The PM_TIM is a monitoring trail trace identifier (TTI) mismatch alarm in the ODU PM
overhead.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Possible Causes
The possible cause of the PM_TIM alarm is as follows:
The PM_TTI byte to be received at the local station is incorrectly set.
Procedure
Step 1 Check whether the SM-TTI byte to be received at the board is consistent with the received
SM-TTI byte. If not, modify it and make sure it is consistent with the received SM-TTI byte.
----End
Related Information
None.
9.179 PORT_MODULE_OFFLINE
Description
The PORT_MODULE_OFFLINE is an alarm indicating that the optical module is offline.
This alarm occurs when a board detects that the optical module of the board is offline.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1 Indicates the actual number of the optical interface on a board where
the alarm occurs.
For example, 0x01 indicates that the alarm is reported from optical
interface 1 of the board.
Possible Causes
The possible cause of the PORT_MODULE_OFFLINE alarm is as follows:
The laser is not installed at the local station.
Procedure
Step 1 View the PORT_MODULE_OFFLINE alarm on the U2000 to confirm the relevant board.
----End
Related Information
None.
9.180 PORTMODE_MISMATCH
Description
The PORTMODE_MISMATCH is an alarm indicating that the working mode of the opposite
FE port does not match with that of the local FE port. When the local FE port is in the auto-
negotiation mode and the opposite FE port is in the non-auto-negotiation mode, the
PORTMODE_MISMATCH alarm is reported.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 2, Parameter 2 is the higher byte, whose value is always 0x00, and thus
Parameter 3 this parameter is meaningless.
Parameter 3 is the lower byte, whose value is always 0x01, and thus this
parameter is meaningless.
Parameter 4, Indicate the current working mode of the port. Parameter 4 is the higher
Parameter 5 byte, and Parameter 5 is the lower byte.
l 0x01: 10M half-duplex.
l 0x02: 10M full-duplex.
l 0x03: 100M half-duplex.
l 0x04: 100M full-duplex.
l 0x05: 1000M half-duplex.
l Indicate the FE port of the standby board. The values of Parameter 4
and Parameter 5 are always 0xFF.
Possible Causes
The possible cause of the PORTMODE_MISMATCH alarm is as follows:
The working mode of the local FE port is not consistent with that of opposite FE port. For
example, the local FE port is in the auto-negotiation mode, while the opposite FE port is in
the non-auto-negotiation mode.
Procedure
Step 1 View the PORTMODE_MISMATCH alarm on the U2000, and then confirm the number of
the MAC port where the PORTMODE_MISMATCH alarm is generated according to
Parameter 1.
Step 2 Disable and then enable the opposite FE port, and start the auto-negotiation mode. Make sure
the working mode of the local FE port is consistent with that of the opposite FE port. Then
check whether the PORTMODE_MISMATCH alarm is cleared.
----End
Related Information
None.
9.181 PRBS_TEST
Description
The PRBS_TEST is a PRBS test alarm. This alarm indicates that a PRBS test is in progress.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 2, Parameter 3 Indicates the number of the VC-4 path that is under test.
Possible Causes
The possible cause of the PRBS_TEST alarm is as follows:
Procedure
Step 1 When the PRBS test ends, the PRBS_TEST alarm is automatically cleared.
Step 2 To clear the PRBS_TEST alarm, you can also cancel the PRBS test.
----End
Related Information
None.
9.182 PROTOCOL_MM
Description
The PROTOCOL_MM is an alarm indicating the encapsulation protocol mismatch.
Attribute
Alarm Severity Alarm Type
Parameters
None.
Possible Causes
The possible cause of the PROTOCOL_MM alarm is as follows:
The types of the data encapsulation protocols at two ends of the communication are different.
Procedure
Step 1 Check whether the encapsulation protocols at the local station and the opposite station are the
same. For example, the local station uses the GFP but the opposite station uses the LAPS. If
the protocols are different, set them to the same. Then, the alarm is cleared.
----End
Related Information
None.
9.183 PS
Description
The PS is an indication alarm of protection switching. This alarm occurs after protection
switching occurs on a service.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Possible Causes
The possible cause of the PS alarm is as follows:
Procedure
Step 1 Query whether a switching command is manually issued to forcibly switch the service to the
protection path. Make sure that the service can be normal on the working path and switch the
service to the working patch. The PS alarm is automatically cleared.
Step 2 If no switching command is issued, determine the cause of working path failure. After
repairing the working path, restore the service. The PS alarm is automatically cleared.
----End
Related Information
None.
9.184 PUM_BCM_ALM
Description
The PUM_BCM_ALM is an alarm indicating that the bias current of the pumping laser
crosses the threshold.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1 In the case of RAMAN amplifier boards, BA2 boards, and BPA boards,
this parameter indicates the laser number.
In the case of OBU01 boards, this parameter indicates the actual optical
interface number of the board.
Name Meaning
Parameter 2, In the case of OBU01 boards, these parameters indicate the pump laser
parameter 3 number.
Parameter 2 is the higher byte, and Parameter 3 is the lower byte.
Parameter 2 is in value 0x01, and Parameter 3 is in value 0x02.
Parameter 4 In the case of OBU01 boards, this parameter indicates the threshold-
crossing type.
l 0x01: The laser driving current temperature exceeds the upper
threshold.
l 0x02: The laser driving current temperature exceeds the lower
threshold.
Possible Causes
The possible causes of the PUM_BCM_ALM alarm are as follows:
l The input wavelength is incorrect.
l The input optical power is extremely low.
l The laser is faulty.
Procedure
Step 1 Check whether the input wavelength is correct. If not, change it to the correct input
wavelength, and then check whether the PUM_BCM_ALM alarm is cleared.
Step 2 If the alarm persists, check whether the input optical power is extremely low. If yes, adjust it
to a proper value, and then check whether the PUM_BCM_ALM alarm is cleared.
Step 3 If the alarm persists, perform a cold reset on the board. Then check whether the
PUM_BCM_ALM alarm is cleared.
NOTICE
If the services travel through the board are not configured with protection, the services are
interrupted after the cold reset of the board.
----End
Related Information
None.
9.185 PUM_TEM_ALM
Description
The PUM_TEM_ALM is an alarm indicating that the working temperature of the pump laser
is over the threshold. This alarm occurs when the working temperature of the pump laser on
the optical amplifier board crosses the threshold.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1 Indicates the number of the optical interface that generates the
PUM_TEM_ALM alarm. For example, 0x01 indicates optical interface
1.
Parameter 2, Indicates the PUMP number of the pump laser that generates the
Parameter 3 PUM_TEM_ALM alarm. The pump number consists of two bytes. For
example, 0x00 0x01 indicates pump laser 1.
Parameter 4 Indicates the threshold crossing type. For example, 0x01 means that the
temperature is more than the upper threshold value and 0x02 means that
the temperature is less than the lower threshold value.
Possible Causes
The possible causes of the PUM_TEM_ALM alarm are as follows:
Procedure
Step 1 Check whether the ambient temperature is normal. If not, change the ambient temperature to
be proper for the equipment operation.
Step 2 If the PUM_TEM_ALM alarm persists, use the U2000 warm reset the faulty board.
Step 3 If the PUM_TEM_ALM alarm still persists, perform a remove-and-insert operation to the
faulty board on the condition that the services are not affected.
Step 4 If the PUM_TEM_ALM alarm persists, replace the faulty board.
----End
Related Information
None.
9.186 PUMP_COOL_EXC
Description
The PUMP_COOL_EXC alarm is an alarm indicating the cool current of pump laser over
threshold. This alarm occurs when the laser cooling current crosses the upper threshold.
Attribute
Alarm Severity Alarm Type
Critical Equipment
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Indicates the optical port where the alarm occurs. For example, 0x01 indicates
Parameter 1
optical port 1.
Indicate the pump laser where the alarm occurs. For example, 0x01 indicates
Parameter 2
pump laser 1.
Indicates the threshold crossing type. For example: 0x01 indicates exceeds the
Parameter 3
upper threshold. 0x02 indicates exceeds the lower threshold.
Possible Causes
The possible causes of the PUMP_COOL_EXC alarm are as follows:
Procedure
Step 1 Check whether the ambient temperature is normal. If not so, improve it.
Step 2 If the alarm is not cleared, check whether the laser parameter table is correct; if not, reload the
parameter table file.
----End
Related Information
None.
9.187 PWD_ENCRYPT_RISK
Description
The PWD_ENCRYPT_RISK alarm indicates that the user password encryption mode of an
NE has security risks. If the user password encryption mode of an NE is MD5 or SHA256,
this alarm is reported when you log in to the NE, change the user password, or create an NE
user.
Attribute
Alarm Severity Alarm Type
Major Security
Parameters
None
Possible Causes
The possible cause of the alarm is as follows:
The user password encryption mode of the NE is MD5 or SHA256.
Procedure
Step 1 Change the user password encryption mode to PBKDF2 on the NMS.
1. On the Main Topology, right-click the required NE and choose NE Explorer from the
shortcut menu.
2. In the NE Explorer, click the NE and choose Security > NE User Password Encryption
Management.
3. Change Encryption Type to PBKDF2.
4. Click Apply.
Step 2 If the alarm persists, contact Huawei technical support engineers to handle the alarm.
----End
Related Information
None
9.188 PWR_MAJ_ALM
Description
The PWR_MAJ_ALM is an alarm of CAU severe overvoltage or undervoltage.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 2, Indicates the voltage type. Parameter 2 is the higher byte, and Parameter
Parameter 3 3 is the lower byte.
The value of Parameter 2 is always 0x00. The values of Parameter 3 are
as follows:
l 0x01: AC
l 0x02: DC
Parameter 4, Indicates the type of the abnormal voltage. Parameter 4 is the higher
Parameter 5 byte, and Parameter 5 is the lower byte.
The value of Parameter 4 is always 0x00. The values of Parameter 5 are
as follows:
l 0x00: Power cut
l 0x01: Overvoltage
l 0x02: Undervoltage
Possible Causes
The possible causes of the PWR_MAJ_ALM alarm are as follows:
Procedure
Step 1 View the PWR_MAJ_ALM alarm on the U2000, and then confirm the alarm cause according
to Parameter 3 and Parameter 5.
l If the AC power is off, find the power off cause. Then restore the power supply in a
timely manner and check whether the alarm is cleared.
l If the DC power is overvoltaged or undervoltaged, the board hardware may be faulty. In
this case, replace the board.
----End
Related Information
None.
9.189 R_FIFO_E
Description
The R_FIFO_E is an alarm indicating that the received FIFO messages overflow.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Possible Causes
The possible causes of the R_FIFO_E alarm are as follows:
l The service cross-connections are incorrectly configured.
l The level of accessed services is incorrect.
Procedure
Step 1 Check whether the R_FIFO_E alarm on the U2000. Check whether the service cross-
connections are correctly configured for the NE at which the alarm occurs. After modifying
the incorrect configuration, check whether the alarm is cleared
Step 2 If the alarm persists, check whether the services accessed to the board are at correct level.
After making sure that the accessed services are correct, check whether the alarm is cleared.
----End
Related Information
None.
9.190 R_LOC
Description
The R_LOC is an alarm indicating loss of clock. This alarm is reported if the line board fails
to extract clock signal from the line signal.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Possible Causes
The possible causes of the R_LOC alarm are as follows:
l The clock extraction module on the line board is faulty.
l The cross-connect and timing board at the opposite station is faulty or is out of position.
Procedure
Step 1 Perform a cold reset on the line board that generates the alarm at the local station. Then check
whether the R_LOC alarm is cleared.
Step 2 If the alarm persists, the clock extraction module on the line board may be faulty. In this case,
replace the line board, and then check whether the R_LOC alarm is cleared.
Step 3 If the alarm persists, check whether the cross-connect and timing board at the opposite station
is faulty. If yes, replace the cross-connect and timing board, and then check whether the
R_LOC alarm is cleared.
----End
Related Information
None.
9.191 R_LOSYNC
Description
The R_LOSYNC is an alarm indicating the loss of synchronization in the receive direction.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Indicates the internal optical interface number. The value is
Parameter 1
always 0x01.
Indicates the path number. The value of Parameter 2 is always
Parameter 2, Parameter 3
0x00, and the value of Parameter 3 is always 0x01.
If there is not the SLAVE_WORKING alarm, both active and standby cross-
connect boards are abnormal. In this case, the status of the service board is
unknown, and the services may be affected with a very high probability.
l If the clocks of both cross-connect boards are faulty, the status of the service board is
unknown, and the services may be affected with a very high probability.
Possible Causes
The possible causes of the R_LOSYNC alarm are as follows:
l The high speed signal conversion chip of the line board or the cross-connect board is
faulty.
l The ATM bus on the backplane is faulty.
l There is a fiber cut.
Procedure
Step 1 Confirm the abnormal cross-connect board and replace it.
----End
Related Information
None.
9.192 REG_MM
Description
The REG_MM is an alarm of REG mode mismatch. The boards with the REG attribute can
transmit the ECC and orderwire communication only if the REG attributes and the rates of the
corresponding optical interfaces on the two paired boards are the same. Otherwise, the
REG_MM alarm is reported to indicate that the current configuration affects the ECC and
orderwire communication.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1 l Indicates the slot number of the paired board, when the logical
paired board is online and is not set to the REG attribute.
l Indicates the slot number of this board, when the logical paired
board is offline.
Possible Causes
The possible causes of the REG_MM alarm are as follows:
Procedure
Step 1 View the REG_MM alarm on the U2000. Confirm the slot number of the board which
generates the alarm according to Parameter 1.
Step 2 Check whether the rate levels of the paired boards are the same. If not, replace it with boards
of the same rate level. Then check whether the REG_MM alarm is cleared.
Step 3 If the REG_MM alarm persists, check whether the REG attributes of the two paired boards
are the same. If not, set the REG attributes to be the same on the U2000. Then the REG_MM
alarm is automatically cleared.
----End
Related Information
None.
9.193 RELAY_ALARM
Description
The RELAY_ALARM is an alarm of the relay. This alarm occurs when there is an alarm
input.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Possible Causes
The possible causes of the RELAY_ALARM alarm are as follows:
Procedure
Step 1 View the RELAY_ALARM alarm on the U2000. Confirm the number of the alarm input/
output according to Parameter 1.
Step 2 Cut off the alarm input/output. Then the RELAY_ALARM alarm is automatically cleared.
----End
Related Information
None.
9.194 RELAY_ALARM_CRITICAL
Description
The RELAY_ALARM_CRITICAL is an alarm of critical alarm inputs. This alarm occurs
when the user sets the severity of an available alarm input to critical.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Possible Causes
The possible cause of the RELAY_ALARM_CRITICAL alarm is as follows:
Procedure
Step 1 View the RELAY_ALARM_CRITICAL alarm on the U2000. Confirm the number of the
alarm input/output according to Parameter 1.
Step 2 Cut off the alarm input. Then the RELAY_ALARM_CRITICAL alarm is automatically
cleared.
----End
Related Information
None.
9.195 RELAY_ALARM_IGNORE
Description
The RELAY_ALARM_IGNORE is an alarm of warning alarm inputs. This alarm occurs
when the user sets the severity of an available alarm input to warning.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Possible Causes
The possible cause of the RELAY_ALARM_IGNORE alarm is as follows:
Procedure
Step 1 View the RELAY_ALARM_IGNORE alarm on the U2000. Confirm the number of the alarm
input/output according to Parameter 1.
Step 2 Cut off the alarm input. Then the RELAY_ALARM_IGNORE alarm is automatically cleared.
----End
Related Information
None.
9.196 RELAY_ALARM_MAJOR
Description
The RELAY_ALARM_MAJOR is an alarm of major alarm inputs. This alarm occurs when
the user sets the severity of an available alarm input to major.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Possible Causes
The possible cause of the RELAY_ALARM_MAJOR alarm is as follows:
Procedure
Step 1 View the RELAY_ALARM_MAJOR alarm on the U2000. Confirm the number of the alarm
input/output according to Parameter 1.
Step 2 Cut off the alarm input. Then the RELAY_ALARM_MAJOR alarm is automatically cleared.
----End
Related Information
None.
9.197 RELAY_ALARM_MINOR
Description
The RELAY_ALARM_MINOR is an alarm of minor alarm inputs. This alarm occurs when
the user sets the severity of an available alarm input to minor.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Possible Causes
The possible cause of the RELAY_ALARM_MINOR alarm is as follows:
Procedure
Step 1 View the RELAY_ALARM_MINOR alarm on the U2000. Confirm the number of the alarm
input/output according to Parameter 1.
Step 2 Cut off the alarm input. Then the RELAY_ALARM_MINOR alarm is automatically cleared.
----End
Related Information
None.
9.198 RELAY_FAIL
Description
The RELAY_FAIL is an alarm indicating that the relay is faulty. This alarm occurs when the
relay on the board is faulty.
Attribute
Alarm Severity Alarm Type
Parameters
None.
Possible Causes
The possible cause of the RELAY_FAIL alarm is as follows:
The relay works abnormally, because the board is faulty.
Procedure
Step 1 Replace the board on which the alarm is reported.
----End
Related Information
None.
9.199 RFA
Description
The RFA is an alarm indicating that the framing E1/T1 frame notification event occurs. If the
framing E1/T1 signals occur in consecutive Z (Z is from two through five) double-frame
cycles, the RFA alarm is reported when the RDI bit of the input signals is set to 1.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Possible Causes
The possible cause of the RFA alarm is as follows:
The LFA alarm occurs at the remote end.
Procedure
Step 1 Check whether the LFA alarm occurs at the opposite end of the path corresponding to the
board that reports the alarm. If yes, clear the LFA alarm at the opposite end. Then the RFA
alarm at the local end is cleared accordingly.
----End
Related Information
None.
9.200 RINGMAPM_MM
Description
The RINGMAPM_MM is an alarm indicating that the generation mode of the ring map at
each node differs.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
Name Meaning
Possible Causes
The causes for the RINGMAPM_MM alarm are as follows:
l An NE may be added. This NE may be added when the entire ring is in the manual
mode. The default setting of a new NE, however, is the automatic mode. If the default
setting of the new NE is not changed, it is different from those of other NEs on the ring.
l The mode of an NE is changed, and then the modes of all the other NEs on the entire
ring are automatically changed. After the mode change, all the NEs are stored to the
database. But if the SCC board is powered off before the updated database is backed up
to the FLASH, the mode of this NE is different with others after the SCC is reset.
l The fiber connection may be faulty during the mode change. In this case, the mode
change message cannot be set to a certain node. Thus, the modes of all the NEs cannot
be automatically changed. If the NE SCC is reset in this process, the mode of this NE is
different from those of other NEs on the ring. In this case, the RINGMAPM_MM alarm
occurs.
Procedure
Step 1 Check whether the generation modes of the ring maps for all the nodes on the MS ring are the
same. If not, change the modes to be the same.
----End
Related Information
Ring Map Generation Mode
A ring map can be generated either in the automatic mode or in the manual mode. The modes
of all the NEs on the ring must be the same. In normal cases, change of an NE mode results in
automatic change of the modes of the other NEs.
9.201 RMFA
Description
The RMFA is an alarm that the framing E1/T1 multiframe notification event occurs. If the
framing E1/T1 signals occur in consecutive Z (Z is from two through five) CAS multiframe
cycles, the RMFA alarm is reported when all the CAS multiframe mutual-notification bits of
the input signals are set to 1.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Possible Causes
The possible cause of the RMFA alarm is as follows:
The LMFA alarm occurs at the remote end.
Procedure
Step 1 Check whether the LMFA alarm occurs at the opposite end of the path corresponding to the
board that reports the alarm. If yes, clear the LMFA alarm at the opposite end. Then the
RMFA alarm at the local end is cleared accordingly.
----End
Related Information
None.
9.202 RPR_DUPLICATE_MAC
Description
The RPR_DUPLICATE_MAC is an alarm of node ID conflict. This alarm indicates node ID
(MAC) duplicate in a resilient packet ring (RPR) network.
NOTE
The MAC address mentioned is different from the MAC address at the physical layer. In a RPR, the
MAC address is converted from the node ID. The last byte of the MAC address in a RPR indicates the
node ID and other bytes are filled with 0. Hence, the node ID conflict indicates MAC address conflict in
a RPR.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Possible Causes
The possible causes of the RPR_DUPLICATE_MAC alarm are as follows:
This alarm occurs when several nodes are using the same node ID (or MAC address) in a
RPR network.
NOTICE
The protocol has some defects in the detection mechanism for this alarm. Hence, in certain
specific situations, the RPR board may incorrectly report the RPR_DUPLICATE_MAC
alarm.
Procedure
Step 1 If the RPR_DUPLICATE_MAC alarm reported by a RPR board automatically ends in a short
time period (03 minutes), the alarm is incorrectly reported and it does not affect the
services. Hence, you need not handle the alarm.
Step 2 If the alarm does not end after a time period, the node ID conflict exists in the RPR ring. In
this case, query the node ID of each node in the RPR network and set the conflict node IDs to
the node IDs that do not have conflict. The alarm is automatically cleared.
----End
Related Information
The situations in which the RPR_DUPLICATE_MAC alarm may be incorrectly
reported
l If forced switching (FS) or manually switching (MS) is performed on a node, and the
node ID of the node is set to have conflict with the node ID of another node, the
irrelevant node may incorrectly report the alarm.
l In a RPR network that contains many nodes, if cold reset is performed on all cross-
connect boards, a node may incorrectly report the alarm.
l If many services are configured for a node, the node may incorrectly report the alarm
when cold reset is performed on the board or the NE is power off.
In the three situations mentioned, the alarm incorrectly reported by a node in a RPR network
automatically ends in a time period (03 minutes). When the RPR network topology
changes, for example, the switching status is changes, the node ID is changed, a node is added
or deleted, active and standby switching is performed on a cross-connect board, cold reset is
performed on a board, wait for 13 minutes. Then, query the alarm of the RPR board to
check whether the RPR_DUPLICATE_MAC alarm exists.
9.203 RPR_ECHO_DLOC
Description
The RPR_ECHO_DLOC is the indication alarm of loss of continuity failure defect (DLOC)
for the OAM function of the RPR module. It is a forecast alarm of an abnormal link and it
indicates that the link communication may be abnormal. The RPR_ECHO_DLOC cannot be
automatically reported. It is a status that the protocol uses for handling the RPR_ECHO_LOC
alarm. During alarm registration, the RPR_ECHO_LOC suppresses the RPR_ECHO_DLOC.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 2, Indicates the number of the path on which the alarm occurs.
Parameter 3 Parameter 2 is the higher byte, and Parameter 3 is the lower byte.
0x01 - 0x10 indicates 1 - 16 ECHO paths respectively.
Possible Causes
The possible causes of the RPR_ECHO_DLOC alarm are as follows:
l If the priority type of the ECHO packet is ClassX, and the ClassX bandwidth of the
request ring network segment or response ring network segment that the ECHO packet
passes is extremely insufficient, the alarm is reported.
l If the entire RPR network has the consistent protection mode and the ECHO packet is set
to unprotected, the alarm is reported when fiber cut exists in the ring network segment
that the ECHO packet passes.
l If the entire RPR network has the consistent protection mode, which is steering, and the
ECHO packet is set to protected, the alarm is reported when fiber cut exists in the ring
network segment that the ECHO packet passes.
l If the ECHO packet is not received and handled in time for any other reason or the
received ECHO packet is incorrect, the alarm may be reported.
Procedure
Step 1 Query the topology information of the RPR network to check whether the information is
normal. Clear the relevant alarm according to the switching conditions of the network. For
details, refer to the procedure for handling the RPR_PS_CHANGE alarm.
Step 2 If the priority type of the ECHO packet is Class X, check whether the Class X bandwidth of
the ring network that the request and response ECHO packets pass is sufficient. If there is no
enough bandwidth, re-allocate the bandwidth of the ring network. You can determine the
bandwidth sufficiency according to the bandwidth configuration and the service amount
transmitted on the ring. For example, if the bandwidth A is 50 M, the priority type of the
ECHO packet is configured to A, and other service amount on the ring occupies about 50 M
bandwidth, the ECHO packet cannot be transmitted in the ring network.
Step 3 When fiber cut exists in the ring network segment that the ECHO packet passes, check
whether the protection mode of the ring network is consistent and is not steering. If the
protection mode of the ring network is consistent and is not steering, check whether the
ECHO packet is set to protected. If yes, check whether the alarm is cleared.
Step 4 Check whether the ECHO packet is not received and handled in time because the RPR packet
receiving mailboxes of the request and response ECHO nodes are blocked. Check whether the
received ECHO packet is incorrect. You can view the printed information in Telnet or query
the ECHO information of the entire RPR port to check whether the ECHO packet is normal.
If the ECHO packet that the node receives is abnormal, perform cold reset or replace the
board.
----End
Related Information
ECHO Path
In the ECHO, each node always has 16 paths. The paths are allocated according to the
processing capability of a board and can be used to check the status of links between one node
and other nodes. The ECHO packet is a request and response packet of the OAM packet. The
ECHO packet sends a request ECHO frame from the source to the destination address. After
receiving the request frame, the destination address parses the ECHO packet and sends a
corresponding response frame to the request node according to the response ring direction
information in the received ECHO packet header. The request node determines the
connectivity of the link according to the received response ECHO frame.
The ECHO packet is managed by path. Hence, the ECHO parameters, the reporting and
clearing of the RPR_ECHO_DLOC and RPR_ECHO_LOC alarms are handled by path. The
RPR_ECHO_DLOC alarm is reported from a path and lasts for 2s before the
RPR_ECHO_LOC alarm of the path is reported.
CLASS X
9.204 RPR_ECHO_LOC
Description
The RPR_ECHO_LOC is an indication alarm of loss of continuity failure (LOC) for the
ECHO function of the RPR module. It indicates that the communication of a link is severely
abnormal.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Name Meaning
Parameter 2, Indicates the number of the path on which the alarm occurs.
Parameter 3 Parameter 2 is the higher byte, and Parameter 3 is the lower byte.
0x01 - 0x10 indicates 1 - 16 ECHO paths respectively.
Possible Causes
The possible cause of the RPR_ECHO_LOC alarm is as follows:
The RPR_ECHO_DLOC alarm is reported from a path and lasts for 2s before the
RPR_ECHO_LOC alarm of the path is reported. Hence, the causes of the RPR_ECHO_LOC
alarm are the same as the causes of the RPR_ECHO_DLOC alarm.
Procedure
Step 1 Refer to the procedure for handling the RPR_ECHO_DLOC alarm.
----End
Related Information
ECHO Path
In the ECHO, each node always has 16 paths. The paths are allocated according to the
processing capability of a board and can be used to check the status of links between one node
and other nodes. The ECHO packet is a request and response packet of the OAM packet. The
ECHO packet sends a request ECHO frame from the source to the destination address. After
receiving the request frame, the destination address parses the ECHO packet and sends a
corresponding response frame to the request node according to the response ring direction
information in the received ECHO packet header. The request node determines the
connectivity of the link according to the received response ECHO frame.
The ECHO packet is managed by path. Hence, the ECHO parameters, the reporting and
clearing of the RPR_ECHO_DLOC and RPR_ECHO_LOC alarms are handled by path. The
RPR_ECHO_DLOC alarm is reported from a path and lasts for 2s before the
RPR_ECHO_LOC alarm of the path is reported.
9.205 RPR_MISCONFIG
Description
The RPR_MISCONFIG is an alarm indicating that the ID of the ring does not match. The
alarm indicates that the ring direction of a RPR node is incorrectly set. The error may be
about fiber connection or cross-connection configuration.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 2, Indicates the path direction in which the alarm occurs. Parameter 2
Parameter 3 is the higher byte, and Parameter 3 is the lower byte.
l 0x01: East direction
l 0x02: West direction
Possible Causes
The possible causes of the RPR_RPR_MISCONFIG alarm are as follows:
l Fiber connection error causes that ring 0 receives a packet of ring 1 or ring 1 receives a
packet of ring 0. The packet contains data packet and protocol packet.
l The incorrect cross-connections configured on a board causes that the VCTRUNK1
connects to VCTRUNK1 and VCTRUNK2 connects to VCTRUNK2. (If the cross-
connections are correctly configured, VCTRUNK1 should connect to VCTRUNK2.)
Procedure
Step 1 Check whether the fiber connection on the line board is correct. The input and output
interfaces of the optical module should match. After the incorrect fiber connection is rectified,
check whether the alarm is cleared.
Step 2 If the alarm persists, query the cross-connection configuration on each board to check whether
the odd timeslots connect to the even timeslots on each RPR board. Rectify any incorrect
cross-connection configuration of the board. The alarm is automatically cleared.
----End
Related Information
None.
9.206 RPR_NB_INCONSIS
Description
The RPR_NB_INCONSIS is an alarm indicating that the topology information of adjacent
nodes is not consistent with each other. This alarm occurs when the topology information
queried from two adjacent nodes is different.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 2, Indicates the path direction in which the alarm occurs. Parameter 2
Parameter 3 is the higher byte, and Parameter 3 is the lower byte.
l 0x01: East direction
l 0x02: West direction
Possible Causes
The possible causes of the RPR_NB_INCONSIS alarm are as follows:
l The ring network configuration is incorrect. For example, the incorrect cross-connection
configuration on the board causes different topology information of two adjacent nodes.
That is, the adjacent node of node A to the east is node B, but the adjacent node of node
B to the west is not node A.
l The fiber connection is incorrect on the line board.
Procedure
Step 1 Query the cross-connection configuration on each board to check whether the odd timeslots
connect to the even timeslots on the RPR boards and whether there are cross-connections that
are not completely configured on a board. After cross-connections are correctly configured,
check whether the alarm is cleared.
Step 2 If the alarm persists, check whether the fiber connections on the line board are correct. Rectify
any incorrect fiber connections. The alarm is automatically cleared.
----End
Related Information
None.
9.207 RPR_PM_INCONSIS
Description
The RPR_PM_INCONSIS is an alarm indicating that the protection modes do not match. It
indicates that the protection modes of nodes in one RPR network are not consistent.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 2, Indicates the path direction in which the alarm occurs. Parameter 2
Parameter 3 is the higher byte, and Parameter 3 is the lower byte.
l 0x01: East direction
l 0x02: West direction.
During the switching in a ring network, if the protection modes of nodes are inconsistent and
the protection mode is steering, the services may be interrupted for a short time, which is less
than 50 ms.
Possible Causes
The possible cause of the RPR_PM_INCONSIS alarm is as follows:
If the protection modes configured for nodes in a RPR network are not consistent, this alarm
is reported.
Procedure
Step 1 Query the protection mode of each node. If the protection modes are not consistent, re-
configure the protection modes according to the compatibility and make sure that the
protection modes of all nodes are consistent. This alarm is automatically cleared.
----End
Related Information
Protection Mode Compatibility
The protection mode wrap is compatible with the wrap_steering. The protection modes wrap/
wrap_steering are not compatible with the steering. If steering is not configured for any node
in a ring network, the services are switched according to the wrap protection mode. If steering
is configured for some nodes and wrap or wrap_steering is configured for some other nodes,
the alarm of inconsistent protection modes occurs and protection switching is performed on
the services according to the steering protection mode.
9.208 RPR_PS_CHANGE
Description
The RPR_PS_CHANGE is an alarm of RPR protection status change. This alarm occurs
when the protection status of a node changes.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Name Meaning
Parameter 2, Indicates the path direction in which the alarm occurs. Parameter 2
Parameter 3 is the higher byte, and Parameter 3 is the lower byte.
l 0x01: East direction
l 0x02: West direction
Possible Causes
The possible causes of the RPR_PS_CHANGE alarm are as follows:
l When the RPR board detects link failure or channel unavailability, including signal fail
(SF) and signal degrade (SD), the RPR protection switching occurs and this alarm is
reported.
l When forced switching is manually issued, including forced switching (FS) and manual
switch (MS), the RPR protection switching occur and this alarm is reported.
Procedure
Step 1 Query the topology information of the ring network to obtain the switching conditions of the
ring network.
Step 2 If the switching condition is FS or MS, manually issue a command of clearing the switching.
The alarm is automatically cleared.
Step 3 If the switching condition is SF,
1. Check whether there is fiber connection error or cross-connection configuration error.
Check whether the RPR_MISCONFIG alarm exists on the U2000. If yes, clear this
alarm.
2. Check whether the VCTRUNK timeslot bindings of nodes in the ring network are
consistent. If not, re-configure the VCTRUNK timeslot bindings.
3. Check whether the laser on the line board is switched on. Make sure that the laser on the
line board is switched on.
4. Check whether there may be fiber cuts. Use loopback to check whether the fiber
connections in the switching area are normal and whether the optical power is too high
or too low. If there are any relevant problems, replace the fiber.
5. Replace the laser to check whether the laser is faulty.
6. Check whether the SF switching command has been issued from the Telnet. Disable the
RPR protocol on the node on which SF switching occurs and enable the protocol again to
check whether SF still exists.
7. If all the previous check results are normal, there may be hardware problems or logical
problems. Perform cold reset, replace a board, or replace the equipment.
Step 4 If the switching condition is SD switch, use the equipment test command or issue a command
from the Telnet to check whether incorrect packets are received. If a node frequently receives
incorrect packets, the loop is abnormal. Perform the following operations to clear the alarm:
1. Check whether there are manually inserted bit errors. If yes, cancel the insertion of bit
errors.
2. Check whether the optical power is too high or too low. Make sure that the optical power
is normal.
3. Replace the fiber to check whether the fiber is normal.
4. Check whether the SD switching command has been issued from the Telnet. Disable the
RPR protocol on the node on which SD switching occurs and enable the protocol again
to check whether SD still exists.
5. If all the previous check results are normal, there may be hardware problems or logical
problems. Perform cold reset, replace a board, or replace the equipment.
----End
Related Information
The RPR protocol defines some basic migration actions for switching conditions of different
priorities for effective network protection. These migration actions comprise the protection
state machine of ring network protection. During the switching of the protection state
machine, the RPR_PS_CHANGE alarm is reported if switching occurs on the loop and the
alarm is not reported if there is no switching on the loop. After the switching, the
RPR_PS_CHANGE alarm is automatically cleared. The alarm is not reported if there is no
switching on the loop.
SF: signal failure, automatic switching. Switching is triggered by media signal failure or RPR
keep-alive failure.
SD: signal degrade, automatic switching. Switching is triggered by degrade of signal quality.
9.209 RPR_STATIONS_EXCEED
Description
The RPR_STATIONS_EXCEED is an alarm of threshold crossing of the total number of
nodes in a RPR network. It indicates that the number of nodes in a RPR network exceeds the
number of nodes that the protocol supports.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Possible Causes
The possible cause of the RPR_STATIONS_EXCEED alarm is as follows:
The RPR protocol supports 255 nodes. This alarm occurs when the number of configured
nodes exceeds 255.
Procedure
Step 1 When you configure a RPR network, make sure that the total number of nodes in the network
is not more than 255. You can delete the extra nodes to clear the RPR_STATIONS_EXCEED
alarm.
----End
Related Information
None.
9.210 RPR_SUM_A0_EXCEED
Description
The RPR_SUM_A0_EXCEED is an alarm of threshold crossing of reserved A0 bandwidth in
a RPR network.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 2, Indicates the number of the RPR network in which the alarm occurs.
Parameter 3 Parameter 2 is the higher byte, and Parameter 3 is the lower byte.
l 0x01: Ring 0
l 0x02: Ring 1
Possible Causes
The possible cause of the RPR_SUM_A0_EXCEED alarm is as follows:
This alarm occurs when the sum of A0 service bandwidth configured for each node exceeds
the maximum bandwidth that the ring network supports.
Procedure
Step 1 View the RPR_SUM_A0_EXCEED alarm on the U2000, and then confirm the relevant RPR
network number according to the alarm parameters.
Step 2 Re-configure the network bandwidth. Make sure that the sum of A0 bandwidth of all nodes on
ring 0 or ring 1 is smaller than the total bandwidth of the network.
----End
Related Information
RPR Network Bandwidth
The bandwidth of a RPR network has several types of priorities, which are A0, A1, B_CIR,
B_EIR, and C. A0 is the reserved bandwidth for priority A and cannot be reused by other
nodes. Bandwidth of other priorities can be reused by any node. The services of B_EIR and C
priorities are applicable to the fair algorithm, in which fair weight is used to control the
inserted traffic of each node. The traffics of services of other priorities are controlled by the
inserted bandwidth that is configured for each service.
When the sum of A0 bandwidth exceeds the total bandwidth of the link in a RPR network,
only services of the A priority are transmitted, and services of B and C priorities cannot be
transmitted. If the total transmit traffic exceeds the total bandwidth of the loop, packet loss
also occurs in services of the high priority. To avoid packet loss, decrease the transmit rate.
NOTE
On the U2000, you can configure the using bandwidth for A services (which is A), the reserved
bandwidth of A services (which is A0), and the using bandwidth of B_CIR services. Other bandwidth
can be calculated according to the previous three values and needs not be set. A1 bandwidth = Using
bandwidth of A services - Reserved bandwidth of A service. B_EIR bandwidth = C bandwidth = Total
loop bandwidth - Using bandwidth of A services - Using bandwidth of B_CIR services.
9.211 RTC_FAIL
Description
The RTC_FAIL is an alarm of SCC real time clock (RTC) failure. This alarm occurs when the
clock of the SCC is faulty.
Attribute
Parameters
None.
Possible Causes
The possible cause of the RTC_FAIL alarm is as follows:
Procedure
Step 1 Replace the SCC board of the corresponding equipment.
----End
Related Information
None.
9.212 RTS
Description
The RTS is an alarm indicating that the Request To Send status of the DCE is abnormal.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 2, Indicates the path number. Parameter 2 is the higher byte, and
Parameter 3 Parameter 3 is the lower byte.
For example, Parameter 2 = 0x00, Parameter 3= 0x01. In this case, the
RTS alarm is reported from path 1 of the board.
Possible Causes
The possible cause of the RTS alarm is as follows:
The DTE at the opposite end works abnormally because the cable is improperly connected, or
the service configuration is incorrect.
Procedure
Step 1 Check whether the DTE at the opposite end works well by following the actions:
1. Check whether the cable is faulty. If yes, remove the fault.
2. Check whether the service configuration is correct, including the settings of DTE and
DCE, inter, slave or exter. Make sure that the service configuration is correct.
After making sure that the DTE at the opposite end works well, the RTS alarm is
automatically cleared.
----End
Related Information
None.
9.213 RS_CROSSTR
Description
The RS_CROSSTR alarm indicates that a regenerator section performance indicator crosses
the threshold. This alarm is reported if a board detects that a regenerator section performance
event crosses the preset threshold.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1 Indicates the ID of the line port that reports the alarm. For example,
0x01 indicates that the alarm is reported by port 1 of the related board.
Parameter 4, The two most significant bits of parameter 4 indicate the performance
Parameter 5 monitoring period.
l 0x01: The monitoring period is 15 minutes.
l 0x02: The monitoring period is 24 hours.
The six least significant bits of parameter 4 and parameter 5 together
indicate the ID of a performance event.
Possible Causes
The possible causes of the RS_CROSSTR alarm are as follows:
Procedure
l Query the RS_CROSSTR alarm on the NMS and determine the board that reports the
alarm. For details, see Viewing the Current Alarms in the Supporting Tasks.
l Cause 1: The other alarms are generated.
a. Check whether any of the following alarms are generated on the board that reports
the RS_CROSSTR alarm on the NMS.
If... Then...
The B1_EXC or B1_SD Ensure that the alarms are cleared immediately. If the
alarm is generated RS_CROSSTR alarm persists, perform the operations
that are required for clearing the alarm generated due
to cause 2.
None of the preceding Perform the operations required when the alarm is
occur generated due to cause 2.
----End
Related Information
If the RSBBE, RSES, RSSES, RSCSES, or RSUAS performance events exceed the preset
threshold, the RS_CROSSTR alarm is generated.
RSES 50 20 100
RSSES 20 0 50
RSUAS 20 0 50
9.214 S1_SYN_CHANGE
Description
The S1_SYN_CHANGE is an alarm indicating that, in the S1 byte mode, the clock source is
switched. This alarm occurs when, in the SSM mode, the traced clock source is switched.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Possible Causes
The possible causes of the S1_SYN_CHANGE alarm are as follows:
l There is a fiber cut.
l The external BITS is interrupted.
l The S1_SYN_CHANGE alarm occurs at the upstream station.
Procedure
Step 1 Check whether there is any fiber cut and whether any service board reports the R_LOS alarm.
If yes, properly connect the fiber to clear the R_LOS alarm, and then check whether the
S1_SYN_CHANGE alarm is cleared.
Step 2 If fiber connections are normal, check the external BITS.
1. Check whether the input cable of the external BITS is damaged. If yes, connect a good
input cable, and then check whether the S1_SYN_CHANGE alarm is cleared.
2. Make sure that the 2 Mbit/s cable interface for the external BITS input is properly
secured on the front panel of the subrack. Check whether the S1_SYN_CHANGE alarm
is cleared.
3. Check whether the 2 Mbit/s cable interface for the external BITS input is faulty. If yes,
replace the relevant interface board, and then check whether the S1_SYN_CHANGE
alarm is cleared.
Step 3 If the alarm persists, check whether the S1_SYN_CHANGE alarm occurs at the upstream
station. If yes, repeat steps 1 and 2 to clear the S1_SYN_CHANGE alarm at the upstream
station. The S1_SYN_CHANGE alarm at the local station is then automatically cleared.
----End
Related Information
None.
9.215 SECU_ALM
Description
The SECU_ALM is an alarm indicating that an illegal user fails to log in to the NE.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 4, Parameter 5 Indicates the first two characters of the user name that is locked
after the login verification fails.
Possible Causes
The cause for the SECU_ALM alarm is as follows:
Procedure
Step 1 Query the EN log to check the user name that is used for the login.
----End
Related Information
After a user fails to log in to an NE for five consecutive times (if the interval between two
logins is less than 3 minutes, the two logins are consecutive logins), the SECU_ALM alarm is
reported upon each subsequent login failure and meanwhile the user is locked for 900
seconds. During the 900 seconds, the user cannot log in to the NE.
9.216 SEC_RADIUS_FAIL
Description
The SEC_RADIUS_FAIL is an alarm indicating that the number of consecutive RADIUS
authentication failures is too great. This alarm occurs when the number of consecutive
RADIUS authentication failures reaches five. (If the interval between two RADIUS
authentication failures is less than 180 seconds, they are considered as consecutive RADIUS
authentication failures.)
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Possible Causes
The possible causes of the alarm are as follows:
l Cause 1: The usage period of the account expires.
l Cause 2: The password, access policy, or shared key of the account is changed.
l Cause 3: There are unauthenticated login attempts on the RADIUS server.
Procedure
Step 1 Cause 1: The usage period of the account expires.
1. Check whether the usage period of the account expires. If yes, use an account that is still
in its usage period.
2. Check whether the alarm clears. If the alarm persists, go to step Step 2.
Step 2 Cause 2: The password, access policy, or shared key of the account is changed.
1. Check whether the password or access policy of the account is changed on the RADIUS
server. If the password or access policy of the account is changed to a wrong value,
change it to a correct value. Check whether the alarm clears. If the alarm persists, go to
the next step.
2. Check whether the shared key for the GNE and the RADIUS server is set correctly. If the
shared key is set incorrectly, set it correctly.
3. Check whether the alarm clears. If the alarm persists, go to step Step 3.
Step 3 Cause 3: There are unauthenticated login attempts on the RADIUS server.
1. Check whether there are unauthenticated login attempts on the RADIUS server. If yes,
remove the source that generates unauthenticated login attempts.
2. Check whether the alarm clears. If the alarm persists, contact Huawei technical support
engineers for handling the alarm.
----End
Related Information
None.
9.217 SERVCHIP_ABN
Description
The SERVCHIP_ABN alarm indicates that a service chip fault is detected. A cross-connect
board reports this alarm when detecting a fault in its service chip or in the service chip of a
service board.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1 Indicates the slot ID of a faulty board. If this parameter takes the value of
0xFF, other faults occurred.
Parameter 2, Indicate the cause of the fault. Parameter 2 always takes the value of 0x00.
Parameter 3 Parameter 3 takes the following values.
When Parameter 1 indicates the slot ID of a service board;
l Parameter 3 takes the value of 0x01 to indicate that the service chip in
the receive direction of a service board is faulty.
l Parameter 3 takes the value of 0x02 to indicate that the service chip in
the transmit direction of a service board is faulty.
When Parameter 1 indicates the slot ID of a cross-connect board or takes the
value of 0xFF;
l Parameter 3 takes the value of 0x01 to indicate that the higher order
cross-connect chip is faulty.
l Parameter 3 takes the value of 0x02 to indicate that the higher order
cross-connect chip between the service board processing incoming
traffic and the lower order cross-connect chip is faulty.
l Parameter 3 takes the value of 0x04 to indicate that the higher order
cross-connect chip between the lower order cross-connect chip and the
service board processing outgoing traffic is faulty.
l Parameter 3 takes the value of 0x08 to indicate that the lower order
cross-connect chip is faulty.
NOTE
Figure 9-2 shows the values of Parameter 3 and their indications.
Possible Causes
The possible causes of the SERVCHIP_ABN alarm are as follows.
Procedure
Step 1 Query the SERVCHIP_ABN alarm on the NMS, and find the faulty board based on the value
of Parameter 1.
l When Parameter 1 indicates the slot ID of a service board, go to the next step.
l When Parameter 1 indicates the slot ID of a cross-connect board, go to Step 3.
l When Parameter 1 takes the value of 0xFF, go to Step 4.
Step 2 Cause 1: The service chip of a service board is faulty.
1. Replace the faulty service board.
2. Check whether the SERVCHIP_ABN alarm is cleared. If the SERVCHIP_ABN alarm
persists, contact Huawei technical support engineers to handle the alarm.
Step 3 Cause 2: The service chip of a cross-connect board is faulty.
1. Check whether Parameter 1 indicates a working or protection cross-connect board. If it is
a protection cross-connect board, replace the protection cross-connect board. If it is a
working cross-connect board, go to the next step.
2. Check whether the switching between the working and protection cross-connect boards
is triggered.
a. If yes, replace the working cross-connect board.
b. If no, manually perform the switching between the working and protection cross-
connect boards, and then replace the working cross-connect board. For details on
how to replace a working cross-connect board, see Replace a Cross-Connect and
Timing Board in the Parts Replacement manual.
3. Check whether the alarm is cleared. If the SERVCHIP_ABN alarm persists, contact
Huawei technical support engineers to handle the alarm.
Step 4 Cause 3: Other unknown fault occurred.
1. When Parameter 1 takes the value of 0xFF, the automatic switching between the working
and protection cross-connect boards may fail. To further locate the fault, perform the
manual switching between the working and protection cross-connect boards.
2. Find the faulty board based on the parameters of the SERVCHIP_ABN alarm.
a. If Parameter 1 indicates the slot ID of a service board, go to Step 2.
b. If Parameter 1 indicates the slot ID of a cross-connect board, go to Step 3.
c. If Parameter 1 takes the value of 0xFF, query the services section by section. Find
the service interruption point, and replace the service board on which the service
interruption point resides.
3. Check whether the alarm is cleared. If the SERVCHIP_ABN alarm persists, contact
Huawei technical support engineers to handle the alarm.
----End
Related Information
Service chip
A service chip can be the board chip on a board processing incoming traffic, cross-connect
board, or service board processing outgoing traffic.
Figure 9-2 shows the service chips of the line boards (service boards) and cross-connect
board, as well as the indications of the parameter values.
Chip fault in the receive Chip fault in the transmit Chip fault in the receive Chip fault in the transmit
direction of a service board direction of a service board Parameter 3 = 0x02 Parameter 3 = 0x08 Parameter 3 = 0x04 direction of a service board direction of a service board
(Parameter 3 = 0x01) (Parameter 3 = 0x02) (Parameter 3 = 0x01) (Parameter 3 = 0x02)
Parameter 3 = 0x01
: lower order service flow
: higher order service flow
9.218 SM_BDI
Description
The SM_BDI is an SM back defect indication at the optical transponder unit (OTU) layer.
This alarm shows that OTUs are provided at the remote end or severe alarms occur at an
upper layer.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Possible Causes
The possible causes of the SM_BDI alarm are as follows:
l Some alarms occur at the remote OTU termination station.
l The transmit unit at the local end is faulty.
l The receive unit at the remote end is faulty.
Procedure
Step 1 Check whether any other higher-level OTU alarm occurs at the remote OTU termination
station. If yes, take priority to clear it, and then check whether the SM_BDI alarm is cleared.
Step 2 If the alarm at the remote end persists, perform an inloop to the local optical interface. If the
SM_BDI occurs, check and modify the configuration.
NOTICE
The loopback causes service interruption.
Step 3 If the alarm persists, replace the board at the local station.
Step 4 If the alarm at the remote end persists and if the inloop is normally performed to the local
optical station, replace the board at the remote end.
----End
Related Information
None.
9.219 SM_BEI
Description
The SM_BEI is an SM back error indication alarm at the optical transponder unit (OTU)
layer. This alarm shows that SM-BIP errors occur at the remote end.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Possible Causes
The possible causes of the SM_BEI alarm are as follows:
Procedure
Step 1 Query the performance of the board at the remote OTU termination station, and clear the bit
errors at the remote end.
----End
Related Information
None.
9.220 SM_BIP8_OVER
Description
The SM_BIP8_OVER is an alarm indicating that the number of bit errors in the OTU SM
section crosses the threshold.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Possible Causes
The possible causes of the SM_BIP8_OVER alarm are as follows:
l The received signals are heavily attenuated.
l The fiber connector is dirty.
l The connector is incorrectly connected.
l The receive unit at the local station is faulty.
l The transmit unit at the opposite station is faulty.
Procedure
Step 1 Check whether any higher-level alarm, such as the R_LOS or R_LOF, is detected on the
U2000. If yes, take priority to clear it, and then check whether the SM_BIP8_OVER alarm is
cleared.
Step 2 Check whether the received optical power of the alarm board is within the specified value
range. If yes, go to step 9.
Step 3 Clean the fiber connector at the local station and the receive optical interface on the line
board, and then check whether the alarm is cleared.
Step 4 Check whether the flange is correctly connected to the optical attenuator at the local station,
and whether the attenuation value specified in the optical attenuator is proper. After making
sure that the flange and optical attenuator are used properly, check whether the alarm is
cleared.
Step 5 Check whether the launched optical power at the opposite station is within the specified value
range. If not, replace the line board.
Step 6 If the launched optical power is within the specified value range, clean the fiber connector at
the opposite station, and then check whether the alarm is cleared.
Step 7 Check whether the flange is correctly connected to the optical attenuator at the opposite
station, and whether the attenuation value specified in the optical attenuator is proper. After
making sure that the flange and optical attenuator are used properly, check whether the alarm
is cleared.
Step 8 Check whether the fiber cable is faulty. If yes, remove the fault, and then check whether the
alarm is cleared.
Step 9 Replace the line board that reports the alarm at the local station, and then check whether the
alarm is cleared.
Step 10 Replace the cross-connect and timing board at the local station, and then check whether the
alarm is cleared.
Step 11 Replace the line board at the opposite station, and then check whether the alarm is cleared.
Step 12 Replace the cross-connect and timing board at the opposite station, and then check whether
the alarm is cleared.
----End
Related Information
None.
9.221 SM_BIP8_SD
Description
The SM_BIP8_SD is an SM BIP error signal degrade alarm in the OTU SM section.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Possible Causes
The possible causes of the SM_BIP8_SD alarm are as follows:
l The received signals are heavily attenuated.
l The fiber connector is dirty.
l The connector is incorrectly connected.
l The receive unit at the local station is faulty.
l The transmit unit at the opposite station is faulty.
Procedure
Step 1 Check whether any higher-level alarm, such as the R_LOS or R_LOF, is detected on the
U2000. If yes, take priority to clear it, and then check whether the SM_BIP8_SD alarm is
cleared.
Step 2 Check whether the received optical power of the alarm board is within the specified value
range. If yes, go to Step 9.
Step 3 Clean the fiber connector at the local station and the receive optical interface on the line
board, and then check whether the alarm is cleared.
Step 4 Check whether the flange is correctly connected to the optical attenuator at the local station,
and whether the attenuation value specified in the optical attenuator is proper. After making
sure that the flange and optical attenuator are used properly, check whether the alarm is
cleared.
Step 5 Check whether the launched optical power at the opposite station is within the specified value
range. If not, replace the line board.
Step 6 If the launched optical power is within the specified value range, clean the fiber connector at
the opposite station, and then check whether the alarm is cleared.
Step 7 Check whether the flange is correctly connected to the optical attenuator at the opposite
station, and whether the attenuation value specified in the optical attenuator is proper. After
making sure that the flange and optical attenuator are used properly, check whether the alarm
is cleared.
Step 8 Check whether the fiber cable is faulty. If yes, remove the fault, and then check whether the
alarm is cleared.
Step 9 Replace the line board that reports the alarm at the local station, and then check whether the
alarm is cleared.
Step 10 Replace the cross-connect and timing board at the local station, and then check whether the
alarm is cleared.
Step 11 Replace the line board at the opposite station, and then check whether the alarm is cleared.
Step 12 Replace the cross-connect and timing board at the opposite station, and then check whether
the alarm is cleared.
----End
Related Information
None.
9.222 SM_IAE
Description
The SM_IAE is an SM incoming alignment error (IAE) alarm in the OTU SM section. When
the ODU frame is synchronously mapped into the OTU frame, the IAE flag is set to true if the
frame alignment errors occur. When the IAE errors are detected at the sink, the sub-frame
alignment bit errors occur in the received services.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Possible Causes
The possible causes of the SM_IAE alarm are as follows:
l The clock jitter event occurs in the transmit unit at the remote end (namely, the source of
the OTU/ODU adaptation function).
l The frame offset on the board termination side of the remote end (namely, the source of
the OTU/ODU adaptation function) is inaccurate.
l The board FEC processing chip at the remote end (namely, the source of the OTU/ODU
adaptation function) is faulty.
Procedure
Step 1 Adjust the frame offset on the board system side of the remote end (namely, the source of the
OTU/ODU adaptation function).
Step 2 If the alarm persists, replace the board at the remote end (namely, the source of the
OTU/ODU adaptation function).
----End
Related Information
None.
9.223 SM_TIM
Description
The SM_TIM is a section monitoring TTI mismatch alarm in the OTU SM overhead.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Possible Causes
The possible causes of the SM_TIM alarm are as follows:
Procedure
Step 1 According to the service network, decide the expected setting of the SM_TTI byte in the
relevant position.
Step 2 Check whether the SM-TTI byte to be received at the board is consistent with the received
SM-TTI byte. If not, modify the incorrect SM-TTI byte to be received.
Step 3 If the received SM-TTI byte is incorrect, check whether the fiber connection at the next local
station is correct. If not, modify the connection.
Step 4 Check whether the setting of the transmitted SM-TTI byte in the upstream services is correct.
If not, modify the transmitted SM-TTI byte in the upstream services.
----End
Related Information
None.
9.224 SPARE_PATH_ALM
Description
The SPARE_PATH_ALM is an alarm of the standby path. For a protection board, if the
standby path that is not configured with services is faulty, the SPARE_PATH_ALM alarm is
reported.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1 Indicates the actual optical interface number of the alarm board.
l For the tributary boards, the value is always 0x01.
l Indicates the actual optical interface number of the line board.
Possible Causes
The possible cause of the SPARE_PATH_ALM alarm is as follows:
Procedure
Step 1 View the SPARE_PATH_ALM alarm on the U2000 to confirm the relevant board.
----End
Related Information
None.
9.225 SPEED_OVER
Description
The SPEED_OVER is an alarm indicating that the rate of the monitored optical interface
exceeds the rate threshold. This alarm occurs when a board detects that the received rate
exceeds the set rate alarm threshold.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Possible Causes
The possible cause of the SPEED_OVER alarm is as follows:
Procedure
Step 1 View the SPEED_OVER alarm on the U2000, and then confirm the relevant optical interface
according to the alarm parameters.
Step 2 Query the rate that the optical interface actually receives and the rate threshold. Set a larger
rate threshold according to the rate range that the board supports, and then check whether the
alarm is cleared.
Step 3 If the alarm persists, check the rate configured for the service. Re-configure the service rate to
a value that is within the threshold. The alarm is automatically cleared.
----End
Related Information
None.
9.226 SQUTABM_MM
Description
The SQUTABM_MM is an alarm indicating that the squelch table generation mode at each
node on the MSP ring differs.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Possible Causes
The possible causes of the SQUTABM_MM alarm are as follows:
l An NE may be added. This NE may be added when the entire ring is in the manual
mode. The default setting of a new NE, however, is the automatic mode. If the default
setting of the new NE is not changed, it is different from those of other NEs on the ring.
l The mode of an NE is changed, and then the modes of all the other NEs on the entire
ring are automatically changed. After the mode change, all the NEs are stored to the
database. But if the SCC board is powered off before the updated database is backed up
to the FLASH, the mode of this NE is different with others after the SCC is reset.
l The fiber connection may be faulty during the mode change. In this case, the mode
change message cannot be set to a certain node. Thus, the modes of all the NEs cannot
be automatically changed. If the NE SCC is reset in this process, the mode of this NE is
different from those of other NEs on the ring. In this case, the RINGMAPM_MM alarm
occurs.
Procedure
Step 1 Check whether the generation modes of the squelch tables for all the nodes on the MS ring are
the same. If not, change the modes to be the same.
----End
Related Information
Squelch Table Generation Mode
A squelch table can be generated either in the automatic mode or in the manual mode. The
modes of all the NEs on the ring must be the same. In normal cases, change of an NE mode
results in automatic change of the modes of the other NEs.
9.227 SSL_CERT_NOENC
Description
The SSL_CERT_NOENC alarm indicates that the Secure Sockets Layer (SSL) certificate file
is not encrypted.
Attribute
Parameters
None
Possible Causes
The possible cause of the SSL_CERT_NOENC alarm is as follows:
Procedure
Step 1 Download and activate the SSL encryption certificate file.
----End
Related Information
None
9.228 STORM_CUR_QUENUM_OVER
Description
The STORM_CUR_QUENUM_OVER is an alarm indicating the storm. When the number of
current alarms on the NE reaches the value that is equal to the maximum number of alarms
supported by an alarm queue minus one, the alarm is reported. The alarm cannot be wrapped
around by other alarms on the NE.
Attribute
Parameters
None.
Possible Causes
The possible cause of the STORM_CUR_QUENUM_OVER alarm is as follows:
The count of the alarms is excessive and thus the alarm queue cannot contain all alarms.
Procedure
Step 1 Check the queue of the current alarms on the U2000. Identify and clear the frequently
reported alarms (STORM_CUR_QUENUM_OVER excluded). If the count of alarms in the
alarm queue is decreased to a certain value, the alarm is cleared automatically.
----End
Related Information
Alarm Storage
The NE register stores the alarm data by "Stopping" and "Wrapping". The NE uses the
"Wrapping" mode by default.
l When the storage mode is "Stopping", if the count of the alarms reaches the capacity
threshold of the register, the new alarm data is discarded.
l When the alarm storage mode is "Wrapping", if the count of the NE alarms reaches the
capacity threshold, the new alarms overwrite the earlier alarm information, and the new
alarms are stored from the start address of the register.
9.229 SUM_INPWR_HI
Description
The SUM_INPWR_HI is an alarm indicating that the combined input optical power of the
laser of the colored optical module is over high.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1 Indicates the actual optical interface number of the board that
generates the alarm.
For example, 0x01 indicates that the alarm is reported from optical
interface 1 of the board.
Parameter 2, Indicates the path number. The value depends on different board
Parameter 3 types. Parameter 2 is the higher byte, and Parameter 3 is the lower
byte.
Possible Causes
The possible causes of the SUM_INPWR_HI alarm are the same as those of the
IN_PWR_HIGH alarm.
Procedure
Step 1 Refer to the procedure for handling the IN_PWR_HIGH alarm.
----End
Related Information
None.
9.230 SUM_INPWR_LOW
Description
The SUM_INPWR_LOW is an alarm indicating that the combined input optical power of the
laser of the colored optical module is over low.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1 Indicates the actual optical interface number of the board that reports
the alarm.
For example, 0x01 indicates that the alarm is reported from optical
interface 1 of the board.
Parameter 2, Indicates the path number. The value depends on different board
Parameter 3 types. Parameter 2 is the higher byte, and Parameter 3 is the lower
byte.
Possible Causes
The possible causes of the SUM_INPWR_LOW alarm are the same as those of the
IN_PWR_LOW alarm.
Procedure
Step 1 Refer to the procedure for handling the IN_PWR_LOW alarm.
----End
Related Information
None.
9.231 SUM_OUTPWR_HI
Description
The SUM_OUTPWR_HI is an alarm indicating that the combined output power of the laser
of the colored optical module is over high.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1 Indicates the actual optical interface number of the board that
generates the alarm.
For example, 0x01 indicates that the alarm is reported from optical
interface 1 of the board.
Name Meaning
Parameter 2, Indicates the path number. The value depends on different board
Parameter 3 types. Parameter 2 is the higher byte, and Parameter 3 is the lower
byte.
Possible Causes
The possible causes of the SUM_OUTPWR_HI alarm are the same as those of the
OUT_PWR_HIGH alarm.
Procedure
Step 1 Refer to the procedure for handling the OUT_PWR_HIGH alarm.
----End
Related Information
None.
9.232 SUM_OUTPWR_LOW
Description
The SUM_OUTPWR_LOW is an alarm indicating that the combined output power of the
laser of the colored optical module is over low.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1 Indicates the actual optical interface number of the board that
generates the alarm.
For example, 0x01 indicates that the alarm is reported from optical
interface 1 of the board.
Parameter 2, Indicates the path number. The value depends on different board
Parameter 3 types. Parameter 2 is the higher byte, and Parameter 3 is the lower
byte.
Possible Causes
The possible causes of the SUM_OUTPWR_LOW alarm are the same as those of the
OUT_PWR_LOW alarm.
Procedure
Step 1 Refer to the procedure for handling the OUT_PWR_LOW alarm.
----End
Related Information
None.
9.233 SWDL_ACTIVATED_TIMEOUT
Description
The SWDL_ACTIVATED_TIMEOUT is an alarm indicating that during package loading, the
NE does not perform the commit operation in a certain time after the board is activated.
Attribute
Alarm Severity Alarm Type
Parameters
None.
Possible Causes
The possible cause of the SWDL_ACTIVATED_TIMEOUT alarm is as follows:
During the 30 minutes after the board is activated, the NE does not perform commit.
Procedure
Step 1 Check this alarm on the NMS, and determine the NE that reports this alarm.
Step 2 In the NE Explorer of the alarmed NE, choose Alarm > Alarm Severity and Auto
Reporting from the Function Tree.
Step 3 In the right pane, right-click the Auto Reporting Status of this alarm and choose Not
Reported from the shortcut menu.
Step 5 In the right pane, right click the Status of this alarm and choose Suppressed from the
shortcut menu.
----End
Related Information
None.
9.234 SWDL_AUTOMATCH_INH
Description
The SWDL_AUTOMATCH_INH is an alarm indicating that the automatic match function is
disabled.
Attribute
Alarm Severity Alarm Type
Parameters
None.
Possible Causes
The possible cause of the SWDL_AUTOMATCH_INH alarm is as follows:
Procedure
Step 1 Check this alarm on the NMS, and determine the NE that reports this alarm.
Step 2 In the NE Explorer of the alarmed NE, choose Alarm > Alarm Severity and Auto
Reporting from the Function Tree.
Step 3 In the right pane, right-click the Auto Reporting Status of this alarm and choose Not
Reported from the shortcut menu.
Step 5 In the right pane, right click the Status of this alarm and choose Suppressed from the
shortcut menu.
----End
Related Information
None.
9.235 SWDL_CHGMNG_NOMATCH
Description
The SWDL_CHGMNG_NOMATCH is an alarm indicating that the software version of the
SCC board is inconsistent with the software version of the alarmed board. This alarm is
reported if the software version of the alarmed board is inconsistent with the software version
of the SCC board.
Attribute
Parameters
None.
The automatic matching function is disabled and the software versions of newly installed
boards cannot automatically match the software version of the SCC board. However, services
are not affected. This alarm is generated during the package loading and does not affect
services. It is recommended that you mask this alarm on the NMS.
Possible Causes
The possible cause of this alarm is as follows:
The software version of the SCC board does not match the software version of any other
boards.
Procedure
Step 1 Check this alarm on the NMS, and determine the NE that reports this alarm.
Step 2 In the NE Explorer of the alarmed NE, choose Alarm > Alarm Severity and Auto
Reporting from the Function Tree.
Step 3 In the right pane, right-click the Auto Reporting Status of this alarm and choose Not
Reported from the shortcut menu.
Step 5 In the right pane, right click the Status of this alarm and choose Suppressed from the
shortcut menu.
----End
Related Information
None.
9.236 SWDL_COMMIT_FAIL
Description
The SWDL_COMMIT_FAIL is an alarm indicating that the commit operation fails for some
boards.
Attribute
Alarm Severity Alarm Type
Parameters
None.
Possible Causes
The possible cause of the SWDL_COMMIT_FAIL is as follows:
Software copy from the standby partition to the active partition fails.
Procedure
Step 1 Check this alarm on the NMS, and determine the NE that reports this alarm.
Step 2 In the NE Explorer of the alarmed NE, choose Alarm > Alarm Severity and Auto
Reporting from the Function Tree.
Step 3 In the right pane, right-click the Auto Reporting Status of this alarm and choose Not
Reported from the shortcut menu.
Step 5 In the right pane, right click the Status of this alarm and choose Suppressed from the
shortcut menu.
----End
Related Information
None.
9.237 SWDL_INPROCESS
Description
The SWDL_INPROCESS is an alarm indicating that the NE is loading the package.
Attribute
Alarm Severity Alarm Type
Parameters
None.
Possible Causes
The possible cause of the SWDL_INPROCESS alarm is as follows:
Procedure
Step 1 Check this alarm on the NMS, and determine the NE that reports this alarm.
Step 2 In the NE Explorer of the alarmed NE, choose Alarm > Alarm Severity and Auto
Reporting from the Function Tree.
Step 3 In the right pane, right-click the Auto Reporting Status of this alarm and choose Not
Reported from the shortcut menu.
Step 5 In the right pane, right click the Status of this alarm and choose Suppressed from the
shortcut menu.
----End
Related Information
None.
9.238 SWDL_NEPKGCHECK
Description
The SWDL_NEPKGCHECK is an alarm indicating that a file in the package is lost or the
package loading fails to pass the check.
Attribute
Alarm Severity Alarm Type
Parameters
None.
Possible Causes
The possible cause of the SWDL_NEPKGCHECK alarm is as follows:
A file in the package is lost.
Procedure
Step 1 Check this alarm on the NMS, and determine the NE that reports this alarm.
Step 2 In the NE Explorer of the alarmed NE, choose Alarm > Alarm Severity and Auto
Reporting from the Function Tree.
Step 3 In the right pane, right-click the Auto Reporting Status of this alarm and choose Not
Reported from the shortcut menu.
Step 4 In the Function Tree, choose Alarm > NE Alarm Suppression.
Step 5 In the right pane, right click the Status of this alarm and choose Suppressed from the
shortcut menu.
Step 6 Click Apply. This alarm is masked on the NMS.
----End
Related Information
None.
9.239 SWDL_PKG_NOBDSOFT
Description
The SWDL_PKG_NOBDSOFT is an alarm indicating that the files of some boards are not in
the package for loading.
Attribute
Alarm Severity Alarm Type
Parameters
None.
Possible Causes
The possible cause of the SWDL_PKG_NOBDSOFT alarm is as follows:
The software of some boards are removed during loading the customized package.
Procedure
Step 1 Check this alarm on the NMS, and determine the NE that reports this alarm.
Step 2 In the NE Explorer of the alarmed NE, choose Alarm > Alarm Severity and Auto
Reporting from the Function Tree.
Step 3 In the right pane, right-click the Auto Reporting Status of this alarm and choose Not
Reported from the shortcut menu.
Step 5 In the right pane, right click the Status of this alarm and choose Suppressed from the
shortcut menu.
----End
Related Information
None.
9.240 SWITCH_DISABLE
Description
The SWITCH_DISABLE is an alarm indicating that the protection switching function is
manually disabled for the board. This alarm is used for internal test purposes.
Attribute
Parameters
None.
Possible Causes
During the test, a command is issued to request the board software to disable the switching
function.
Procedure
Step 1 Log in to the NE to cancel the switching disabling command. The SWITCH_DISABLE alarm
is cleared.
----End
Related Information
None.
9.241 SWDL_ROLLBACK_FAIL
Description
The SWDL_ROLLBACK_FAIL is an alarm indicating that some board rollback fails when
the NE performs rollback.
Attribute
Parameters
None.
Possible Causes
The possible cause of the SWDL_ROLLBACK_FAIL alarm is as follows:
Procedure
Step 1 Check this alarm on the NMS, and determine the NE that reports this alarm.
Step 2 In the NE Explorer of the alarmed NE, choose Alarm > Alarm Severity and Auto
Reporting from the Function Tree.
Step 3 In the right pane, right-click the Auto Reporting Status of this alarm and choose Not
Reported from the shortcut menu.
Step 5 In the right pane, right click the Status of this alarm and choose Suppressed from the
shortcut menu.
----End
Related Information
None.
9.242 SYNC_C_LOS
Description
The SYNC_C_LOS is an alarm indicating the loss of synchronization source level. This alarm
occurs when the clock source of a service board is lost in the priority table.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
Name Meaning
Parameter 1, Indicates the number of the faulty clock source. The ID of the time source
Parameter 2 occupies two bytes.
l Parameter 1 indicates the slot ID where the board is housed. The slot ID
starts from 1. If the value of Parameter 1 is 0xF0, it indicates the external
clock source (external clock source 1 and external clock source 2). If the
value of Parameter 1 is 0xF1, it indicates the internal clock source.
l Parameter 2 indicates the actual optical port ID on the board. The optical
port ID starts from 1. If the value of Parameter 2 is 0x01, it indicates
external clock source 1 and the internal clock source. If the value of
Parameter 2 is 0x02, it indicates external clock source 2.
Possible Causes
The possible causes of the SYNC_C_LOS alarm are as follows:
l Input signals are lost at the optical or electrical interface that is connected to the clock
source.
l There is a fiber cut (when a line clock source is traced).
Procedure
Step 1 On the U2000, view the line or tributary clock source traced by the NE.
NOTICE
If the services travel through the board are not configured with protection, the services
are interrupted after the cold reset of the board.
3. If the alarm persists, replace the relevant line board, and then check whether the alarm is
cleared.
4. If the alarm persists, perform a cold reset for the cross-connect and timing board, and
then check whether the alarm is cleared.
NOTICE
If there is not a standby cross-connect board that properly functions for protection, cold
reset of a cross-connect board may entirely interrupt the services.
NOTICE
If the services travel through the board are not configured with protection, the services
are interrupted after the cold reset of the board.
3. If the alarm persists, replace the relevant tributary board, and then check whether the
SYNC_C_LOS alarm is cleared.
4. If the alarm persists, perform a cold reset for the cross-connect and timing board, and
then check whether the alarm is cleared.
NOTICE
If there is not a standby cross-connect board that properly functions for protection, cold
reset of a cross-connect board may entirely interrupt the services.
----End
Related Information
NOTE
When an external clock source is lost, the EXT_SYNC_LOS alarm is reported, instead of the
SYNC_C_LOS alarm.
9.243 SYNC_F_M_SWITCH
Description
The SYNC_F_M_SWITCH is an alarm indicating the forced or manual switching state of a
clock source.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1, Indicates the number of the clock source that is in the forced or manual
Parameter 2 switching state. The ID of the time source occupies two bytes.
l Parameter 1 indicates the slot ID where the board is housed. The slot ID
starts from 1. If the value of Parameter 1 is 0xF0, it indicates the external
clock source (external clock source 1 and external clock source 2). If the
value of Parameter 1 is 0xF1, it indicates the internal clock source.
l Parameter 2 indicates the actual optical port ID on the board. The optical
port ID starts from 1. If the value of Parameter 2 is 0x01, it indicates
external clock source 1 and the internal clock source. If the value of
Parameter 2 is 0x02, it indicates external clock source 2.
Possible Causes
The possible cause of the SYNC_F_M_SWITCH alarm is as follows:
A manual or forced switching command is issued for the clock source.
Procedure
Step 1 View the SYNC_F_M_SWITCH alarm on the U2000, and then confirm the relevant clock
source according to the alarm parameters.
Step 2 Clear the manual or forced switching for the relevant clock source, and the alarm is
automatically cleared.
----End
Related Information
None.
9.244 SYNC_FAIL
Description
The SYNC_FAIL is an alarm indicating that the batch backup of the databases of the active
and standby SCC boards fails.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Possible Causes
The possible causes of the SYNC_FAIL are as follows:
l The software versions of the active and standby SCC boards are inconsistent.
l The communication fails during the batch backup of the databases of the active and
standby SCC boards.
l Message sending fails or the database is detected damaged during the batch backup of
the databases of the active and standby SCC boards.
Procedure
Step 1 When Parameter 1 is 0x20, it indicates that the software versions of the active and standby
SCC boards are inconsistent. Replace the SCC boards or re-load the NE software to make the
software versions of the active and standby SCC boards consistent.
Step 2 When Parameter 1 is 0x21, it indicates that the communication fails during the batch backup.
If the communication fails for a short time, the system automatically initiates another batch
backup. If the communication fails for a long time, contact Huawei engineers.
----End
Related Information
None.
9.245 SYNC_LOCKOFF
Description
The SYNC_LOCKOFF is an alarm indicating that the clock source in the priority list is
locked.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1, Indicates the number of the locked clock source. The ID of the time source
Parameter 2 occupies two bytes.
l Parameter 1 indicates the slot ID where the board is housed. The slot ID
starts from 1. If the value of Parameter 1 is 0xF0, it indicates the external
clock source (external clock source 1 and external clock source 2). If the
value of Parameter 1 is 0xF1, it indicates the internal clock source.
l Parameter 2 indicates the actual optical port ID on the board. The optical
port ID starts from 1. If the value of Parameter 2 is 0x01, it indicates
external clock source 1 and the internal clock source. If the value of
Parameter 2 is 0x02, it indicates external clock source 2.
Possible Causes
The possible cause of the SYNC_LOCKOFF alarm is as follows:
Procedure
Step 1 After the lockout of the clock source is released on the U2000, the SYNC_LOCKOFF alarm
is automatically cleared.
----End
Related Information
None.
9.246 SYSLOG_COMM_FAIL
Description
The SYSLOG_COMM_FAIL is an alarm indicating that the communication between the NE
and the syslog server fails.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Possible Causes
The possible cause of the SYSLOG_COMM_FAIL alarm is as follows:
In the TCP mode, the connection between the NE and syslog server is interrupted, or the
session between the NE and server is abnormal.
Procedure
Step 1 Rectify the fault of the link between the NE and syslog server, or rectify the fault of the
protocol.
----End
Related Information
None.
9.247 T_ALOS
Description
The T_ALOS is an alarm indicating the loss of analog signals at the E1 or T1 interfaces. If no
service signals are input at the 2 Mbit/s or 1.5 Mbit/s port, the T_ALOS alarm is reported.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 2, Indicates the path number. Parameter 2 is the higher byte, and
Parameter 3 Parameter 3 is the lower byte.
For example, Parameter 2 = 0x00, Parameter 3= 0x01. In this case, the
T_ALOS alarm is reported from path 1 of the board.
Possible Causes
The possible causes of the T_ALOS alarm are as follows:
Procedure
Step 1 View the T_ALOS alarm on the U2000 to confirm the relevant board.
Step 2 Check whether the E1 or T1 services in the relevant path of the board are accessed. After
making sure that the services are accessed, check whether the T_ALOS alarm is cleared. If the
alarm persists, go to the next step.
Step 3 If the alarm persists, perform service self-loop (namely, hardware inloop) to the path at the
DDF.
NOTICE
The loopback causes service interruption.
l If the alarm is cleared, the equipment at the opposite end is faulty. After removing the
fault, check whether the T_ALOS alarm is cleared.
l If the alarm persists, go to the next step.
Step 4 Perform self-loop (namely, hardware inloop) to the path at the interface board.
NOTICE
The loopback causes service interruption.
l If the alarm is cleared, the signal cable connection is faulty. After removing the faulty
connection, check whether the T_ALOS alarm is cleared.
l If the alarm persists, go to the next step.
NOTICE
The loopback causes service interruption.
l If the alarm is cleared, the interface board is faulty. Remove the interface board and
insert it again, or replace the interface board. Then check whether the T_ALOS is
cleared.
l If the alarm persists, go to the next step.
Step 6 If the alarm persists, replace the board that reports the alarm.
Step 7 If the alarm persists, check whether the equipment at the opposite station is faulty. If yes,
replace the faulty board of the opposite station.
----End
Related Information
None.
9.248 T_FIFO_E
Description
The T_FIFO_E is an alarm indicating that the transmitted FIFO messages overflow.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Possible Causes
The possible causes of the T_FIFO_E alarm are as follows:
Procedure
Step 1 Check whether the service cross-connections are correctly configured for the NE at which the
alarm occurs. After modifying the incorrect configuration, check whether the alarm is cleared.
Step 2 If the alarm persists, check whether the services accessed to the board are correct. After
making sure that the accessed services are correct, check whether the alarm is cleared.
----End
Related Information
None.
9.249 T_LOC
Description
The T_LOC is an alarm indicating that there is no clock on the transmit line side. This alarm
occurs if there is no clock on the line side of a board when a service is being transmitted.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1 Indicates the actual number of the optical interface on a board where
the alarm occurs.
For example, 0x01 indicates that the alarm is reported from optical
interface 1 of the board.
Possible Causes
The possible cause of the T_LOC alarm is as follows:
The cross-connect and timing board is faulty or offline, which causes no clock on the receive
line side.
Procedure
Step 1 View the T_LOC alarm on the U2000, and then confirm the relevant optical interface
according to the alarm parameters.
Step 2 Check the receive optical interface that corresponds to the transmit service of this optical
interface. Refer to the procedure for handling the R_LOC alarm to clear the T_LOC alarm.
----End
Related Information
None.
9.250 T_LOS
Description
The T_LOS is an alarm indicating the loss of input signal at the line side in the transmit
direction. This alarm occurs when no optical signal is detected at the line side in the transmit
direction.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1 l For the EFS0 board, the value is always 0x01, and this parameter is
meaningless.
l For the EFS4 board, the value is always 0x01, and this parameter is
meaningless.
l For the EGS2 board, the value indicates the port number of the board
that generates the alarm. The value range is 0x01 - 0x02.
Parameter 2, Indicates the port number of the board that generates the alarm. Parameter 2
Parameter 3 is always 0x00, and the value range of Parameter 3 depends on different
board types.
l For the EFS0 board, the value range is 0x01 - 0x08 (1 - 8).
l For the EFS4 board, the value range is 0x01 - 0x04 (1 - 4).
l For the EGS2 board, it does not have this parameter.
Possible Causes
The possible causes of the T_LOS alarm are as follows:
Procedure
Step 1 View the T_LOS alarm on the U2000 to confirm the relevant board. According to Parameter 1
or Parameter 2 together with Parameter 3, confirm the specific port number of the board.
Step 2 Check whether the cross-connect board is installed in the equipment or is loose. After you
make sure that the cross-connect board is installed well, check whether the alarm is cleared.
Step 3 If the alarm persists, check whether the corresponding line board is loose. After you make
sure that the line board is installed well, check whether the alarm is cleared.
Step 4 If the alarm persists, check whether the line board is faulty. If yes, replace the line board and
then check whether the alarm is cleared.
Step 5 If the alarm persists, check whether the service board is loose. After you make sure that the
service board is installed well, check whether the alarm is cleared.
Step 6 If the alarm persists, check whether the service board is faulty. If yes, replace the service
board and then check whether the alarm is cleared.
Step 7 If the alarm persists, it is probable that the clock of the active and standby cross-connect
boards fails or is of poor quality. Replace the active and standby cross-connect boards.
----End
Related Information
None.
9.251 TC_DEG
Description
The TC_DEG is a degraded signal indication in the tandem connection. If the number of B3
bit errors in the tandem connection monitoring section exceeds the specified TC_DEG
threshold value, the TC_DEG alarm is reported.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Possible Causes
The possible causes of the TC_DEG alarm are as follows:
l A higher-level bit error alarm occurs at either the TCM source or the TCM sink.
l The received signals are heavily attenuated.
l The fiber connector is dirty.
l The fiber connector is loose.
l The receive unit at the sink end is faulty.
l The transmit unit at the source end is faulty.
Procedure
Step 1 Check whether any higher-level bit error alarm, such as the B1_EXC, B2_EXC, B3_EXC,
B1_SD, B2_SD or B3_SD alarm, is detected at the source and the sink. If yes, take priority to
clear it. Moreover, clean the fiber connector, and make sure the fiber connector is inserted
firmly. Then check whether the TC_DEG alarm at the local station is cleared.
Step 2 If the alarm persists, check whether the transmit board at the source is faulty. If yes, perform a
cold reset on the transmit board, and then check whether the alarm is cleared.
NOTICE
If the services travel through the board are not configured with protection, the services are
interrupted after the cold reset of the board.
Step 3 If the alarm persists, replace the relevant line board at the source, and then check whether the
alarm is cleared.
Step 4 If the alarm persists, check whether the receive board at the sink is faulty. If yes, perform a
cold reset on the receive board, and then check whether the alarm is cleared.
NOTICE
If the services travel through the board are not configured with protection, the services are
interrupted after the cold reset of the board.
Step 5 If the alarm persists, replace the line board that generates the alarm at the sink, and then check
whether the alarm is cleared.
Step 6 If the alarm persists, possibly the performance of other carrier networks is degraded. In this
case, ask the relevant carrier for the solution.
----End
Related Information
None.
9.252 TC_EXC
Description
The TC_EXC is an excessive error indication in the tandem connection. When the number of
B3 bit errors in the tadem connection monitoring section exceeds the specified threshold
value, the TC_EXC alarm is reported.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Possible Causes
The possible causes of the TC_EXC alarm are as follows:
l A higher-level bit error alarm occurs at either the TCM source or the TCM sink.
l The received signals are heavily attenuated.
l The fiber connector is dirty.
l The fiber connector is loose.
l The receive unit at the sink is faulty.
l The transmit unit at the source is faulty.
l The performance of the other inevitable carrier networks is degraded.
Procedure
Step 1 Check whether any higher-level bit error alarm, such as the B1_EXC, B2_EXC, B3_EXC,
B1_SD, B2_SD or B3_SD alarm, is detected at the TCM source and the TCM sink. If yes,
take priority to clear it. Moreover, clean the fiber connector, and make sure the fiber connector
is inserted firmly. Then check whether the TC_EXC alarm at the local station is cleared.
Step 2 If the alarm persists, check whether the receive board at the sink is faulty. If yes, perform a
cold reset on the board that reports the alarm at the sink, and then check whether the alarm is
cleared.
NOTICE
If the services travel through the board are not configured with protection, the services are
interrupted after the cold reset of the board.
Step 3 If the alarm persists, replace the line board that generates the alarm, and then check whether
the alarm is cleared.
Step 4 If the alarm persists, check whether the transmit board at the source is faulty. If yes, perform a
cold reset on the relevant line board at the source end, and then check whether the alarm is
cleared.
NOTICE
If the services travel through the board are not configured with protection, the services are
interrupted after the cold reset of the board.
Step 5 If the alarm persists, replace the relevant line board at the source, and then check whether the
alarm is cleared.
Step 6 If the alarm persists, possibly the performance of other inevitable carrier networks is
degraded. In this case, ask the relevant carrier for the solution.
----End
Related Information
None.
9.253 TC_INCAIS
Description
The TC_INCAIS is an incoming AIS indication in the tandem connection. When the four
higher significant IEC bits of the N1 byte in five frames consecutively received at the TCM
sink are 1110, the TC_INCAIS alarm occurs.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Name Meaning
Possible Causes
The possible causes of the TC_INCAIS alarm are as follows:
Procedure
Step 1 Check whether any alarm, such as the R_LOS, R_LOF, MS_AIS, AU_AIS or AU_LOP,
occurs at the TCM source. If yes, clear it, and then check whether the TC_INCAIS alarm is
cleared.
Step 2 If the alarm persists, check whether the service configuration is correct. If the service level is
incorrectly configured, modify the incorrect configuration, and then check whether the
TC_INCAIS alarm is cleared.
Step 3 If the alarm persists, check whether the TCM source and sink fully support the TCM Option2
function. If not, replace the relevant board with a board that fully supports the TCM Option2
function.
Step 4 If the alarm persists, check whether the transmit board at the source is faulty. If yes, perform a
cold reset on the transmit board, and then check whether the alarm is cleared.
NOTICE
If the services travel through the board are not configured with protection, the services are
interrupted after the cold reset of the board.
Step 5 If the alarm persists, replace the relevant line board at the source, and then check whether the
alarm is cleared.
Step 6 If the alarm persists, check whether the receive board at the sink is faulty. If yes, perform a
cold reset on the line board that reports the alarm at the sink, and then check whether the
alarm is cleared.
NOTICE
If the services travel through the board are not configured with protection, the services are
interrupted after the cold reset of the board.
Step 7 If the alarm persists, replace the line board that generates the alarm at the sink, and then check
whether the alarm is cleared.
----End
Related Information
TCM Option2
TCM is provided with two protocols: TCM Option1 and TCM Option2. The products of
Huawei support the protocol TCM Option2. For details, refer to ITU-T G.707/Y.1322.
9.254 TC_LTC
Description
The TC_LTC is an alarm indicating loss of tandem connection. When the TCM sink fails to
locate the frame header of multiplex frame 76, the TC_LTC alarm is reported.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Name Meaning
Possible Causes
The possible causes of the TC_LTC alarm are as follows:
l Some higher-level alarms are received at the TCM source or sink.
l The services are incorrectly configured.
l The TCM source or sink employs the board that does not fully support the TCM Option2
function.
l The transmit unit at the source is faulty.
l The receive unit at the sink is faulty.
Procedure
Step 1 Check whether any higher-level bit error alarm, such as the B1_EXC, B2_EXC, B3_EXC,
B1_SD, B2_SD or B3_SD alarm, is detected at the source and the sink. If yes, take priority to
clear it. Moreover, clean the fiber connector, and make sure the fiber connector is inserted
firmly. Then check whether the TC_LTC alarm at the local station is cleared.
Step 2 If the alarm persists, check whether the service configuration is correct. If the service level is
incorrectly configured, modify the incorrect configuration, and then check whether the
TC_LTC alarm is cleared.
Step 3 If the alarm persists, check whether the TCM source and sink fully support the TCM Option2
function. If not, replace the relevant board with a board that fully supports the TCM Option2
function.
Step 4 If the alarm persists, check whether the transmit board at the source is faulty. If yes, perform a
cold reset on the relevant line board, and then check whether the alarm is cleared.
NOTICE
If the services travel through the board are not configured with protection, the services are
interrupted after the cold reset of the board.
Step 5 If the alarm persists, replace the relevant line board at the source, and then check whether the
alarm is cleared.
Step 6 If the alarm persists, check whether the receive board at the sink is faulty. If yes, perform a
cold reset on the line board that reports the alarm, and then check whether the alarm is
cleared.
NOTICE
If the services travel through the board are not configured with protection, the services are
interrupted after the cold reset of the board.
Step 7 If the alarm persists, replace the line board that generates the alarm at the sink, and then check
whether the alarm is cleared.
----End
Related Information
For boards with the TCM function, refer to the Hardware Description.
9.255 TC_ODI
Description
The TC_ODI is an outgoing defect indication in the tandem connection. When the TCM sink
consecutively receives five frames, which contain the N1 byte, showing the TC_ODI
indication (bit 7 of the 74th frame is 1), the TC_ODI alarm is reported.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1 Indicates the actual optical interface number of the alarm board.
Name Meaning
Possible Causes
The possible cause of the TC_ODI alarm is as follows:
The TC_ODI alarm is an accompanying alarm. When the TCM sink generates an alarm, such
as the TC_UNEQ, TC_TIM, TC_LTC or TC_INCAIS, it returns a TC_ODI alarm to the TCM
source.
Procedure
Step 1 After you clear the TC_UNEQ, TC_TIM, TC_LTC or TC_INCAIS alarm that occurs at the
TCM sink, the TC_ODI alarm is automatically cleared.
----End
Related Information
None.
9.256 TC_OEI
Description
The TC_OEI is an outgoing error indication in the tandem connection. When the accumulated
number of tandem connection output errors received at the sink within one second is greater
than 0, the TC_OEI alarm is reported.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
Name Meaning
Possible Causes
The possible cause of the TC_OEI alarm is as follows:
Some bit errors occur in the signals output from the TCM sink.
Procedure
Step 1 Check whether any higher-level bit error alarm, such as the B1_EXC, B2_EXC, B3_EXC,
B1_SD, B2_SD or B3_SD alarm, is detected at the source and the sink. If yes, take priority to
clear it. Moreover, clean the fiber connector, and make sure the fiber connector is inserted
firmly. Then check whether the TC_OEI alarm at the local station is cleared.
Step 2 If the alarm persists, check whether the transmit board at the source is faulty. If yes, perform a
cold reset on the relevant line board, and then check whether the alarm is cleared.
NOTICE
If the services travel through the board are not configured with protection, the services are
interrupted after the cold reset of the board.
Step 3 If the alarm persists, replace the relevant line board at the source, and then check whether the
alarm is cleared.
Step 4 If the alarm persists, check whether the receive board at the sink is faulty. If yes, perform a
cold reset on the board that reports the alarm, and then check whether the alarm is cleared.
NOTICE
If the services travel through the board are not configured with protection, the services are
interrupted after the cold reset of the board.
Step 5 If the alarm persists, replace the line board that generates the alarm at the sink, and then check
whether the alarm is cleared.
Step 6 If the alarm persists, possibly the performance of other inevitable carrier networks is
degraded. In this case, ask the relevant carrier for the solution.
----End
Related Information
None.
9.257 TC_RDI
Description
The TC_RDI is a remote defect indication in the tandem connection. When the TCM sink
consecutively receives five frames, which contain the N1 byte, showing the TC_RDI
indication (bit 8 of the 73rd frame is 1), the TC_RDI alarm is reported.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Possible Causes
The possible cause of the TC_RDI alarm is as follows:
The TC_RDI alarm is an accompanying alarm. When a line board at the TCM sink reports the
TC_UNEQ, TC_TIM or TC_LTC alarm, it returns a TC_RDI alarm to the TCM source.
Procedure
Step 1 After you clear the TC_UNEQ, TC_TIM or TC_LTC alarm that occurs at the TCM sink, the
TC_RDI alarm is automatically cleared.
----End
Related Information
None.
9.258 TC_REI
Description
The TC_REI is a remote error indication in the tandem connection. When the accumulated
number of tandem connection remote bit errors received at the sink within one second is
greater than 0, the TC_REI alarm is reported.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Possible Causes
The possible cause of the TC_REI alarm is as follows:
Bit errors occur in the monitored tandem connection section.
Procedure
Step 1 Check whether any higher-level bit error alarm, such as the B1_EXC, B2_EXC, B3_EXC,
B1_SD, B2_SD or B3_SD alarm, is detected at the source and the sink. If yes, take priority to
clear it. Moreover, clean the fiber connector, and make sure the fiber connector is inserted
firmly. Then check whether the TC_REI alarm at the local station is cleared.
Step 2 If the alarm persists, check whether the transmit board at the source is faulty. If yes, perform a
cold reset on the relevant board, and then check whether the alarm is cleared.
NOTICE
If the services travel through the board are not configured with protection, the services are
interrupted after the cold reset of the board.
Step 3 If the alarm persists, replace the relevant line board at the source, and then check whether the
alarm is cleared.
Step 4 If the alarm persists, check whether the receive board at the sink is faulty. If yes, perform a
cold reset on the line board that reports the alarm, and then check whether the alarm is
cleared.
NOTICE
If the services travel through the board are not configured with protection, the services are
interrupted after the cold reset of the board.
Step 5 If the alarm persists, replace the line board that generates the alarm at the sink, and then check
whether the alarm is cleared.
Step 6 If the alarm persists, possibly the performance of other inevitable carrier networks is
degraded. In this case, ask the relevant carrier for the solution.
----End
Related Information
None.
9.259 TC_TIM
Description
The TC_TIM is a trace identifier mismatch alarm in the tandem connection. When the tandem
connection tracing byte received at the TCM sink does not match the expected byte, the
TC_TIM alarm occurs.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1 Indicates the actual optical interface number of the alarm board.
Possible Causes
The possible causes of the TC_TIM alarm are as follows:
Procedure
Step 1 Check whether any higher-level bit error alarm, such as the B1_EXC, B2_EXC, B3_EXC,
B1_SD, B2_SD or B3_SD alarm, is detected at the source and the sink. If yes, take priority to
clear it. Moreover, clean the fiber connector, and make sure the fiber connector is inserted
firmly. Then check whether the TC_TIM alarm at the local station is cleared.
Step 2 If the alarm persists, check whether the tandem tracing byte transmitted from the source line
board is consistent with the expected tandem tracing byte at the sink line board. If not, modify
it, and then check whether the alarm is cleared.
Step 3 If the alarm persists, check whether the service configuration is correct. After modifying the
incorrect configuration, check whether the TC_TIM alarm is cleared.
Step 4 If the alarm persists, check whether the TCM source and sink fully support the TCM Option2
function. If not, replace the relevant board with a board that fully supports the TCM Option2
function.
Step 5 If the alarm persists, check whether the transmit board at the source is faulty. If yes, perform a
cold reset on the relevant line board. Then check whether the alarm is cleared.
NOTICE
If the services travel through the board are not configured with protection, the services are
interrupted after the cold reset of the board.
Step 6 If the alarm persists, replace the relevant line board at the source, and then check whether the
alarm is cleared.
Step 7 If the alarm persists, check whether the receive board at the sink is faulty. If yes, perform a
cold reset on the line board that reports the alarm. Then check whether the alarm is cleared.
NOTICE
If the services travel through the board are not configured with protection, the services are
interrupted after the cold reset of the board.
Step 8 If the alarm persists, replace the line board that generates the alarm at the sink, and then check
whether the alarm is cleared.
Step 9 If the alarm persists, possibly the performance of other inevitable carrier networks is
degraded. In this case, ask the relevant carrier for the solution.
----End
Related Information
None.
9.260 TC_UNEQ
Description
The TC_UNEQ is an alarm indicating that no services are loaded to the tandem connection.
When the N1 byte is all "1"s in the five frames consecutively received at TCM sink, the
TC_UNEQ alarm is reported.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1 Indicates the actual optical interface number of the alarm board.
Possible Causes
The possible causes of the TC_UNEQ alarm are as follows:
l The service configuration is incorrect.
l The transmit unit at the source is faulty.
l The receive unit at the sink is faulty.
Procedure
Step 1 Check whether the service configuration is correct. If the service level is incorrectly
configured, modify the incorrect configuration, and then check whether the TC_UNEQ alarm
is cleared.
Step 2 If the alarm persists, check whether the transmit board at the source is faulty. If yes, perform a
cold reset on the relevant board, and then check whether the alarm is cleared.
NOTICE
If the services travel through the board are not configured with protection, the services are
interrupted after the cold reset of the board.
Step 3 If the alarm persists, replace the relevant line board at the source, and then check whether the
alarm is cleared.
Step 4 If the alarm persists, check whether the receive board at the sink is faulty. If yes, perform a
cold reset on the board that reports the alarm, and then check whether the alarm is cleared.
NOTICE
If the services travel through the board are not configured with protection, the services are
interrupted after the cold reset of the board.
Step 5 If the alarm persists, replace the line board that generates the alarm at the sink, and then check
whether the alarm is cleared.
----End
Related Information
None.
9.261 TD
Description
The TD is an alarm of laser transmission degradation. This alarm occurs when a board detects
that the output optical power or the bias current of the laser exceeds the threshold of
degradation alarm.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1 Indicates the actual number of the optical interface on a board where
the alarm occurs.
Parameter 2, Indicate the cause of the alarm for WDM boards. Parameter 2 is the
Parameter 3 higher byte, and Parameter 3 is the lower byte.
l 0x01: The output optical power exceeds the specified threshold.
l 0x02: The laser bias current exceeds the specified threshold.
The value is always 0x01 for data boards.
Possible Causes
The possible cause of the TD alarm is as follows:
Procedure
Step 1 View the TD alarm on the NMS, and then confirm the relevant optical interface according to
Parameter 1.
Step 2 If the optical module on the board is swappable, replace the optical module and then check
whether the alarm is cleared.
Step 3 If the optical module cannot be directly replaced, replace the board.
----End
Related Information
None.
9.262 TEM_HA
Description
The TEM_HA is an alarm indicating that the temperature of the laser is extremely high.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1 Indicates the actual optical interface number of the alarm board.
Parameter 2, Parameter 3 The value is always 0x01, and this parameter is meaningless.
Possible Causes
The possible causes of the TEM_HA alarm are as follows:
Procedure
Step 1 Check whether the ambient temperature in the equipment room is extremely high. If yes,
decrease it to a proper value for the equipment to work well, and then check whether the
TEM_HA alarm is cleared.
Step 2 If the alarm persists, the optical module may be faulty. Replace the board that generates the
alarm, and then check whether the TEM_HA alarm is cleared.
----End
Related Information
None.
9.263 TEM_LA
Description
The TEM_LA is an alarm indicating that the temperature of the laser is extremely low.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1 Indicates the actual optical interface number of the alarm board.
Parameter 2, Parameter 3 The value is always 0x01, and this parameter is meaningless.
Possible Causes
The possible causes of the TEM_LA alarm are as follows:
Procedure
Step 1 Check whether the ambient temperature in the equipment room is extremely low. If yes,
increase it to a proper value for the equipment to work well, and then check whether the
TEM_LA alarm is cleared.
Step 2 If the alarm persists, the optical module may be faulty. Replace the board that generates the
alarm, and then check whether the TEM_LA alarm is cleared.
----End
Related Information
None.
9.264 TEST_STATUS
Description
The TEST_STATUS is an alarm indicating that the board is in the test status.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1 Indicates the optical port ID. The value is always 0x01.
Parameter 2, Parameter 3 Indicates the path ID. The value is always 0x01.
Possible Causes
The possible cause of the TEST_STATUS alarm is as follows:
Procedure
Step 1 View the TEST_STATUS alarm on the U2000 to confirm the relevant board.
Step 2 When a command is issued to end the test status, the TEST_STATUS alarm is automatically
cleared. However, this does not eliminate the system impact that arose during the test status of
the board. To ensure that the commands issued during the test status no longer affect the
system, perform a cold reset for the board.
----End
Related Information
None.
9.265 TIME_LOS
Description
The TIME_LOS alarm indicates that the line time source is not available. This alarm is
reported only when the IEEE 1588v2 Time function is enabled and no time source exists.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1, Indicates the ID of the time source. The ID of the time source occupies two
Parameter 2 bytes.
l Parameter 1 indicates the slot ID where the board is housed. The slot ID
starts from 1. If the value of Parameter 1 is 0xF0, it indicates the external
clock source (external clock source 1 and external clock source 2). If the
value of Parameter 1 is 0xF1, it indicates the internal clock source.
l Parameter 2 indicates the actual optical port ID on the board. The optical
port ID starts from 1. If the value of Parameter 2 is 0x01, it indicates
external clock source 1 and the internal clock source. If the value of
Parameter 2 is 0x02, it indicates external clock source 2.
Possible Causes
The possible causes of the TIME_LOS alarm are as follows:
Procedure
Step 1 Check whether any alarms such as R_LOS and R_LOF are generated on the optical interface
of the board. If any alarms are generated, ensure that they are cleared immediately. Then,
check whether the TIME_LOS alarm is cleared.
Step 2 If the TIME_LOS alarm persists, check whether the fiber connector is dirty. If the fiber
connector is dirty, clean it. Then, check whether the alarm is cleared.
Step 3 If the TIME_LOS alarm persists, check whether the Ethernet cable is damaged or pressed. If
the Ethernet cable is damaged or pressed, replace the Ethernet cable. Then, check whether the
alarm is cleared.
Step 4 If the TIME_LOS alarm persists, check whether the board is in place on the NMS.
l If the board is not in place, place the board properly. Then, check whether the alarm is
cleared.
l If the physical board is in place but in the offline status, perform a warm reset on the
board. Then, check whether the alarm is cleared. If the alarm persists, perform a cold
reset on the board. Then, check whether the alarm is cleared.
----End
Related Information
None.
9.266 TIME_FORCE_SWITCH
Description
The TIME_FORCE_SWITCH alarm indicates that the time source is switched forcibly. This
alarm is reported when the IEEE 1588v2 Time function is enabled and an external switching
command is issued to switch the time source forcibly.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1, Indicates the ID of the time source. The ID of the time source occupies two
Parameter 2 bytes.
l Parameter 1 indicates the slot ID where the board is housed. The slot ID
starts from 1. If the value of Parameter 1 is 0xF0, it indicates the external
clock source (external clock source 1 and external clock source 2). If the
value of Parameter 1 is 0xF1, it indicates the internal clock source.
l Parameter 2 indicates the actual optical port ID on the board. The optical
port ID starts from 1. If the value of Parameter 2 is 0x01, it indicates
external clock source 1 and the internal clock source. If the value of
Parameter 2 is 0x02, it indicates external clock source 2.
Possible Causes
The possible cause of the TIME_FORCE_SWITCH alarm is as follows:
Procedure
Step 1 Clear the forced switching status on the NMS.
----End
Related Information
1. When the TIME_FORCE_SWITCH alarm is generated, the clock source used for time
tracing of the entire NE may not be the optimal computed clock source to be traced.
2. Only the time source in the priority table can be traced forcibly.
9.267 TIME_NO_TRACE_MODE
Description
The TIME_NO_TRACE_MODE alarm indicates that the IEEE 1588v2 Time of the boards is
in the non-locked status. This alarm is reported when the IEEE 1588v2 Time function of a
board is enabled and when the current tracing source of the board is the internal time source.
Attribute
Alarm Severity Alarm Type
Parameters
None.
Possible Causes
The possible causes of the TIME_NO_TRACE_MODE alarm are as follows:
l The time source priority table is not configured with the external time source.
l The corresponding time source cannot be traced, because the parameter values of the
announce attribute of the local NE are smaller than the parameter values of the announce
attribute of the upstream NE.
l The time source priority table is configured but the internal time source is still traced. It
indicates that the other time sources do not meet the tracing conditions due to certain
reasons, for example, the fiber may be connected incorrectly, or the board may be
offline.
Procedure
Step 1 Check whether the time source priority table is configured with the external time source. If
the time source priority table is not configured with the external time source, configure the
time source priority table with the external time source. Then, check whether the alarm is
cleared.
Step 2 If the alarm persists, view the announce attribute of the NE on the NMS. If the attribute value
of the NE is smaller than the attribute value of the external time source, change the value of
the announce attribute of the NE in one of the following manners:
l Change the value of the announce attribute of the local NE, and ensure that the value is
greater than the value of the announce attribute of the upstream NE. Then, check whether
the alarm is cleared.
l Change the value of the announce attribute of the upstream NE, and ensure that the value
is smaller than the value of the announce attribute of the local NE. Then, check whether
the alarm is cleared.
Step 3 If the TIME_NO_TRACE_MODE alarm persists, check whether the fibers are connected
properly. For example, if the fiber connector is loose, dirty, or damaged, tighten and clean the
fiber connector. Then, check whether the alarm is cleared.
Step 4 If the TIME_LOS alarm persists, check whether the board is in place on the NMS.
l If the board is not in place, place the board properly. Then, check whether the alarm is
cleared.
l If the physical board is in place but in the offline status, perform a warm reset on the
board. Then, check whether the alarm is cleared. If the TIME_NO_TRACE_MODE
alarm persists, perform a cold reset on the board. Then, check whether the alarm is
cleared.
----End
Related Information
The time source priority table specifies the range of the time source. Only the time source in
the priority table can be selected as the tracing source. By default, the priority table contains
the internal time source only. The optimal time source computed according to the source
selection algorithm specified in IEEE 1588 can be used as the tracing source. The source
selection algorithm compares the values of the announce attribute.
The announce attribute refers to the quality attribute of the time source at an NE. The
announce attribute contains the parameters such as NE ID, priority 1, priority 2, and clock
quality. The parameter values of the announce attribute determine the quality of the time
source. If the parameter values are small, the clock quality is high. If the clock quality is high,
the tracing probability is high.
The parameter values of the announce attribute are compared in the order of priority 1, clock
quality, priority 2, and NE ID. If the values of priority 1, clock quality, and priority 2 are the
same for different time sources, the source selection algorithm compares the NE IDs. If the
NE IDs of different time sources are different from each other, the clock source with a smaller
NE ID is traced. If an NE is required to trace the time source of the other NEs, the parameter
values of the announce attribute of the other NEs are a bit smaller than the parameter values
of the announce attribute of the local NE.
9.268 TIME_NOT_SUPPORT
Description
The TIME_NOT_SUPPORT alarm indicates that the board does not support the IEEE 1588v2
Time function. This alarm is reported if a user enables the IEEE 1588v2 Time function of the
board that does not support the function.
Attribute
Parameters
None.
Possible Causes
The possible cause of the TIME_NOT_SUPPORT alarm is as follows:
The board does not support the IEEE 1588v2 Time function but is configured in the priority
table of the time source.
Procedure
Step 1 Query the TIME_NOT_SUPPOR alarm on the NMS and determine the board that reports the
alarm. For details, see Viewing the Current Alarms in the Supporting Tasks.
l If the IEEE 1588v2 Time function is not required, delete the time source of the board
that reports the alarm from the time source priority table.
l If the IEEE 1588v2 Time function is required, replace the board with a board that
supports the IEEE 1588v2 Time function.
----End
Related Information
For the boards that support the IEEE 1588v2 Time function, see the Hardware Description.
9.269 TPS_ALM
Description
The TPS_ALM is an alarm of TPS protection switching. This alarm occurs when the board is
in the TPS switching state. The TPS protection has three states: automatic switching state,
forced switching state, and manual switching state.
NOTE
For the data boards that generate the TPS_ALM alarm, there are no alarm parameters. For the tributary
boards that generate the TPS_ALM alarm, the parameters are described as follows.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Possible Causes
The possible causes of the TPS_ALM alarm are as follows:
l The hardware of the working board is faulty, and the TPS automatic switching occurs.
l The hardware of the working board is not faulty. The TPS switching command is issued,
however, and services are switched from the working board to the protection board.
Procedure
Step 1 Check whether the TPS switching command is manually issued.
l If yes, issue the command to clear the TPS switching. Accordingly, services are switched
from the protection board to the working board and the TPS_ALM alarm is
automatically cleared.
l If not, check whether there is the HARD_BAD alarm reported from the working board.
If yes, it indicates that the hardware of the working board is faulty. After the
HARD_BAD alarm is cleared, the services are switched from the protection board to the
working board and then the TPS_ALM alarm is cleared.
Step 2 For the tributary boards, decide the slot number of the working board that performs the
switching according to Parameter 4. (The command line is required.) Replace the faulty board
and perform the service switching to the working board. The TPS_ALM alarm is
automatically cleared.
----End
Related Information
Page Number
The page number refers to the number of each board in the 1:N (N8) TPS protection groups.
The page number of the protection board is always 0, and the page number of the working
board can be any value within 1 - N. When the TPS occurs to the board, the working board
that performs the switching can be confirmed according to the parameters of the TPS_ALM
alarm for fast fault location.
9.270 TR_LOC
Description
The TR_LOC is an alarm indicating that the clock of the cross-connect board is faulty. If a
board has detected loss of the clock signal of the cross-connect board, loss of the frame
header, or damage to the cross-connect board, the TR_LOC alarm is reported.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Name Meaning
Parameter 4 For the auxiliary board, IF board, and Ethernet SAN service board, the
parameter indicates the following faults:
l 0x01: Failure of clock signal of the cross-connect board in the slot with a
smaller ID.
l 0x02: Failure of clock signal of the cross-connect board in the slot with a
greater ID.
l 0x03: Failure of clock signal of the active/standby cross-connect boards.
For PDH boards (excluding DDN boards), the parameter indicates the
following faults:
l bit[0]: Faulty bus on the cross-connect board in the slot with a smaller
ID.
l bit[1]: Faulty bus on the cross-connect board in the slot with a greater
ID.
For DDN boards, SDH board, the parameter indicates the following faults:
l Bit[0]: Loss of the clock signal of the cross-connect board in the slot
with a smaller ID.
l Bit[1]: Loss of the frame header of the cross-connect board in the slot
with a smaller ID.
l Bit[2]: Damage to the status indication line of the cross-connect board in
the slot with a smaller ID.
l Bit[4]: Loss of the clock signal of the cross-connect board in the slot
with a greater ID.
l Bit[5]: Loss of the frame header of the cross-connect board in the slot
with a greater ID.
l Bit[6]: Damage to the status indication line of the cross-connect board in
the slot with a greater ID.
Name Meaning
Parameter 4, For Ethernet boards for transparent transmission, switch, the parameter
Parameter 5 indicates the following faults:
l Bit[0]: Loss of the clock signal of the cross-connect board in the slot
with a smaller ID.
l Bit[1]: Loss of the frame header of the cross-connect board in the slot
with a smaller ID.
l Bit[2]: Damage to the status indication line of the cross-connect board in
the slot with a smaller ID.
l Bit[3]: Loss of the clock signal of the cross-connect board in the slot
with a greater ID.
l Bit[4]: Loss of the frame header of the cross-connect board in the slot
with a greater ID.
l Bit[5]: Damage to the status indication line of the cross-connect board in
the slot with a greater ID.
NOTE
If the bit corresponding to the parameter is 1, the alarm exists. If the bit corresponding
to the parameter is 0, the alarm does not exist.
Possible Causes
The possible causes of the TR_LOC alarm are as follows:
Procedure
Step 1 View the TR_LOC alarm at the local station, and check whether the alarm occurs at the
service boards.
l If the TR_LOC alarm occurs at most service boards, the cross-connect board is faulty. In
this case, replace the faulty cross-connect board.
l If only the local board reports the alarm, replace the board.
----End
Related Information
None.
9.271 TS16_AIS
Description
The TS16_AIS is an alarm in timeslot 16 of the PCM30 frame in the 2 Mbit/s signals. In two
consecutive multiframe cycles of the PCM30 frame in the services at the 2 Mbit/s interface on
the PDH board, if the number of 0s contained in timeslot 16 of each multiframe is not more
than three, the TS16_AIS alarm is reported.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Possible Causes
The possible cause of the TS16_AIS alarm is as follows:
A hardware fault alarm, such as the PLL_FAIL or CHIP_FAIL, occurs on the board at the
opposite station.
Procedure
Step 1 Check whether any hardware fault alarm, such as the PLL_FAIL or CHIP_FAIL, occurs on
the board at the opposite and upstream station. If yes, clear it, and then check whether the
TS16_AIS alarm is cleared.
----End
Related Information
None.
9.272 TU_AIS_VC12
Description
The TU_AIS_VC12 is a TU alarm indication signal in the VC-12 lower order path. TU alarm
indication is the VC-12 path AIS. If a board has detected that the TU path is all "1"s, the
TU_AIS_VC12 alarm is reported.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Possible Causes
The possible causes of the TU_AIS_VC12 alarm are as follows:
l Some higher-level alarms, such as the R_LOS, R_LOF, HP_SLM or AU_AIS, occur in
the system.
l A hardware fault alarm, such as the PLL_FAIL or CHIP_FAIL, occurs at the upstream
station.
l The cross-connect and timing board is faulty.
l The relevant path at the opposite station is faulty.
Procedure
Step 1 Check whether any higher-level alarm, such as the R_LOS, R_LOF, HP_SLM or AU_AIS, is
detected on the U2000. If yes, take priority to clear it, and then check whether the
TU_AIS_VC12 alarm is cleared. If the alarm persists, go to the next step.
Step 2 Check whether any hardware fault alarm, such as the PLL_FAIL or CHIP_FAIL, occurs at the
upstream station. If yes, clear it, and then check whether the TU_AIS_VC12 alarm is cleared.
If the alarm persists, go to the next step.
Step 3 Perform a cold reset on the board that reports the alarm. Then check whether the
TU_AIS_VC12 alarm is cleared. If the alarm persists, go to the next step.
NOTICE
If the services travel through the board are not configured with protection, the services are
interrupted after the cold reset of the board.
Step 4 Replace the board that reports the alarm, and then check whether the TU_AIS_VC12 alarm is
cleared. If the alarm persists, go to the next step.
Step 5 Check whether the cross-connect and timing board is faulty. If yes, replace it, and then check
whether the TU_AIS_VC12 alarm is cleared.
Step 6 Check whether the board at the opposite station is faulty. If yes, replace it, and then check
whether the TU_AIS_VC12 alarm is cleared.
----End
Related Information
None.
9.273 TU_AIS_VC3
Description
The TU_AIS_VC3 is a TU alarm indication signal in the VC-3 lower order path. TU alarm
indication is the AIS at the level of the VC-3 lower order path. If a board has detected that the
TU path is all "1"s, the TU_AIS_VC3 alarm is reported.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Possible Causes
The possible causes of the TU_AIS_VC3 alarm are as follows:
l Some higher-level alarms, such as the R_LOS, R_LOF, HP_SLM or AU_AIS, occur in
the system.
l A hardware fault alarm, such as the PLL_FAIL or CHIP_FAIL, occurs at the upstream
station.
l The cross-connect and timing board is faulty.
l The relevant path at the opposite station is faulty.
Procedure
Step 1 Check whether any higher-level alarm, such as the R_LOS, R_LOF, HP_SLM or AU_AIS, is
detected on the U2000. If yes, take priority to clear it, and then check whether the
TU_AIS_VC3 alarm is cleared. If the alarm persists, go to the next step.
Step 2 Check whether any hardware fault alarm, such as the PLL_FAIL or CHIP_FAIL, occurs at the
upstream station. If yes, clear it, and then check whether the TU_AIS_VC3 alarm is cleared.
If the alarm persists, go to the next step.
Step 3 Perform a cold reset on the board that reports the alarm. Then check whether the
TU_AIS_VC3 alarm is cleared. If the alarm persists, go to the next step.
NOTICE
If the services travel through the board are not configured with protection, the services are
interrupted after the cold reset of the board.
Step 4 Replace the board that reports the alarm, and then check whether the TU_AIS_VC3 alarm is
cleared. If the alarm persists, go to the next step.
Step 5 Check whether the cross-connect and timing board is faulty. If yes, replace it, and then check
whether the TU_AIS_VC3 alarm is cleared.
Step 6 Check whether the board at the opposite station is faulty. If yes, replace it, and then check
whether the TU_AIS_VC3 alarm is cleared.
----End
Related Information
None.
9.274 TU_LOP_VC12
Description
The TU_LOP_VC12 is an alarm indicating the loss of pointer in the TU of the VC-12 lower
order path. If a board has detected that the TU-PTR value is an invalid pointer or NDF
reversion in eight consecutive frames, the TU_LOP_VC12 alarm is reported.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Possible Causes
The possible causes of the TU_LOP_VC12 alarm are as follows:
l Some higher-level alarms, such as the R_LOS, R_LOF, HP_SLM or AU_AIS, occur in
the system.
l A hardware fault alarm, such as the PLL_FAIL or CHIP_FAIL, occurs at the upstream
station.
l The cross-connect and timing board is faulty.
l The relevant path at the opposite station is faulty.
Procedure
Step 1 Check whether any higher-level alarm, such as the R_LOS, R_LOF, HP_SLM or AU_AIS, is
detected on the U2000. If yes, take priority to clear it, and then check whether the
TU_LOP_VC12 alarm is cleared. If the alarm persists, go to the next step.
Step 2 Check whether any hardware fault alarm, such as the PLL_FAIL or CHIP_FAIL, occurs at the
upstream station. If yes, clear it, and then check whether the TU_LOP_VC12 alarm is cleared.
If the alarm persists, go to the next step.
Step 3 Perform a cold reset on the board that reports the alarm. Then check whether the
TU_LOP_VC12 alarm is cleared. If the alarm persists, go to the next step.
NOTICE
If the services travel through the board are not configured with protection, the services are
interrupted after the cold reset of the board.
Step 4 Replace the board that reports the alarm, and then check whether the TU_LOP_VC12 alarm is
cleared. If the alarm persists, go to the next step.
Step 5 Check whether the cross-connect and timing board is faulty. If yes, replace it, and then check
whether the TU_LOP_VC12 alarm is cleared.
Step 6 Check whether the board at the opposite station is faulty. If yes, replace it, and then check
whether the TU_LOP_VC12 alarm is cleared.
----End
Related Information
None.
9.275 TU_LOP_VC3
Description
The TU_LOP_VC3 is an alarm indicating the loss of pointer in the VC-3 lower order path. If
a board has detected that the TU-PTR value is an invalid pointer or NDF reversion in eight
consecutive frames, the TU_LOP_VC3 alarm is reported.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Possible Causes
The possible causes of the TU_LOP_VC3 alarm are as follows:
l Some higher-level alarms, such as the R_LOS, R_LOF, HP_SLM or AU_AIS, occur in
the system.
l The service cross-connection is incorrectly configured.
l A hardware fault alarm, such as the PLL_FAIL or CHIP_FAIL, occurs at the upstream
station.
l The cross-connect and timing board is faulty.
l The relevant path at the opposite station is faulty.
Procedure
Step 1 Check whether any higher-level alarm, such as the R_LOS, R_LOF, HP_SLM or AU_AIS, is
detected on the NMS. If yes, take priority to clear it, and then check whether the
TU_LOP_VC3 alarm is cleared. If the alarm persists, go to the next step.
Step 2 Along the signal flow, check whether the cross-connect configuration of the service is correct.
If the bound timeslot and the cross-connected timeslot are different, for example, if VC-3 of
the first VC-4 is the bound timeslot, whereas VC-3 of the third VC-4 is the cross-connected
timeslot, the TU_LOP_VC3 alarm is reported. After modifying the incorrect cross-connect
configuration, check whether the alarm is cleared. If the alarm persists, go to the next step.
Step 3 Check whether any hardware fault alarm, such as the PLL_FAIL or CHIP_FAIL, occurs at the
upstream station. If yes, clear it, and then check whether the TU_LOP_VC3 alarm is cleared.
If the alarm persists, go to the next step.
Step 4 Perform a cold reset on the board that reports the alarm. Then check whether the
TU_LOP_VC3 alarm is cleared. If the alarm persists, go to the next step.
NOTICE
If the services travel through the board are not configured with protection, the services are
interrupted after the cold reset of the board.
Step 5 Replace the board that reports the alarm, and then check whether the TU_LOP_VC3 alarm is
cleared. If the alarm persists, go to the next step.
Step 6 Check whether the cross-connect and timing board is faulty. If yes, replace it, and then check
whether the TU_LOP_VC3 alarm is cleared.
Step 7 Check whether the board at the opposite station is faulty. If yes, replace it, and then check
whether the TU_LOP_VC3 alarm is cleared.
----End
Related Information
None.
9.276 UHCS
Description
The UHCS is an alarm indicating the uncorrectable cell errors. This alarm shows that multiple
uncorrectable bit errors occur in the cell header.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 4, Indicates the VCTRUNK port ID. The value range is 0x8001 -
Parameter 5 0x8046. That is, Parameter 4 is always in value 0x80, and Parameter 5
is in the value range of 0x01 - 0x46.
Possible Causes
The possible causes of the UHCS alarm are as follows:
l Some bit errors occur in the relevant SDH receive path of the ATM port. That is, some
bit error alarms, such as the B1_SD, B2_ SD or B3_ SD, occur in the relevant SDH path
of the port.
l The ATM processing chip of the board is faulty.
Procedure
Step 1 View the UHCS alarm on the U2000, and then confirm the relevant port according to the
alarm parameters.
Step 2 On the U2000, check whether any bit error alarm, such as the B1_SD, B2_ SD or B3_ SD,
occurs at the local station. If yes, clear it, and then check whether the UHCS alarm is cleared.
Step 3 If the alarm persists, the ATM processing chip of the board may be faulty. In this case,
perform a cold reset on the board. Then check whether the UHCS alarm is cleared.
NOTICE
If the services travel through the board are not configured with protection, the services are
interrupted after the cold reset of the board.
Step 4 If the alarm persists, replace the board that generates the UHCS alarm.
----End
Related Information
None.
9.277 UP_T1AIS
Description
The UP_T1AIS is an alarm indication of the upstream 1.5 Mbit/s signals. If a tributary board
has detected that the upstream T1 signals are all "1"s, the UP_T1AIS alarm is reported.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 2, Indicates the path number. Parameter 2 is the higher byte, and Parameter 3
Parameter 3 is the lower byte.
For example, Parameter 2 = 0x00, Parameter 3= 0x01. In this case, the
UP_T1AIS alarm is reported from path 1 of the board.
Possible Causes
The possible causes of the UP_T1AIS alarm are as follows:
l The TU_LOP, TU_AIS, or DOWN_T1_AIS alarm occurs on the tributary board that
interconnects with the tributary board at the local station.
l An alarm such as T_ALOS or UP_T1AIS occurs on the tributary board that is located at
the opposite station and that accesses the 1.5 Mbit/s signals.
l A hardware fault alarm, such as the PLL_FAIL or CHIP_FAIL, occurs at the opposite
station.
l The local board is faulty.
Procedure
Step 1 On the U2000, check whether the TU_LOP, TU_AIS, or DOWN_T1_AIS alarm occurs on the
tributary board that interconnects with the tributary board of the local station. If yes, clear it,
and then check whether the UP_T1AIS alarm is cleared.
Step 2 If the alarm persists, check whether any alarm such as T_ALOS or UP_T1AIS occurs on the
tributary board that is located at the opposite station and that accesses the 1.5 Mbit/s signals.
If yes, clear it, and then check whether the UP_T1AIS alarm is cleared.
Step 3 If the alarm persists, check whether any hardware fault alarm, such as the PLL_FAIL or
CHIP_FAIL, occurs on the board of the opposite station. If yes, clear it, and then check
whether the UP_T1AIS alarm is cleared.
Step 4 If the alarm persists, replace the relevant board of the opposite station.
----End
Related Information
None.
9.278 V5_VCAIS
Description
The V5_VCAIS is an alarm indicating that bits 5-7 of the V5 byte in the lower order VC-12
path are all "1"s.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Name Meaning
Parameter 2, Indicates the number of the path in which the alarm occurs. Parameter 2 is
Parameter 3 the higher byte, and Parameter 3 is the lower byte.
For example, Parameter 2 = 0x00, Parameter 3= 0x01. In this case, the
V5_VCAIS alarm is reported from path 1 of the board.
Note: For the N2PQ1 or R2PD1 board in the SEVER mode, the path number
is reported from 0x40, which indicates the first VC3 path.
Possible Causes
The possible causes of the V5_VCAIS alarm are as follows:
l A hardware fault alarm, such as the PLL_FAIL or CHIP_FAIL, occurs on the upstream
board of the service.
l The tributary board hardware is faulty.
Procedure
Step 1 Check whether any hardware fault alarm, such as the PLL_FAIL or CHIP_FAIL, occurs on
the upstream board of the service. If yes, clear it, and then check whether the V5_VCAIS
alarm is cleared.
Step 2 If the alarm persists, the tributary board hardware is faulty. In this case, perform a cold reset
on the board. Then check whether the V5_VCAIS alarm is cleared. If the alarm persists, go to
the next step.
NOTICE
If the services travel through the board are not configured with protection, the services are
interrupted after the cold reset of the board.
----End
Related Information
None.
9.279 VC_AIS
Description
VC_AIS is the alarm indication signal of a virtual channel (VC) connection. When a forward
or backward VC connection that is set with the segment and end attribute receives AIS cells,
the VC_AIS alarm is reported to indicate that the upstream service is abnormal.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 2, Indicate the connection ID and the connection direction. The value is the
Parameter 3 remainder derived from the formula [(ConnID - 1) x 2 + ConnDir]/2048.
ConnDir indicates the connection direction, and ConnId indicates the
connection ID. An odd value means that ConnDir is 1 (forward direction).
An even value means that ConnDir is 2 (backward direction).
Parameter 4 Indicates the group number. The parameter value is an integer derived by
rounding off the result of the following formula: ((ConnId - 1) x 2 +
ConnDir)/2048. The unidirectional connections that report VC_AIS alarms
are divided into groups of 2048.
Name Meaning
Parameter 5 Indicates the number of the source ATM port of the unidirectional
connection based on the connection ID and the connection direction.
l For N1IDQ1 and N1IDL4 boards, the value range is 0x01 - 0x4A (1 -
74). 0x01 - 0x04 (1 - 4) is the number of an external optical port, and
0x05 - 0x4A (5 - 74) is the number of an internal VCTRUNK port.
l For N1ADQ1 and N1ADL4 boards, the value range is 0x01 - 0x14. 0x01
- 0x04 (1 - 4) is the number of an external optical port, and 0x05 - 0x14
(5 - 20) is the number of an internal VCTRUNK port.
Note: The number of an internal VCTRUNK port is computed by the
following formula: (VCTRUNK port ID - 0x8001 + 0x0005). Wherein, the
VCTRUNK port ID is the configured ID of the VCTRUNK port.
Possible Causes
The possible causes of the VC_AIS alarm are as follows:
l On the ATM connection, the SDH path of an upstream NE is faulty in the receive
direction. For example, an SDH alarm, such as the R_LOS, R_LOF, MS_AIS, AU_AIS,
AU_LOP, TU_AIS or TU_LOP, occurs at the NE.
l The LCD alarm occurs at an upstream ATM port.
l The CC sink is activated on an upstream NE, but the relevant CC source is not activated.
Moreover, no user cells are received because the current bandwidth utilization is zero. In
this case, the upstream NE reports the CC_LOC alarm and inserts AIS cells downstream,
resulting in the VC_AIS alarm on the local NE.
l The ATM processing chip of the board is faulty.
Procedure
Step 1 View the VC_AIS alarm on the U2000, and determine the relevant connection according to
Parameters 2 and 3.
Step 2 Check whether any alarm, such as the R_LOS, R_LOF, MS_AIS, AU_AIS, AU_LOP,
TU_AIS or TU_LOP, occurs in the relevant SDH path of an upstream NE, which connects to
the ATM port. If yes, clear it, and check whether the VC_AIS alarm is cleared.
Step 3 If the alarm persists, check whether the LCD alarm occurs at the ATM port on the ATM board
of the upstream NE. If yes, clear it, and check whether the VC_AIS alarm at the local NE is
cleared.
Step 4 If the alarm persists, check whether the CC sink is activated on an upstream NE, and the
relevant CC source is not activated. Meanwhile, check whether the CC_LOC alarm occurs. If
yes, deactivate the CC sink and clear the CC_LOC alarm at the upstream NE, and then check
whether the VC_AIS alarm at the local NE is cleared.
Step 5 If the alarm persists, the ATM processing chip of the board may be faulty. In this case,
perform a cold reset on the board. Then check whether the VC_AIS alarm is cleared.
NOTICE
If the service on the board is not protected, a cold reset on the board causes service
interruptions.
Step 6 If the alarm persists, replace the board that reports the VC_AIS alarm.
----End
Related Information
Unidirectional Connection
A complete bidirectional connection is divided into a forward unidirectional connection and a
backward unidirectional connection. The direction of the forward and backward connections
is based on the same node. As shown in Figure 9-3, the forward and backward directions for
node B are respectively:
A B C D E
Segment Segment
The segment and end attributes include segment endpoint, endpoint, segment and endpoint,
non segment and endpoint.
l If an NE is set with the segment endpoint attribute, it captures alarms of only segment
endpoints.
l If an NE is set with the endpoint attribute, it captures alarms of only endpoints.
l If an NE is set with the segment and endpoint attribute, it captures alarms of both
endpoints and segment endpoints.
l If an NE is set with the non segment and endpoint attribute, it fails to capture alarms of
endpoints or segment endpoints.
9.280 VC_RDI
Description
VC_RDI is the remote defect indication of a virtual channel (VC) connection. When a
forward or backward VC connection that is set with the segment and end attribute receives
RDI cells, the VC_RDI alarm is reported to indicate that the downstream service is abnormal.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Name Meaning
Parameter 2, Indicate the connection ID and the connection direction. The value is the
Parameter 3 remainder derived from the formula [(ConnID - 1) x 2 + ConnDir]/2048.
ConnDir indicates the connection direction, and ConnId indicates the
connection ID. An odd value means that ConnDir is 1 (forward direction).
An even value means that ConnDir is 2 (backward direction).
Parameter 4 Indicates the group number. The parameter value is an integer derived by
rounding off the result of the following formula: ((ConnId - 1) x 2 +
ConnDir)/2048. The unidirectional connections that report VC_AIS alarms
are divided into groups of 2048.
Parameter 5 Indicates the number of the source ATM port of the unidirectional
connection based on the connection ID and the connection direction.
l For N1IDQ1 and N1IDL4 boards, the value range is 0x01 - 0x4A (1 -
74). 0x01 - 0x04 (1 - 4) is the number of an external optical port, and
0x05 - 0x4A (5 - 74) is the number of an internal VCTRUNK port.
l For N1ADQ1 and N1ADL4 boards, the value range is 0x01 - 0x14. 0x01
- 0x04 (1 - 4) is the number of an external optical port, and 0x05 - 0x14
(5 - 20) is the number of an internal VCTRUNK port.
Note: The number of an internal VCTRUNK port is computed by the
following formula: (VCTRUNK port ID - 0x8001 + 0x0005). Wherein, the
VCTRUNK port ID is the configured ID of the VCTRUNK port.
Possible Causes
The possible causes of the VC_RDI alarm are as follows:
Procedure
Step 1 View the VC_RDI alarm on the U2000, and determine the relevant connection according to
Parameters 2 and 3.
Step 2 Check whether the VC_AIS alarm occurs in the receive direction of the downstream VC
connection. If yes, clear it, and check whether the VC_RDI alarm is cleared.
Step 3 If the alarm persists, the ATM processing chip of the board may be faulty. In this case,
perform a cold reset on the board. Then check whether the VC_RDI alarm is cleared.
NOTICE
If the service on the board is not protected, a cold reset on the board causes service
interruptions.
Step 4 If the alarm persists, replace the board that reports the VC_RDI alarm.
----End
Related Information
Unidirectional Connection
A complete bidirectional connection is divided into a forward unidirectional connection and a
backward unidirectional connection. The direction of the forward and backward connections
is based on the same node. As shown in Figure 9-5, the forward and backward directions for
node B are respectively:
A B C D E
Segment Segment
l If an NE is set with the segment and endpoint attribute, it captures alarms of both
endpoints and segment endpoints.
l If an NE is set with the non segment and endpoint attribute, it fails to capture alarms of
endpoints or segment endpoints.
9.281 VC3_CROSSTR
Description
The VC3_CROSSTR is an alarm indicating that the VC-3 performance crosses the threshold.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1 Indicates the number of the optical interface where the VC-3
performance threshold-crossing occurs.
Parameter 2, Indicates the number of the path where the VC-3 performance
Parameter 3 threshold-crossing occurs.
Parameter 4 The higher two bits indicate the performance monitoring period.
l 01: 15-minute performance monitoring
l 02: 24-hour performance monitoring
The lower six bits together with Parameter 5 indicate the
performance event ID.
l The service quality of the board that reports the alarm is degraded.
l The services of the board that reports the alarm are interrupted.
Possible Causes
The possible causes of the VC3_CROSSTR alarm are as follows:
l The laser performance at the opposite station is degraded.
l the received optical power at the local station is over high or over low.
l The clock performance at the local station or the opposite station is degraded.
l The fiber performance is degraded.
Procedure
Step 1 Perform an inloop on the board that reports the VC3_CROSSTR alarm at the local station.
NOTICE
The loopback causes service interruption.
NOTICE
The loopback causes service interruption.
1. If the alarm is cleared, it indicates that the fault occurs to the opposite station. Go to Step
3.
2. If the alarm persists, it indicates that the fiber performance is degraded or the fiber
jumper connector is dirty. Go to Step 5.
Step 3 Replace the line board at the opposite station.
1. If the alarm is cleared, the fault is removed. The alarm handling ends.
2. If the alarm persists, replace the cross-connect and timing board at the opposite station.
The alarm handling ends.
Step 4 Replace the board that reports the VC3_CROSSTR alarm at the local station.
1. If the alarm is cleared, the fault is removed. The alarm handling ends.
2. If the alarm persists, replace the cross-connect and timing board at the local station. The
alarm handling ends.
Step 5 Clean the fiber jumper connectors at both the local and opposite stations.
1. If the alarm is cleared, the fault is removed. The alarm handling ends.
2. If the alarm persists, it indicates that the fault occurs to the fiber cables. Remove the
fault, and the alarm handling ends.
----End
Related Information
None.
9.282 VCAT_LOA
Description
The VCAT_LOA is an alarm indicating that the delay of the virtual concatenation is over
long. This alarm occurs when the delay time of the timeslots bound to a VC trunk exceeds the
time allowed by the virtual concatenation delay. The time allowed by the virtual
concatenation delay depends on different board types. For details, refer to Virtual
Concatenation Delay.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 2, Parameter Indicates the VC trunk number that generates the alarm.
3 Parameter 2 is the higher byte, and Parameter 3 is the lower byte.
Possible Causes
The possible cause of the VCAT_LOA alarm is as follows:
VCTRUNKs traverse different physical links, resulting in large delay differences between the
VCTRUNKs.
Procedure
Step 1 View the VCAT_LOA alarm on the NMS to confirm the relevant board. According to
Parameter 2 and Parameter 3, confirm the specific VC trunk number of the board.
Step 2 Configure the timeslots of the VC trunk again, so that they pass the same fiber. If they need to
pass different fibers, make sure that the distance difference of the fibers is the shortest.
----End
Related Information
Virtual Concatenation Delay
9.283 VCAT_LOM_VC12
Description
The VCAT_LOM_VC12 is an alarm indicating the loss of the virtual concatenation
multiframe in the VC-12 path. This alarm occurs when the system detects that the multiframe
indicator (MFI) field in the K4 byte of the VC-12 timeslot is illegal.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 2, Parameter Indicates the VC-12 path number that generates the alarm.
3 Parameter 2 is the higher byte, and Parameter 3 is the lower byte.
Possible Causes
The possible causes of the VCAT_LOM_VC12 alarm are as follows:
l There are bit error alarms BIP_EXC and BIP_SD in the line.
l The virtual concatenation delay is over long.
l The MFI field in the K4 byte transmitted from the opposite end is incorrect.
Procedure
Step 1 View the VCAT_LOM_VC12 alarm on the U2000 to confirm the relevant board.
Step 2 Check on the U2000 whether there are bit error alarms BIP_EXC and BIP_SD reported from
the board. If yes, clear them and check whether the VCAT_LOM_VC12 alarm is cleared.
Step 3 If the alarm persists, check on the U2000 whether there is the VCAT_LOA alarm. If yes, it
indicates that the virtual concatenation delay is over long. Refer to the procedure for handling
the VCAT_LOA alarm to clear it. After that, check whether the VCAT_LOM_VC12 alarm is
cleared.
Step 4 If the alarm persists, check whether the board that reports the VCAT_LOM_VC12 alarm at
the local end is faulty. Replace the board that reports the alarm at the local station, and then
check whether the VCAT_LOM_VC12 alarm is cleared.
Step 5 If the alarm persists, it indicates that the MFI domain transmitted from the SDH opposite end
is incorrect. Replace the corresponding board at the opposite station, and then check whether
the VCAT_LOM_VC12 alarm is cleared.
----End
Related Information
None.
9.284 VCAT_LOM_VC3
Description
The VCAT_LOM_VC3 is an alarm indicating the loss of the virtual concatenation multiframe
in the VC-3 path. This alarm occurs when the system detects that the multiframe indicator
(MFI) field in the H4 byte of the VC-3 timeslot is illegal.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 2, Parameter Indicates the VC-3 path number that generates the alarm.
3 Parameter 2 is the higher byte, and Parameter 3 is the lower byte.
Possible Causes
The possible causes of the VCAT_LOM_VC3 alarm are as follows:
l There are bit error alarms BIP_EXC and BIP_SD in the line.
Procedure
Step 1 View the VCAT_LOM_VC3 alarm on the U2000 to confirm the relevant board.
Step 2 Check on the U2000 whether there are bit error alarms BIP_EXC and BIP_SD reported from
the board. If yes, clear them and check whether the VCAT_LOM_VC3 alarm is cleared.
Step 3 If the alarm persists, check on the U2000 whether there is the VCAT_LOA alarm. If yes, it
indicates that the virtual concatenation delay is over long. Refer to the procedure for handling
the VCAT_LOA alarm to clear it. After that, check whether the VCAT_LOM_VC3 alarm is
cleared.
Step 4 If the alarm persists, check whether the board that reports the VCAT_LOM_VC3 alarm at the
local end is faulty. Replace the board that reports the alarm at the local station, and then check
whether the VCAT_LOM_VC3 alarm is cleared.
Step 5 If the alarm persists, it indicates that the MFI domain transmitted from the SDH opposite end
is incorrect. Replace the corresponding board at the opposite station, and then check whether
the VCAT_LOM_VC3 alarm is cleared.
----End
Related Information
None.
9.285 VCAT_LOM_VC4
Description
The VCAT_LOM_VC4 is an alarm indicating the loss of the virtual concatenation multiframe
in the VC-4 path. This alarm occurs when the system detects that the multiframe indicator
(MFI) field in the H4 byte of the VC-4 timeslot is illegal.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 2, Parameter Indicates the VC-4 path number that generates the alarm.
3 Parameter 2 is the higher byte, and Parameter 3 is the lower byte.
Possible Causes
The possible causes of the VCAT_LOM_VC4 alarm are as follows:
l There are bit error alarms BIP_EXC and BIP_SD in the line.
l The virtual concatenation delay is over long.
l The MFI field in the K4 byte transmitted from the opposite end is incorrect.
Procedure
Step 1 View the VCAT_LOM_VC4 alarm on the U2000 to confirm the relevant board.
Step 2 Check on the U2000 whether there are bit error alarms BIP_EXC and BIP_SD reported from
the board. If yes, clear them and check whether the VCAT_LOM_VC4 alarm is cleared.
Step 3 If the alarm persists, check on the U2000 whether there is the VCAT_LOA alarm. If yes, it
indicates that the virtual concatenation delay is over long. Refer to the procedure for handling
the VCAT_LOA alarm to clear it. After that, check whether the VCAT_LOM_VC4 alarm is
cleared.
Step 4 If the alarm persists, check whether the board that reports the VCAT_LOM_VC4 alarm at the
local end is faulty. Replace the board that reports the alarm at the local station, and then check
whether the VCAT_LOM_VC4 alarm is cleared.
Step 5 If the alarm persists, it indicates that the MFI domain transmitted from the SDH opposite end
is incorrect. Replace the corresponding board at the opposite station, and then check whether
the VCAT_LOM_VC4 alarm is cleared.
----End
Related Information
None.
9.286 VCAT_SQM_VC12
Description
The VCAT_SQM_VC3 is an alarm indicating the sequence mismatch of the virtual
concatenation in the VC-12 path. This alarm occurs when the serial numbers of members in
the virtual concatenation at the VC-12 level mismatch.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 2, Parameter Indicates the VC-12 path number that generates the alarm.
3 Parameter 2 is the higher byte, and Parameter 3 is the lower byte.
Possible Causes
The possible causes of the VCAT_SQM_VC12 alarm are as follows:
l There are bit error alarms BIP_EXC and BIP_SD in the line.
l The serial numbers transmitted from the opposite end are incorrect.
Procedure
Step 1 View the VCAT_SQM_VC12 alarm on the U2000 to confirm the relevant board.
Step 2 Check on the U2000 whether there are bit error alarms BIP_EXC and BIP_SD reported from
the board. If yes, clear them and check whether the VCAT_SQM_VC12 alarm is cleared.
Step 3 If the alarm persists, check whether the board that reports the VCAT_SQM_VC12 alarm at
the local end is faulty. Replace the board that reports the alarm at the local station, and then
check whether the VCAT_SQM_VC12 alarm is cleared.
Step 4 If the alarm persists, it indicates that the serial numbers transmitted from the SDH opposite
end is incorrect. Replace the corresponding board at the opposite station, and then check
whether the VCAT_SQM_VC12 alarm is cleared.
----End
Related Information
None.
9.287 VCAT_SQM_VC3
Description
The VCAT_SQM_VC3 is an alarm indicating the sequence mismatch of the virtual
concatenation in the VC-3 path. This alarm occurs when the serial numbers of members in the
virtual concatenation at the VC-3 level mismatch.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 2, Parameter Indicates the VC-3 path number that generates the alarm.
3 Parameter 2 is the higher byte, and Parameter 3 is the lower byte.
Possible Causes
The possible causes of the VCAT_SQM_VC3 alarm are as follows:
l There are bit error alarms BIP_EXC and BIP_SD in the line.
l The serial numbers transmitted from the opposite end are incorrect.
Procedure
Step 1 View the VCAT_SQM_VC3 alarm on the U2000 to confirm the relevant board.
Step 2 Check on the U2000 whether there are bit error alarms BIP_EXC and BIP_SD reported from
the board. If yes, clear them and check whether the VCAT_SQM_VC3 alarm is cleared.
Step 3 If the alarm persists, check whether the board that reports the VCAT_SQM_VC3 alarm at the
local end is faulty. Replace the board that reports the alarm at the local station, and then check
whether the VCAT_SQM_VC3 alarm is cleared.
Step 4 If the alarm persists, it indicates that the serial numbers transmitted from the SDH opposite
end is incorrect. Replace the corresponding board at the opposite station, and then check
whether the VCAT_SQM_VC3 alarm is cleared.
----End
Related Information
None.
9.288 VCAT_SQM_VC4
Description
The VCAT_SQM_VC4 is an alarm indicating the sequence mismatch of the virtual
concatenation in the VC-4 path. This alarm occurs when the serial numbers of members in the
virtual concatenation at the VC-4 level mismatch.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Name Meaning
Parameter 2, Parameter Indicates the VC-4 path number that generates the alarm.
3 Parameter 2 is the higher byte, and Parameter 3 is the lower byte.
Possible Causes
The possible causes of the VCAT_SQM_VC4 alarm are as follows:
l There are bit errors alarms BIP_EXC and BIP_SD in the line.
l The serial numbers transmitted from the opposite end are incorrect.
Procedure
Step 1 View the VCAT_SQM_VC4 alarm on the U2000 to confirm the relevant board.
Step 2 Check on the U2000 whether there are bit error alarms BIP_EXC and BIP_SD reported from
the board. If yes, clear them and check whether the VCAT_SQM_VC4 alarm is cleared.
Step 3 If the alarm persists, check whether the board that reports the VCAT_SQM_VC4 alarm at the
local end is faulty. Replace the board that reports the alarm at the local station, and then check
whether the VCAT_SQM_VC4 alarm is cleared.
Step 4 If the alarm persists, it indicates that the serial numbers transmitted from the SDH opposite
end is incorrect. Replace the corresponding board at the opposite station, and then check
whether the VCAT_SQM_VC4 alarm is cleared.
----End
Related Information
None.
9.289 VCTRUNK_NO_FLOW
Description
The VCTRUNK_NO_FLOW is an alarm indicating that the VCTRUNK port has no traffic. If
the VCTRUNK port has no traffic, the VCTRUNK_NO_FLOW alarm is reported.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1 Indicates the number of the logical port. The value of this parameter
is always 0x01.
Possible Causes
The possible causes of the VCTRUNK_NO_FLOW alarm are as follows:
l No services are configured at the local end.
l The local end has abnormal alarms, or does not transmit packets.
l The opposite end has abnormal services, or no packets arrive at the local end.
Procedure
Step 1 View the VCTRUNK_NO_FLOW alarm on the U2000 to confirm the board where the
VCTRUNK_NO_FLOW alarm is generated. According to Parameter 2 and Parameter 3,
confirm the number of the specific VCTRUNK port of the board.
Step 2 Check whether any service is configured at the port. If not, check whether carelessness causes
the missing of service configuration.
Step 3 If yes, confirm the direction in which the traffic stops according to Parameter 4.
l If the traffic stops in the TX direction, check whether the local services are abnormal.
l If the traffic stops in the RX direction, check whether the local cross-connections are
correctly configured.
a. If not, rectify the incorrect configuration, and then check whether the
VCTRUNK_NO_FLOW alarm is cleared.
b. If not, check whether the fiber in the RX direction is damaged. If the fiber is
damaged, replace the fiber and then check whether the VCTRUNK_NO_FLOW
alarm is cleared.
c. If not, check whether the cross-connect board and line board involved in the RX
direction work normally. If not, replace the faulty board.
----End
Related Information
None.
9.290 VCG_MM
Description
The VCG_MM is a mismatch alarm of the VC ring protection group. This alarm shows that
the attributes of the two ATM protection groups (namely, VC_Ring) do not match.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1 Indicates the direction of the protection group. Only two values are
provided. The value 0x01 refers to the source end, and the value
0x10 refers to the sink end.
Parameter 2, Indicates the protection group ID. The value range is 1-4096. That is,
Parameter 3 Parameter 2 is in the value range of 0x00-0x01, and Parameter 3 is in
the value range of 0x00-0xFF.
Possible Causes
The possible cause of the VCG_MM alarm is as follows:
The protection mode at the two ends are different. For example, the 1+1 protection is set at
one end, but the 1:1 protection is set at another end.
Procedure
Step 1 View the VCG_MM alarm on the U2000, and then confirm the relevant protection group
according to the alarm parameters.
Step 2 Check whether the protection mode of the VCTRUNK protection group at one end matches
that at another end. If the protection mode of the VCTRUNK protection group at one end does
not match that at another end, modify it on the U2000, and then check whether the VCG_MM
alarm is cleared.
----End
Related Information
None.
9.291 VP_AIS
Description
VP_AIS is the alarm indication signal of a virtual path (VP) connection. When a forward or
backward VP connection that is set with the segment and end attribute receives AIS cells, the
VP_AIS alarm is reported to indicate that the upstream service is abnormal.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 2, Indicate the connection ID and the connection direction. The value is the
Parameter 3 remainder derived from the formula [(ConnID - 1) x 2 + ConnDir]/2048.
ConnDir indicates the connection direction, and ConnId indicates the
connection ID. An odd value means that ConnDir is 1 (forward direction).
An even value means that ConnDir is 2 (backward direction).
Name Meaning
Parameter 4 Indicates the group number. The parameter value is an integer derived by
rounding off the result of the following formula: ((ConnId - 1) x 2 +
ConnDir)/2048. The unidirectional connections that report VC_AIS alarms
are divided into groups of 2048.
Parameter 5 Indicates the number of the source ATM port of the unidirectional
connection based on the connection ID and the connection direction.
l For N1IDQ1 and N1IDL4 boards, the value range is 0x01 - 0x4A (1 -
74). 0x01 - 0x04 (1 - 4) is the number of an external optical port, and
0x05 - 0x4A (5 - 74) is the number of an internal VCTRUNK port.
l For N1ADQ1 and N1ADL4 boards, the value range is 0x01 - 0x14. 0x01
- 0x04 (1 - 4) is the number of an external optical port, and 0x05 - 0x14
(5 - 20) is the number of an internal VCTRUNK port.
Note: The number of an internal VCTRUNK port is computed by the
following formula: (VCTRUNK port ID - 0x8001 + 0x0005). Wherein, the
VCTRUNK port ID is the configured ID of the VCTRUNK port.
Possible Causes
The possible causes of the VP_AIS alarm are as follows:
l On the ATM connection, the SDH path of an upstream NE is faulty in the receive
direction. For example, an SDH alarm, such as the R_LOS, R_LOF, MS_AIS, AU_AIS,
AU_LOP, TU_AIS or TU_LOP, occurs at the NE.
l The LCD alarm occurs at an upstream ATM port.
l The CC sink is activated on an upstream NE, but the relevant CC source is not activated.
Moreover, no user cells are received because the current bandwidth utilization is zero. In
this case, the upstream NE reports the CC_LOC alarm and inserts AIS cells downstream,
resulting in the VP_AIS alarm on the local NE.
l The ATM processing chip of the board is faulty.
Procedure
Step 1 View the VP_AIS alarm on the U2000, and determine the relevant connection according to
Parameters 2 and 3.
Step 2 Check whether any alarm, such as the R_LOS, R_LOF, MS_AIS, AU_AIS, AU_LOP,
TU_AIS or TU_LOP, occurs in the relevant SDH path of an upstream NE, which connects to
the ATM port. If yes, clear it, and check whether the VP_AIS alarm is cleared.
Step 3 If the alarm persists, check whether the LCD alarm occurs at the ATM port on the ATM board
of the upstream NE. If yes, clear it, and check whether the VP_AIS alarm is cleared.
Step 4 If the alarm persists, check whether the CC sink is activated on an upstream NE, and the
relevant CC source is not activated. Meanwhile, check whether the CC_LOC alarm occurs. If
yes, deactivate the CC sink and clear the CC_LOC alarm at the upstream NE, and then check
whether the VP_AIS alarm is cleared.
Step 5 If the alarm persists, the ATM processing chip may be faulty. In this case, perform a cold reset
on the board that generates the alarm, and then check whether the VP_AIS alarm is cleared.
NOTICE
If the service on the board is not protected, a cold reset on the board causes service
interruptions.
Step 6 If the alarm persists, replace the board that reports the VP_AIS alarm.
----End
Related Information
Unidirectional Connection
Forward Backward
A B C
As shown in Figure 9-8, the endpoint is the termination point in the chain network. It
monitors the whole virtual connection. The segment endpoint generally monitors a segment of
the whole connection.
A B C D E
Segment Segment
The segment and end attributes include segment endpoint, endpoint, segment and endpoint,
non segment and endpoint.
l If an NE is set with the segment endpoint attribute, it captures alarms of only segment
endpoints.
l If an NE is set with the endpoint attribute, it captures alarms of only endpoints.
l If an NE is set with the segment and endpoint attribute, it captures alarms of both
endpoints and segment endpoints.
l If an NE is set with the non segment and endpoint attribute, it fails to capture alarms of
endpoints or segment endpoints.
9.292 VP_RDI
Description
VP_RDI is the remote defect indication of a virtual path (VP) connection. When a forward or
backward VP connection that is set with the segment and end attribute receives RDI cells, the
VP_RDI alarm is reported to indicate that the downstream service is abnormal.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Name Meaning
Parameter 2, Indicate the connection ID and the connection direction. The value is the
Parameter 3 remainder derived from the formula [(ConnID - 1) x 2 + ConnDir]/2048.
ConnDir indicates the connection direction, and ConnId indicates the
connection ID. An odd value means that ConnDir is 1 (forward direction).
An even value means that ConnDir is 2 (backward direction).
Parameter 4 Indicates the group number. The parameter value is an integer derived by
rounding off the result of the following formula: ((ConnId - 1) x 2 +
ConnDir)/2048. The unidirectional connections that report VC_AIS alarms
are divided into groups of 2048.
Parameter 5 Indicates the number of the source ATM port of the unidirectional
connection based on the connection ID and the connection direction.
l For N1IDQ1 and N1IDL4 boards, the value range is 0x01 - 0x4A (1 -
74). 0x01 - 0x04 (1 - 4) is the number of an external optical port, and
0x05 - 0x4A (5 - 74) is the number of an internal VCTRUNK port.
l For N1ADQ1 and N1ADL4 boards, the value range is 0x01 - 0x14. 0x01
- 0x04 (1 - 4) is the number of an external optical port, and 0x05 - 0x14
(5 - 20) is the number of an internal VCTRUNK port.
Note: The number of an internal VCTRUNK port is computed by the
following formula: (VCTRUNK port ID - 0x8001 + 0x0005). Wherein, the
VCTRUNK port ID is the configured ID of the VCTRUNK port.
Possible Causes
The possible causes of the VP_RDI alarm are as follows:
Procedure
Step 1 View the VP_RDI alarm on the U2000, and determine the relevant connection according to
Parameters 2 and 3.
Step 2 Check whether the VP_AIS alarm occurs in the receive direction of the downstream VP
connection. If yes, clear it, and check whether the VP_RDI alarm is cleared.
Step 3 If the alarm persists, the ATM processing chip of the board may be faulty. In this case,
perform a cold reset on the board. Then check whether the VP_RDI alarm is cleared.
NOTICE
If the service on the board is not protected, a cold reset on the board causes service
interruptions.
Step 4 If the alarm persists, replace the board that reports the VP_RDI alarm.
----End
Related Information
Unidirectional Connection
A complete bidirectional connection is divided into a forward unidirectional connection and a
backward unidirectional connection. The direction of the forward and backward connections
is based on the same node. As shown in Figure 9-9, the forward and backward directions for
node B are respectively:
A B C D E
Segment Segment
9.293 VPG_MM
Description
The VPG_MM is a mismatch alarm of the VP ring protection group. This alarm shows that
the attributes of the two ATM protection groups (namely, VP_Ring) do not match.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1 Indicates the direction of the protection group. Only two values are
provided. The value 0x01 refers to the source, and the value 0x10
refers to the sink.
Parameter 2, Indicates the protection group ID. The value range is 1-4096. That is,
Parameter 3 Parameter 2 is in the value range of 0x00-0x01, and Parameter 3 is in
the value range of 0x00-0xFF.
Possible Causes
The possible cause of the VPG_MM alarm is as follows:
The protection mode at the two ends are different. For example, the 1+1 protection is set at
one end, but the 1:1 protection is set at another end.
Procedure
Step 1 View the VPG_MM alarm on the U2000, and then confirm the relevant protection group
according to the alarm parameters.
Step 2 Check whether the protection mode of the VP ring protection group at one end matches that at
another end. If the protection mode of the VP ring protection group at one end does not match
that at another end, modify it on the U2000, and then check whether the VPG_MM alarm is
cleared.
----End
Related Information
None.
9.294 W_OFFLINE
Description
The W_OFFLINE is an alarm indicating that the front panel of a board is out of position.
Attribute
Alarm Severity Alarm Type
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Possible Causes
The possible causes of the W_OFFLINE alarm are as follows:
l The front panel is pulled open.
l The ejector levers on the front panel are faulty.
Procedure
Step 1 View the W_OFFLINE alarm on the U2000 to confirm the relevant board.
Step 2 Check whether the front panel of the board is pulled open. If yes, properly secure the front
panel back in position. Check whether the alarm is cleared.
Step 3 If the alarm persists, replace the faulty board.
----End
Related Information
None.
9.295 WORK_CUR_OVER
Description
The WORK_CUR_OVER is an alarm indicating that the working current is over the
threshold. The COA board reports this alarm when the working current crosses the threshold.
Attribute
Alarm Severity Alarm Type
Parameters
None.
Possible Causes
The possible cause of the WORK_CUR_OVER alarm is as follows:
The EDFA module is aged.
Procedure
Step 1 Replace the COA board. Then check whether the WORK_CUR_OVER alarm is cleared.
----End
Related Information
None.
9.296 WRG_BD_TYPE
Description
The WRG_BD_TYPE is an alarm of wrong board type. This alarm occurs when the types of
the logical board and the physical board are different.
Attribute
Parameters
When you view an alarm on the network management system, select the alarm. In the Alarm
Details field display the related parameters of the alarm. The alarm parameters are in the
following format: Alarm Parameters (hex): parameter1 parameter2...parameterN. For details
about each parameter, refer to the following table.
Name Meaning
Parameter 1 Indicates the number of the slot that generates this alarm.
Possible Causes
The possible causes of the WRG_BD_TYPE alarm are as follows:
l The original board is replaced by one that supports the board version replacement
function.
l The types of the logical board and the physical board are different.
Procedure
Step 1 View the WRG_BD_TYPE alarm on the U2000, and then confirm the slot number according
to Parameter 1.
Step 2 Check whether the physical board in this slot supports the board version replacement function
and whether the physical board can alternate with one of the logical board type. If yes, wait
for several minutes. Then the WRG_BD_TYPE alarm is automatically cleared.
Step 3 If the WRG_BD_TYPE alarm persists, check whether the logical board in this slot is correct.
If yes, replace the corresponding physical boards. Then check whether this alarm is cleared.
Step 4 If the logical board is wrong, create a correct logical board on the U2000 according to the
physical board type. Then check whether the WRG_BD_TYPE alarm is cleared.
----End
Related Information
None.
The chapter lists all the performance events supported by the products.
NOTE
The names of RMON performance entries may vary with the version of the NMS.
Check and error Indicates the performance events regarding service check and
correction performance bit error correction of a board, including:
events l Bit error performance events in the multiplex section
l Bit error performance events in the regeneration section
l Bit error performance events of the higher order paths
l Bit error performance events of the lower order paths
l Service performance events on the line side
l FEC service performance events
l TCM performance events
l ATM service performance events
Ethernet performance Indicates the performance events such as the package loss count
events of the receive or transmit data of a board, collision detection,
and quality.
Abbreviation Description
Abbreviation Description
rprSpanRxUcastClas-
frames/s
sAFrames
rprSpanRxUcastClas-
Byte/s
sABytes
rprSpanRxUcastClassB
- frames/s
CirFrames
rprSpanRxUcastClassB
packets/s
CirBytes
rprSpanRxUcastClass-
frames/s
BEirFrames
rprSpanRxUcastClass-
packets/s
BEirBytes
rprSpanRxUcastClassC
frames/s
Frames
rprSpanRxUcastClassC
packets/s
Bytes
rprSpanRxMcastClas-
frames/s
sAFrames
rprSpanRxMcastClas-
packets/s
sABytes
rprSpanRxMcastClass
frames/s
BCirFrames
rprSpanRxMcastClass
packets/s
BCirBytes
rprSpanRxMcastClass-
frames/s
BEirFrames
rprSpanRxMcastClass-
packets/s
BEirBytes
rprSpanRxMcastClass
frames/s
CFrames
rprSpanRxMcastClass
packets/s
CBytes
rprSpanTxUcastClas-
frames/s
sAFrames
rprSpanTxUcastClas-
packets/s
sABytes
rprSpanTxUcastClassB
frames/s
CirFrames
rprSpanTxUcastClassB
packets/s
CirBytes
rprSpanTxUcastClass-
frames/s
BEirFrames
rprSpanTxUcastClass-
packets/s
BEirBytes
rprSpanTxUcastClassC
frames/s
Frames
rprSpanTxUcastClassC
packets/s
Bytes
rprSpanTxMcastClas-
frames/s
sAFrames
rprSpanTxMcastClas-
packets/s
sABytes
rprSpanTxMcastClass
BCirFrames frames/s
rprSpanTxMcastClass
BCirBytes packets/s
rprSpanTxMcastClass-
BEirFrames frames/s
rprSpanTxMcastClass-
packets/s
BEirBytes
rprSpanTxMcastClass
frames/s
CFrames
rprSpanTxMcastClass
packets/s
CBytes
rprSpanTxCtrlFrames frames/s
rprSpanTxOamEcho-
frames/s
Frames
rprSpanTxOamFlush-
frames/s
Frames
rprSpanTxOamOrg-
frames/s
Frames
rprSpanTxTopoAtd-
frames/s
Frames
rprSpanTxTopoChk-
frames/s
SumFrames
rprSpanTxTopoTp-
frames/s
Frames
rprSpanRxCtrlFrames frames/s
rprSpanRxOamEcho-
Frames frames/s
rprSpanRxOamFlush-
Frames frames/s
rprSpanRxOamOrg-
Frames frames/s
rprSpanRxTopoAtd-
Frames frames/s
rprSpanRxTopoChk-
frames/s
SumFrames
rprSpanRxTopoTp-
frames/s
Frames
rprClientTxUcastClas-
frames/s
sAFrames
rprClientTxUcastClas-
packets/s
sABytes
rprClientTxUcast-
frames/s
ClassBCirFrames
rprClientTxUcast-
packets/s
ClassBCirBytes
rprClientTxUcast-
frames/s
ClassBEirFrames
rprClientTxUcast-
packets/s
ClassBEirBytes
rprClientTxUcast-
frames/s
ClassCFrames
rprClientTxUcast-
packets/s
ClassCBytes
rprClientTxMcastClas-
frames/s
sAFrames
rprClientTxMcastClas-
packets/s
sABytes
rprClientTxMcast-
frames/s
ClassBCirFrames
rprClientTxMcast-
packets/s
ClassBCirBytes
rprClientTxMcast-
frames/s
ClassBEirFrames
rprClientTxMcast-
packets/s
ClassBEirBytes
rprClientTxMcast-
frames/s
ClassCFrames
rprClientTxMcast-
packets/s
ClassCBytes
rprClientTxBcast-
frames/s
Frames
rprClientRxUcastClas-
frames/s
sAFrames
rprClientRxUcastClas-
packets/s
sABytes
rprClientRxUcast-
frames/s
ClassBCirFrames
rprClientRxUcast-
packets/s
ClassBCirBytes
rprClientRxUcast-
frames/s
ClassBEirFrames
rprClientRxUcast-
packets/s
ClassBEirBytes
rprClientRxUcast-
frames/s
ClassCFrames
rprClientRxUcast-
packets/s
ClassCBytes
rprClientRxMcastClas-
frames/s
sAFrames
rprClientRxMcastClas-
packets/s
sABytes
rprClientRxMcast-
frames/s
ClassBCirFrames
rprClientRxMcast-
packets/s
ClassBCirBytes
rprClientRxMcast-
frames/s
ClassBEirFrames
rprClientRxMcast-
frames/s
ClassBEirBytes
rprClientRxMcast-
frames/s
ClassCFrames
rprClientRxMcast-
packets/s
ClassCBytes
rprClientRxBcast-
frames/s
Frames
rprSpanErrorTtlExp-
frames/s
Frames
rprSpanErrorTooLong-
frames/s
Frames
rprSpanErrorTooShort-
frames/s
Frames
rprSpanErrorBadHec-
frames/s
Frames
rprSpanErrorBadFcs-
frames/s
Frames
rprSpanErrorSelfSrcU-
frames/s
castFrames
rprSpanErrorPmdA-
frames/s
bortFrames
rprSpanErrorBadAddr-
frames/s
Frames
rprSpanErrorBadPari-
frames/s
tyFrames
rprSpanErrorContai-
frames/s
nedFrames
rprSpanErrorBadDa-
frames/s
taFcsFrames
rprSpanErrorBadCtrlFc
frames/s
sFrames
rprSpanErrorScffErrors frames/s
rprSpanErrorErrored-
seconds/s
Seconds
rprSpanErrorSevere-
seconds/s
lyErroredSeconds
rprSpanErrorUnavaila-
seconds/s
bleSeconds
10.2.1 BA2
WCVMAX WCVMIN WCVCUR
10.2.2 N1BPA
WCVMAX WCVMIN WCVCUR
10.2.3 N2BPA
WCVMAX WCVMIN WCVCUR
10.2.4 COA
BDTEMPMAX BDTEMPMIN BDTEMPCUR
10.2.5 N1ADL4
VC3UAS
ATM_TRAN_CELL
10.2.6 N1ADQ1
VC3UAS
ATM_TRAN_CELL
10.2.7 N1DX1
LPBBE LPCSES LPFECSES
CRC4_ERR DDN_CRC4_ERR
10.2.8 N1DXA
LPBBE LPCSES LPFECSES
CRC4_ERR
10.2.9 N1EFS0
Table 10-19 SDH
HPBBE HPCSES HPES
LPSES LPUAS
AlignmentErrors FCSErrors
Packets
Received(256~511
Octets in Length) Packets Received(512~1023 Packets Received(1024~1518
(packets) Octets in Length)(packets) Octets in Length)(packets)
Packets
Received(packets)
Packets
Transmitted(256~511 Packets Packets
Octets in Length) Transmitted(512~1023 Transmitted(1024~1518 Octets
(packets) Octets in Length)(packets) in Length)(packets)
10.2.10 N1EFS0A
Table 10-23 SDH
HPBBE HPCSES HPES
BDTEMPMAX BDTEMPMIN
AlignmentErrors FCSErrors
Packets
Packets Received(256~511 Received(512~1023 Octets Packets Received(1024~1518
Octets in Length)(packets) in Length)(packets) Octets in Length)(packets)
Packets Received(packets)
VCG_TXSPEED VCG_RXSPEED
10.2.11 N1EFS4
LPSES LPUAS
AlignmentErrors FCSErrors
Packets Received(64
Octets in Length) Packets Received(65~127 Packets Received(128~255
(packets) Octets in Length)(packets) Octets in Length)(packets)
Packets
Received(256~511
Octets in Length) Packets Received(512~1023 Packets Received(1024~1518
(packets) Octets in Length)(packets) Octets in Length)(packets)
Packets
Received(packets)
Packets Transmitted(64
Octets in Length) Packets Transmitted(65~127 Packets Transmitted(128~255
(packets) Octets in Length)(packets) Octets in Length)(packets)
Packets
Transmitted(256~511 Packets Packets
Octets in Length) Transmitted(512~1023 Transmitted(1024~1518 Octets
(packets) Octets in Length)(packets) in Length)(packets)
10.2.12 N1EFT8
AlignmentErrors FCSErrors
Packets
Received(512~1023 Octets Packets Received(1024~1518
in Length)(packets) Octets in Length)(packets)
Bad Octets
Transmitted(Byte) FCS Errors(frames)
10.2.13 N1EFT8A
Table 10-36 SDH
HPBBE HPCSES HPES
AlignmentErrors FCSErrors
Packets
Received(512~1023 Octets Packets Received(1024~1518
in Length)(packets) Octets in Length)(packets)
Packets
Packets Transmitted(64 Packets Transmitted(65~127 Transmitted(128~255
Octets in Length)(packets) Octets in Length)(packets) Octets in Length)(packets)
Bad Octets
Transmitted(Byte) FCS Errors(frames)
10.2.14 N1EGS4
LateCollisions DeferredTransmissions
Oversize Packets
Received(packets)
10.2.15 N1EGT2
LPUAS
Packets
Received(256~511 Packets
Octets in Length) Received(512~1023 Octets Packets Received(1024~1518
(packets/s) in Length)(packets/s) Octets in Length)(packets/s)
Packets
Packets Transmitted(512~1023 Packets
Transmitted(256~511 Octets Octets in Length) Transmitted(1024~1518
in Length)(packets/s) (packets/s) Octets in Length)(packets/s)
10.2.16 N1EMS2
Table 10-50 SDH
HPBBE HPCSES HPES
BDTEMPMAX BDTEMPMIN
AlignmentErrors FCSErrors
Packets
Packets Received(256~511 Received(512~1023 Octets Packets Received(1024~1518
Octets in Length)(packets) in Length)(packets) Octets in Length)(packets)
Packets Received(packets)
VCG_TXSPEED VCG_RXSPEED
10.2.17 N1EMS4
Table 10-55 SDH
HPBBE HPCSES HPES
LateCollisions DeferredTransmissions
Oversize Packets
Received(packets)
NOTE
Only half-duplex FE electrical port supports "Delayed frames", "Late collisions", "Single Collision
Frames", and "Multiple Collision Frames".
10.2.18 N1EFP0
Table 10-60 SDH
BDTEMPCUR
Packets
Received(256~511
Octets in Length) Packets Received(512~1023 Packets Received(1024~1518
(packets) Octets in Length)(packets) Octets in Length)(packets)
Packets
Received(packets)
Packets
Packets Transmitted(512~1023 Packets
Transmitted(256~511 Octets Octets in Length) Transmitted(1024~1518 Octets
in Length)(packets) (packets) in Length)(packets)
Good Full Frame Speed Good Full Frame Octets Good Full Frame Octets
Transmitted(Byte/s) Received(Byte) Transmitted(Byte)
10.2.19 N1IDL4
TPLMAX TPLMIN
ATM_TRAN_CELL
10.2.20 N1IDL4A
TPLMAX TPLMIN
ATM_TRAN_CELL
10.2.21 N1IDQ1
TPLMAX TPLMIN
ATM_TRAN_CELL
10.2.22 N1IDQ1A
Table 10-71 SDH
AUPJCHIGH AUPJCLOW AUPJCNEW
TPLMAX TPLMIN
ATM_TRAN_CELL
10.2.23 N1IFSD1
AUPJCHIGH AUPJCLOW AUPJCNEW
BDTEMPMIN BDTEMPCUR
10.2.24 N1LWX
LSBISACUR LSBISAMAX LSBISAMIN
10.2.25 N1MST4
AUPJCHIGH AUPJCLOW HPBBE
TPLMAX TPLMIN
10.2.26 N1PD3
E3_LCV_SDH E3_LES_SDH E3_LSES_SDH
10.2.27 N1PL3
E3_LCV_SDH E3_LES_SDH E3_LSES_SDH
10.2.28 N1PL3A
E3_LCV_SDH E3_LES_SDH E3_LSES_SDH
TUPJCNEW
10.2.29 N1PQ1
LPBBE LPCSES LPES
10.2.30 N1PQM
CRC4_ERR CRC6_ERR E1_LCV_SDH
TUPJCHIGH TUPJCLOW
10.2.31 N1RPC01
LSOOPMAX LSOOPMIN LSOOPCUR
10.2.32 N1RPC02
LSOOPMAX LSOOPMIN LSOOPCUR
10.2.33 N1SEP
AUPJCHIGH AUPJCLOW AUPJCNEW
10.2.34 N1SEP1
AUPJCHIGH AUPJCLOW AUPJCNEW
10.2.35 N1SF16
AUPJCHIGH AUPJCLOW AUPJCNEW
TPLMAX TPLMIN
10.2.36 N1SL1
AUPJCHIGH AUPJCLOW AUPJCNEW
10.2.37 N1SL1A
AUPJCHIGH AUPJCLOW AUPJCNEW
10.2.38 N1SL4
AUPJCHIGH AUPJCLOW AUPJCNEW
10.2.39 N1SL4A
AUPJCHIGH AUPJCLOW AUPJCNEW
10.2.40 N1SL16
AUPJCHIGH AUPJCLOW AUPJCNEW
10.2.41 N1SL16A
AUPJCHIGH AUPJCLOW AUPJCNEW
10.2.42 N1SLD4
AUPJCHIGH AUPJCLOW AUPJCNEW
10.2.43 N1SLD4A
AUPJCHIGH AUPJCLOW AUPJCNEW
10.2.44 N1SLQ1
AUPJCHIGH AUPJCLOW AUPJCNEW
10.2.45 N1SLQ1A
AUPJCHIGH AUPJCLOW AUPJCNEW
10.2.46 N1SLQ4
AUPJCHIGH AUPJCLOW AUPJCNEW
10.2.47 N1SLQ4A
AUPJCHIGH AUPJCLOW AUPJCNEW
10.2.48 N1SLT1
AUPJCHIGH AUPJCLOW AUPJCNEW
10.2.49 N1SPQ4
AUPJCHIGH AUPJCLOW AUPJCNEW
RSSES RSUAS
10.2.50 N2EFS0
Table 10-73 SDH
HPBBE HPCSES HPES
LPSES LPUAS
AlignmentErrors FCSErrors
Packets Received(64
Octets in Length) Packets Received(65~127 Packets Received(128~255
(packets) Octets in Length)(packets) Octets in Length)(packets)
Packets
Received(256~511
Octets in Length) Packets Received(512~1023 Packets Received(1024~1518
(packets) Octets in Length)(packets) Octets in Length)(packets)
Packets
Received(packets)
Packets Transmitted(64
Octets in Length) Packets Transmitted(65~127 Packets Transmitted(128~255
(packets) Octets in Length)(packets) Octets in Length)(packets)
Packets
Transmitted(256~511 Packets Packets
Octets in Length) Transmitted(512~1023 Transmitted(1024~1518 Octets
(packets) Octets in Length)(packets) in Length)(packets)
10.2.51 N2EFS4
Table 10-77 SDH
LPSES LPUAS
AlignmentErrors FCSErrors
Packets Received(64
Octets in Length) Packets Received(65~127 Packets Received(128~255
(packets) Octets in Length)(packets) Octets in Length)(packets)
Packets
Received(256~511
Octets in Length) Packets Received(512~1023 Packets Received(1024~1518
(packets) Octets in Length)(packets) Octets in Length)(packets)
Packets
Received(packets)
Packets Transmitted(64
Octets in Length) Packets Transmitted(65~127 Packets Transmitted(128~255
(packets) Octets in Length)(packets) Octets in Length)(packets)
Packets
Transmitted(256~511 Packets Packets
Octets in Length) Transmitted(512~1023 Transmitted(1024~1518 Octets
(packets) Octets in Length)(packets) in Length)(packets)
10.2.52 N2EFT8
RXPKT512 RXPKT1024
TXPKT512 TXPKT1024
10.2.53 N2EFT8A
Table 10-86 SDH
HPBBE HPES HPSES
RXPKT512 RXPKT1024
TXPKT512 TXPKT1024
10.2.54 N2EGR2
Table 10-91 SDH
HPBBE HPCSES HPES
Packets
Received(packets/s)
FCS Errors(frames/s)
Table 10-95 Statistics of RMON VCG performance (receive frame count at Span side)
rprSpanRxMcastClassC-
Bytes(Byte/s)
Table 10-96 Statistics of RMON VCG performance (transmit frame count at Span side)
rprSpanTxUcastClassA- rprSpanTxUcastClassA- rprSpanTxUcastClassBCir-
Frames(frames/s) Bytes(Byte/s) Frames(frames/s)
rprSpanTxMcastClassC-
Bytes(Byte/s)
Table 10-97 Statistics of RMON VCG performance (count of control layer frames)
rprSpanTxCtrlFrames(frame rprSpanTxOamEcho- rprSpanTxOamFlush-
s/s) Frames(frames/s) Frames(frames/s)
rprSpanRxTopoChkSum- rprSpanRxTopoTp-
Frames(frames/s) Frames(frames/s)
rprClientTxMcastClassC- rprClientTxBcast-
Bytes(Byte/s) Frames(frames/s)
rprClientRxMcastClassC- rprClientRxBcast-
Bytes(Byte/s) Frames(frames/s)
rprSpanErrorUnavailable-
Seconds(seconds/s)
10.2.55 N2EGS2
LPSES LPUAS
AlignmentErrors
Packets Packets
Transmitted(256~511 Transmitted(512~1023 Packets
Octets in Length) Octets in Length) Transmitted(1024~1518 Octets
(packets/s) (packets/s) in Length)(packets/s)
FCS Errors(frames/s)
10.2.56 N2EGT2
Table 10-105 SDH
HPBBE HPCSES HPES
BDTEMPMAX BDTEMPMIN
Packets
Received(256~511 Packets
Octets in Length) Received(512~1023 Octets Packets Received(1024~1518
(packets/s) in Length)(packets/s) Octets in Length)(packets/s)
Packets
Packets Transmitted(512~1023 Packets
Transmitted(256~511 Octets Octets in Length) Transmitted(1024~1518
in Length)(packets/s) (packets/s) Octets in Length)(packets/s)
10.2.57 N2EMR0
Table 10-109 SDH
HPBBE HPCSES HPES
Packets
Received(packets/s)
FCS Errors(frames/s)
Table 10-113 Statistics of RMON VCG performance (receive frame count at Span side)
rprSpanRxUcastClassA- rprSpanRxUcastClassA- rprSpanRxUcastClassBCir-
Frames(frames/s) Bytes(Byte/s) Frames(frames/s)
rprSpanRxMcastClassC-
Bytes(Byte/s)
Table 10-114 Statistics of RMON VCG performance (transmit frame count at Span side)
rprSpanTxMcastClassC-
Bytes(Byte/s)
Table 10-115 Statistics of RMON VCG performance (count of control layer frames)
rprSpanRxTopoChkSum- rprSpanRxTopoTp-
Frames(frames/s) Frames(frames/s)
rprClientTxMcastClassC- rprClientTxBcast-
Bytes(Byte/s) Frames(frames/s)
rprClientRxMcastClassC- rprClientRxBcast-
Bytes(Byte/s) Frames(frames/s)
rprSpanErrorUnavailable-
Seconds(seconds/s)
10.2.58 N2PD3
CRC4_ERR CRC6_ERR E3_LCV_SDH
LPFECSES
10.2.59 N2PL3
CRC4_ERR CRC6_ERR E3_LCV_SDH
LPFECSES
10.2.60 N2PL3A
CRC4_ERR CRC6_ERR E3_LCV_SDH
LPFECSES
10.2.61 N2PQ1
CRC4_ERR E1_LCV_SDH E1_LES_SDH
10.2.62 N2PQ3
CRC4_ERR CRC6_ERR E3_LCV_SDH
LPFECSES
10.2.63 N2SL1
AUPJCHIGH AUPJCLOW AUPJCNEW
10.2.64 N2SL4
AUPJCHIGH AUPJCLOW AUPJCNEW
10.2.65 N2SL16
AUPJCHIGH AUPJCLOW AUPJCNEW
10.2.66 N2SL16A
AUPJCHIGH AUPJCLOW AUPJCNEW
10.2.67 N2SLD4
AUPJCHIGH AUPJCLOW AUPJCNEW
10.2.68 N2SLO1
AUPJCHIGH AUPJCLOW AUPJCNEW
10.2.69 N2SLQ1
AUPJCHIGH AUPJCLOW AUPJCNEW
10.2.70 N2SLQ4
AUPJCHIGH AUPJCLOW AUPJCNEW
10.2.71 N2SPQ4
AUPJCHIGH AUPJCLOW AUPJCNEW
RSSES RSUAS
10.2.72 N3EFS4
Table 10-119 SDH
HPBBE HPCSES HPES
BDTEMPMAX BDTEMPMIN
AlignmentErrors FCSErrors
Packets
Packets Received(256~511 Received(512~1023 Octets Packets Received(1024~1518
Octets in Length)(packets) in Length)(packets) Octets in Length)(packets)
Packets Received(packets)
VCG_TXSPEED VCG_RXSPEED
10.2.73 N3EGS2
Table 10-124 SDH
HPBBE HPCSES HPES
BDTEMPMIN BDTEMPCUR
FCSErrors
Packets
Packets Transmitted(64 Transmitted(65~127
Octets in Length) Octets in Length) Packets Transmitted(128~255
(packets/s) (packets/s) Octets in Length)(packets/s)
Packets Packets
Transmitted(256~511 Transmitted(512~1023 Packets
Octets in Length) Octets in Length) Transmitted(1024~1518 Octets
(packets/s) (packets/s) in Length)(packets/s)
FCS Errors(frames/s)
VCG_TXSPEED VCG_RXSPEED
10.2.74 N3EGS4
LateCollisions DeferredTransmissions
Oversize Packets
Received(packets)
10.2.75 N3SL16
AUPJCHIGH AUPJCLOW AUPJCNEW
10.2.76 N3SL16A
AUPJCHIGH AUPJCLOW AUPJCNEW
10.2.77 N3SLQ41
AUPJCHIGH AUPJCLOW AUPJCNEW
10.2.78 N4SLD64
RSBBE RSES RSSES
10.2.79 N4EFS0
Table 10-134 SDH
HPBBE HPCSES HPES
LPSES LPUAS
AlignmentErrors FCSErrors
Packets Received(64
Octets in Length) Packets Received(65~127 Packets Received(128~255
(packets) Octets in Length)(packets) Octets in Length)(packets)
Packets
Received(256~511
Octets in Length) Packets Received(512~1023 Packets Received(1024~1518
(packets) Octets in Length)(packets) Octets in Length)(packets)
Packets
Received(packets)
Packets Transmitted(64
Octets in Length) Packets Transmitted(65~127 Packets Transmitted(128~255
(packets) Octets in Length)(packets) Octets in Length)(packets)
Packets
Transmitted(256~511 Packets Packets
Octets in Length) Transmitted(512~1023 Transmitted(1024~1518 Octets
(packets) Octets in Length)(packets) in Length)(packets)
10.2.80 N4EGS4
Table 10-138 SDH
Oversize Packets
Received(packets)
10.2.81 N5EFS0
BDTEMPMAX BDTEMPMIN
AlignmentErrors FCSErrors
Packets
Packets Received(256~511 Received(512~1023 Octets Packets Received(1024~1518
Octets in Length)(packets) in Length)(packets) Octets in Length)(packets)
Packets Received(packets)
Packets
Packets Transmitted(64 Transmitted(65~127 Packets Transmitted(128~255
Octets in Length)(packets) Octets in Length)(packets) Octets in Length)(packets)
VCG_TXSPEED VCG_RXSPEED
10.2.82 ODU
ENVTMPMAX ENVTMPMIN ENVTMPCUR
10.2.83 Q2CXL1
GSCC
BDTEMPMAX BDTEMPMIN BDTEMPCUR
Q1SL1
AUPJCHIGH AUPJCLOW AUPJCNEW
TPLMAX TPLMIN
10.2.84 Q2CXL4
GSCC
BDTEMPMAX BDTEMPMIN BDTEMPCUR
Q1SL4
AUPJCHIGH AUPJCLOW AUPJCNEW
TPLMAX TPLMIN
10.2.85 Q2CXL16
GSCC
BDTEMPMAX BDTEMPMIN BDTEMPCUR
Q1SL16
AUPJCHIGH AUPJCLOW AUPJCNEW
TPLMAX TPLMIN
10.2.86 Q3CXL1
GSCC
BDTEMPMAX BDTEMPMIN BDTEMPCUR
Q1SL1
AUPJCHIGH AUPJCLOW AUPJCNEW
TPLMAX TPLMIN
10.2.87 Q3CXL4
GSCC
BDTEMPMAX BDTEMPMIN BDTEMPCUR
Q1SL4
AUPJCHIGH AUPJCLOW AUPJCNEW
TPLMAX TPLMIN
10.2.88 Q3CXL16
GSCC
BDTEMPMAX BDTEMPMIN BDTEMPCUR
Q1SL16
AUPJCHIGH AUPJCLOW AUPJCNEW
TPLMAX TPLMIN
10.2.89 Q5CXLLN
GSCC
BDTEMPMAX BDTEMPMIN BDTEMPCUR
Q2SLN
AUPJCHIGH AUPJCLOW AUPJCNEW
10.2.90 Q5CXLQ41
GSCC
BDTEMPMAX BDTEMPMIN BDTEMPCUR
Q2SLQ41
AUPJCHIGH AUPJCLOW AUPJCNEW
10.2.91 R1CXLLN
GSCC
BDTEMPMAX BDTEMPMIN BDTEMPCUR
R1SLN
AUPJCHIGH AUPJCLOW AUPJCNEW
10.2.92 R1CXLD41
GSCC
BDTEMPMAX BDTEMPMIN BDTEMPCUR
R1SLD41
AUPJCHIGH AUPJCLOW AUPJCNEW
10.2.93 R1CXLQ41
GSCC
BDTEMPMAX BDTEMPMIN BDTEMPCUR
R1SLQ41
AUPJCHIGH AUPJCLOW AUPJCNEW
10.2.94 R1EFT4
Packets
Received(512~1023 Octets Packets Received(1024~1518
in Length)(packets) Octets in Length)(packets)
Bad Octets
Transmitted(Byte) FCS Errors(frames)
10.2.95 R1PD1
LPBBE LPCSES LPES
TUPJCNEW
10.2.96 R1PL1
LPBBE LPCSES LPES
TUPJCNEW
10.2.97 R1SL1
AUPJCHIGH AUPJCLOW AUPJCNEW
TPLMAX TPLMIN
10.2.98 R1SL4
AUPJCHIGH AUPJCLOW AUPJCNEW
TPLMAX TPLMIN
10.2.99 R1SLD4
AUPJCHIGH AUPJCLOW AUPJCNEW
TPLMAX TPLMIN
10.2.100 R1SLQ1
AUPJCHIGH AUPJCLOW AUPJCNEW
TPLMAX TPLMIN
10.2.101 R2CXLLN
GSCC
BDTEMPMAX BDTEMPMIN BDTEMPCUR
R2SLN
AUPJCHIGH AUPJCLOW AUPJCNEW
10.2.102 R2CXLQ41
GSCC
BDTEMPMAX BDTEMPMIN BDTEMPCUR
R2SLQ41
AUPJCHIGH AUPJCLOW AUPJCNEW
10.2.103 R2PD1
CRC4_ERR E1_LCV_SDH E1_LES_SDH
10.2.104 R3PD1
CRC4_ERR E1_LCV_SDH E1_LES_SDH
10.2.105 R3SL1
AUPJCHIGH AUPJCLOW AUPJCNEW
10.2.106 R3SL4
AUPJCHIGH AUPJCLOW AUPJCNEW
10.2.107 R3SLD4
AUPJCHIGH AUPJCLOW AUPJCNEW
10.2.108 R3SLQ1
AUPJCHIGH AUPJCLOW AUPJCNEW
This chapter describes the method and steps of clearing the performance events.
NOTE
For bit error clearing, see "Troubleshooting Bit Errors" of the Troubleshooting.
11.1.1 ATM_CORRECTED_HCSERR
Description
The ATM_CORRECTED_HCSERR indicates the number of cells that are received by an
ATM port and contain correctable header check sequence (HCS) errors. When a correctable
HCS error cell is received, it indicates that there is a correctable single-bit error in the cell
header. According to this single-bit error, you can determine the quality of the service
received by the port.
Attribute
Performance Event ID Performance Event Type
Impact on System
None.
Related Alarms
Alarm Name Correlation
Procedure
Step 1 Check whether any bit error alarms such as B1 and B2 occur in the SDH services on the
cross-connect side and on the external optical interface side. If yes, see the method of
handling bit error alarms to eliminate the bit errors.
Step 2 If there are not B1, B2, B3, or BIP2 bit error alarms in SDH paths but there is a CHCS count,
you can determine that there are bit errors at the internal physical layer. In this case, perform a
cold reset for the board.
Step 3 If the alarm and the performance event persist, the board may be faulty. In this case, replace
the board.
----End
Related Information
None.
11.1.2 ATM_EGCELL
Description
The ATM_EGCELL indicates the count of cells transmitted over the ATM connection. It is
adopted to check whether the service is normally transmitted over the ATM connection.
Attribute
Performance Event ID Performance Event Type
Impact on System
None.
Related Alarms
None.
Procedure
Step 1 If there is no count of cells:
1. Check whether any LCD alarm is generated at the ATM port of the connection, which
results in the failure of the service. If yes, clear it according to the method of clearing the
LCD alarm.
2. Check whether the start time of monitoring the ATM performance is set in the Monitor
Period field. Make sure it is set correctly.
3. Check whether the function of monitoring the ATM performance at the port is enabled.
Make sure it is enabled.
4. Check whether the time of the SCC (service control and communication unit) is
consistent with that displayed on the U2000. If not, set it to be consistent with the time
displayed on the U2000.
5. Check whether the ATM connection is set up. If not, set it up correctly.
6. Check whether the ATM connection is for multicast service, and whether the
performance event is generated at the sink of the multicast service.
7. Check whether the ATM_INGCELL shows the count at another end of the ATM
connection. If yes, the ATM processing chip on the board is faulty. In this case, perform
a cold reset on the board or replace the board.
8. If the ATM_INGCELL still does not show the count, the ATM processing chip on the
board for a upstream connection is faulty. In this case, perform a cold reset on the board
or replace the board.
Step 2 If the count of transmitted cells is inconsistent with the expected value:
1. Check whether the count is shown by the ATM_UNCORRECTED_HCSERR at the
ATM port at another end of the ATM connection or at the higher-level upstream ATM
port. If yes, clear it.
2. Check whether the count shown by the ATM_INGCELL at another end of the ATM
connection is consistent with the expected value. If yes, the ATM processing chip on the
board is faulty. In this case, perform a cold reset on the board or replace the board.
3. If the count is inconsistent with the expected value, the ATM processing chip on the
board for a upstream connection is faulty. In this case, perform a cold reset on the board
or replace the board.
----End
Related Information
None.
11.1.3 ATM_INGCELL
Description
The ATM_INCELL indicates the count of correct cells received over the ATM connection. It
is adopted to check whether the service is normally received over the ATM connection.
Attribute
Performance Event ID Performance Event Type
Impact on System
None.
Related Alarms
None.
Procedure
Step 1 If there is no count of cells:
1. Check whether any LCD alarm is generated at the ATM port of the connection, which
results in the failure of the service. If yes, clear it according to the method of clearing the
LCD alarm.
2. Check whether the start time of monitoring the ATM performance is set in the Monitor
Period field. Make sure it is set correctly.
3. Check whether the function of monitoring the ATM performance at the port is enabled.
Make sure it is enabled.
4. Check whether the time of the SCC is consistent with that displayed on the U2000. If
not, set it to be consistent with the time displayed on the U2000.
5. Check whether the ATM connection is set up. If not, set it up correctly.
6. Check whether the ATM connection is for multicast service, and whether the
performance event is generated at the source of the multicast service.
7. Check whether the ATM_EGCELL at another end of the ATM connection shows the
count. If yes, the ATM processing chip on the board is faulty. In this case, perform a cold
reset on the board or replace the board.
8. If the ATM_EGCELL still does not show the count, the ATM processing chip on the
board for a upstream connection is faulty. In this case, perform a cold reset on the board
or replace the board.
Step 2 If the count of received cells is inconsistent with the expected value:
1. Check whether the count is shown by the ATM_UNCORRECTED_HCSERR at the
ATM port at another end of the ATM connection or at the higher-level upstream ATM
port. If yes, clear it.
2. Check whether the count shown by the ATM_EGCELL at another end of the ATM
connection is consistent with the expected value. If yes, the ATM processing chip on the
board is faulty. In this case, perform a cold reset on the board or replace the board.
3. If the count is inconsistent with the expected value, the ATM processing chip on the
board for a upstream connection is faulty. In this case, perform a cold reset on the board
or replace the board.
----End
Related Information
Monitor Period: It includes 15-Minute, 24-Hour, and Custom Period (variable period, which
can be set by the user). The option 15-Minute, 24-Hour or Custom Period is adopted as a
period to accumulate the count of performance events. After the period is reached, the count
of performance events is exported from the Current Performance Data database to the History
Performance Data database. In this case, you can query the count of history performance
events on the U2000.
To monitor the performance event, you need to select the VPI and VCI values for a
connection, but you do not need to select them for a port.
11.1.4 ATM_RECV_CELL
Description
The ATM_RECV_CELL indicates the count of cells received at the ATM port. It is adopted to
check whether the service is normally received at the ATM port.
Attribute
Performance Event ID Performance Event Type
Impact on System
None.
Related Alarms
None.
Procedure
Step 1 If there is no count of cells:
1. Check whether any LCD alarm is generated at the ATM port of the connection, which
results in the failure of the service. If yes, clear it according to the method of clearing the
LCD alarm.
2. Check whether the start time of monitoring the ATM performance is set in the Monitor
Period field. Make sure it is set correctly.
3. Check whether the function of monitoring the ATM performance at the port is enabled.
Make sure it is enabled.
4. Check whether the time of the SCC is consistent with that displayed on the U2000. If
not, set it to be consistent with the time displayed on the U2000.
5. Check whether the count is shown by the ATM_TRAN_CELL at the upstream ATM
port, which is directly connected to the ATM port. If yes, the ATM processing chip on
the board is faulty. In this case, perform a cold reset on the board or replace the board.
6. If the ATM_TRAN_CELL still does not show the count, the ATM processing chip on the
board connected to a upstream port is faulty. In this case, perform a cold reset on the
board or replace the board.
Step 2 If the count of received cells is inconsistent with the expected value:
1. Check whether the count is shown by the ATM_UNCORRECTED_HCSERR at the
ATM port of the connection or at the upstream ATM port. If yes, clear it.
2. Check whether the count shown by the ATM_TRAN_CELL at the upstream ATM port,
which is directly connected to the ATM port, is consistent with the expected value. If
yes, the ATM processing chip on the board is faulty. In this case, perform a cold reset on
the board or replace the board.
3. If the count is still inconsistent with the expected value, the ATM processing chip on the
board for a upstream connection is faulty. In this case, perform a cold reset on the board
or replace the board.
----End
Related Information
None.
11.1.5 ATM_RECV_IDLECELL
Description
The ATM_RECV_IDLECELL indicates the count of empty cells received at the ATM port. It
is adopted to check whether the service is normally received at the ATM physical layer.
Attribute
Performance Event ID Performance Event Type
Impact on System
None.
Related Alarms
None.
Procedure
Step 1 If no count of empty cells is shown, handle the event according to the method described in the
"If there is no count of cells" item of the ATM_RECV_CELL.
Step 2 If the count of empty cells is inconsistent with the expected value, generally, the ATM
physical-layer chip of a upstream ATM board is faulty. In the case, perform a cold reset on the
board or replace the board.
----End
Related Information
None.
11.1.6 ATM_TRAN_CELL
Description
The ATM_TRAN_CELL indicates the count of cells transmitted at the ATM port. It is
adopted to check whether the service is normally transmitted at the ATM port.
Attribute
Performance Event ID Performance Event Type
Impact on System
None.
Related Alarms
None.
Procedure
Step 1 If there is no count of cells:
1. Check whether any LCD alarm is generated at the ATM port of the connection, which
results in the failure of the service. If yes, clear it according to the method of clearing the
LCD alarm.
2. Check whether the start time of monitoring the ATM performance is set in the Monitor
Period field. Make sure it is set correctly.
3. Check whether the function of monitoring the ATM performance at the port is enabled.
Make sure it is enabled.
4. Check whether the time of the SCC is consistent with that displayed on the U2000. If
not, set it to be consistent with the time displayed on the U2000.
5. Check whether the ATM connection is for multicast service, and whether the
performance event is generated at the sink of the multicast service.
6. If the ATM_TRAN_CELL still does not show the count, the ATM processing chip on the
board is faulty. In this case, perform a cold reset on the board or replace the board.
Step 2 If the count of transmitted cells is inconsistent with the expected value:
1. Check whether the count is shown by the ATM_UNCORRECTED_HCSERR at the
ATM port at another end of the ATM connection or at the higher-level upstream ATM
port. If yes, clear it.
2. If the count of transmitted cells is inconsistent with the expected value, the ATM
processing chip on the board is faulty. In this case, perform a cold reset on the board or
replace the board.
----End
Related Information
None.
11.1.7 ATM_UNCORRECTED_HCSERR
Description
The ATM_UNCORRECTED_HCSERR indicates the number of cells that are received by an
ATM port and contain uncorrectable header check sequence (HCS) errors. When an
uncorrectable HCS error cell is received, it indicates that there are uncorrectable multi-bit
errors in the cell header. According to the multi-bit errors, you can determine whether there is
any cell loss in the received service.
Attribute
Performance Event ID Performance Event Type
Impact on System
When this performance event is generated, cell loss already occurs. The number of lost cells
depends on the count value of this performance event.
Related Alarms
Alarm Name Correlation
Procedure
Step 1 Check whether any bit error alarms such as B1 and B2 SDH occur in the SDH services on the
cross-connect side and on the external optical interface side. If yes, see the method of
handling bit error alarms to eliminate the bit errors.
Step 2 If there are not B1, B2, B3, or BIP2 bit error alarms in SDH paths but there is a UHCS count,
you can determine that there are bit errors at the internal physical layer. In this case, perform a
cold reset for the board.
Step 3 If the alarm and the performance event persist, the board may be faulty. In this case, replace
the board.
----End
Related Information
None.
11.2.1 AUPJCHIGH
Description
The AUPJCHIGH indicates the positive justification count of the administrative unit pointer.
Attribute
Performance Event ID Performance Event Type
Impact on System
A small count of positive justification events of the AU pointer occur in the data segment.
The system is not affected. If the pointer justification event occurs frequently, you need to
find out the causes and take proper measures to ensure that the system runs stably.
Related Alarms
None.
Procedure
Step 1 Check whether clock alarms, such as the SYN_BAD, LTI, S1_SYN_CHANGE, and
EXT_SYNC_LOS, are generated in the whole network. If yes, take priority to clear them.
Step 2 For the network-wide pointer justification, check whether the clock configurations are
consistent with those specified in the plan, including clock ID, SSM protocol, and clock
tracing level.
Step 3 For the non-network-wide pointer justification, check whether the optical fibers are connected
correctly, and whether the ambient temperature of the equipment is within the specified value
range. If the AU pointer justification event occurs continuously, contact the technical support
engineers from Huawei.
----End
Related Information
None.
11.2.2 AUPJCLOW
Description
The AUPJCLOW indicates the negative justification count of the administrative unit pointer.
Attribute
Performance Event ID Performance Event Type
Impact on System
A small count of negative justification events of the AU pointer occur in the data segment.
The system is not affected. If the pointer justification event occurs frequently, you need to
find out the causes and take proper measures to ensure that the system runs stably.
l The clocks in two NEs trace each other because the optical fibers are connected
incorrectly.
l The equipment performance is degraded due to high temperature.
l The clocks are configured incorrectly. If the extended SSM protocol is enabled but the
clock IDs are not set, the loss of the primary clock source causes the network-wide
pointer justification event.
l The clock quality is degraded because the SSM clock protection is disabled.
l The performance of the line board is degraded.
l The performance of the clock board is degraded.
Related Alarms
None.
Procedure
Step 1 Check whether clock alarms, such as the SYN_BAD, LTI, S1_SYN_CHANGE, and
EXT_SYNC_LOS, are generated in the whole network. If yes, take priority to clear them.
Step 2 For the network-wide pointer justification, check whether the clock configurations are
consistent with those specified in the plan, including clock ID, SSM protocol, and clock
tracing level.
Step 3 For the non-network-wide pointer justification, check whether the optical fibers are connected
correctly, and whether the ambient temperature of the equipment is within the specified value
range. If the AU pointer justification event occurs continuously, contact the technical support
engineers from Huawei.
----End
Related Information
None.
11.2.3 AUPJCNEW
Description
The AUPJCNEW indicates the new count of administrative unit pointer.
Attribute
Performance Event ID Performance Event Type
Impact on System
A new count of AU pointers is generated. The system is not affected. If a new count of AU
pointers is generated frequently, you need to find out the causes and take proper measures to
ensure that the system runs stably.
Related Alarms
None.
Procedure
Step 1 Check whether clock alarms, such as the SYN_BAD, LTI, S1_SYN_CHANGE, and
EXT_SYNC_LOS, are generated in the whole network. If yes, take priority to clear them.
Step 2 For the network-wide pointer justification, check whether the clock configurations are
consistent with those specified in the plan, including clock ID, SSM protocol, and clock
tracing level.
Step 3 For the non-network-wide pointer justification, check whether the optical fibers are connected
correctly, and whether the ambient temperature of the equipment is within the specified value
range. If the AU pointer justification event occurs continuously, contact the technical support
engineers from Huawei.
----End
Related Information
None.
11.2.4 BCV
Description
Pump Laser Back Facet Current
It includes:
l BCVMAX: stand for the maximum value during a period of time.
l BCVMIN: stand for the minimum value during a period of time.
l BCVCUR: stand for the current value.
Attribute
Performance Event ID Performance Event Type
BCVMIN: 0x77
BCVCUR: 0x78
Impact on System
None.
Related Alarms
None.
Procedure
Step 1 None
----End
Related Information
None.
11.2.5 CCV
Description
Pump Laser Cooling Current
It includes:
l CCVMAX: the maximum value during a period of time.
l CCVMIN: the minimum value during a period of time.
l CCVCUR: the current value.
Attribute
Performance Event Performance Event Type
ID
CCVMIN: 0x74
CCVCUR: 0x75
Impact on System
None.
Related Alarms
Alarm Name Correlation
Procedure
Step 1 If any alarm occurs, use the method of the related alarm to clear it.
----End
Related Information
None.
11.2.6 CRC4_ERR
Description
The CRC4_ERR is a performance event indicating the CRC4 check errors.
Attribute
Performance Event Performance Event Type
ID
Impact on System
If bit errors occur in the tributary services on an NE but no related alarms are reported on the
NE, the system will not be affected. However, you need to find out the causes and
troubleshoot the problem in a timely manner. Otherwise, alarms will be generated and the
signal transmission quality will be affected.
External causes:
Equipment problems:
l The signal attenuation at the receiving side of the NE tributary board is excessive, the
transmitting circuit of the opposite end is faulty, or the receiving circuit of the local end
is faulty.
l The performance of the NE clock synchronization is poor.
l The cross-connect unit and the line board or the tributary board poorly match.
l The NE tributary board is faulty.
l Fans of the NE fail;
l The board fails or the board performance degrades.
l The CRC settings of the interconnected equipment and the local equipment are different.
Related Alarms
None.
Procedure
Step 1 First, eliminate external causes, such as poor grounding and too high operating temperature. If
possible, perform a loopback to locate the fault.
Step 2 Troubleshoot the problems caused by the inconsistency between the CRC setting of the
interconnected equipment and that of the local equipment.
Step 3 If only the tributary reports bit errors, the problem may lie in the cooperation of the cross-
connect unit and tributary board at the local station. Replace the tributary board and SCB
board to verify the faulty point and remove the fault.
----End
Related Information
None.
11.2.7 DDN_CRC4_ERR
Description
The DDN_CRC4_ERR is a performance event indicating the CRC4 error on DDN side.
Attribute
Performance Event Performance Event Type
ID
Impact on System
If bit errors occur in the services on an NE but no related alarms are reported on the NE, the
system will not be affected. However, you need to find out the causes and troubleshoot the
problem in a timely manner. Otherwise, alarms will be generated and the signal transmission
quality will be affected.
Related Alarms
None.
Procedure
Step 1 Refer to the 11.2.6 CRC4_ERR.
----End
Related Information
None.
11.2.8 E1_LCV_SDH
Description
The E1_LCV_SDH is a performance event indicating the E1 line side code violation count.
Attribute
Performance Event Performance Event Type
ID
Impact on System
If bit errors occur in the services, you need to find out the causes and troubleshoot the
problem in a timely manner. Otherwise, alarms will be generated and the signal transmission
quality will be affected.
Equipment problems:
Related Alarms
None.
Procedure
Step 1 First eliminate external causes, such as poor grounding, too high operating temperature, too
low or too high the receiving optical power of the line board.
Step 2 Check whether the correct E1 service code is selected. If not, modify the code of the servces
received by a board by setting the code type of the board.
Step 3 The port of the tributary board may be faulty. Replace the board.
----End
Related Information
None.
11.2.9 E1_LES_SDH
Description
The E1_LES_SDH is a performance event indicating the E1 line side code violation errored
second.
Attribute
Performance Event Performance Event Type
ID
Impact on System
If bit errors occur in the services, you need to find out the causes and troubleshoot the
problem in a timely manner. Otherwise, alarms will be generated and the signal transmission
quality will be affected.
External causes:
l The fiber performance is degraded, and the fiber has extremely high attenuation.
l The fiber connector is dirty or incorrect.
l The equipment is poorly grounded.
l There is a strong interference source around the equipment.
l The working temperature is extremely high or extremely low, and the opposite
equipment cannot tolerate such temperature.
Equipment problems:
Related Alarms
None.
Procedure
Step 1 Refer to the 11.2.8 E1_LCV_SDH.
----End
Related Information
None.
11.2.10 E1_LSES_SDH
Description
The E1_LSES_SDH is a performance event indicating the E1 line side code violation severely
errored second.
Attribute
Performance Event Performance Event Type
ID
Impact on System
If bit errors occur in the services, you need to find out the causes and troubleshoot the
problem in a timely manner. Otherwise, alarms will be generated and the signal transmission
quality will be affected.
Related Alarms
None.
Procedure
Step 1 Refer to the 11.2.8 E1_LCV_SDH.
----End
Related Information
None.
11.2.11 E3_LCV_SDH
Description
The E3_LCV_SDH is a performance event indicating the E3 line side code violation count.
Attribute
Performance Event Performance Event Type
ID
Impact on System
If bit errors occur in the services, you need to find out the causes and troubleshoot the
problem in a timely manner. Otherwise, alarms will be generated and the signal transmission
quality will be affected.
External causes:
l The fiber performance is degraded, and the fiber has extremely high attenuation.
l The fiber connector is dirty or incorrect.
l The equipment is poorly grounded.
l There is a strong interference source around the equipment.
l The working temperature is extremely high or extremely low, and the opposite
equipment cannot tolerate such temperature.
Equipment problems:
Related Alarms
None.
Procedure
Step 1 First eliminate external causes, such as poor grounding, too high operating temperature, too
low or too high the receiving optical power of the line board.
Step 2 Check whether the correct E3 service code is selected. If not, modify the code of the servces
received by a board by setting the code type of the board.
Step 3 The port of the tributary board may be faulty. Replace the board.
----End
Related Information
None.
11.2.12 E3_LES_SDH
Description
The E3_LES_SDH is a performance event indicating the E3 line side code violation errored
second.
Attribute
Performance Event Performance Event Type
ID
Impact on System
If bit errors occur in the services, you need to find out the causes and troubleshoot the
problem in a timely manner. Otherwise, alarms will be generated and the signal transmission
quality will be affected.
Related Alarms
None.
Procedure
Step 1 Refer to the 11.2.11 E3_LCV_SDH.
----End
Related Information
None.
11.2.13 E3_LSES_SDH
Description
The E3_LSES_SDH is a performance event indicating the E3 line side code violation severely
errored second.
Attribute
Performance Event Performance Event Type
ID
Impact on System
If bit errors occur in the services, you need to find out the causes and troubleshoot the
problem in a timely manner. Otherwise, alarms will be generated and the signal transmission
quality will be affected.
External causes:
l The fiber performance is degraded, and the fiber has extremely high attenuation.
l The fiber connector is dirty or incorrect.
l The equipment is poorly grounded.
l There is a strong interference source around the equipment.
l The working temperature is extremely high or extremely low, and the opposite
equipment cannot tolerate such temperature.
Equipment problems:
Related Alarms
None.
Procedure
Step 1 Refer to the 11.2.11 E3_LCV_SDH.
----End
Related Information
None.
11.2.14 EDTMP
Description
The EDTMP is a performance event indicating the laser temperature. It contains the
EDTMPMAX, EDTMPMIN, and EDTMPCUR, which respectively indicates the maximum
value, minimum value, and current value during a period of time.
Attribute
Performance Event Performance Event Type
ID
EDTMPMIN: 0x83
EDTMPCUR: 0x84
Impact on System
None.
Related Alarms
Alarm Name Correlation
Procedure
Step 1 If any alarm occurs, use the method of the related alarm to clear it.
----End
Related Information
None.
11.2.15 EDRPL
Description
The EDRPL is a performance event indicating the output optical power. It contains the
EDRPLMAX, EDRPLMIN, and EDRPLCUR, which respectively indicates the maximum
value, minimum value, and current value during a period of time.
Attribute
Performance Event Performance Event Type
ID
EDRPLMIN: 0x7D
EDRPLCUR: 0x7E
Impact on System
Bit errors may be generated in the services and the services may be interrupted.
Related Alarms
Alarm Name Correlation
Procedure
Step 1 If any alarm occurs, use the method of the related alarm to clear it.
----End
Related Information
None.
11.2.16 EDTPL
Description
The EDTPL is a performance event indicating the output optical power. It contains the
EDTPLMAX, EDTPLMIN, and EDTPLCUR, which respectively indicates the maximum
value, minimum value, and current value during a period of time.
Attribute
Performance Event Performance Event Type
ID
EDTPLMIN: 0x7A
EDTPLCUR: 0x7B
Impact on System
Bit errors may be generated in the services and the services may be interrupted.
Related Alarms
Alarm Name Correlation
Procedure
Step 1 If any alarm occurs, use the method of the related alarm to clear it.
----End
Related Information
None.
11.2.17 ENVTMP
Description
The ENVTMP is a performance event indicating the ambient temperature of a board. It
contains the ENVTMPMAX, ENVTMPMIN, and ENVTMPCUR, which respectively
indicates the maximum value, minimum value, and current value of the ambient temperature
of a board.
Attribute
Performance Event Performance Event Type
ID
ENVTMPMIN: 0xDF
ENVTMPCUR: 0xE0
Impact on System
If the ambient temperature of a board is very high or low, the working performance of a board
may be degraded. Consequently, bit errors or other faults occur.
Related Alarms
Alarm Name Correlation
Procedure
Step 1 If any alarm occurs, use the method of the related alarm to clear it.
----End
Related Information
None.
11.2.18 FEC_AFT_COR_ER
Description
After FEC Correct Errored Rate
Attribute
Performance Event Performance Event Type
ID
Impact on System
After the error correction, the value should be 0 normally. If the value is not 0, it indicates that
the bit errors in the services bring impact on the transmission quality. In this case, determine
the cause in a timely manner.
In this case, there must be FEC_BEF_COR_ER accompanied. You can adjust the optical
power to increase the OSNR.
Related Alarms
Alarm Name Correlation
BEFFEC_EXC Signal degraded before FEC alarm. Signals sent from WDM sides
of the opposite-end OTU have the FEC function. As a result, before
performing signal FEC in the receive direction of WDM side of the
local-end OTU, the local-end OTU counts the bit error rate. This
alarm occurs when the counted bit error rate crosses the threshold.
MW_FEC_UNCO This alarm is generated when there is any byte that cannot be used
R for correcting errors.
Procedure
Step 1 If any alarm occurs, use the method of the related alarm to clear it.
----End
Related Information
None.
11.2.19 FEC_BEF_COR_ER
Description
Before FEC Correct Errored Rate
Attribute
Performance Event Performance Event Type
ID
Impact on System
There are bit errors in the line. The services, however, may not be affected. If the bit error rate
(BER) is low, the system operates normally. If the BER is high, determine the cause and
resolve the problem in a timely manner to avoid the occurrence of any alarm, and thus to
ensure the signal transmission quality.
Related Alarms
Alarm Name Correlation
BEFFEC_EXC Signal degraded before FEC alarm. Signals sent from WDM sides
of the opposite-end OTU have the FEC function. As a result, before
performing signal FEC in the receive direction of WDM side of the
local-end OTU, the local-end OTU counts the bit error rate. This
alarm occurs when the counted bit error rate crosses the threshold.
MW_FEC_UNCO This alarm is generated when there is any byte that cannot be used
R for correcting errors.
Procedure
Step 1 If any alarm occurs, use the method of the related alarm to clear it.
----End
Related Information
None.
11.2.20 FEC_COR_0BIT_CNT
Description
Forward Error Correction - Corrected 0 Bit Count
Attribute
Performance Event Performance Event Type
ID
Impact on System
None.
Related Alarms
None.
Procedure
Step 1 None
----End
Related Information
None.
11.2.21 FEC_COR_1BIT_CNT
Description
Forward Error Correction - Corrected 1 Bit Count
Attribute
Performance Event Performance Event Type
ID
Impact on System
None.
Related Alarms
None.
Procedure
Step 1 None
----End
Related Information
None.
11.2.22 FEC_COR_BYTE_CNT
Description
Forward Error CorrectionCorrected Byte Count
Attribute
Performance Event Performance Event Type
ID
Impact on System
None.
Related Alarms
None.
Procedure
Step 1 None.
----End
Related Information
None.
11.2.23 FEC_UNCOR_BLOCK_CNT
Description
Forward Error Correction - uncorrected Block Count
Attribute
Performance Event Performance Event Type
ID
Impact on System
There are bit errors in the services and the signal transmission quality is affected.
Related Alarms
Alarm Name Correlation
BEFFEC_EXC The bit errors cross the specified threshold before they are
corrected. If the signals transmitted by the opposite station have the
FEC function, the bit error ratio (BER) is counted before the bit
errors are corrected in FEC mode in the receive direction of the
board at the local station. This alarm is generated when the BER
exceeds the specified threshold.
Procedure
Step 1 If any alarm occurs, use the method of the related alarm to clear it.
----End
Related Information
None.
11.2.24 HPBBE
Description
The HPBBE stands for higher order path background block error.
Attribute
Performance Event ID Performance Event Type
Impact on System
A small number of bit errors occur in the higher order path. If no related alarms are generated,
the system is not affected. You need to, however, find out the causes and take proper measures
in time to avoid generating alarms, which affect the quality of the signals transmitted in the
higher order path.
Related Alarms
Alarm Name Correlation
B3_SD When the count of B3 bit errors in the alarm path exceeds the threshold
(1 x 10-6), the alarm is reported.
B3_EXC When the count of B3 bit errors in the alarm path exceeds the threshold
(1 x 10-3), the alarm is reported.
Procedure
Step 1 Refer to the method of handling the B3_EXC and B3_SD alarms.
----End
Related Information
Background Block Error
The background block error means that one or more bit errors occur in the data block during
transmission.
11.2.25 HPCSES
Description
The HPCSES stands for higher order path consecutive severely errored second.
Attribute
Performance Event ID Performance Event Type
Impact on System
A great number of bit errors occur in the higher order path. If no related alarms are generated,
the system is not affected. You need to, however, find out the causes and take proper measures
in time to avoid generating alarms, which affect the quality of the signals transmitted in the
higher order path.
Related Alarms
Alarm Name Correlation
B3_SD When the count of B3 bit errors in the alarm path is close to the
threshold (1 x 10-6), the alarm is reported.
B3_EXC When the count of B3 bit errors in the alarm path exceeds the
threshold (1 x 10-3), the alarm is reported.
Procedure
Step 1 Refer to the method of handling the B3_SD and B3_EXC alarm.
----End
Related Information
None.
11.2.26 HPES
Description
The HPES stands for higher order path errored second.
Attribute
Performance Event ID Performance Event Type
Impact on System
A small number of bit errors occur in the higher order path. If no related alarms are generated,
the system is not affected. You need to, however, find out the causes and take proper measures
in time to avoid generating alarms, which affect the quality of the signals transmitted in the
higher order path.
Related Alarms
Alarm Name Correlation
B3_SD When the count of B3 bit errors in the alarm path exceeds the
threshold (1 x 10-6), the alarm is reported.
B3_EXC When the count of B3 bit errors in the alarm path is exceeds the
threshold (1 x 10-3), the alarm is reported.
Procedure
Step 1 Refer to the method of handling the B3_SD and B3_EXC alarm.
----End
Related Information
The ES (errored second) refers to the second in which one or more errored blocks are
detected.
11.2.27 HPFEBBE
Description
The HPFEBBE stands for higher order path far end background block error.
Attribute
Performance Event ID Performance Event Type
Impact on System
A small number of bit errors occur at the far end of the higher order path. If no related alarms
are generated, the system is not affected. You need to, however, find out the causes and take
proper measures in time to avoid generating alarms, which affect the quality of the signals
transmitted in the higher order path.
Related Alarms
Alarm Name Correlation
HP_REI If the board has detected that the value is 1-8 for bits 1-4 of the G1 byte
in the higher order path, the alarm is reported.
Procedure
Step 1 Refer to the method of handling the HP_REI alarm.
----End
Related Information
The background block error means that one or more bit errors occur in the data block during
transmission.
11.2.28 HPFEES
Description
The HPFEES stands for higher order path far end errored second.
Attribute
Performance Event ID Performance Event Type
Impact on System
A small number of bit errors occur at the far end of the higher order path. If no related alarms
are generated, the system is not affected. You need to, however, find out the causes and take
proper measures in time to avoid generating alarms, which affect the quality of the signals
transmitted in the higher order path.
Related Alarms
Alarm Name Correlation
HP_REI If the board has detected that the value is 1-8 for bits 1-4 of the G1
byte in the higher order path, the alarm is reported.
Procedure
Step 1 Refer to the method of handling the HP_REI alarm.
----End
Related Information
Remote Errored Second
The remote errored second refers to the errored second that is detected at the peer end.
11.2.29 HPFECSES
Description
The HPFECSES stands for higher order path far end consecutive severely errored second.
Attribute
Performance Event ID Performance Event Type
Impact on System
A great number of bit errors occur at the far end of the higher order path. If no related alarms
are generated, the system is not affected. You need to, however, find out the causes and take
proper measures in time to avoid generating alarms, which affect the quality of the signals
transmitted in the higher order path.
Related Alarms
Alarm Name Correlation
HP_REI If the board has detected that the value is 1-8 for bits 1-4 of the G1
byte in the higher order path, the alarm is reported.
Procedure
Step 1 Refer to the method of handling the HP_REI alarm.
----End
Related Information
Severely Errored Second
The SES (severely errored second) refers to the second in which more than 30% errored
blocks occur or at least one SDP (serious disturbance period) occurs.
The CSES (consecutive severely errored second) refers to the SES (severely errored second)
event that occurs consecutively.
The remote bit error refers to the bit error that is detected at the opposite station.
11.2.30 HPFESES
Description
The HPFESES stands for higher order path far end severely errored second.
Attribute
Performance Event ID Performance Event Type
Impact on System
A great number of bit errors occur at the far end of the higher order path. If no related alarms
are generated, the system is not affected. You need to, however, find out the causes and take
proper measures in time to avoid generating alarms, which affect the quality of the signals
transmitted in the higher order path.
Related Alarms
Alarm Name Correlation
HP_REI If the board has detected that the value is 1-8 for bits 1-4 of the G1
byte in the higher order path, the alarm is reported.
Procedure
Step 1 Refer to the method of handling the HP_REI alarm.
----End
Related Information
Severely Errored Second
The SES (severely errored second) refers to the second in which more than 30% errored
blocks occur or at least one SDP (serious disturbance period) occurs.
11.2.31 HPFEUAS
Description
The HPFEUAS is a performance event indicating the higher order path far end unavailable
second.
Attribute
Performance Event Performance Event Type
ID
Impact on System
If bit errors occur in the services on a remote NE, detect the causes and troubleshoot the
problem in a timely manner. Otherwise, alarms will be generated and the signal transmission
quality will be affected.
External causes:
l The fiber performance degrades and the attenuation is excessive at the opposite station.
l The fiber connector is dirty or incorrect at the opposite station.
l The equipment is poorly grounded at the opposite station.
l There is a strong interference source around the equipment at the opposite station.
l The working temperature is extremely high or extremely low, and the opposite
equipment cannot tolerate such temperature.
Equipment problems:
l The signal attenuation at the receiving side of the line board at the opposite station is
excessive, the transmitting circuit of the opposite station is faulty, or the receiving circuit
of the local station is faulty.
l The synchronization performance of the clock is poor at the opposite station.
l The cross-connect unit and the line board poorly match at the opposite station.
l The fan of the opposite equipment becomes faulty.
l The board fails or the board performance degrades at the opposite station.
Related Alarms
Alarm Name Correlation
Procedure
Step 1 If any alarm occurs, use the method of the related alarm to clear it.
----End
Related Information
None.
11.2.32 HPSES
Description
The HPSES stands for higher order path severely errored second.
Attribute
Performance Event ID Performance Event Type
Impact on System
A great number of bit errors occur in the higher order path. If no related alarms are generated,
the system is not affected. You need to, however, find out the causes and take proper measures
in time to avoid generating alarms, which affect the quality of the signals transmitted in the
higher order path.
Related Alarms
Alarm Name Correlation
B3_SD When the count of B3 bit errors in the alarm path exceeds the
threshold (1 x 10-6), the alarm is reported.
B3_EXC When the count of B3 bit errors in the alarm path exceeds the
threshold (1 x 10-3), the alarm is reported.
Procedure
Step 1 Refer to the method of handling the B3_EXC and B3_SDalarms.
----End
Related Information
Severely Errored Second
The SES (severely errored second) refers to the second in more than 30% errored blocks
occur or at least one SDP (serious disturbance period) occurs.
11.2.33 HPUAS
Description
The HPUAS stands for higher order path unavailable second.
Attribute
Performance Event ID Performance Event Type
Impact on System
l A great number of bit errors occur in the higher order path. If no related alarms are
generated, the system is not affected. You need to, however, find out the causes and take
proper measures in time to avoid generating alarms, which affect the quality of the
signals transmitted in the higher order path.
l If the performance event is generated, check whether the AU_AIS, B3_EXC and
HP_UNEQ alarms are generated. If yes, the services may be interrupted.
less than 10-3, the period from the first second is called the period of available second. The ES
(errored second) refers to the second in which one or more errored blocks occur. The possible
causes of the event are as follows:
l There is interference from the external environment.
l A fault occurs in the switch that interworks with the SDH equipment.
l The signal cable is faulty.
l The line board is faulty.
l The cross-connection unit is faulty.
l The clock unit is faulty.
l The tributary unit is faulty.
Related Alarms
Alarm Name Correlation
B3_SD When the count of B3 bit errors in the alarm path exceeds the threshold
(1 x 10-6), the alarm is reported.
B3_EXC When the count of B3 bit errors in the alarm path exceeds the threshold
(1 x 10-3), the alarm is reported.
Procedure
Step 1 Refer to the method of handling the B3_SD, B3_EXC, AU_AIS, HP_TIM, and
HP_UNEQalarms.
----End
Related Information
None.
11.2.34 LPBBE
Description
The LPBBE is a performance event indicating the lower order path block of background error.
Attribute
Performance Event Performance Event Type
ID
Impact on System
If bit errors occur in the services, you need to find out the causes and troubleshoot the
problem in a timely manner. Otherwise, alarms will be generated and the signal transmission
quality will be affected. If bit errors exceed the BIP bit error threshold-crossing threshold and
degrade threshold, the BIP_EXC and BIP_SD alarms will be generated.
External causes:
Equipment problems:
l The signal attenuation at the receiving side of the line board is excessive, the
transmitting circuit of the opposite end is faulty, or the receiving circuit of the local end
is faulty.
l The synchronization performance of the clock is poor.
l The cross-connect unit and the line board or the cross-connect unit and the tributary
board poorly match.
l The faulty TU.
l The fan fails.
l Board failure or performance deterioration.
Related Alarms
Alarm Name Correlation
BIP_EXC Indicates the BIP bit errors when the service level is VC-12.
BIP_SD Indicates that the BIP signal degraded when the service level is
VC-12.
B3_EXC Indicates BIP excessive errors when the service level is VC-3.
B3_SD Indicates that the higher order path (B3) signal degraded when the
service level is VC-3.
Procedure
Step 1 Eliminate external causes, such as poor grounding, too high operating temperature, too low or
too high the received optical power of the line board. Then, check whether bit errors occur on
the line boards.
Step 2 If bit errors occur in all the line boards of an NE, the clock unit may be faulty. In this case,
replace the boards.
Step 3 If only a line board reports that bit errors exist, it indicates that the local line board might be
faulty or that the opposite NE or fibers are faulty. Locate the faulty board and replace it.
Step 5 If only the tributary reports bit errors, the cross-connect board may work with the tributary
board improperly at the local NE. In this case, replace the tributary board and cross-connect
board to verify the faulty point and clear the fault.
----End
Related Information
None.
11.2.35 LPCSES
Description
Lower order path continuous severe bit error second
Attribute
Performance Event Performance Event Type
ID
Impact on System
If bit errors occur in the services, you need to find out the causes and troubleshoot the
problem in a timely manner. Otherwise, alarms will be generated and the signal transmission
quality will be affected. If bit errors exceed the BIP bit error threshold-crossing threshold and
degrade threshold, the BIP_EXC and BIP_SD alarms will be generated.
External causes:
Equipment problems:
l The signal attenuation at the receiving side of the line board is excessive, the
transmitting circuit of the opposite end is faulty, or the receiving circuit of the local end
is faulty.
l The synchronization performance of the clock is poor.
l The cross-connect unit and the line board or the cross-connect unit and the tributary
board poorly match.
l The faulty TU.
l The fan fails.
l Board failure or performance deterioration.
Related Alarms
Alarm Name Correlation
BIP_EXC Indicates the BIP bit errors when the service level is VC-12.
BIP_SD Indicates that the BIP signal degraded when the service level is
VC-12.
B3_EXC Indicates BIP excessive errors when the service level is VC-3.
B3_SD Indicates that the higher order path (B3) signal degraded when the
service level is VC-3.
Procedure
Step 1 If any alarm occurs, use the method of the related alarm to clear it.
----End
Related Information
None.
11.2.36 LPES
Description
Lower order path errored second
Attribute
Performance Event Performance Event Type
ID
Impact on System
If bit errors occur in the services, you need to find out the causes and troubleshoot the
problem in a timely manner. Otherwise, alarms will be generated and the signal transmission
quality will be affected. If bit errors exceed the BIP bit error threshold-crossing threshold and
degrade threshold, the BIP_EXC and BIP_SD alarms will be generated.
Related Alarms
Alarm Name Correlation
BIP_EXC Indicates the BIP bit errors when the service level is VC-12.
BIP_SD Indicates that the BIP signal degraded when the service level is
VC-12.
B3_EXC Indicates BIP excessive errors when the service level is VC-3.
B3_SD Indicates that the higher order path (B3) signal degraded when the
service level is VC-3.
Procedure
Step 1 If any alarm occurs, use the method of the related alarm to clear it.
----End
Related Information
None.
11.2.37 LPFEBBE
Description
The LPFEBBE is a performance event indicating the lower order path far end block of
background error.
Attribute
Performance Event ID Performance Event Type
Impact on System
If bit errors occur in the services on a remote NE but no related alarms are reported on the
remote NE, the system will not be affected. However, you need to find out the causes and
troubleshoot the problem in a timely manner. Otherwise, alarms will be generated and the
signal transmission quality will be affected.
External causes:
l The fiber performance degrades and the attenuation is excessive at the opposite station.
l The fiber connector is dirty or incorrect at the opposite station.
l The equipment is poorly grounded at the opposite station.
l There is a strong interference source around the equipment at the opposite station.
l The working temperature is extremely high or extremely low, and the opposite
equipment cannot tolerate such temperature.
Equipment problems:
l The signal attenuation at the receiving side of the line board at the opposite station is
excessive, the transmitting circuit of the opposite station is faulty, or the receiving circuit
of the local station is faulty.
l The synchronization performance of the clock is poor at the opposite station.
l The cross-connect unit and the line board, or the cross-connect and the tributary board
poorly match at the opposite station.
l The opposite NE tributary board is faulty.
l The fan of the opposite equipment becomes faulty.
l The board fails or the board performance degrades at the opposite station.
Related Alarms
Alarm Name Correlation
LP_REI Bit errors occur on the lower order path at the remote end.
Procedure
Step 1 If any alarm occurs, use the method of the related alarm to clear it.
----End
Related Information
None.
11.2.38 LPFECSES
Description
Lower order path far end consecutive severely errored second
Attribute
Performance Event Performance Event Type
ID
Impact on System
If bit errors occur in the services on a remote NE but no related alarms are reported on the
remote NE, the system will not be affected. However, you need to find out the causes and
troubleshoot the problem in a timely manner. Otherwise, alarms will be generated and the
signal transmission quality will be affected.
l The cross-connect unit and the line board, or the cross-connect and the tributary board
poorly match at the opposite station.
l The opposite NE tributary board is faulty.
l The fan of the opposite equipment becomes faulty.
l The board fails or the board performance degrades at the opposite station.
Related Alarms
Alarm Name Correlation
LP_REI Bit errors occur on the lower order path at the remote end.
Procedure
Step 1 If any alarm occurs, use the method of the related alarm to clear it.
----End
Related Information
None.
11.2.39 LPFEES
Description
Lower order path far end errored second
Attribute
Performance Event Performance Event Type
ID
Impact on System
If bit errors occur in the services on a remote NE but no related alarms are reported on the
remote NE, the system will not be affected. However, you need to find out the causes and
troubleshoot the problem in a timely manner. Otherwise, alarms will be generated and the
signal transmission quality will be affected.
third bit of the V5 byte is verified. When the service is of the VC-3 level, the G1 byte is
verified.
External causes:
l The fiber performance degrades and the attenuation is excessive at the opposite station.
l The fiber connector is dirty or incorrect at the opposite station.
l The equipment is poorly grounded at the opposite station.
l There is a strong interference source around the equipment at the opposite station.
l The working temperature is extremely high or extremely low, and the opposite
equipment cannot tolerate such temperature.
Equipment problems:
l The signal attenuation at the receiving side of the line board at the opposite station is
excessive, the transmitting circuit of the opposite station is faulty, or the receiving circuit
of the local station is faulty.
l The synchronization performance of the clock is poor at the opposite station.
l The cross-connect unit and the line board, or the cross-connect and the tributary board
poorly match at the opposite station.
l The opposite NE tributary board is faulty.
l The fan of the opposite equipment becomes faulty.
l The board fails or the board performance degrades at the opposite station.
Related Alarms
Alarm Name Correlation
LP_REI Bit errors occur on the lower order path at the remote end.
Procedure
Step 1 If any alarm occurs, use the method of the related alarm to clear it.
----End
Related Information
None.
11.2.40 LPFESES
Description
Lower order path far end severely errored second
Attribute
Performance Event Performance Event Type
ID
Impact on System
If bit errors occur in the services on a remote NE but no related alarms are reported on the
remote NE, the system will not be affected. However, you need to find out the causes and
troubleshoot the problem in a timely manner. Otherwise, alarms will be generated and the
signal transmission quality will be affected.
Related Alarms
Alarm Name Correlation
LP_REI Bit errors occur on the lower order path at the remote end.
Procedure
Step 1 If any alarm occurs, use the method of the related alarm to clear it.
----End
Related Information
None.
11.2.41 LPFEUAS
Description
The LPFEUAS is a performance event indicating the lower order far end unavailable second.
Attribute
Performance Event Performance Event Type
ID
Impact on System
If bit errors occur in the services, you need to find out the causes and troubleshoot the
problem in a timely manner. Otherwise, alarms will be generated and the signal transmission
quality will be affected. If bit errors exceed the BIP bit error threshold-crossing threshold and
degrade threshold, the BIP_EXC and BIP_SD alarms will be generated.
Equipment problems:
l The signal attenuation at the receiving side of the line board at the opposite station is
excessive, the transmitting circuit of the opposite station is faulty, or the receiving circuit
of the local station is faulty.
l The synchronization performance of the clock is poor at the opposite station.
l The cross-connect unit and the line board, or the cross-connect and the tributary board
poorly match at the opposite station.
l The opposite NE tributary board is faulty.
l The fan of the opposite equipment becomes faulty.
l The board fails or the board performance degrades at the opposite station.
Related Alarms
Alarm Name Correlation
LP_REI Bit errors occur on the lower order path at the remote end.
Procedure
Step 1 If any alarm occurs, use the method of the related alarm to clear it.
----End
Related Information
None.
11.2.42 LPSES
Description
Lower order path severely errored second
Attribute
Performance Event Performance Event Type
ID
Impact on System
If bit errors occur in the services, you need to find out the causes and troubleshoot the
problem in a timely manner. Otherwise, alarms will be generated and the signal transmission
quality will be affected. If bit errors exceed the BIP bit error threshold-crossing threshold and
degrade threshold, the BIP_EXC and BIP_SD alarms will be generated.
Related Alarms
Alarm Name Correlation
BIP_EXC Indicates the BIP bit errors when the service level is VC-12.
BIP_SD Indicates that the BIP signal degraded when the service level is
VC-12.
B3_EXC Indicates BIP excessive errors when the service level is VC-3.
B3_SD Indicates that the higher order path (B3) signal degraded when the
service level is VC-3.
Procedure
Step 1 If any alarm occurs, use the method of the related alarm to clear it.
----End
Related Information
None.
11.2.43 LSBISA
Description
Laser Bias Current
It includes:
Attribute
Performance Event ID Performance Event Type
LSBISAMIN: 0xD0
LSBISACUR: 0xD1
Impact on System
None.
Related Alarms
Alarm Name Correlation
Procedure
Step 1 If any alarm occurs, use the method of the related alarm to clear it.
----End
Related Information
None.
11.2.44 LPUAS
Description
Lower order path unavailable second
Attribute
Performance Event Performance Event Type
ID
Impact on System
If bit errors occur in the services, you need to find out the causes and troubleshoot the
problem in a timely manner. Otherwise, alarms will be generated and the signal transmission
quality will be affected. If bit errors exceed the BIP bit error threshold-crossing threshold and
degrade threshold, the BIP_EXC and BIP_SD alarms will be generated.
Equipment problems:
l The signal attenuation at the receiving side of the line board is excessive, the
transmitting circuit of the opposite end is faulty, or the receiving circuit of the local end
is faulty.
l The synchronization performance of the clock is poor.
l The cross-connect unit and the line board or the cross-connect unit and the tributary
board poorly match.
l The Faulty TU.
l The fan fails.
l Board failure or performance deterioration.
Related Alarms
Alarm Name Correlation
BIP_EXC Indicates the BIP bit errors when the service level is VC-12.
BIP_SD Indicates that the BIP signal degraded when the service level is
VC-12.
B3_EXC Indicates BIP excessive errors when the service level is VC-3.
B3_SD Indicates that the higher order path (B3) signal degraded when the
service level is VC-3.
Procedure
Step 1 If any alarm occurs, use the method of the related alarm to clear it.
----End
Related Information
None.
11.2.45 LSCLC
Description
Laser Cooling Current
It includes:
Attribute
Performance Event Performance Event Type
ID
LSCLCMIN: 0xE2
LSCLCCUR: 0xE3
Impact on System
When the cooling current of a laser exceeds the threshold, the optical module of the board
works abnormally. As a result, services cannot be transmitted or received normally.
Related Alarms
Alarm Name Correlation
Procedure
Step 1 If any alarm occurs, use the method of the related alarm to clear it.
----End
Related Information
None.
11.2.46 LSIOP
Description
Input Optical Power
It includes:
Attribute
Performance Event ID Performance Event Type
LSIOPMIN: 0xCA
LSIOPCUR: 0xCB
Impact on System
When the input optical power is very high or very low, bit errors and the LOF alarm may be
generated in the received signals, which brings impact on the services.
Related Alarms
Alarm Name Correlation
IN_PWR_HIGH It is generated when the optical power input by board is higher than
the upper threshold.
IN_PWR_LOW It is generated when the optical power input by board is lower than
the lower threshold.
Procedure
Step 1 If no alarm is generated when the current performance value is at least 2 dB higher than the
history performance value and the change in optical power is not caused by normal operations
(such as expansion or upgrade), refer to the procedure for handling the IN_PWR_HIGH
alarm.
Step 2 If no alarm is generated when the current performance value is at least 2 dB lower than the
history performance value and the change in optical power is not caused by normal operations
(such as expansion or upgrade), refer to the procedure for handling the IN_PWR_LOW
alarm.
----End
Related Information
None.
11.2.47 LSOOP
Description
Output Optical Power
It includes:
Attribute
Performance Event Performance Event Type
ID
LSOOPMIN: 0xC7
LSOOPCUR: 0xC8
Impact on System
If the output optical power of the laser is abnormal, there is impact on the normal
transmission of services.
Related Alarms
Alarm Name Correlation
OUT_PWR_LOW It is generated when the optical power output by board is lower than
the lower threshold.
Procedure
Step 1 If no alarm is generated when the current performance value is at least 2 dB higher than the
history performance value and the change in optical power is not caused by normal operations
(such as expansion or upgrade), refer to the procedure for handling the OUT_PWR_HIGH
alarm.
Step 2 If no alarm is generated when the current performance value is at least 2 dB lower than the
history performance value and the change in optical power is not caused by normal operations
(such as expansion or upgrade), refer to the procedure for handling the OUT_PWR_LOW
alarm.
----End
Related Information
None.
11.2.48 LSTMP
Description
Laser Temperature
It includes:
Attribute
Performance Event ID Performance Event Type
LSTMPMIN: 0xCD
LSTMPCUR: 0xCE
Impact on System
None.
Related Alarms
Alarm Name Correlation
Procedure
Step 1 If any alarm occurs, use the method of the related alarm to clear it.
----End
Related Information
None.
11.2.49 MSBBE
Description
The MSBBE stands for multiplex section background block error.
Attribute
Performance Event ID Performance Event Type
Impact on System
A small number of bit errors occur in the signals of the multiplex section. If no related alarms
are generated, the system is not affected. You need to, however, find out the causes and take
proper measures in time to avoid generating alarms, which affect the quality of the signals
transmitted in the higher order path.
Related Alarms
Alarm Name Correlation
B2_SD If the board has detected that the count of B2 bit errors exceeds the
specified B2_SD alarm threshold (default value: 10-6), the alarm is
reported.
B2_EXC If the board has detected that the count of B2 bit errors exceeds the
specified B2_EXC alarm threshold (default value: 10-3), the alarm is
reported.
Procedure
Step 1 Refer to the method of handling the B2_EXCand B2_SDalarms.
----End
Related Information
Background Block Error
The background block error means that one or more bit errors occur in the data block during
transmission.
11.2.50 MSCSES
Description
The MSCSES stands for multiplex section consecutive severely errored second.
Attribute
Performance Event ID Performance Event Type
Impact on System
When the performance event occurs, the services are unavailable.
Related Alarms
Alarm Name Correlation
B2_SD If the board has detected that the count of B2 bit errors exceeds the
specified B2_SD alarm threshold (default value: 10-6), the alarm is
reported.
B2_EXC If the board has detected that the count of B2 bit errors exceeds the
specified B2_EXC alarm threshold (default value: 10-3), the alarm is
reported.
Procedure
Step 1 Refer to the method of handling the B2_EXC and B2_SD alarms.
----End
Related Information
None.
11.2.51 MSES
Description
The MSES stands for multiplex section errored second.
Attribute
Performance Event ID Performance Event Type
Impact on System
A small number of bit errors occur in the signals of the multiplex section. If no related alarms
are generated, the system is not affected. You need to, however, find out the causes and take
proper measures in time to avoid generating alarms, which affect the quality of the signals
transmitted in the multiplex section.
Related Alarms
Alarm Name Correlation
B2_SD If the board has detected that the count of B2 bit errors exceeds the
specified B2_SD alarm threshold (default value: 10-6), the alarm is
reported.
B2_EXC If the board has detected that the count of B2 bit errors exceeds the
specified B2_EXC alarm threshold (default value: 10-), the alarm is
reported.
Procedure
Step 1 Refer to the method of handling the B2_EXC and B2_SD alarms.
----End
Related Information
Errored Second
The ES (errored second) refers to the second in which one or more errored blocks occur.
11.2.52 MSFEBBE
Description
The MSFEBBE stands for multiplex section far end background block error.
Attribute
Performance Event ID Performance Event Type
Impact on System
A small number of bit errors occur at the far end of the multiplex section. If no related alarms
are generated, the services at the local end and the peer end are not affected. You need to,
however, find out the causes and take proper measures in time to avoid generating alarms,
which affect the quality of the signals transmitted in the multiplex section.
Related Alarms
Alarm Name Correlation
MS_REI If the board has detected that the value is 1 - 24 for the M1 overhead
byte in the multiplex section, the alarm is reported.
Procedure
Step 1 Refer to the method of handling the MS_REIalarm.
----End
Related Information
None.
11.2.53 MSFECSES
Description
The MSFECSES stands for multiplex section far end consecutive severely errored second.
Attribute
Performance Event ID Performance Event Type
Impact on System
A great number of bit errors occur at the far end of the multiplex section. If no related alarms
are generated, the system is not affected. You need to, however, find out the causes and take
proper measures in time to avoid generating alarms, which affect the quality of the signals
transmitted in the multiplex section.
Related Alarms
Alarm Name Correlation
MS_REI If the board has detected that the value is 1 - 24 for the M1
overhead byte in the multiplex section, the alarm is reported.
Procedure
Step 1 Refer to the method of handling the MS_REI alarm.
----End
Related Information
None.
11.2.54 MSFEES
Description
The MSFEES stands for multiplex section far end errored second.
Attribute
Performance Event ID Performance Event Type
Impact on System
A small number of bit errors occur at the far end of the multiplex section. If no related alarms
are generated, the system is not affected. You need to, however, find out the causes and take
proper measures in time to avoid generating alarms, which affect the quality of the signals
transmitted in the multiplex section.
Related Alarms
Alarm Name Correlation
MS_REI If the board has detected that the value is 1 - 24 for the M1 overhead
byte in the multiplex section, the alarm is reported.
Procedure
Step 1 Refer to the method of handling the MS_REI alarm.
----End
Related Information
Errored Second
The ES (errored second) refers to the second in which one or more errored blocks occur.
11.2.55 MSFESES
Description
The MSFESES stands for multiplex section far end severely errored second.
Attribute
Performance Event ID Performance Event Type
Impact on System
A great number of bit errors occur at the far end of the multiplex section. If no related alarms
are generated, the system is not affected. You need to, however, find out the causes and take
proper measures in time to avoid generating alarms, which affect the quality of the signals
transmitted in the multiplex section.
Related Alarms
Alarm Name Correlation
MS_REI If the board has detected that the value is 1 - 24 for the M1 overhead
byte in the multiplex section, the alarm is reported.
Procedure
Step 1 Refer to the method of handling the MS_REI alarm.
----End
Related Information
Severely Errored Second
The SES (severely errored second) refers to the second in which more than 30% errored
blocks (15% for STM-1 signals, and 25% for STM-4 signals) occur or at least one SDP
(serious disturbance period) occurs.
11.2.56 MSFEUAS
Description
The MSFEUAS is a performance event indicating the multiplex section far end unavailable
second.
Attribute
Performance Event Performance Event Type
ID
Impact on System
If bit errors occur in the services on a remote NE but no related alarms are reported on the
remote NE, the system will not be affected. However, you need to find out the causes and
troubleshoot the problem in a timely manner. Otherwise, alarms will be generated and the
signal transmission quality will be affected.
External causes:
l The fiber performance degrades and the attenuation is excessive at the opposite station.
l The fiber connector is dirty or incorrect at the opposite station.
l The equipment is poorly grounded at the opposite station.
l There is a strong interference source around the equipment at the opposite station.
l The working temperature is extremely high or extremely low, and the opposite
equipment cannot tolerate such temperature.
Equipment problems:
l The signal attenuation at the receiving side of the line board at the opposite station is
excessive, the transmitting circuit of the opposite station is faulty, or the receiving circuit
of the local station is faulty.
l The synchronization performance of the clock is poor at the opposite station.
l The cross-connect unit and the line board poorly match at the opposite station.
l The fan of the opposite equipment becomes faulty.
l The board fails or the board performance degrades at the opposite station.
Related Alarms
Alarm Name Correlation
Procedure
Step 1 If any alarm occurs, use the method of the related alarm to clear it.
----End
Related Information
None.
11.2.57 MSSES
Description
The MSSES stands for multiplex section severely errored second.
Attribute
Performance Event ID Performance Event Type
Impact on System
A great number of bit errors occur in the signals of the multiplex section. If no related alarms
are generated, the system is not affected. You need to, however, find out the causes and take
proper measures in time to avoid generating alarms, which affect the quality of the signals
transmitted in the multiplex section.
Related Alarms
Alarm Name Correlation
B2_SD If the board has detected that the count of B2 bit errors exceeds the
specified B2_SD alarm threshold (default value: 10-6), the alarm is
reported.
B2_EXC If the board has detected that the count of B2 bit errors exceeds the
specified B2_EXC alarm threshold (default value: 10-3), the alarm is
reported.
Procedure
Step 1 Refer to the method of handling the B2_EXC and B2_SD alarms.
----End
Related Information
None.
11.2.58 MSUAS
Description
The MSUAS stands for multiplex section unavailable second.
Attribute
Performance Event ID Performance Event Type
Impact on System
When the performance event occurs, the services in the multiplex section are unavailable.
Related Alarms
Alarm Name Correlation
B2_SD If the board has detected that the count of B2 bit errors exceeds the
specified B2_SD alarm threshold (default value: 10-6), the alarm is
reported.
B2_EXC If the board has detected that the count of B2 bit errors exceeds the
specified B2_EXC alarm threshold (default value: 10-3), the alarm is
reported.
Procedure
Step 1 Refer to the method of handling the B2_EXC, B2_SD, R_LOS, and R_LOF alarms.
----End
Related Information
None.
11.2.59 ODU2PMBIP8
Description
ODU PM Section BIP8
Attribute
Performance Event Performance Event Type
ID
Impact on System
There are bit errors in the services. If the number of bit errors increases, determine the cause
and resolve the problem in a timely manner to avoid the occurrence of any alarm, and thus to
ensure the signal transmission quality.
Related Alarms
Alarm Name Correlation
PM_BIP8_OVER ODU layer PM section BIP (Bit Interleaved Parity) exceed the
upper threshold. The alarm occurs when the number of BIP8 bit
errors of the PM section in the optical channel data unit layer
crosses the upper threshold.
PM_BIP8_SD Optical channel data unit layer, path monitoring section bit
interleaved parity signal degraded. The alarm occurs when the
number of BIP8 bit errors of the PM section in the optical channel
data unit layer crosses the degraded threshold.
Procedure
Step 1 If any alarm occurs, use the method of the related alarm to clear it.
----End
Related Information
None.
11.2.60 OSPITMPMIN
Description
The OSPITMPMIN indicates the minimum value of the temperature in the tube core of the
laser.
Attribute
Performance Event ID Performance Event Type
Impact on System
The performance event does not affect the equipment and the system. If the temperature in the
tube core of the laser is extremely low, however, the laser may work abnormally. If the
temperature is within the specified value range, you do not need to take any action.
Related Alarms
Alarm Name Correlation
TEM_HA When the temperature of the laser is higher than the upper
threshold, the alarm is reported.
TEM_LA When the temperature of the laser is less than the lower threshold,
the alarm is reported.
Procedure
Step 1 Refer to the method of handling the TEM_HA and TEM_LA alarms.
----End
Related Information
None.
11.2.61 OSPITMPMAX
Description
The OSPITMPMAX indicates the maximum value of the temperature in the tube core of the
laser.
Attribute
Performance Event ID Performance Event Type
Impact on System
The performance event does not affect the equipment and the system. If the temperature in the
tube core of the laser is extremely high, however, the laser may work abnormally. If the
temperature is within the specified value range, you do not need to take any action.
Related Alarms
Alarm Name Correlation
TEM_HA When the temperature of the laser is higher than the upper
threshold, the alarm is reported.
TEM_LA When the temperature of the laser is less than the lower threshold,
the alarm is reported.
Procedure
Step 1 Refer to the method of handling the TEM_HA and TEM_LA alarms.
----End
Related Information
None.
11.2.62 OSPITMPCUR
Description
The OSPITMPCUR indicates the current value of the temperature in the tube core of the laser.
Attribute
Performance Event ID Performance Event Type
Impact on System
The performance event does not affect the equipment and the system. If the temperature in the
tube core of the laser is extremely high or low, however, the laser may work abnormally.
Consequently, the services may be interrupted. If the temperature is within the specified value
range, you do not need to take any action.
Related Alarms
Alarm Name Correlation
TEM_HA When the temperature of the laser is higher than the upper
threshold, the alarm is reported.
TEM_LA When the temperature of the laser is less than the lower threshold,
the alarm is reported.
Procedure
Step 1 Refer to the method of handling the TEM_HA and TEM_LA alarms.
----End
Related Information
None.
11.2.63 OSPICCVMIN
Description
The OSPICCVMIN indicates the minimum value of the cooling current of the laser.
Attribute
Performance Event ID Performance Event Type
Impact on System
The performance event does not affect the equipment and the system. If the cooling current of
the laser is extremely low, however, the laser may work abnormally. Consequently, the
services may be interrupted. If the cooling current is within the specified value range, you do
not need to take any action.
Related Alarms
Alarm Name Correlation
LSR_COOL_ALM When the cooling current of the laser is beyond the specified
value range, this alarm is generated.
Procedure
Step 1 Refer to the method of handling the LSR_COOL_ALM.
----End
Related Information
None.
11.2.64 OSPICCVMAX
Description
The OSPICCVMAX indicates the maximum value in the cooling current history of the laser.
Attribute
Performance Event ID Performance Event Type
Impact on System
The performance event does not affect the equipment and the system. If the cooling current of
the laser is extremely high, however, the laser may work abnormally. If the cooling current is
within the specified value range, you do not need to take any action.
Related Alarms
Alarm Name Correlation
LSR_COOL_ALM When the cooling current of the laser is beyond the specified
value range, this alarm is generated.
Procedure
Step 1 Refer to the method of handling the LSR_COOL_ALM alarm.
----End
Related Information
None.
11.2.65 OSPICCVCUR
Description
The OSPICCVCUR indicates the current value of the cooling current of the laser.
Attribute
Performance Event ID Performance Event Type
Impact on System
The performance event does not affect the equipment and the system. If the cooling current of
the laser is extremely high or low, however, the laser may work abnormally. If the cooling
current is within the specified value range, you do not need to take any action.
Related Alarms
Alarm Name Correlation
LSR_COOL_ALM When the cooling current of the laser is beyond the specified
value range, this alarm is generated.
Procedure
Step 1 Refer to the method of handling the LSR_COOL_ALM alarm.
----End
Related Information
None.
11.2.66 OTU2SMBIP8
Description
OTU SM Section BIP8
Attribute
Performance Event Performance Event Type
ID
Impact on System
There are bit errors in the services. If the number of bit errors increases, determine the cause
and resolve the problem in a timely manner to avoid the occurrence of any alarm, and thus to
ensure the signal transmission quality.
Related Alarms
Alarm Name Correlation
Procedure
Step 1 If any alarm occurs, use the method of the relevant alarm to clear it.
----End
Related Information
None.
11.2.67 RSBBE
Description
The RSBBE stands for regenerator section background block error.
Attribute
Performance Event ID Performance Event Type
Impact on System
A small number of bit errors occur in the regenerator section of the line. If no related alarms
are generated, the system is not affected. You need to, however, find out the causes and take
proper measures in time to avoid generating alarms, which affect the quality of the signals
transmitted in the regenerator section of the line.
Related Alarms
Alarm Name Correlation
B1_SD If the board has detected that the count of B1 bit errors exceeds the
specified B1_SD alarm threshold (default value: 10-6), the alarm is
reported.
B1_EXC If the board has detected that the count of B1 bit errors exceeds the
specified B1_EXC alarm threshold (default value: 10-3), the alarm
is reported.
Procedure
Step 1 Refer to the method of handling the B1_SD and B1_EXC alarms.
----End
Related Information
Background Block Error
The background block error means that one or more bit errors occur in the data block during
transmission.
11.2.68 RSCSES
Description
The RSCSES stands for regenerator section consecutive severely errored second.
Attribute
Performance Event ID Performance Event Type
Impact on System
The services are interrupted within the period in which errored seconds occur.
Related Alarms
Alarm Name Correlation
B1_SD If the board has detected that the count of B1 bit errors exceeds the
specified B1_SD alarm threshold (default value: 10-6), the alarm is
reported.
B1_EXC If the board has detected that the count of B1 bit errors exceeds the
specified B1_EXC alarm threshold (default value: 10-3), the alarm
is reported.
Procedure
Step 1 Refer to the method of handling the B1_SD and B1_EXC alarms.
----End
Related Information
None.
11.2.69 RSES
Description
The RSES stands for regenerator section errored second.
Attribute
Performance Event ID Performance Event Type
Impact on System
A small number of bit errors occur in the regenerator section of the line. If no related alarms
are generated, the system is not affected. You need to, however, find out the causes and take
proper measures in time to avoid generating alarms, which affect the quality of the signals
transmitted in the regenerator section of the line.
Related Alarms
Alarm Name Correlation
B1_SD If the board has detected that the count of B1 bit errors exceeds the
specified B1_SD alarm threshold (default value: 10-6), the alarm is
reported.
B1_EXC If the board has detected that the count of B1 bit errors exceeds the
specified B1_EXC alarm threshold (default value: 10-3), the alarm
is reported.
Procedure
Step 1 Refer to the method of handling the B1_SD and B1_EXC alarms.
----End
Related Information
Errored Second
The ES (errored second) refers to the second in which one or more errored blocks are
detected.
11.2.70 RSOFS
Description
The RSOFS indicates the out-of-frame second of the regenerator section.
Attribute
Performance Event ID Performance Event Type
Impact on System
When the performance event occurs, the frame alignment bytes are lost. Consequently, the
services are interrupted.
Related Alarms
Alarm Name Correlation
R_OOF If more than five frames cannot be correctly aligned with the SDH
frame header consecutively, the alarm is reported.
R_LOF When the R_OOF alarm lasts for three milliseconds, the alarm is
reported.
Procedure
Step 1 Refer to the method of handling the R_OOF and R_LOF alarms.
----End
Related Information
None.
11.2.71 RSOOF
Description
The RSOOF indicates the count of out-of-frame events in the regenerator section.
Attribute
Performance Event ID Performance Event Type
Impact on System
When the performance event occurs, the frame alignment bytes are lost. Consequently, the
services are interrupted.
Related Alarms
Alarm Name Correlation
R_OOF If more than five frames cannot be correctly aligned with the SDH
frame header consecutively, the alarm is reported.
R_LOF When the R_OOF alarm lasts for three milliseconds, the alarm is
reported.
Procedure
Step 1 Refer to the method of handling the R_OOF and R_LOF alarms.
----End
Related Information
None.
11.2.72 RSSES
Description
The RSSES stands for regenerator section severely errored second.
Attribute
Performance Event ID Performance Event Type
Impact on System
A great number of bit errors occur in the regenerator section of the line. If no related alarms
are generated, the system is not affected. You need to, however, find out the causes and take
proper measures in time to avoid generating alarms, which affect the quality of the signals
transmitted in the regenerator section of the line.
Related Alarms
Alarm Name Correlation
B1_SD If the board has detected that the count of B1 bit errors exceeds the
specified B1_SD alarm threshold (default value: 10-6), the alarm is
reported.
B1_EXC If the board has detected that the count of B1 bit errors exceeds the
specified B1_EXC alarm threshold (default value: 10-3), the alarm is
reported.
Procedure
Step 1 Refer to the method of handling the B1_SD and B1_EXC alarms.
----End
Related Information
Severely Errored Second
The SES (severely errored second) refers to the second in which more than 30% errored
blocks occur or at least one SDP (serious disturbance period) occurs.
11.2.73 RSUAS
Description
The RSUAS stands for regenerator section unavailable second. It indicates the count of
seconds in which the services are interrupted.
Attribute
Performance Event ID Performance Event Type
Impact on System
When the performance event occurs, the services are interrupted.
Related Alarms
Alarm Name Correlation
B1_SD If the board has detected that the count of B1 bit errors exceeds the
specified B1_SD alarm threshold (default value: 10-6), the alarm is
reported.
B1_EXC If the board has detected that the count of B1 bit errors exceeds
specified the B1_EXC alarm threshold (default value: 10-3), the
alarm is reported.
Procedure
Step 1 Refer to the method of handling the B1_SD and B1_EXC alarms.
----End
Related Information
The UAS (unavailable second) refers to the period of unavailable time when the SES event
occurs for more than 10 seconds consecutively. When the SES event does not occur for 10
seconds consecutively, the available time begins from the eleventh second, including the
previous 10 seconds.
11.2.74 RPLMIN
Description
The RPLMIN indicates the minimum value of the input optical power.
Attribute
Performance Event ID Performance Event Type
Impact on System
The performance event does not affect the equipment and the system. If the input optical
power is extremely low, however, the laser may fail to detect the signals.
Related Alarms
Alarm Name Correlation
IN_PWR_ABN When the input optical power is higher than the upper threshold or
is less than the lower threshold, the alarm is reported.
Procedure
Step 1 Refer to the method of handling the IN_PWR_ABN alarm.
----End
Related Information
None.
11.2.75 RPLMAX
Description
The RPLMAX indicates the maximum value of the input optical power.
Attribute
Performance Event ID Performance Event Type
Impact on System
The performance event does not affect the equipment and the system. If the input optical
power is extremely high, however, the laser may be damaged.
Related Alarms
Alarm Name Correlation
IN_PWR_ABN When the input optical power is higher than the upper threshold or
is less than the lower threshold, the alarm is reported.
Procedure
Step 1 Refer to the method of handling the IN_PWR_ABN alarm.
----End
Related Information
None.
11.2.76 RPLCUR
Description
The RPLCUR indicates the current value of the input optical power.
Attribute
Performance Event ID Performance Event Type
Impact on System
The performance event does not affect the equipment and the system. If the input optical
power is extremely high, the laser may be damaged. If the input optical power is extremely
low, the laser may fail to detect the signals. You can know the normal range of the input
optical power by querying the specifications for related optical interfaces.
Related Alarms
Alarm Name Correlation
IN_PWR_ABN When the input optical power is higher than the upper threshold or
is less than the lower threshold, the alarm is reported.
Procedure
Step 1 Refer to the method of handling the IN_PWR_ABN alarm.
----End
Related Information
None.
11.2.77 T1_LCV_SDH
Description
The T1_LCV_SDH is a performance event indicating the T1 line side code violation count.
Attribute
Performance Event Performance Event Type
ID
Impact on System
If bit errors occur in the services, you need to find out the causes and troubleshoot the
problem in a timely manner. Otherwise, alarms will be generated and the signal transmission
quality will be affected.
External causes:
l The fiber performance is degraded, and the fiber has extremely high attenuation.
l The fiber connector is dirty or incorrect.
l The equipment is poorly grounded.
l There is a strong interference source around the equipment.
l The working temperature is extremely high or extremely low, and the opposite
equipment cannot tolerate such temperature.
Equipment problems:
Related Alarms
None.
Procedure
Step 1 First eliminate external causes, such as poor grounding, too high operating temperature, too
low or too high the receiving optical power of the line board.
Step 2 Check if the T1 service pattern is correct. If it is incorrect, set the pattern of the board to
modify the service pattern that the board receives.
Step 3 The port of the tributary board may be faulty. Replace the board.
----End
Related Information
None.
11.2.78 T1_LES_SDH
Description
The T1_LES_SDH is a performance event indicating the T1 line side code violation errored
second.
Attribute
Performance Event Performance Event Type
ID
Impact on System
If bit errors occur in the services, you need to find out the causes and troubleshoot the
problem in a timely manner. Otherwise, alarms will be generated and the signal transmission
quality will be affected.
Related Alarms
None.
Procedure
Step 1 Refer to the 11.2.77 T1_LCV_SDH.
----End
Related Information
None.
11.2.79 T1_LSES_SDH
Description
The T1_LSES_SDH is a performance event indicating the T1 line side code violation severely
errored second.
Attribute
Performance Event Performance Event Type
ID
Impact on System
If bit errors occur in the services, you need to find out the causes and troubleshoot the
problem in a timely manner. Otherwise, alarms will be generated and the signal transmission
quality will be affected.
External causes:
l The fiber performance is degraded, and the fiber has extremely high attenuation.
l The fiber connector is dirty or incorrect.
l The equipment is poorly grounded.
l There is a strong interference source around the equipment.
l The working temperature is extremely high or extremely low, and the opposite
equipment cannot tolerate such temperature.
Equipment problems:
Related Alarms
None.
Procedure
Step 1 Refer to the 11.2.77 T1_LCV_SDH.
----End
Related Information
None.
11.2.80 T3_LCV_SDH
Description
The T3_LCV_SDH is a performance event indicating the T3 line side code violation count.
Attribute
Performance Event Performance Event Type
ID
Impact on System
If bit errors occur in the services, you need to find out the causes and troubleshoot the
problem in a timely manner. Otherwise, alarms will be generated and the signal transmission
quality will be affected.
Related Alarms
None.
Procedure
Step 1 First eliminate external causes, such as poor grounding, too high operating temperature, too
low or too high the receiving optical power of the line board.
Step 2 Check if the T3 service pattern is correct. If it is incorrect, set the pattern of the board to
modify the service pattern that the board receives.
Step 3 The port of the tributary board may be faulty. Replace the board.
----End
Related Information
None.
11.2.81 T3_LES_SDH
Description
The T3_LES_SDH is a performance event indicating the T3 line side code violation errored
second.
Attribute
Performance Event Performance Event Type
ID
Impact on System
If bit errors occur in the services, you need to find out the causes and troubleshoot the
problem in a timely manner. Otherwise, alarms will be generated and the signal transmission
quality will be affected.
External causes:
l The fiber performance is degraded, and the fiber has extremely high attenuation.
l The fiber connector is dirty or incorrect.
l The equipment is poorly grounded.
l There is a strong interference source around the equipment.
l The working temperature is extremely high or extremely low, and the opposite
equipment cannot tolerate such temperature.
Equipment problems:
Related Alarms
None.
Procedure
Step 1 Refer to the 11.2.80 T3_LCV_SDH.
----End
Related Information
None.
11.2.82 T3_LSES_SDH
Description
The T3_LSES_SDH is a performance event indicating the T3 line side code violation severely
errored second.
Attribute
Performance Event Performance Event Type
ID
Impact on System
If bit errors occur in the services, you need to find out the causes and troubleshoot the
problem in a timely manner. Otherwise, alarms will be generated and the signal transmission
quality will be affected.
External causes:
l The fiber performance is degraded, and the fiber has extremely high attenuation.
l The fiber connector is dirty or incorrect.
l The equipment is poorly grounded.
l There is a strong interference source around the equipment.
l The working temperature is extremely high or extremely low, and the opposite
equipment cannot tolerate such temperature.
Equipment problems:
Related Alarms
None.
Procedure
Step 1 Refer to the 11.2.80 T3_LCV_SDH.
----End
Related Information
None.
11.2.83 TPLMIN
Description
The TPLMIN indicates the minimum value of the output optical power.
Attribute
Performance Event ID Performance Event Type
Impact on System
The performance event does not affect the equipment and the system. If the output optical
power of the laser is beyond the specified value range, however, the laser fails to work or is
going to the end of its life. If the output optical power is within the specified value range, you
do not need to take any action.
Related Alarms
Alarm Name Correlation
LSR_WILL_DIE When the output optical power is greatly beyond the specified
value range, the alarm is reported, showing that the life of the
laser is going to the end.
Procedure
Step 1 Refer to the method of handling the TF and LSR_WILL_DIE alarms.
----End
Related Information
None.
11.2.84 TPLMAX
Description
The TPLMAX indicates the maximum value of the output optical power.
Attribute
Performance Event ID Performance Event Type
Impact on System
The performance event does not affect the equipment and the system. If the output optical
power of the laser is beyond the specified value range, however, the laser fails to work or is
going to the end of its life. Consequently, the services are interrupted. If the output optical
power is within the specified value range, you do not need to take any action.
Related Alarms
Alarm Name Correlation
LSR_WILL_DIE When the output optical power is greatly beyond the specified
value range, the alarm is reported, showing that the life of the
laser is going to the end.
Procedure
Step 1 Refer to the method of handling the TF and LSR_WILL_DIE alarms.
----End
Related Information
None.
11.2.85 TPLCUR
Description
The TPLCUR indicates the current value of the output optical power.
Attribute
Performance Event ID Performance Event Type
Impact on System
The performance event does not affect the equipment and the system. If the output optical
power of the laser is beyond the specified value range, however, the laser fails to work or is
going to the end of its life. Consequently, the services are interrupted. If the output optical
power is within the specified value range, you do not need to take any action.
Related Alarms
Alarm Name Correlation
LSR_WILL_DIE When the output optical power is greatly beyond the specified
value range, the alarm is reported, showing that the life of the
laser is going to the end.
Procedure
Step 1 Refer to the method of handling the TF and LSR_WILL_DIE alarms.
----End
Related Information
None.
11.2.86 TLBMIN
Description
The TLBMIN indicates the minimum value of the bias current of the laser.
Attribute
Performance Event ID Performance Event Type
Impact on System
The performance event does not affect the equipment and the system. If the bias current of the
laser is beyond the specified value range, however, the laser fails to work or is going to the
end of its life. Consequently, the services are interrupted. If the bias current is within the
specified value range, you do not need to take any action.
Related Alarms
Alarm Name Correlation
TF When the bias current of the laser is beyond the specified value
range, the alarm is reported, showing transmission failure of the
laser.
LSR_WILL_DIE When the bias current of the laser is less than the TF value, the
alarm is reported, showing that the life of the laser is going to the
end.
Procedure
Step 1 Refer to the method of handling the TF and LSR_WILL_DIE alarms.
----End
Related Information
None.
11.2.87 TLBMAX
Description
The TLBMAX indicates the maximum value of the bias current of the laser.
Attribute
Performance Event ID Performance Event Type
Impact on System
The performance event does not affect the equipment and the system. If the bias current of the
laser is beyond the specified value range, however, the laser fails to work or is going to the
end of its life. Consequently, the services are interrupted. If the bias current is within the
specified value range, you do not need to take any action.
Related Alarms
Alarm Name Correlation
TF When the bias current of the laser is beyond the specified value
range, the alarm is reported, showing transmission failure of the
laser.
LSR_WILL_DIE When the bias current of the laser is less than the TF value, the
alarm is reported, showing that the life of the laser is going to the
end.
Procedure
Step 1 Refer to the method of handling the TF and LSR_WILL_DIE alarms.
----End
Related Information
None.
11.2.88 TLBCUR
Description
The TLBCUR indicates the current value of the bias current of the laser.
Attribute
Performance Event ID Performance Event Type
Impact on System
The performance event does not affect the equipment and the system. If the bias current of the
laser is beyond the specified value range, however, the laser fails to work or is going to the
end of its life. Consequently, the services are interrupted. If the bias current is within the
specified value range, you do not need to take any action.
Related Alarms
Alarm Name Correlation
TF When the bias current of the laser is beyond the specified value
range, the alarm is reported, showing transmission failure of the
laser.
LSR_WILL_DIE When the bias current of the laser is less than the TF value, the
alarm is reported, showing that the life of the laser is going to the
end.
Procedure
Step 1 Refer to the method of handling the TF and LSR_WILL_DIE alarms.
----End
Related Information
None.
11.2.89 TUPJCHIGH
Description
The TUPJCHIGH is a performance event indicating the count of positive TU pointer
justifications.
Attribute
Performance Event Performance Event Type
ID
Impact on System
A small amount of pointer justification does not affect the services, whereas a large amount of
pointer justification causes bit errors in the services. In this case, detect the causes and
troubleshoot the problem in a timely manner. Otherwise, alarms will be generated and the
signal transmission quality will be affected.
l The fibers are incorrectly connected, resulting in the mutual clock tracing of the two
NEs.
l If the NEs trace the external clock, check the quality of the external clock.
Human factors:
l The configuration of the clock source is incorrect. There are two clock sources in one
network.
l The configuration of the clock source tracing priority is incorrect. The clocks of the two
NEs trace each other.
Equipment problems:
Related Alarms
Alarm Name Correlation
Procedure
Step 1 Check whether the fibers are incorrectly connected. In the case of the MSP ring, the service is
interrupted if the fibers are incorrectly connected.
Step 2 If the NE traces the external clock, check the quality of the external clock.
Step 3 Check the configuration of the clock and ensure that the configuration is correct.
Step 4 Analyze the pointer justification performance events, and locate the faulty point by changing
the position of the clock source and clock tracing direction.
----End
Related Information
None.
11.2.90 TUPJCLOW
Description
The TUPJCLOW is a performance event indicating the count of negative TU pointer
justifications.
Attribute
Performance Event Performance Event Type
ID
Impact on System
A small amount of pointer justification does not affect the services, whereas a large amount of
pointer justification causes bit errors in the services. In this case, detect the causes and
troubleshoot the problem in a timely manner. Otherwise, alarms will be generated and the
signal transmission quality will be affected.
Equipment problems:
l The LU is faulty, providing bad clock.
l The tributary board is faulty. As a result, the clock is of a bad quality.
l The timing unit is faulty, proving bad timing source or being unable to lock the traced
timing source.
Related Alarms
Alarm name Correlation
Procedure
Step 1 Refer to the 11.2.89 TUPJCHIGH.
----End
Related Information
None.
11.2.91 TUPJCNEW
Description
The TUPJCNEW is a performance event indicating the count of new TU pointer
justifications.
Attribute
Performance Event Performance Event Type
ID
Impact on System
A small amount of pointer justification does not affect the services, whereas a large amount of
pointer justification causes bit errors in the services. In this case, detect the causes and
troubleshoot the problem in a timely manner. Otherwise, alarms will be generated and the
signal transmission quality will be affected.
l If the NEs trace the external clock, check the quality of the external clock.
Human factors:
l The configuration of the clock source is incorrect. There are two clock sources in one
network.
l The configuration of the clock source tracing priority is incorrect. The clocks of the two
NEs trace each other.
Equipment problems:
l The LU is faulty, providing bad clock.
l The tributary board is faulty. As a result, the clock is of a bad quality.
l The timing unit is faulty, proving bad timing source or being unable to lock the traced
timing source.
Related Alarms
Alarm name Correlation
Procedure
Step 1 Refer to the 11.2.89 TUPJCHIGH.
----End
Related Information
None.
11.2.92 WCV
Description
Pump Laser Working Current, also called Pump Laser Driver Current or Pump Laser Bias
Current.
It includes:
l WCVMAX: stand for the maximum value during a period of time (in 1mA).
l WCVMIN: stand for the minimum value during a period of time (in 1mA).
l WCVCUR: stand for the current value (in 1mA).
Attribute
Performance Event Performance Event Type
ID
WCVMIN: 0x71
WCVCUR: 0x72
Impact on System
When the pump laser works normally, there is no impact on the services. If an alarm is
generated, determine the cause.
Related Alarms
Alarm Name Correlation
PUM_BCM_ALM The board reports this alarm when the detected pump laser driver
current is higher than the threshold due to laser exceptions caused
by laser aging, or over-high/low environment temperature.
LSR_WILL_DIE The board reports this alarm when the pump laser driver current is
higher than the termination threshold due to laser aging.
Procedure
Step 1 If any alarm occurs, use the method of the related alarm to clear it.
----End
Related Information
None.
11.2.93 XCSTMP
Description
The XCSTMP is a performance event indicating the temperature of a board. It contains the
XCSTMPMAX, XCSTMPMIN, and XCSTMPCUR, which respectively indicates the
maximum value, minimum value, and current value of the temperature of a board.
Attribute
Performance Event Performance Event Type
ID
XCSTMPMIN: 0xBD
XCSTMPCUR: 0xBE
Impact on System
Excessively high or low board temperature might cause faults such as degradation of the
board working performance and bit errors.
Related Alarms
Alarm Name Correlation
Procedure
Step 1 If any alarm occurs, use the method of the related alarm to clear it.
----End
Related Information
None.
11.3.1 AlignmentErrors
Description
The AlignmentErrors event indicates the number of received frames with an alignment error,
involving AligErrOv and AligErrUd performance events. The AligErrOv performance event
indicates that the received frames with alignment error exceed the upper threshold. The
AligErrUd performance event indicates that the received frames with alignment error are
lower than the lower threshold.
Attribute
Performance Event ID Performance Event Type
AligErrUd: 0x0132
Impact on System
When an alignment error occurs to a packet, the cyclic redundancy check (CRC) error is
usually accompanied. When a CRC error occurs, the packet is usually discarded and thus
system services are affected.
Related Alarms
None.
Procedure
l Cause 1: A transmission fault exists at the peer end.
a. If the AligErrOv performance event is reported, connect the Smartbits and the
Ethernet board to check whether bit errors exist in the packets transmitted from the
peer end. If yes, rectify the peer fault first.
l Cause 2: The external line is faulty.
a. If the AligErrOv performance event is reported, check whether the local end reports
ETH_LOS and B3_EXC_VC3 alarms caused by damaged external lines and too
large attenuation. If yes, see relevant alarm handling methods.
l Cause 3: The board is internally faulty.
a. If the AligErrOv performance event is reported, check whether the board reports
alarms indicating a board or chip fault, such as the HARD_BAD alarm. If yes, see
relevant alarm handling methods.
l If the AligErrUd performance event is reported, you can infer that the performance
indicator has restored to normal. You can check whether the local end can receive
services normally. If the services are normally received, check whether the lower
threshold is set to 0. If not, set the lower threshold to a lower value to eliminate the
performance event.
----End
Related Information
For the 4.0 platform, an alarm is reported after the RMON statistical value exceeds the
threshold. For the 5.0 platform, an event is reported after the RMON statistical value exceeds
the threshold. Performance events are classified into two types: events indicating that the
performance statistical value exceeds the upper threshold and events indicating that the
performance statistical value is lower than the lower threshold.
RMON performance items are threshold-crossing events. Hence, the RMON performance
events can be used to determine whether the statistical value within a sampling period exceeds
the threshold. The sampling period is set to 10 s by default and is changeable.
AligErrOv GE: 9
100 Mbit/s: 1
10 Mbit/s: 1
NOTE
The lower threshold of the AligErrUd performance event is 0 by default. You can set the lower threshold
according to actual situations. A proper lower threshold can prompt you that the performance item is
restored to normal.
11.3.2 InBadOcts
Description
The InBadOcts event indicates the total number of bytes in bad packets received, excluding
the framing bit but including the FCS byte. The InBadOcts event involves InBadOctsOv and
InBadOctsUd performance events. The InBadOctsOv performance event indicates that the
total number of bytes in bad packets received exceeds the upper threshold. The InBadOctsUd
performance event indicates that the total number of bytes in bad packets received is lower
than the lower threshold.
Attribute
Performance Event ID Performance Event Type
InBadOctsUd: 0x012C
Impact on System
Boards discard bad packets. This may even interrupt system services.
Related Alarms
None.
Procedure
l Cause 1: An error occurs when the peer end transmits packets.
a. If the InBadOctsOv performance event is reported, connect the Smartbits and the
Ethernet board to check whether bit errors exist in the packets transmitted from the
peer end. If yes, rectify the peer fault first.
l Cause 2: The transmission line is in poor quality and bit errors exist.
a. If the InBadOctsOv performance event is reported, check whether the local end
reports ETH_LOS alarms and BER-related alarms such as the B3_EXC_VC3
alarm caused by damaged external lines and too large attenuation. If yes, see
relevant alarm handling methods.
l Cause 3: The board hardware at the local end is faulty.
a. If the InBadOctsOv performance event is reported, check whether the board reports
alarms indicating a board or chip fault, such as the HARD_BAD alarm. If yes, see
relevant alarm handling methods.
l If the InBadOctsUd performance event is reported, you can infer that the performance
indicator has restored to normal. You can check whether the local end can receive
services normally. If the services are normal, check whether the lower threshold is set to
0. If not, set the lower threshold to a lower value to eliminate the performance event.
----End
Related Information
For the 4.0 platform, an alarm is reported after the RMON statistical value exceeds the
threshold. For the 5.0 platform, an event is reported after the RMON statistical value exceeds
the threshold. Performance events are classified into two types: events indicating that the
performance statistical value exceeds the upper threshold and events indicating that the
performance statistical value is lower than the lower threshold.
RMON performance items are threshold-crossing events. Hence, the RMON performance
events can be used to determine whether the statistical value within a sampling period exceeds
the threshold. The sampling period is set to 10 s by default and is changeable.
NOTE
The lower threshold of the InBadOctsUd performance event is 0 by default. You can set the lower
threshold according to actual situations. A proper lower threshold can prompt you that the performance
item is restored to normal.
11.3.3 OutBadOcts
Description
The OutBadOcts event indicates the total number of bytes in bad packets transmitted,
excluding the framing bit but including the FCS byte. The OutBadOcts event involves
OutBadOctsOv and OutBadOctsUd performance events. The OutBadOctsOv performance
event indicates that the total number of bytes in bad packets transmitted exceeds the upper
threshold. The OutBadOctsUd performance event indicates that the total number of bytes in
bad packets transmitted is lower than the lower threshold.
Attribute
Performance Event ID Performance Event Type
OutBadOctsUd: 0x012E
Impact on System
The services of the connected equipment are affected, including data services and changes of
the protocol-related state machine.
Related Alarms
None.
Procedure
l If the OutBadOctsOv performance event is reported, check whether the board reports
alarms indicating a board or chip fault, such as the HARD_BAD alarm. If yes, see
relevant alarm handling methods.
l If the OutBadOctsUd performance event is reported, you can infer that the performance
indicator has restored to normal. You can check whether the local end can transmit
services normally. For example, query whether the send-back alarm indicating that the
peer end receives services abnormally disappears. If the services are normal, check
whether the lower threshold is set to 0. If not, set the lower threshold to a lower value to
eliminate the performance event.
----End
Related Information
RMON statistical value
For the 4.0 platform, an alarm is reported after the RMON statistical value exceeds the
threshold. For the 5.0 platform, an event is reported after the RMON statistical value exceeds
the threshold. Performance events are classified into two types: events indicating that the
performance statistical value exceeds the upper threshold and events indicating that the
performance statistical value is lower than the lower threshold.
RMON performance items are threshold-crossing events. Hence, the RMON performance
events can be used to determine whether the statistical value within a sampling period exceeds
the threshold. The sampling period is set to 10 s by default and is changeable.
NOTE
The lower threshold of the OutBadOctsUd performance event is 0 by default. You can set the lower
threshold according to actual situations. A proper lower threshold can prompt you that the performance
item is restored to normal.
State machine
Protocol implementation can be described by state machines. Each state machine stands for a
functional domain. The functional domain contains a group of absolute states that are
mutually associated and converted.
11.3.4 Collisions
Description
The Collisions event indicates the number of detected packet collisions, involving ColOv and
ColUd performance events. The ColOv performance event indicates that the detected
collisions exceed the upper threshold. The ColUd performance event indicates that the
detected collisions are lower than the lower threshold.
Attribute
Performance Event ID Performance Event Type
ColUd: 0x0130
Impact on System
The port collision event causes delay or packet losses during data transmission.
Related Alarms
None.
Procedure
Step 1 If the ColOv performance event is reported, query the working modes of the associated ports
through the U2000. If most ports work in half-duplex mode, adjust them to be in full-duplex
or auto-negotiation mode.
Step 2 If the ColUd performance event is reported, you can infer that the performance indicator has
restored to normal. In this case, check whether the lower threshold is set to 0. If not, set the
lower threshold to a lower value to eliminate the performance event.
Step 3 If the performance event persists, check whether the board reports alarms indicating a board
or chip fault, such as the HARD_BAD alarm. If yes, see relevant alarm handling methods.
----End
Related Information
For the 4.0 platform, an alarm is reported after the RMON statistical value exceeds the
threshold. For the 5.0 platform, an event is reported after the RMON statistical value exceeds
the threshold. Performance events are classified into two types: events indicating that the
performance statistical value exceeds the upper threshold and events indicating that the
performance statistical value is lower than the lower threshold.
RMON performance items are threshold-crossing events. Hence, the RMON performance
events can be used to determine whether the statistical value within a sampling period exceeds
the threshold. The sampling period is set to 10 s by default and is changeable.
NOTE
The lower threshold of the ColUd performance event is 0 by default. You can set the lower threshold
according to actual situations. A proper lower threshold can prompt you that the performance item is
restored to normal.
Description
The Deferred Transmissions event indicates the number of frames deferred due to
transmission medium congestion when they are transmitted for the first time. Note that the
counting value does not include the frames related to packet collisions. The event involves
DefTxOv and DefTxUd performance events. The DefTxOv performance event indicates that
the frames transmitted unsuccessfully exceed the upper threshold. The DefTxUd performance
event indicates that the frames transmitted unsuccessfully are lower than the lower threshold.
Attribute
Performance Event ID Performance Event Type
DefTxUd: 0x013A
Impact on System
This event decreases the rate of frame transmission and thus leads to packet congestion within
a board. This finally decreases the throughput capability of the board.
Related Alarms
None.
Procedure
Step 1 If the DefTxOv performance event is reported, query the working modes of the associated
ports through the U2000. If most ports work in half-duplex mode, adjust them to be in full-
duplex or auto-negotiation mode.
Step 2 If the DefTxUd performance event is reported, you can infer that the performance indicator
has restored to normal. In this case, check whether the lower threshold is set to 0. If not, set
the lower threshold to a lower value to eliminate the performance event.
Step 3 If the performance event persists, check whether the board reports alarms indicating a board
or chip fault, such as the HARD_BAD alarm. If yes, see relevant alarm handling methods.
----End
Related Information
For the 4.0 platform, an alarm is reported after the RMON statistical value exceeds the
threshold. For the 5.0 platform, an event is reported after the RMON statistical value exceeds
the threshold. Performance events are classified into two types: events indicating that the
performance statistical value exceeds the upper threshold and events indicating that the
performance statistical value is lower than the lower threshold.
RMON performance items are threshold-crossing events. Hence, the RMON performance
events can be used to determine whether the statistical value within a sampling period exceeds
the threshold. The sampling period is set to 10 s by default and is changeable.
DefTxOv GE: 9
100 Mbit/s: 1
10 Mbit/s: 1
NOTE
The lower threshold value of the DefTxUd performance event is 0 by default. You can set the lower
threshold according to actual situations. A proper lower threshold can prompt you that the performance
item is restored to normal.
11.3.6 DropEvent
Description
The DropEvent indicates the number of packet drop events due to the lack of resources,
involving DropOv and DropUd performance events. The DropOv performance event indicates
that the number of packet drop events exceeds the upper threshold. The DropUd performance
event indicates that the number of packet drop events is lower than the lower threshold.
NOTE
The counting value does not mean the number of dropped packets but means the number of packet drop
events.
Attribute
Performance Event ID Performance Event Type
DropUd: 0x012A
Impact on System
Too many packet drops affect services directly and have serious impacts on the system.
Therefore, you need to check packet drops in time.
Related Alarms
None.
Procedure
Step 1 If the DropOv performance event is reported, enable the flow control through the U2000. You
can configure data traffic according to actual services and manually reduce port traffic.
Step 2 If the DropUd performance event is reported, you can infer that the performance indicator has
restored to normal. You can check whether the local end can receive services normally. If the
services are normal, check whether the lower threshold is set to 0. If not, set the lower
threshold to a lower value to eliminate the performance event.
Step 3 If the performance event persists, check whether the board reports alarms indicating a board
or chip fault, such as the HARD_BAD alarm. If yes, see relevant alarm handling methods.
----End
Related Information
For the 4.0 platform, an alarm is reported after the RMON statistical value exceeds the
threshold. For the 5.0 platform, an event is reported after the RMON statistical value exceeds
the threshold. Performance events are classified into two types: events indicating that the
performance statistical value exceeds the upper threshold and events indicating that the
performance statistical value is lower than the lower threshold.
RMON performance items are threshold-crossing events. Hence, the RMON performance
events can be used to determine whether the statistical value within a sampling period exceeds
the threshold. The sampling period is set to 10 s by default and is changeable.
DropOv GE: 9
100 Mbit/s: 1
10 Mbit/s: 1
NOTE
The lower threshold of the DropUd performance event is 0 by default. You can set the lower threshold
according to actual situations. A proper lower threshold can prompt you that the performance item is
restored to normal.
11.3.7 FCSErrors
Description
The FCSErrors event indicates the number of the Ethernet data frames with an FCS error,
excluding ultra long frames and ultra short frames. The FCS Errors event involves FCSErrOv
and FCSErrUd performance events, indicating that the frames with an FCS error exceed the
upper threshold and are lower than the lower threshold respectively.
Attribute
Performance Event ID Performance Event Type
FCSErrUd: 0x0134
Impact on System
Most boards discard packets with an FCS error. This may even interrupt system services.
l Cause 1: The working modes of the ports are mismatched at both ends. For example, the
full-duplex mode is used at one end and the half-duplex mode is used at the other end.
l Cause 2: The line quality in the receive direction of an Ethernet board is poor, and bit
errors exist.
l Cause 3: The board hardware at the local end is faulty.
Related Alarms
None.
Procedure
l Cause 1: The working modes of the ports are mismatched at both ends.
a. If the FCSErrOv performance event is reported, query whether the working modes
of the ports at both ends are matched through the U2000. If mismatched, adjust the
working modes of the ports according to actual situations.
l Cause 2: The line quality in the receive direction of an Ethernet board is poor, and bit
errors exist.
a. If the FCSErrOv performance event is reported, check whether the local end reports
ETH_LOS alarms caused by damaged external lines and too large attenuation. If
yes, see relevant alarm handling methods.
l Cause 3: The board hardware at the local end is faulty.
a. If the FCSErrOv performance event is reported, check whether the board reports
alarms indicating a board or chip fault, such as the HARD_BAD alarm. If yes, see
relevant alarm handling methods.
l If the FCSErrUd performance event is reported, you can infer that the performance
indicator has restored to normal. In this case, check whether the lower threshold is set to
0. If not, set the lower threshold to a lower value to eliminate the performance event.
----End
Related Information
For the 4.0 platform, an alarm is reported after the RMON statistical value exceeds the
threshold. For the 5.0 platform, an event is reported after the RMON statistical value exceeds
the threshold. Performance events are classified into two types: events indicating that the
performance statistical value exceeds the upper threshold and events indicating that the
performance statistical value is lower than the lower threshold.
RMON performance items are threshold-crossing events. Hence, the RMON performance
events can be used to determine whether the statistical value within a sampling period exceeds
the threshold. The sampling period is set to 10 s by default and is changeable.
FCSErrOv GE: 9
100 Mbit/s: 1
10 Mbit/s: 1
NOTE
The lower threshold of the FCSErrUd performance event is 0 by default. You can set the lower threshold
according to actual situations. A proper lower threshold can prompt you that the performance item is
restored to normal.
11.3.8 Fragments
Description
The Fragments is a performance event indicating the number of packets that contain less than
64 bytes and have FCS or alignment errors. This performance event is reported when the
number of received fragmented packets is more than the upper-threshold or less than the
lower-threshold.
Attribute
Performance Event ID Performance Event Type
Impact on System
Most boards discard the packets that have FCS errors, hence resulting in data transmission
delay or packet loss.
Related Alarms
None.
Procedure
l Cause 1: The working modes of the ports are mismatched at both ends.
a. If the number of received fragmented packets is more than the upper-threshold,
query whether the working modes of the ports at both ends are matched through the
U2000. If mismatched, adjust the working modes of the ports according to actual
situations.
l Cause 2: The board hardware is faulty.
a. If the number of received fragmented packets is more than the upper-threshold,
check whether the board at the local end or oppossite end reports alarms indicating
a board or chip fault, such as the HARD_BAD alarm. If yes, see relevant alarm
handling methods.
----End
Related Information
For the 4.0 platform, an alarm is reported after the RMON statistical value exceeds the
threshold. For the 5.0 platform, an event is reported after the RMON statistical value exceeds
the threshold. Performance events are classified into two types: events indicating that the
performance statistical value exceeds the upper threshold and events indicating that the
performance statistical value is lower than the lower threshold.
RMON performance items are threshold-crossing events. Hence, the RMON performance
events can be used to determine whether the statistical value within a sampling period exceeds
the threshold. The sampling period is set to 10 s by default and is changeable.
Fragments GE: 9
100 Mbit/s: 1
10 Mbit/s: 1
NOTE
The lower threshold of the Fragments performance event is 0 by default. You can set the lower threshold
according to actual situations. A proper lower threshold can prompt you that the performance item is
restored to normal.
11.3.9 Jabbers
Description
The Jabbers is a performance event indicating the number of packets that contain more than
1518 bytes and have FCS or alignment errors. This performance event is reported when the
number of received fuzzy packets is more than the upper-threshold or less than the lower-
threshold.
Attribute
Performance Event ID Performance Event Type
Impact on System
Most boards discard the packets that have FCS errors, hence resulting in data transmission
delay or packet loss.
l Cause 1: The working modes of the ports are mismatched at both ends. For example, the
full-duplex mode is used at one end and the half-duplex mode is used at the other end.
Related Alarms
None.
Procedure
l Cause 1: The working modes of the ports are mismatched at both ends.
a. If the number of received fuzzy packets is more than the upper-threshold, query
whether the working modes of the ports at both ends are matched through the
U2000. If mismatched, adjust the working modes of the ports according to actual
situations.
l Cause 2: The board hardware is faulty.
a. If the number of received fuzzy packets is less than the lower-threshold, check
whether the board at the local end or oppossite end reports alarms indicating a
board or chip fault, such as the HARD_BAD alarm. If yes, see relevant alarm
handling methods.
----End
Related Information
For the 4.0 platform, an alarm is reported after the RMON statistical value exceeds the
threshold. For the 5.0 platform, an event is reported after the RMON statistical value exceeds
the threshold. Performance events are classified into two types: events indicating that the
performance statistical value exceeds the upper threshold and events indicating that the
performance statistical value is lower than the lower threshold.
RMON performance items are threshold-crossing events. Hence, the RMON performance
events can be used to determine whether the statistical value within a sampling period exceeds
the threshold. The sampling period is set to 10 s by default and is changeable.
Jabbers GE: 10
100 Mbit/s: 1
10 Mbit/s: 1
NOTE
The lower threshold of the Jabbers performance event is 0 by default. You can set the lower threshold
according to actual situations. A proper lower threshold can prompt you that the performance item is
restored to normal.
Description
The Late Collisions event indicates the number of collisions detected within a timeslot period
after a packet is transmitted, involving LateColOv and ColUd performance events. The
LateColOv performance event indicates that the detected collisions exceed the upper
threshold. The LateColUd performance event indicates that the detected collisions are lower
than the lower threshold.
Attribute
Performance Event ID Performance Event Type
LateColUd: 0x0136
Impact on System
Based on the implementation principles of boards, the impacts of this performance event on
the system are as follows:
l If a board neglects the reported performance event and does not stop transmitting packets
until the packets are transmitted normally, the delay is caused when the peer end receives
services.
l If a board records the reported performance event and stops transmitting packets, the
peer end fails to receive services normally.
Related Alarms
None.
Procedure
l If the LateColOv performance event is reported, check whether the network diameter of
an LAN is too large. If yes, divide the network and deploy equipment to different buses
or physically shared equipment (such as the hub).
NOTE
For the port rate of 10 Mbit/s, the maximum Ethernet diameter is 2000 m. For the port rate of 100
Mbit/s, the maximum Ethernet diameter is 200 m.
l If the LateColUd performance event is reported, you can infer that the performance
indicator has restored to normal. In this case, check whether the lower threshold is set to
0. If not, set the lower threshold to a lower value to eliminate the performance event.
----End
Related Information
For the 4.0 platform, an alarm is reported after the RMON statistical value exceeds the
threshold. For the 5.0 platform, an event is reported after the RMON statistical value exceeds
the threshold. Performance events are classified into two types: events indicating that the
performance statistical value exceeds the upper threshold and events indicating that the
performance statistical value is lower than the lower threshold.
RMON performance items are threshold-crossing events. Hence, the RMON performance
events can be used to determine whether the statistical value within a sampling period exceeds
the threshold. The sampling period is set to 10 s by default and is changeable.
NOTE
The lower threshold of the LateColUd performance event is 0 by default. You can set the lower
threshold according to actual situations. A proper lower threshold can prompt you that the performance
item is restored to normal.
11.3.11 OversizePkts
Description
The OversizePkts is a performance event indicating the number of packets that are received
on the Ethernet MAC port side, contain more than 1518 octets (excluding framing bits, but
including FCS octets) and are otherwise well formed. This performance event is reported
when the number of received ultra long packets is more than the upper-threshold or less than
the lower-threshold.
Attribute
Performance Event ID Performance Event Type
Impact on System
During data transmission, this performance event affects the system to a certain extent
depending on the preset maximum frame length of the port and the actual received frame
length of the port.
l If the length of a data frame received by the port is longer than the preset maximum
length, the data frame is discarded, and thus the system services are affected.
l If the length of a data frame received by the port is shorter than the preset maximum
length, the system and services are not affected. The user is only prompted that the data
frame received by the port contains more than 1518 octets.
Related Alarms
None.
Procedure
l Cause 1: The frame received by the board contains more than 1518 octets.
a. Check the preset maximum frame length of the local port.
n If the length of the data frame received by the port is longer than the preset
maximum frame length, change the preset maximum frame length to the frame
length that is supported by the board to ensure that the data frame is not
discarded.
n If the length of the data frame received by the port is longer than 1518 bytes
but shorter than the preset maximum frame length, the data frame is not
discarded. The performance event is, however, reported continuously.
l Cause 2: The board hardware is faulty.
a. Check whether the board at the opposite end or local end reports alarms indicating a
board or chip fault, such as the HARD_BAD alarm. If yes, see relevant alarm
handling methods.
----End
Related Information
RMON Performance Threshold
For the 4.0 platform, an alarm is reported after the RMON statistical value exceeds the
threshold. For the 5.0 platform, an event is reported after the RMON statistical value exceeds
the threshold. Performance events are classified into two types: events indicating that the
performance statistical value exceeds the upper threshold and events indicating that the
performance statistical value is lower than the lower threshold.
RMON performance items are threshold-crossing events. Hence, the RMON performance
events can be used to determine whether the statistical value within a sampling period exceeds
the threshold. The sampling period is set to 10 s by default and is changeable.
OversizePkts GE: 9
100 Mbit/s: 1
10 Mbit/s: 1
NOTE
The lower threshold of the OversizePkts performance event is 0 by default. You can set the lower
threshold according to actual situations. A proper lower threshold can prompt you that the performance
item is restored to normal.
11.3.12 UndersizePkts
Description
The UndersizePkts is a performance event indicating the number of packets that are received
on the Ethernet MAC port side, contain less than 64 octets (excluding framing bits, but
including FCS octets) and are otherwise well formed. This performance event is reported
when the number of received ultra long packets is more than the upper-threshold or less than
the lower-threshold.
Attribute
Performance Event ID Performance Event Type
Impact on System
Boards discard the received data frames that contain less than 64 octets, thus affecting system
services.
Related Alarms
None.
Procedure
l Cause 1: The board hardware is faulty.
a. Check whether the board at the opposite end or local end reports alarms indicating a
board or chip fault, such as the HARD_BAD alarm. If yes, see relevant alarm
handling methods.
----End
Related Information
RMON Performance Threshold
For the 4.0 platform, an alarm is reported after the RMON statistical value exceeds the
threshold. For the 5.0 platform, an event is reported after the RMON statistical value exceeds
the threshold. Performance events are classified into two types: events indicating that the
performance statistical value exceeds the upper threshold and events indicating that the
performance statistical value is lower than the lower threshold.
RMON performance items are threshold-crossing events. Hence, the RMON performance
events can be used to determine whether the statistical value within a sampling period exceeds
the threshold. The sampling period is set to 10 s by default and is changeable.
UndersizePkts GE: 9
100 Mbit/s: 1
10 Mbit/s: 1
NOTE
The lower threshold of the UndersizePkts performance event is 0 by default. You can set the lower
threshold according to actual situations. A proper lower threshold can prompt you that the performance
item is restored to normal.
l The length range of data frames a board can process is different. The data frames
transmitted from the peer end are in the normal range but may exceed the range of data
frames the local end can process.
l Ultra short frames are independent of services. The operations such as encapsulation on
the peer equipment may change the length of a data frame. As a result, the data frame is
regarded as an ultra short frame by downstream nodes.
11.3.13 Sperbadaddrpkt
Description
The Sperbadaddrpkt event indicates the number of frames with an destination address error
and received by the RPR port.
Attribute
Performance Event Performance Event Type
ID
Impact on System
This performance event may interrupt services.
Related Alarms
None.
Procedure
l Cause 1: The RPR network runs abnormally.
a. Check whether the network runs normally. If not, perform a warm reset on the
board, or enable the RPR protocol again. For the operations of performing a warm
reset on the board, refer to Resetting Boards. For the operations of enabling the
RPR protocol, refer to Configuring RPR Topology Information.
l Cause 2: The external line is faulty.
a. Check whether the local end reports ETH_LOS alarms and BER-related alarms
such as the B3_EXC_VC3 alarm caused by damaged external lines and too large
attenuation. If yes, see relevant alarm handling methods.
l Cause 3: The equipment hardware at the local end is faulty.
a. Check whether the board reports alarms indicating a board or chip fault, such as the
HARD_BAD alarm. If yes, see relevant alarm handling methods.
----End
Related Information
None.
11.3.14 SperbadctlFcspkt
Description
The SperbadctlFcspkt event indicates the number of Ethernet control frames with an FCS
error and received by the RPR port, that is, the number of frames that are not copied to the
MAC control sublayer because of the inconsistency between the actual and expected FCS
values.
Attribute
Performance Event ID Performance Event Type
Impact on System
This performance event affects the topology structure of the RPR network and even interrupts
services.
Related Alarms
None.
Procedure
l Cause 1: The transmission line is in poor quality and bit errors exist.
a. Check whether the local end reports ETH_LOS alarms and BER-related alarms
such as the B3_EXC_VC3 alarm caused by damaged external lines and too large
attenuation. If yes, see relevant alarm handling methods.
l Cause 2: The board hardware at the local end is faulty.
a. Check whether the board reports alarms indicating a board or chip fault, such as the
HARD_BAD alarm. If yes, see relevant alarm handling methods.
----End
Related Information
None.
11.3.15 SperbadDataFcspkt
Description
The SperbadDataFcspkt event indicates the number of Ethernet data frames with an FCS error
and received by the RPR port.
Attribute
Performance Event ID Performance Event Type
Impact on System
The RPR chip discards packets with an FCS error. This may even interrupt system services.
l Cause 1: The transmission line is in poor quality and bit errors exist.
l Cause 2: The board hardware at the local end is faulty.
Related Alarms
None.
Procedure
l Cause 1: The transmission line is in poor quality and bit errors exist.
a. Check whether the local end reports ETH_LOS alarms and BER-related alarms
such as the B3_EXC_VC3 alarm caused by damaged external lines and too large
attenuation. If yes, see relevant alarm handling methods.
l Cause 2: The board hardware at the local end is faulty.
a. Check whether the board reports alarms indicating a board or chip fault, such as the
HARD_BAD alarm. If yes, see relevant alarm handling methods.
----End
Related Information
None.
11.3.16 SperbadFcspkt
Description
The SperbadFcspkt event indicates the number of Ethernet data frames with an FCS error and
received on the line side.
Attribute
Performance Event ID Performance Event Type
Impact on System
The RPR board discards packets with an FCS error. This may even interrupt system services.
Related Alarms
None.
Procedure
l Cause 1: The transmission line is in poor quality and bit errors exist.
a. Check whether the local end reports ETH_LOS alarms and BER-related alarms
such as the B3_EXC_VC3 alarm caused by damaged external lines and too large
attenuation. If yes, see relevant alarm handling methods.
l Cause 2: The board hardware at the local end is faulty.
a. Check whether the board reports alarms indicating a board or chip fault, such as the
HARD_BAD alarm. If yes, see relevant alarm handling methods.
----End
Related Information
In Ethernet frames, FCS is a 32-bit frame check field and is behind the end of the frame. In
this way, the receiving end can detect whether bit errors exist in information payload.
11.3.17 SperbadHecpkt
Description
The SperbadHecpkt event indicates the number of Ethernet data frames with a header error
control (HEC) error on the line side.
Attribute
Performance Event ID Performance Event Type
Impact on System
If an HEC error occurs, the corresponding frame is deleted. This may even affect system
services.
Related Alarms
None.
Procedure
l Cause 1: The RPR topology structure is abnormal or the cross-connect service is
incorrectly configured.
a. Check whether the topology structure of the RPR network is abnormal. In addition,
query whether there are alarms causing ring network switchover through the
U2000, such as the RPR_MISCONFIG alarm. If yes, see relevant alarm handling
methods.
l Cause 2: The board hardware at the local end is faulty.
a. Check whether the board reports alarms indicating a board or chip fault, such as the
HARD_BAD alarm. If yes, see relevant alarm handling methods.
----End
Related Information
The HEC field contains 16 bits and is used to detect and optionally correct frame header
errors in transmission.
11.3.18 SperbadParitypkt
Description
The SperbadParitypkt event indicates the number of the frames with an odd parity check error
on the line side, that is, the number of the frames whose actual parity values are different from
the expected ones.
Attribute
Performance Event ID Performance Event Type
Impact on System
The frames whose actual parity values are different from the expected ones are discarded.
This may invalidate the fair algorithm. In the case of network congestion, the ring network
fails to enable the fair algorithm to adjust node traffic.
l Cause 1: The transmission line is in poor quality and bit errors exist.
l Cause 2: The board hardware at the local end is faulty.
Related Alarms
None.
Procedure
l Cause 1: The transmission line is in poor quality and bit errors exist.
a. Check whether the local end reports ETH_LOS alarms and BER-related alarms
such as the B3_EXC_VC3 alarm caused by damaged external lines and too large
attenuation. If yes, see relevant alarm handling methods.
l Cause 2: The board hardware at the local end is faulty.
a. Check whether the board reports alarms indicating a board or chip fault, such as the
HARD_BAD alarm. If yes, see relevant alarm handling methods.
----End
Related Information
The Parity field contains one bit. Because fairness frames contain no HEC field to protect
frame headers, the SperbadHecpkt event is used to protect TTL and Base Control fields in
RPR data frames.
11.3.19 Spercontainedpkt
Description
The Spercontainedpkt event indicates the number of frames with a sequence error and
received by the RPR port.
Attribute
Performance Event ID Performance Event Type
Impact on System
This performance event may even interrupt services.
Related Alarms
None.
Procedure
l Cause 1: Fiber connections of the RPR network are incorrect.
a. Check whether the fibers of the line boards in the RPR network are correctly
connected. In addition, query whether relevant alarms such as the
RPR_MISCONFIG alarm are generated. If yes, see relevant alarm handling
methods.
l Cause 2: Node numbers in the RPR network are incorrectly configured.
a. Check whether the node numbers in the RPR network conflict. In addition, query
whether relevant alarms such as the RPR_DUPLICATE_MAC alarm are
generated. If yes, see relevant alarm handling methods.
l Cause 3: The equipment hardware at the local end is faulty.
a. Check whether the board reports alarms indicating a board or chip fault, such as the
HARD_BAD alarm. If yes, see relevant alarm handling methods.
----End
Related Information
None.
11.3.20 Spereredsnds
Description
The Spereredsnds event indicates the errored seconds (ESs) of the RPR port.
Attribute
Performance Event ID Performance Event Type
Impact on System
This performance event causes wrong packets in services.
Related Alarms
None.
Procedure
l Cause 1: The external line is faulty.
a. Check whether the local end reports ETH_LOS alarms and BER-related alarms
such as the B3_EXC_VC3 alarm caused by damaged external lines and too large
attenuation. If yes, see relevant alarm handling methods.
l Cause 2: The board hardware at the local end is faulty.
a. Check whether the board reports alarms indicating a board or chip fault, such as the
HARD_BAD alarm. If yes, see relevant alarm handling methods.
----End
Related Information
None.
11.3.21 SperPmdabortpkt
Description
The SperPmdabortpkt event indicates the number of frames received by the RPR port but
discarded by the physical medium dependent (PMD) sublayer.
Attribute
Performance Event ID Performance Event Type
Impact on System
This performance event may even interrupt services.
Related Alarms
None.
Procedure
Step 1 Check whether the board reports alarms indicating a board or chip fault, such as the
HARD_BAD alarm. If yes, see relevant alarm handling methods.
----End
Related Information
The PMD sublayer defines bottom-layer parameters, such as the bit rate on the medium.
11.3.22 SperScffers
Description
The SperScffers event indicates the frames with a single-choke fairness frame (SCFF)error
and received by the RPR port.
Attribute
Performance Event ID Performance Event Type
Impact on System
This performance event may invalidate the fair algorithm of the RPR. In the case of network
congestion, the ring network fails to enable the fair algorithm to adjust node traffic.
l Cause 1: The transmission line is in poor quality and bit errors exist.
l Cause 2: The board hardware at the local end is faulty.
Related Alarms
None.
Procedure
l Cause 1: The transmission line is in poor quality and bit errors exist.
a. Check whether the local end reports ETH_LOS alarms and BER-related alarms
such as the B3_EXC_VC3 alarm caused by damaged external lines and too large
attenuation. If yes, see relevant alarm handling methods.
l Cause 2: The board hardware at the local end is faulty.
a. Check whether the board reports alarms indicating a board or chip fault, such as the
HARD_BAD alarm. If yes, see relevant alarm handling methods.
----End
Related Information
The SCFF is to notify upstream nodes of the calculated fair-rate fairness frames of the local
node.
11.3.23 SperSelfSrcupkt
Description
The SperSelfSrcupkt event indicates the number of unicast frames with their source addresses
removed. The event is used to count the data frames transmitted and received by the same
station.
Attribute
Performance Event ID Performance Event Type
Impact on System
None.
Related Alarms
None.
Procedure
l Cause 1: The RPR topology structure is abnormal.
a. Check whether the topology structure of the RPR network is abnormal. In addition,
query whether there are alarms causing ring network switchover through the
U2000, such as the RPR_MISCONFIG alarm. If yes, see relevant alarm handling
methods.
l Cause 2: The board hardware at the local end is faulty.
a. Check whether the board reports alarms indicating a board or chip fault, such as the
HARD_BAD alarm. If yes, see relevant alarm handling methods.
----End
Related Information
In normal cases, the frames transmitted from a source station must not be received by the
same source station in the ring network.
11.3.24 SperSvlrdsnds
Description
The SperSvlrdsnds event indicates the severely errored seconds (SESs) of the RPR port.
Attribute
Performance Event ID Performance Event Type
Impact on System
This performance event causes substantive wrong packets in services. You need to find out
causes and handle the performance event in time to prevent an alarm. Otherwise, the signal
transmission quality is affected and services are even interrupted.
Related Alarms
None.
Procedure
l Cause 1: The external line is faulty.
a. Check whether the local end reports ETH_LOS alarms and BER-related alarms
such as the B3_EXC_VC3 alarm caused by damaged external lines and too large
attenuation. If yes, see relevant alarm handling methods.
l Cause 2: The board hardware at the local end is faulty.
a. Check whether the board reports alarms indicating a board or chip fault, such as the
HARD_BAD alarm. If yes, see relevant alarm handling methods.
----End
Related Information
The ES indicates the second containing more than one bit error block. The SES indicates the
second containing 30% bit error blocks or the second in which one defect occurs.
11.3.25 Spertlpkt
Description
The Spertlpkt event indicates the number of ultra long frames received on the line side, that is,
the number of ultra long frames received by the RPR side from the SDH side.
Attribute
Performance Event ID Performance Event Type
Impact on System
If the length of the data frame received by a board exceeds the preset length, the data frame is
discarded, thus affecting system services.
Related Alarms
None.
Procedure
l Cause 1: The length configured by a board for ultra long frames is less than the length of
the frame actually received by the board.
a. Check whether the peer equipment transmits data frames that are ultra long frames
for the local equipment.
n If the data to be transmitted is too long due to peer service configurations, re-
configure the length of data frames.
n If the ranges of the data frames processed by the transmitting and receiving
nodes are different, modify the ranges.
l Cause 2: The board hardware at the local end is faulty.
a. Check whether the board reports alarms indicating a board or chip fault, such as the
HARD_BAD alarm. If yes, see relevant alarm handling methods.
----End
Related Information
l The length range of data frames a board can process is different. The data frames
transmitted from the peer end are in the normal range but may exceed the range of data
frames the local end can process.
l Ultra long frames are independent of services. The operations such as encapsulation on
the peer equipment may change the length of a data frame. As a result, the data frame is
regarded as an ultra long frame by downstream nodes.
11.3.26 Spertspkt
Description
The Spertlpkt event indicates the number of ultra short frames received on the line side, that
is, the number of ultra short frames received by the RPR side from the SDH side.
Attribute
Performance Event ID Performance Event Type
Impact on System
Based on board implementation principles, the RPR chip has different length requirements for
received data frames. Boards discard the received data frames exceeding the frame length
range, thus affecting system services.
l Cause 1: The length of the frame actually received by a board is less than the length
configured by the board for ultra short frames.
l Cause 2: The board hardware at the local end is faulty.
Related Alarms
None.
Procedure
l Cause 1: The length of the frame actually received by a board is less than the length
configured by the board for ultra short frames.
a. Check whether the peer equipment transmits data frames that are ultra short frames
for the local equipment.
n If the data to be transmitted is too short due to peer service configurations, re-
configure the length of data frames.
n If the ranges of the data frames processed by the transmitting and receiving
nodes are different, modify the ranges.
l Cause 2: The board hardware at the local end is faulty.
a. Check whether the board reports alarms indicating a board or chip fault, such as the
HARD_BAD alarm. If yes, see relevant alarm handling methods.
----End
Related Information
l The length range of data frames a board can process is different. The data frames
transmitted from the peer end are in the normal range but may exceed the range of data
frames the local end can process.
l Ultra short frames are independent of services. The operations such as encapsulation on
the peer equipment may change the length of a data frame. As a result, the data frame is
regarded as an ultra short frame by downstream nodes.
11.3.27 SperTtlExppkt
Description
The SperTtlExppkt event indicates the number of stripped packets with TTL set to 0 on the
local node.
Attribute
Performance Event ID Performance Event Type
Impact on System
Boards discard the packets with TTL set to 0. Before substantive packets arrive at the
destination node, their TTL values decrease to 0 due to abnormal factors. This seriously
affects system services.
Related Alarms
None.
Procedure
l Cause 1: The system topology is abnormal.
a. Check whether the topology structure of the RPR network is abnormal. In addition,
query whether there are alarms causing ring network switchover through the
U2000, such as the RPR_MISCONFIG alarm. If yes, see relevant alarm handling
methods.
l Cause 2: The board hardware at the local end is faulty.
a. Check whether the board reports alarms indicating a board or chip fault, such as the
HARD_BAD alarm. If yes, see relevant alarm handling methods.
----End
Related Information
The TTL indicates the maximum time for a packet to live in a network. Its value should be
equal to or greater than the number of nodes the packet passes through.
Before a packet arrives at the destination node, the TTL value decreases by 1 every time the
packet passes through a node. When the TTL value decreases to 0, the packet is discarded.
11.3.28 SperUasnds
Description
The SperUasnds event indicates the unavailable seconds (UASs) of the PRP port path.
Attribute
Performance Event ID Performance Event Type
Impact on System
This performance event indicates that bit errors exist in services. You need to find out causes
and handle the performance event in time to ensure signal transmission quality.
l Cause 1: The transmission line is in poor quality and bit errors exist.
Related Alarms
None.
Procedure
l Cause 1: The transmission line is in poor quality and bit errors exist.
a. Check whether the local end reports ETH_LOS alarms and BER-related alarms
such as the B3_EXC_VC3 alarm caused by damaged external lines and too large
attenuation. If yes, see relevant alarm handling methods.
l Cause 2: The board hardware at the local end is faulty.
a. Check whether the board reports alarms indicating a board or chip fault, such as the
HARD_BAD alarm. If yes, see relevant alarm handling methods.
----End
Related Information
UAS
The UAS indicates that the time from second 11 when the SESs last over then seconds. The
ten-second time with SESs is also included in the unavailable time. When the SESs disappear
for over ten seconds, the available time from second 11 arrives. The ten-second time without
SESs is also included in the available time.
When the RPR network is interrupted, UASs starts to be counted.
11.4.1 RSL
Description
The RSL is a performance event indicating the microwave receive signal level. It contains the
RSLMAX, RSLMIN, and RSLCUR, which respectively indicates the maximum value,
minimum value, and current value of the microwave receive signal level.
Attribute
Performance Event Performance Event Type
ID
RSLMIN: 0x219F
RSLCUR: 0x21A0
Impact on System
When the microwave receive power is overly low or overly high, bit errors might occur and
the service might be interrupted.
Related Alarms
Alarm Name Correlation
RADIO_RSL_LOW This alarm is reported when the receive signal level is less
than the specified lower threshold.
Procedure
Step 1 If any alarm occurs, use the method of the related alarm to clear it.
----End
Related Information
None.
11.4.2 TSL
Description
The TSL is a performance event indicating the microwave transmit signal level. It contains
the TSLMAX, TSLMIN, and TSLCUR, which respectively indicates the maximum value,
minimum value, and current value of the microwave transmit signal level.
Attribute
Performance Event Performance Event Type
ID
TSLMIN: 0x21A2
TSLCUR: 0x21A3
Impact on System
When the microwave transmit power is too low or too high, the receive power at the opposite
station will be too low or too high. Moreover, bit errors might occur and services might be
interrupted.
Related Alarms
Alarm Name Correlation
Procedure
Step 1 If any alarm occurs, use the method of the related alarm to clear it.
----End
Related Information
None.
This topic describes the abnormal events that are provided for the OSN products.
Abnormal events, such as board resetting and various switching operations, indicate the
current operating status of the network. Abnormal events may also notify the user of certain
operations on a real-time basis.
NOTICE
The board removal, board installation, and cold resetting operations mentioned in the
document interrupt services. Therefore, you need to take precautions before you perform such
operations if the services that pass the relevant boards are not provided with protection.
NOTE
The event names and parameter values may vary according to the version of the NMS.
Attribute
Abnormal Event Severity Abnormal Event Type
Parameters
Name Meaning
Parameter 2 Indicates the current path where the linear MSP operates.
l "1" indicates the working path.
l "0" indicates the protection path.
Impact on System
This event prompts users to identify the cause of MSP switching. If a link fails, you should
repair it promptly and ensure that the working path and protection path of the linear MSP are
in the idle state.
Possible Causes
The possible causes of the linear MSP switching are as follows:
SF R_LOS
R_LOF
MS_AIS
B2_EXC
SD B2_SD
Procedure
l Check the abnormal event on the NMS.
l Cause 1: This event is automatically triggered.
a. Identify the cause of the linear MSP switching according to Parameter 3 of this
event.
n If the switching request is of the LPS_SF or LPS_SD type, go to the next step.
n If the switching request is of the LPS_MS type, go to the handling procedure
associated with cause 2.
n If the switching request is of the LPS_WTR (the service is normal in the
working path), LPS_NR (the service is normal in the working path), or
LPS_DNR type (the protection path is carrying services), you can ignore this
event.
n If the switching request is of the LPS_LP type, check whether the switching is
caused by human intervention or by protection failures.
If the switching is caused by human intervention, you need to clear the
lockout state. For details, refer to Querying and Clearing the Switching
Status in the Supporting Tasks.
If the switching is caused by protection failure, go to the next step.
n If the switching request is of the STOP type, choose Configuration > Linear
MS from the Function Tree. Click Start Protocol.
b. Query current alarms on the NMS. For details, refer to Viewing the Current Alarms
in the Supporting Tasks. Then check whether the working path or the protection
path has any of the alarms listed in Table 13-1. If yes, handle the alarms before you
proceed.
c. Check the status of the current linear MS. For details, refer to Querying and
Clearing the Switching Status in the Supporting Tasks. If the working path and
protection path of the current linear MS are in the idle state, you can infer that the
fault has been rectified.
l Cause 2: This event is manually triggered.
a. Identify the cause of the linear MSP switching according to Parameter 3 of this
event.
n If the switching request is of the LPS_FS, or LPS_MS, or LPS_EXER type,
go to the next step.
n If the switching is automatically triggered, go to the handling procedure
associated with cause 1.
b. Based on the occurrence time of the switching event, query the event logs through
the NMS, and check whether the switching is triggered manually. For details, refer
to Querying the Operation Log of the NMS in Supporting Tasks. If it is triggered
manually, go to the next step.
c. Check the status of the current linear MS. For details, refer to Querying and
Clearing the Switching Status in the Supporting Tasks.
n If the working path and protection path of the current linear MS are in the idle
state, go to the next step.
n If either the working path or the protection path of the current linear MS, or
both of them, are not in the idle state, take step 2 of cause 1.
d. Clear the manual switching state. For details, refer to Querying and Clearing the
Switching Status in the Supporting Tasks.
----End
Related Information
For details about how to handle the problems associated with MSP switching, see
"Troubleshooting Multiplex Section Protection Switching Faults" in Troubleshooting.
Attribute
Abnormal Event Severity Abnormal Event Type
Parameters
Name Meaning
Parameter 1 Indicates the source of the SNCP, consisting of the slot number,
optical interface number, higher order path number, and lower
order path number.
Parameter 2 Indicates the sink of the SNCP, consisting of the slot number,
optical interface number, higher order path number, and lower
order path number.
Parameter 5 Indicates the current state of the working path in the SNCP.
l SF
l SD
l NORMAL
Parameter 6 Indicates the current state of the protection path in the SNCP.
l SF
l SD
l NORMAL
Impact on System
This event prompts users to identify the cause of SNCP switching. If a link fails, you should
repair it promptly and ensure that the working path and protection path of the SNCP are in the
normal state.
Possible Causes
The possible causes of the SNCP switching are as follows:
l Cause 1: This event is automatically triggered.
The cross-connect board triggers SNCP switching when the working path or protection
path detects an alarm associated with SF or SD. Table 13-2 lists the SD/SD alarms that
may trigger SNCP switching.
The service processing board where the higher order monitoring points
operate is offline.
Procedure
l Check the abnormal event on the NMS.
l Cause 1: This event is automatically triggered.
a. Identify the cause of the SNCP switching according to Parameter 4 of this event.
n If the switching request is of the SNCP_SF or SNCP_SD type, go to the next
step.
n If the switching request is of the SNCP_MS type, go to the handling procedure
associated with cause 2.
n If the switching request is of the SNCP_WTR or SNCP_IDLE type, you can
infer that the service is normal in the working path. In this case, you can ignore
this event.
n If the switching request is of the SNCP_LOCKED type, you need to clear the
lockout state. For details, refer to Querying and Clearing the Switching Status
in the Supporting Tasks.
b. Query current alarms on the NMS. For details, refer to Viewing the Current Alarms
in the Supporting Tasks. Then check whether the working path or the protection
path of the SNCP has any of the alarms listed in Table 13-2. If yes, handle the
alarms before you proceed.
c. Check the current state of the SNCP. For details, refer to Querying and Clearing the
Switching Status in the Supporting Tasks. If the working path and protection path of
the current SNCP are in the idle state, you can infer that the fault has been rectified.
l Cause 2: This event is manually triggered.
a. Identify the cause of the SNCP switching according to Parameter 4 of this event.
n If the switching request is of the SNCP_FS or SNCP_MS type, go to the next
step.
n If the switching is automatically triggered, go to the handling procedure
associated with cause 1.
b. Based on the occurrence time of the switching event, query the event logs through
the NMS, and check whether the switching is triggered manually. For details, refer
Related Information
For details about how to handle the problems associated with SNCP switching, see
"Troubleshooting SNCP Switching Faults" in Troubleshooting.
Attribute
Abnormal Event Severity Abnormal Event Type
Parameters
Name Meaning
Name Meaning
Parameter 4 Indicates the current state of the working path in the SNCMP.
l SF
l SD
l NORMAL
Impact on System
This event prompts users to identify the cause of SNCMP switching. If a link fails, you should
repair it promptly and ensure that the working path and protection path of the SNCMP are in
the normal state.
Possible Causes
The possible causes of the SNCMP switching are as follows:
Procedure
l Check the abnormal event on the NMS.
l Cause 1: This event is automatically triggered.
a. Identify the cause of the SNCMP switching according to Parameter 3 of this event.
n If the switching request is of the SNCMP_SF or SNCMP_SD type, go to the
next step.
n If the switching request is of the SNCMP_MS type, go to the handling
procedure associated with cause 2.
n If the switching request is of the SNCMP_WTR or SNCMP_IDLE type, you
can infer that the service is normal in the working path. In this case, you can
ignore this event.
n If the switching request is of the SNCMP_LOCKED type, you need to clear
the lockout state. For details, refer to Querying and Clearing the Switching
Status in the Supporting Tasks.
b. Query current alarms on the NMS. For details, refer to Viewing the Current Alarms
in the Supporting Tasks. Then check whether the working path or the protection
path of the SNCMP has any of the alarms listed in Table 13-2. If yes, handle the
alarms before you proceed.
c. Check the current state of the SNCMP. For details, refer to Querying and Clearing
the Switching Status in the Supporting Tasks. If the working path and protection
path of the current linear MS are in the idle state, you can infer that the fault has
been rectified.
l Cause 2: This event is manually triggered.
a. Identify the cause of the SNCMP switching according to Parameter 3 of this event.
n If the switching request is of the SNCMP_FS or SNCMP_MS type, go to the
next step.
n If the switching is automatically triggered, go to the handling procedure
associated with cause 1.
b. Based on the occurrence time of the switching event, query the event logs through
the NMS, and check whether the switching is triggered manually. For details, refer
to Querying the Operation Log of the NMS in Supporting Tasks. If it is triggered
manually, go to the next step.
c. Click the NE in the NE Explorer, and then choose Configuration > SNCMP
Service Control from the Function Tree.
d. Check the current state of the SNCMP. For details, refer to Querying and Clearing
the Switching Status in the Supporting Tasks.
n If the working path and protection path of the current linear MS are in the
normal state, go to the next step.
n If either the working path or the protection path of the current SNCMP, or both
of them, are not in the normal state, take step 2 of cause 1.
e. Clear the manual switching state. For details, refer to Querying and Clearing the
Switching Status in the Supporting Tasks.
----End
Related Information
None.
Attribute
Abnormal Event Severity Abnormal Event Type
Parameters
Name Meaning
Parameter 3 Indicates the current state of the working path in the SNCTP.
l SF
l SD
l VALID
Parameter 4 Indicates the current state of the protection path in the SNCTP.
l SF
l SD
l VALID
Impact on System
This event prompts users to identify the cause of SNCTP switching. If a link fails, you should
repair it promptly and ensure that the working path and protection path of the SNCTP are in
the valid state.
Possible Causes
The possible causes of the SNCTP switching are as follows:
l Cause 1: This event is automatically triggered.
The cross-connect board triggers SNCTP switching when the working path or protection
path detects an alarm associated with SF or SD. Table 13-3 lists the SD and SF alarms
that may trigger SNCTP switching.
AU_LOP
MS_AIS, AU_AIS
HP_UNEQ
HP_LOM
B3_EXC
SD B3_SD
Procedure
l Check the abnormal event on the NMS.
l Cause 1: This event is automatically triggered.
a. Identify the cause of the SNCTP switching according to Parameter 5 of this event.
n If the switching request is of the SNCTP_SF or SNCTP_SD type, go to the
next step.
n If the switching request is of the SNCTP_MS type, go to the handling
procedure associated with cause 2.
n If the switching request is of the SNCTP_WTR or SNCTP_IDLE type, you
can infer that the service is normal in the working path. In this case, you can
neglect this event.
n If the switching request is of the SNCTP_LOCKED type, you need to clear
the lockout state. For details, refer to Querying and Clearing the Switching
Status in the Supporting Tasks.
b. Query current alarms on the NMS. For details, refer to Viewing the Current Alarms
in the Supporting Tasks. Then check whether the working path or the protection
path of the SNCTP has any of the alarms listed in Table 13-3. If yes, handle the
alarms before you proceed.
c. Check the current state of the SNCTP. For details, refer to Querying and Clearing
the Switching Status in the Supporting Tasks. If the working path and protection
path of the current SNCTP are in the valid state, you can infer that the fault has
been rectified.
l Cause 2: This event is manually triggered.
a. Identify the cause of the SNCTP switching according to Parameter 5 of this event.
n If the switching request is of the SNCTP_FS or SNCTP_MS type, go to the
next step.
n If the switching is automatically triggered, go to the handling procedure
associated with cause 1.
b. Based on the occurrence time of the switching event, query the event logs through
the NMS, and check whether the switching is triggered manually. For details, refer
to Querying the Operation Log of the NMS in Supporting Tasks. If it is triggered
manually, go to the next step.
c. Check the current state of the SNCTP. For details, refer to Querying and Clearing
the Switching Status in the Supporting Tasks.
n If the working path and protection path of the current SNCTP are in the valid
state, go to the next step.
n If either the working path or the protection path of the current SNCTP, or both
of them, are not in the valid state, take step 2 of cause 1.
d. Clear the manual switching state. For details, refer to Querying and Clearing the
Switching Status in the Supporting Tasks.
----End
Related Information
None.
Attribute
Abnormal Event Severity Abnormal Event Type
Parameters
Name Meaning
Impact on System
This event prompts users to identify the cause of TPS switching. If a board is faulty or fails,
you need to repair it promptly and ensure that the working board and protection board work
normally.
Possible Causes
The possible causes of the TPS switching are as follows:
Procedure
l Check the abnormal event on the NMS.
l Cause 1: This event is automatically triggered.
a. Query current alarms on the NMS. For details, refer to Viewing the Current Alarms
in the Supporting Tasks. Then check whether any alarm listed in Table 13-4, Table
13-5, Table 13-6, and Table 13-7 is reported. If yes, handle the alarms before you
proceed.
l Cause 2: This event is manually triggered.
a. Identify the cause of the TPS switching according to Parameter 5 of this event.
Related Information
For details about how to handle the problems associated with TPS switching, see
"Troubleshooting Tributary Protection Switching Faults" in Troubleshooting.
The possible causes of TPS switching are listed in the table below.
Table 13-4 Trigger conditions of TPS switching on the N1PD3 and N1PL3
Trigger Condition Alarm Reporting
The FPGA detects that the 38 MHz active The TR_LOC alarm is reported.
and standby clocks transmitted on the
cross-connect board are lost.
The FPGA detects that the 155 MHz The PLL_FAIL alarm is reported.
phase-locked loop is unlocked.
The FPGA detects that certain clock The TR_LOC alarm is reported.
signals transmitted on the cross-connect
board, such as the 38 MHz active and
standby clocks, are lost.
The FPGA detects that the 155 MHz The PLL_FAIL alarm is reported.
phase-locked loop is unlocked.
Table 13-6 Trigger conditions of TPS switching on the N2PD3, N2PL3, and N2PQ3
Trigger Condition Remarks
The FPGA detects that certain clock The TR_LOC alarm is reported.
signals transmitted on the cross-connect
board, such as the 38 MHz active and
standby clocks, are lost.
l The FPGA detects that the 32 MHz The PLL_FAIL alarm is reported.
phase-locked loop is unlocked.
l The FPGA detects that the 155 MHz
phase-locked loop is unlocked.
The FPGA detects that certain clock The TR_LOC alarm is reported.
signals transmitted on the cross-connect
board, such as the 38 MHz active and
standby clocks, are lost.
Attribute
Abnormal Event Severity Abnormal Event Type
Parameters
Name Meaning
Possible Causes
l An external switching command (for example, forced switching and clear switching) is
run. As a result, an active/standby protection switching is performed from the working
unit to the protection unit or from the protection unit to the working unit.
l The working unit or protection unit of the protection group becomes faulty and then is
automatically switched to the peer unit.
Procedure
Step 1 Query the type of the 1+1 protection switching event on the NMS.
If... Then...
The switching is caused by an external Find the cause of the external switching, and
switching then clear manual switching immediately.
The working unit or protection unit of Replace the board where the faulty unit is
the protection group is faulty located.
----End
Relevant Information
None.
A Glossary
Numerics
1U The standard electronics industries association (EIA) rack unit (44 mm/1.75 in.)
1+1 backup A backup method in which two components mirror each other. If the active
component goes down, the standby component takes over services from the active
component to ensure that the system service is not interrupted.
1+1 hot standby A backup mode in which two systems with the same functions are deployed, one in
the active state and the other in the standby state with power on. The standby system
backs up the data of the active system automatically. Once the active system
encounters a fault, the standby system takes over services from the active system
automatically or by manual intervention.
1000BASE-T An Ethernet specification that uses the twisted pair cable with the transmission speed
as 1000 Mbit/s and the transmission distance as 100 meters.
10BASE-T An Ethernet specification that uses the twisted pair cable with the transmission speed
as 10 Mbit/s and the transmission distance as 100 meters.
2DM two-way delay measurement
3G See 3rd Generation.
3R reshaping, retiming, regenerating
3rd Generation (3G) The third generation of digital wireless technology, as defined by the International
Telecommunications Union (ITU). Third generation technology is expected to deliver
data transmission speeds between 144 kbit/s and 2 Mbit/s, compared to the 9.6 kbit/s
to 19.2 kbit/s offered by second generation technology.
802.1Q in 802.1Q A VLAN feature that allows the equipment to add a VLAN tag to a tagged frame. The
(QinQ) implementation of QinQ is to add a public VLAN tag to a frame with a private VLAN
tag to allow the frame with double VLAN tags to be transmitted over the service
provider's backbone network based on the public VLAN tag. This provides a layer 2
VPN tunnel for customers and enables transparent transmission of packets over
private VLANs.
A
A/D analog/digit
automatic laser A technique (procedure) to automatically shutdown the output power of laser
shutdown (ALS) transmitters and optical amplifiers to avoid exposure to hazardous levels.
automatic teller An automatic teller machine or automated teller machine (ATM) is an electronic
machine (ATM) device which allows a bank's customers to make cash withdrawals and check their
account balances at any time without the need for a human teller. Many ATMs also
allow people to deposit cash or checks, transfer money between their bank accounts or
even buy postage stamps.
automatic transmit A method of adjusting the transmit power based on fading of the transmit signal
power control (ATPC) detected at the receiver
available bit rate A kind of service categories defined by the ATM forum. ABR only provides possible
(ABR) forwarding service and applies to the connections that does not require the real-time
quality. It does not provide any guarantee in terms of cell loss or delay.
avalanche photodiode A semiconductor photodetector with integral detection and amplification stages.
(APD) Electrons generated at a p/n junction are accelerated in a region where they free an
avalanche of other electrons. APDs can detect faint signals but require higher voltages
than other semiconductor electronics.
B
B-ISDN See broadband integrated services digital network.
BA booster amplifier
BA2 2 x booster amplifier
BBE background block error
BC boundary clock
BCD binary coded decimal
BDI See backward defect indication.
BE See best effort.
BEI backward error indication
BER See basic encoding rule.
BFD See Bidirectional Forwarding Detection.
BGP Border Gateway Protocol
BIAE backward incoming alignment error
BIOS See basic input/output system.
BIP See bit interleaved parity.
BIP-8 See bit interleaved parity-8.
BITS See building integrated timing supply.
BMC best master clock
BNC See Bayonet-Neill-Concelman.
BOM bill of materials
BPDU See bridge protocol data unit.
bit interleaved parity A method of error monitoring. With even parity, the transmitting equipment generates
(BIP) an X-bit code over a specified portion of the signal in such a manner that the first bit
of the code provides even parity over the first bit of all X-bit sequences in the covered
portion of the signal, the second bit provides even parity over the second bit of all X-
bit sequences within the specified portion, and so forth. Even parity is generated by
setting the BIP-X bits so that an even number of 1s exist in each monitored partition
of the signal. A monitored partition comprises all bits in the same bit position within
the X-bit sequences in the covered portion of the signal. The covered portion includes
the BIP-X.
bit interleaved parity-8 Consists of a parity byte calculated bit-wise across a large number of bytes in a
(BIP-8) transmission transport frame. Divide a frame is into several blocks with 8 bits (one
byte) in a parity unit and then arrange the blocks in matrix. Compute the number of
"1" or "0" over each column. Then fill a 1 in the corresponding bit for the result if the
number is odd, otherwise fill a 0.
bound path A parallel path with several serial paths bundled together. It improves the data
throughput capacity.
bridge protocol data Data messages exchanged across switches within an extended LAN that uses a
unit (BPDU) spanning tree protocol (STP) topology. BPDU packets contain information on ports,
addresses, priorities, and costs, and they ensure that the data reaches its intended
destination. BPDU messages are exchanged across bridges to detect loops in a
network topology. These loops are then removed by shutting down selected bridge
interfaces and placing redundant switch ports in a backup, or blocked, state.
broadband integrated A standard defined by the ITU-T to handle high-bandwidth applications, such as
services digital voice. It currently uses the ATM technology to transmit data over SONNET-based
network (B-ISDN) circuits at 155 to 622 Mbit/s or higher speed.
broadband remote A new type of access gateway for broadband networks. As a bridge between backbone
access server (BRAS) networks and broadband access networks, BRAS provides methods for fundamental
access and manages the broadband access network. It is deployed at the edge of
network to provide broadband access services, convergence, and forwarding of
multiple services, meeting the demands for transmission capacity and bandwidth
utilization of different users. BRAS is a core device for the broadband users' access to
a broadband network.
broadcast A means of delivering information to all members in a network. The broadcast range
is determined by the broadcast address.
building integrated In the situation of multiple synchronous nodes or communication devices, one can use
timing supply (BITS) a device to set up a clock system on the hinge of telecom network to connect the
synchronous network as a whole, and provide satisfactory synchronous base signals to
the building integrated device. This device is called BITS.
built-in WDM A function which integrates some simple WDM systems into products that belong to
the OSN series. That is, the OSN products can add or drop several wavelengths
directly.
burst A process of forming data into a block of the proper size, uninterruptedly sending the
block in a fast operation, waiting for a long time, and preparing for the next fast
sending.
bus A path or channel for signal transmission. The typical case is that, the bus is an
electrical connection that connects one or more conductors. All devices that are
connected to a bus, can receive all transmission contents simultaneously.
C
CAC See connection admission control.
CAPEX capital expenditure
CAR committed access rate
CAS See channel associated signaling.
CAU See client automatic upgrade.
CBS See committed burst size.
CCI connection control interface
CCITT Consultative Committee of International Telegraph and Telephone
CCM continuity check message
CCS See Common Channel Signaling.
CDMA2000 A 3G technology developed by Qualcomm of the US. Technology competitive with
WCDMA, upgraded from CDMA1, and developed by the GSM community as a
worldwide standard for 3G mobile.
CDVT cell delay variation tolerance
CE See customer edge.
CES See circuit emulation service.
CF compact flash
CFM connectivity fault management
CFR cell fill rate
CGMP Cisco Group Management Protocol
CIR committed information rate
CISPR International Special Committee on Radio Interference
CIST See Common and Internal Spanning Tree.
CLEI common language equipment identification
CLK clock board
CLNP connectionless network protocol
CLP See cell loss priority.
CMEP connection monitoring end point
CMI coded mark inversion
CMR cell misinsertion ratio
CR connection request
CR-LDP Constraint-based Routed Label Distribution Protocol
CRC See cyclic redundancy check.
CRC-4 multiframe A multiframe recommended by ITU-T G.704 and set up based on the first bit of
timeslot 0. The CRC-4 multiframe is different from the CAS multiframe in principle
and implementation. Each CRC-4 multiframe contains 16 PCM frames. Each CRC-4
multiframe consists of two CRC-4 sub-multiframes. Each CRC-4 sub-multiframe is a
CRC-4 check block that contains 2048 (256 x 8) bits. Bits C1 to C4 of a check block
can check the previous check block.
CSA Canadian Standards Association
CSES consecutive severely errored second
CSF Client Signal Fail
CSMA/CD See carrier sense multiple access with collision detection.
CSPF Constrained Shortest Path First
CST See common spanning tree.
CTP connection termination point
CV connectivity verification
CW control word
CWDM See coarse wavelength division multiplexing.
CoS class of service
Common Channel A signaling system used in telephone networks that separates signaling information
Signaling (CCS) from user data. A specified channel is exclusively designated to carry signaling
information for all other channels in the system.
Common and Internal The single spanning tree jointly calculated by STP and RSTP, the logical connectivity
Spanning Tree (CIST) using MST bridges and regions, and MSTP. The CIST ensures that all LANs in the
bridged local area network are simply and fully connected.
called number The number dialed by the subscriber to originate a call.
carrier sense multiple Carrier sense multiple access with collision detection (CSMA/CD) is a computer
access with collision networking access method in which:
detection (CSMA/CD)
l A carrier sensing scheme is used.
l A transmitting data station that detects another signal while transmitting a frame,
stops transmitting that frame, transmits a jam signal, and then waits for a random
time interval before trying to send that frame again.
cell loss priority (CLP) A field in the ATM cell header that determines the probability of a cell being dropped
if the network becomes congested. Cells with CLP = 0 are insured traffic, which is
unlikely to be dropped. Cells with CLP = 1 are best-effort traffic, which might be
dropped.
channel associated A signaling system in which signaling information is transmitted within a dedicated
signaling (CAS) voice channel. China Signaling System No. 1 is a type of CAS signaling.
circuit emulation A function with which the E1/T1 data can be transmitted through ATM networks. At
service (CES) the transmission end, the interface module packs timeslot data into ATM cells. These
ATM cells are sent to the reception end through the ATM network. At the reception
end, the interface module re-assigns the data in these ATM cells to E1/T1 timeslots.
The CES technology guarantees that the data in E1/T1 timeslots can be recovered to
the original sequence at the reception end.
client automatic A function that enables a user to automatically detect the update of the client version
upgrade (CAU) and upgrade the client. This keeps the version of the client is the same as that of the
server.
coarse wavelength A signal transmission technology that multiplexes widely-spaced optical channels into
division multiplexing the same fiber. CWDM spaces wavelengths at a distance of several nm. CWDM does
(CWDM) not support optical amplifiers and is applied in short-distance chain networking.
committed burst size A parameter used to define the capacity of token bucket C, that is, the maximum burst
(CBS) IP packet size when information is transferred at the committed information rate. This
parameter must be greater than 0 but should be not less than the maximum length of
an IP packet to be forwarded.
common spanning tree A single spanning tree that connects all the MST regions in a network. Every MST
(CST) region is considered as a switch; therefore, the CST can be considered as their
spanning tree generated with STP/RSTP.
congestion Extra intra-network or inter-network traffic resulting in decreased network service
efficiency.
connection admission A control process in which the network takes actions in the call set-up phase (or call
control (CAC) re-negotiation phase) to determine which connection request is admitted.
cross-connection The connection of channels between the tributary board and the line board, or between
line boards inside the NE. Network services are realized through the cross-connections
of NEs.
customer edge (CE) A part of the BGP/MPLS IP VPN model that provides interfaces for directly
connecting to the Service Provider (SP) network. A CE can be a router, switch, or
host.
cyclic redundancy A procedure used to check for errors in data transmission. CRC error checking uses a
check (CRC) complex calculation to generate a number based on the data transmitted. The sending
device performs the calculation before performing the transmission and includes the
generated number in the packet it sends to the receiving device. The receiving device
then repeats the same calculation. If both devices obtain the same result, the
transmission is considered to be error free. This procedure is known as a redundancy
check because each transmission includes not only data but extra (redundant) error-
checking values.
D
D/A digital-analog converter
DAPI destination access point identifier
DC direct current
DC-C See DC-return common (with ground).
DC-I See DC-return isolate (with ground).
DC-return common A power system, in which the BGND of the DC return conductor is short-circuited
(with ground) (DC-C) with the PGND on the output side of the power supply cabinet and also on the line
between the output of the power supply cabinet and the electric equipment.
DC-return isolate (with A power system, in which the BGND of the DC return conductor is short-circuited
ground) (DC-I) with the PGND on the output side of the power supply cabinet and is isolated from the
PGND on the line between the output of the power supply cabinet and the electric
equipment.
data circuit- The equipment that provides the signal conversion and coding between the data
terminating equipment terminal equipment (DTE) and the line. A DCE is located at a data station. The DCE
(DCE) may be separate equipment, or an integral part of the DTE or intermediate equipment.
The DCE may perform other functions that are normally performed at the network end
of the line.
data communication A communication network used in a TMN or between TMNs to support the data
network (DCN) communication function.
data terminal A user device composing the UNI. The DTE accesses the data network through the
equipment (DTE) DCE equipment (for example, a modem) and usually uses the clock signals produced
by DCE.
delay measurement The time elapsed since the start of transmission of the first bit of the frame by a source
(DM) node until the reception of the last bit of the loopbacked frame by the same source
node, when the loopback is performed at the frame's destination node.
dense wavelength The technology that utilizes the characteristics of broad bandwidth and low
division multiplexing attenuation of single mode optical fiber, employs multiple wavelengths with specific
(DWDM) frequency spacing as carriers, and allows multiple channels to transmit simultaneously
in the same fiber.
differentiated service An IETF standard that defines a mechanism for controlling and forwarding traffic in a
(DiffServ) differentiated manner based on CoS settings to handle network congestion.
differentiated services According to the QoS classification standard of the Differentiated Service (Diff-Serv),
code point (DSCP) the type of services (ToS) field in the IP header consists of six most significant bits
and two currently unused bits, which are used to form codes for priority marking.
Differentiated services code point (DSCP) is the six most important bits in the ToS. It
is the combination of IP precedence and types of service. The DSCP value is used to
ensure that routers supporting only IP precedence can be used because the DSCP
value is compatible with IP precedence. Each DSCP maps a per-hop behavior (PHB).
Therefore, terminal devices can identify traffic using the DSCP value.
digital data network A data transmission network that is designed to transmit data on digital channels (such
(DDN) as the fiber channel, digital microwave channel, or satellite channel).
digital subscriber line A network device, usually situated in the main office of a telephone company, that
access multiplexer receives signals from multiple customer Digital Subscriber Line (DSL) connections
(DSLAM) and uses multiplexing techniques to put these signals on a high-speed backbone line.
digital video A suite of internationally accepted open standards for digital television. DVB
broadcasting (DVB) standards are maintained by the DVB Project, an international industry consortium
with more than 300 members, and they are published by a Joint Technical Committee
(JTC) of European Telecommunications Standards Institute (ETSI), European
Committee for Electrotechnical Standardization (CENELEC) and European
Broadcasting Union (EBU).
dispersion The maximum error of the local clock compared with the reference clock.
dispersion A type of module that contains dispersion compensation fibers to compensate for the
compensation module dispersion of the transmitting fiber.
(DCM)
distributed link A board-level port protection technology that detects unidirectional fiber cuts and
aggregation group negotiates with the opposite port. In the case of a link down failure on a port or
(DLAG) hardware failure on a board, services are automatically switched to the slave board,
thereby achieving 1+1 protection for the inter-board ports.
downstream In an access network, the direction of transmission toward the subscriber end of the
link.
dual tone multiple Multi-frequency signaling technology for telephone systems. According to this
frequency (DTMF) technology, standard set combinations of two specific voice band frequencies, one
from a group of four low frequencies and the other from a group of four high
frequencies, are used.
E
E-Aggr See Ethernet aggregation.
E-LAN See Ethernet local area network.
E-Line See Ethernet line.
E-Tree See Ethernet-tree.
E2E end to end
EBS See excess burst size.
EDFA See erbium-doped fiber amplifier.
EEC Ethernet Electric Interface PMC Card
EEPROM See electrically erasable programmable read-only memory.
EF See expedited forwarding.
EFCI explicit forward congestion indication
EFM Ethernet in the First Mile
EFM OAM Ethernet in the first mile OAM
EIA See Electronic Industries Alliance.
EIR See excess information rate.
EMC See electromagnetic compatibility.
EPD early packet discard
EPL See Ethernet private line.
EPLAN See Ethernet private LAN service.
EPON See Ethernet passive optical network.
ERPS Ethernet ring protection switching
ESC See electric supervisory channel.
ESCON See enterprise system connection.
ESD electrostatic discharge
ETS European Telecommunication Standards
ETSI See European Telecommunications Standards Institute.
EVPL See Ethernet virtual private line.
EVPLAN See Ethernet virtual private LAN service.
EXP See experimental bits.
Electronic Industries An association based in Washington, D.C., with members from various electronics
Alliance (EIA) manufacturers. It sets standards for electronic components. RS-232-C, for example, is
the EIA standard for connecting serial components.
EoD See Ethernet over dual domains.
Ethernet A LAN technology that uses the carrier sense multiple access with collision detection
(CSMA/CD) media access control method. The Ethernet network is highly reliable
and easy to maintain. The speed of an Ethernet interface can be 10 Mbit/s, 100 Mbit/s,
1000 Mbit/s, or 10,000 Mbit/s.
Ethernet aggregation A type of Ethernet service that is based on a multipoint-to-point EVC (Ethernet virtual
(E-Aggr) connection).
Ethernet line (E-Line) A type of Ethernet service that is based on a point-to-point EVC (Ethernet virtual
connection).
Ethernet local area A type of Ethernet service that is based on a multipoint-to-multipoint EVC (Ethernet
network (E-LAN) virtual connection).
Ethernet over dual A type of boards. EoD boards bridge the PSN and TDM networks, enabling Ethernet
domains (EoD) service transmission across PSN and TDM networks.
Ethernet passive A passive optical network based on Ethernet. It is a new generation broadband access
optical network technology that uses a point-to-multipoint structure and passive fiber transmission. It
(EPON) supports upstream/downstream symmetrical rates of 1.25 Gbit/s and a reach distance
of up to 20 km. In the downstream direction, the bandwidth is shared based on
encrypted broadcast transmission for different users. In the upstream direction, the
bandwidth is shared based on TDM. EPON meets the requirements for high
bandwidth.
Ethernet private LAN A type of Ethernet service provided by SDH, PDH, ATM, or MPLS server layer
service (EPLAN) networks. This service is carried over dedicated bandwidth between multipoint-to-
multipoint connections.
Ethernet private line A type of Ethernet service provided by SDH, PDH, ATM, or MPLS server layer
(EPL) networks. This service is carried over dedicated bandwidth between point-to-point
connections.
Ethernet virtual A type of Ethernet service provided by SDH, PDH, ATM, or MPLS server layer
private LAN service networks. This service is carried over shared bandwidth between multipoint-to-
(EVPLAN) multipoint connections.
Ethernet virtual A type of Ethernet service provided by SDH, PDH, ATM, or MPLS server layer
private line (EVPL) networks. This service is carried over shared bandwidth between point-to-point
connections.
Ethernet-tree (E-Tree) An Ethernet service type that is based on a Point-to-multipoint Ethernet virtual
connection.
European A standards-setting body in Europe. Also the standards body responsible for GSM.
Telecommunications
Standards Institute
(ETSI)
Expires A header field of the SIP message. It specifies the duration after which the message or
message content expires.
eSFP enhanced small form-factor pluggable
egress The egress LER. The group is transferred along the LSP consisting of a series of LSRs
after the group is labeled.
electric supervisory A technology that implements communication among all the nodes and transmission
channel (ESC) of monitoring data in an optical transmission network. The monitoring data of ESC is
introduced into DCC service overhead and is transmitted with service signals.
electrically erasable A type of EPROM that can be erased with an electrical signal. It is useful for stable
programmable read- storage for long periods without electricity while still allowing reprograming.
only memory EEPROMs contain less memory than RAM, take longer to reprogram, and can be
(EEPROM) reprogramed only a limited number of times before wearing out.
electromagnetic A condition which prevails when telecommunications equipment is performing its
compatibility (EMC) individually designed function in a common electromagnetic environment without
causing or suffering unacceptable degradation due to unintentional electromagnetic
interference to or from other equipment in the same environment.
encapsulation A technology for layered protocols, in which a lower-level protocol accepts a message
from a higher-level protocol and places it in the data portion of the lower-level frame.
Protocol A's packets have complete header information, and are carried by protocol B
as data. Packets that encapsulate protocol A have a B header, an A header, followed by
the information that protocol A is carrying. Note that A could equal to B, as in IP
inside IP.
encryption A function used to transform data so as to hide its information content to prevent it's
unauthorized use.
enterprise system A path protocol that connects the host to various control units in a storage system.
connection (ESCON) Enterprise system connection is a serial bit stream transmission protocol that operates
a rate of 200 Mbit/s.
erbium-doped fiber An optical device that amplifies optical signals. This device uses a short optical fiber
amplifier (EDFA) doped with the rare-earth element, Erbium. The signal to be amplified and a pump
laser are multiplexed into the doped fiber, and the signal is amplified by interacting
with doping ions. When the amplifier passes an external light source pump, it
amplifies the optical signals in a specific wavelength range.
excess burst size (EBS) A parameter related to traffic. In the single rate three color marker (srTCM) mode,
traffic control is achieved by token buckets C and E. The excess burst size parameter
defines the capacity of token bucket E, that is, the maximum burst IP packet size when
the information is transferred at the committed information rate. This parameter must
be greater than 0 but should be not less than the maximum length of an IP packet to be
forwarded.
excess information rate The bandwidth for excessive or burst traffic above the CIR; it equals the result of the
(EIR) actual transmission rate without the safety rate.
exercise switching An operation to check whether the protection switching protocol functions properly.
The protection switching is not really performed.
expedited forwarding The highest order QoS in the Diff-Serv network. EF PHB is suitable for services that
(EF) demand low packet loss ratio, short delay, and broad bandwidth. In all the cases, EF
traffic can guarantee a transmission rate equal to or faster than the set rate. The DSCP
value of EF PHB is "101110".
experimental bits A field in the MPLS packet header, three bits long. This field is always used to
(EXP) identify the CoS of the MPLS packet.
F
FAS frame alignment signal
FC See Fibre Channel.
FCC Federal Communications Commission
FCS frame check sequence
FDD See frequency division duplex.
FDDI See fiber distributed data interface.
FDI See forward defect indication.
FDI packet See forward defect indication packet.
FDV See frame delay variation.
FE fast Ethernet
FEC See forward error correction.
FFD fast failure detection
FIB See forwarding information base.
FICON See Fibre Connect.
FIFO See first in first out.
FLR See frame loss ratio.
FPGA See field programmable gate array.
FPS See fast protection switching.
FR See frame relay.
FRR See fast reroute.
FRU See Field replaceable unit.
FTN FEC to NHLFE
Fibre Channel (FC) A high-speed transport technology used to build SANs. FC is primarily used for
transporting SCSI traffic from servers to disk arrays, but it can also be used on
networks carrying ATM and IP traffic. FC supports single-mode and multi-mode fiber
connections, and can run on twisted-pair copper wires and coaxial cables. FC provides
both connection-oriented and connectionless services.
Fibre Connect A new generation connection protocol that connects the host to various control units.
(FICON) It carries a single byte command protocol through the physical path of fibre channel,
and provides a higher transmission rate and better performance than ESCON.
Field replaceable unit "A unit or component of a system that is designed to be replaced in the field, i.e.,
(FRU) without returning the system to a factory or repair depot. Field replaceable units may
either be customer-replaceable or their replacement may require trained service
personnel."
fast protection A type of pseudo wire automatic protection switching (PW APS). When the working
switching (FPS) PW is faulty, the source transmits services to the protection PW and the sink receives
the services from the protection PW. FPS generally works with the interworking
function (IWF) to provide end-to-end protection for services.
fast reroute (FRR) A technology which provides a temporary protection of link availability when part of
a network fails. The protocol enables the creation of a standby route or path for an
active route or path. When the active route is unavailable, the traffic on the active
route can be switched to the standby route. When the active route is recovered, the
traffic can be switched back to the active route. FRR is categorized into IP FRR, VPN
FRR, and TE FRR.
fault alarm A type of alarm caused by hardware and/or software faults, for example, board failure,
or by the exception that occurs in major functions. After handling, a fault alarm can be
cleared, upon which the NE reports a recovery alarm. Fault alarms are of higher
severity than event alarms.
fiber distributed data A standard developed by the American National Standards Institute (ANSI) for high-
interface (FDDI) speed fiber-optic LANs. FDDI provides specifications for transmission rates of 100
megabits per second on token ring networks.
field programmable A semi-customized circuit that is used in the Application Specific Integrated Circuit
gate array (FPGA) (ASIC) field and developed based on programmable components. FPGA remedies
many of the deficiencies of customized circuits, and allows the use of many more gate
arrays.
firewall A combination of a series of components set between different networks or network
security domains. By monitoring, limiting, and changing the data traffic across the
firewall, it masks the interior information, structure and running state of the network
as much as possible to protect the network security.
first in first out (FIFO) A stack management method in which data that is stored first in a queue is also read
and invoked first.
forced switching The action of switching traffic signals between a working channel and protection
channel. The switching occurs even if the channel to which traffic is being switched is
faulty or an equal or higher priority switching command is in effect.
forward defect A packet generated and traced forward to the sink node of the LSP by the node that
indication (FDI) first detects defects. It includes fields to indicate the nature of the defect and its
location. Its primary purpose is to suppress alarms being raised at affected higher level
client LSPs and (in turn) their client layers.
forward defect A packet that responds to the detected failure event. It is used to suppress alarms of
indication packet (FDI the upper layer network where failure has occurred.
packet)
forward error A bit error correction technology that adds correction information to the payload at the
correction (FEC) transmit end. Based on the correction information, the bit errors generated during
transmission can be corrected at the receive end.
forwarding A table that provides information for network hardware (bridges and routers) for them
information base (FIB) to forward data packets to other networks. The information contained in a routing
table differs according to whether it is used by a bridge or a router. A bridge relies on
both the source (originating) and destination addresses to determine where and how to
forward a packet.
frame delay variation A measurement of the variations in the frame delay between a pair of service frames,
(FDV) where the service frames belong to the same CoS instance on a point to point ETH
connection.
frame loss ratio (FLR) A ratio, is expressed as a percentage, of the number of service frames not delivered
divided by the total number of service frames during time interval T, where the
number of service frames not delivered is the difference between the number of
service frames arriving at the ingress ETH flow point and the number of service
frames delivered at the egress ETH flow point in a point-to-point ETH connection.
frame relay (FR) A packet-switching protocol used for WANs. Frame relay transmits variable-length
packets at up to 2 Mbit/s over predetermined, set paths known as PVCs (permanent
virtual circuits). It is a variant of X.25 but sacrifices X.25's error detection for the sake
of speed.
frequency division An application in which channels are divided by frequency. In an FDD system, the
duplex (FDD) uplink and downlink use different frequencies. Downlink data is sent through bursts.
Both uplink and downlink transmission use frames with fixed time length.
fuse A safety device that protects an electric circuit from excessive current, consisting of or
containing a metal element that melts when current exceeds a specific amperage,
thereby opening the circuit.
G
G-ACH generic associated channel header
G.711 Audio codec standard (A-law or U-law) that uses pulse code modulation (PCM). Its
data rate is 64 kbit/s.
GAL generic associated channel header label
GCC general communication channel
GCP GMPLS control plan
GCRA generic cell rate algorithm
GE Gigabit Ethernet
GFC generic flow control
GFP See Generic Framing Procedure.
GMPLS generalized multiprotocol label switching
GNE See gateway network element.
GPON gigabit-capable passive optical network
GPS See Global Positioning System.
GR See graceful restart.
GRE See Generic Routing Encapsulation.
GSM See Global system for mobile communications.
GUI graphical user interface
Generic Framing A framing and encapsulated method that can be applied to any data type. GFP is
Procedure (GFP) defined by ITU-T G.7041.
Generic Routing A mechanism for encapsulating any network layer protocol over any other network.
Encapsulation (GRE) GRE is used for encapsulating IP datagrams tunneled through the Internet. GRE
serves as a Layer 3 tunneling protocol and provides a tunnel for transparently
transmitting data packets.
Global Positioning A global navigation satellite system that provides reliable positioning, navigation, and
System (GPS) timing services to users worldwide.
Global system for The second-generation mobile networking standard defined by the European
mobile Telecommunications Standards Institute (ETSI). It is aimed at designing a standard for
communications global mobile phone networks. GSM consists of three main parts: mobile switching
(GSM) subsystem (MSS), base station subsystem (BSS), and mobile station (MS).
gain The difference between the optical power from the input optical interface of the
optical amplifier and the optical power from the output optical interface of the jumper
fiber, which expressed in dB.
gateway network An NE that serves as a gateway for other NEs to communicate with a network
element (GNE) management system.
graceful restart (GR) In IETF, protocols related to Internet Protocol/Multiprotocol Label Switching (IP/
MPLS) such as Open Shortest Path First (OSPF), Intermediate System-Intermediate
System (IS-IS), Border Gateway Protocol (BGP), Label Distribution Protocol (LDP),
and Resource Reservation Protocol (RSVP) are extended to ensure that the forwarding
is not interrupted when the system is restarted. This reduces the flapping of the
protocols at the control plane when the system performs an active/standby switchover.
This series of standards is called graceful restart.
H
HCS higher order connection supervision
HD-SDI high definition serial digital interface
HDB3 See high density bipolar of order 3 code.
HDTV See high definition television.
HEC See header error control.
HPA higher order path adaptation
HPT higher order path termination
HQoS See hierarchical quality of service.
HSDPA See High Speed Downlink Packet Access.
HSI high-speed Internet
HUAWEI Electronic The software used to view, search for, and upgrade electronic documentation of
Document Explorer Huawei products. HedEx, pronounced as [hediks], has two editions, HedEx Lite and
(HedEx) HedEx Server.
HedEx See HUAWEI Electronic Document Explorer.
High Speed Downlink A modulating-demodulating algorithm put forward in 3GPP R5 to meet the
Packet Access requirement for asymmetric uplink and downlink transmission of data services. It
(HSDPA) enables the maximum downlink data service rate to reach 14.4 Mbit/s without
changing the WCDMA network topology.
header error control A field within the ATM frame whose purpose is to correct any single bit error in the
(HEC) cell Header and also to detect any multi-bit errors. It actually performs a CRC check in
the first four header bits and also at the receiving end.
hierarchical quality of A type of QoS that controls the traffic of users and performs the scheduling according
service (HQoS) to the priority of user services. HQoS has an advanced traffic statistics function, and
the administrator can monitor the usage of bandwidth of each service. Hence, the
bandwidth can be allocated reasonably through traffic analysis.
high definition A type of TV that is capable of displaying at least 720 progressive or 1080 interlaced
television (HDTV) active scan lines. It must be capable of displaying a 16:9 image using at least 540
progressive or 810 interlaced active scan lines.
high density bipolar of A code used for baseband transmissions between telecommunications devices. The
order 3 code (HDB3) HDB3 code has the following feature: high capability of clock extraction, no direct
current component, error-checking capability, and a maximum of three consecutive
zeros.
I
IAE incoming alignment error
IANA See Internet Assigned Numbers Authority.
IC See integrated circuit.
ICC See ITU carrier code.
ICMP See Internet Control Message Protocol.
ICP IMA Control Protocol
IDU See indoor unit.
IEC International Electrotechnical Commission
IEEE See Institute of Electrical and Electronics Engineers.
IETF Internet Engineering Task Force
IF See intermediate frequency.
IGMP See Internet Group Management Protocol.
IGP See Interior Gateway Protocol.
ILM incoming label map
IMA frame A control unit in the IMA protocol. It is a logical frame defined as M consecutive
cells, numbered 0 to M-l, transmitted on each of the N links in an IMA group.
IPA See intelligent power adjustment.
IPTV See Internet Protocol television.
IPv4 See Internet Protocol version 4.
IPv6 See Internet Protocol version 6.
ISDN integrated services digital network
ISO International Organization for Standardization
ISP See Internet service provider.
IST internal spanning tree
ITC independent transmit clock
ITU See International Telecommunication Union.
ITU carrier code (ICC) A code assigned to a network operator/service provider, maintained by the ITU-T
Telecommunication Standardization Bureau (TSB).
ITU-T International Telecommunication Union-Telecommunication Standardization Sector
Institute of Electrical A professional association of electrical and electronics engineers based in the United
and Electronics States, but with membership from numerous other countries. The IEEE focuses on
Engineers (IEEE) electrical, electronics, and computer engineering, and produces many important
technology standards.
Interior Gateway A routing protocol that is used within an autonomous system. The IGP runs in small-
Protocol (IGP) sized and medium-sized networks. The commonly used IGPs are the routing
information protocol (RIP), the interior gateway routing protocol (IGRP), the
enhanced IGRP (EIGRP), and the open shortest path first (OSPF).
International A United Nations agency, one of the most important and influential recommendation
Telecommunication bodies, responsible for recommending standards for telecommunication (ITU-T) and
Union (ITU) radio networks (ITU-R).
Internet Assigned A department operated by the IAB. IANA delegates authority for IP address-space
Numbers Authority allocation and domain-name assignment to the NIC and other organizations. IANA
(IANA) also maintains a database of assigned protocol identifiers used in the TCP/IP suite,
including autonomous system numbers.
Internet Control A network layer protocol that provides message control and error reporting between a
Message Protocol host server and an Internet gateway.
(ICMP)
Internet Group One of the TCP/IP protocols for managing the membership of Internet Protocol
Management Protocol multicast groups. It is used by IP hosts and adjacent multicast routers to establish and
(IGMP) maintain multicast group memberships.
Internet Protocol A system that provides TV services over the IP network. In the IPTV system, media
television (IPTV) streams from satellites, terrestrial, and studios are converted by the encoder to the
media streams applicable to the IP network. Then the media streams are transmitted to
the terminal layer on the IP network. Media content is displayed on a TV set after
media streams are processed by specified receiving devices (for example, an STB).
Internet Protocol The current version of the Internet Protocol (IP). IPv4 utilizes a 32bit address which is
version 4 (IPv4) assigned to hosts. An address belongs to one of five classes (A, B, C, D, or E) and is
written as 4 octets separated by periods and may range from 0.0.0.0 through to
255.255.255.255. Each IPv4 address consists of a network number, an optional
subnetwork number, and a host number. The network and subnetwork numbers
together are used for routing, and the host number is used to address an individual host
within the network or subnetwork.
Internet Protocol An update version of IPv4, which is designed by the Internet Engineering Task Force
version 6 (IPv6) (IETF) and is also called IP Next Generation (IPng). It is a new version of the Internet
Protocol. The difference between IPv6 and IPv4 is that an IPv4 address has 32 bits
while an IPv6 address has 128 bits.
Internet service An organization that offers users access to the Internet and related services.
provider (ISP)
indoor unit (IDU) The indoor unit of the split-structured radio equipment. It implements accessing,
multiplexing/demultiplexing, and intermediate frequency (IF) processing for services.
integrated circuit (IC) A combination of inseparable associated circuit elements that are formed in place and
interconnected on or within a single base material to perform a microcircuit function.
intelligent power A technology that reduces the optical power of all the amplifiers in an adjacent
adjustment (IPA) regeneration section in the upstream to a safe level if the system detects the loss of
optical signals on the link. IPA helps ensure that maintenance engineers are not injured
by the laser escaping from a broken fiber or a connector that is not plugged in
properly.
intermediate frequency The transitional frequency between the frequencies of a modulated signal and an RF
(IF) signal.
J
jitter The measure of short waveform variations caused by vibration, voltage fluctuations,
and control system instability.
jumper A connection wire for connecting two pins.
L
L2VPN Layer 2 virtual private network
L3VPN Layer 3 virtual private network
LACP See Link Aggregation Control Protocol.
LACPDU Link Aggregation Control Protocol data unit
LAG See link aggregation group.
LAN See local area network.
LAPD link access procedure on the D channel
LAPS Link Access Protocol-SDH
LB See loopback.
LBM See loopback message.
LBR See loopback reply.
LC Lucent connector
LCAS See link capacity adjustment scheme.
LCD liquid crystal display
LCK See Locked signal function.
LCN local communications network
LCT local craft terminal
LER See label edge router.
LIFO See last in first out.
LIU logical interface unit
LLC See logical link control.
LLID local loopback ID
LM See loss measurement.
LMP link management protocol
link capacity LCAS in the virtual concatenation source and sink adaptation functions provides a
adjustment scheme control mechanism to hitless increase or decrease the capacity of a link to meet the
(LCAS) bandwidth needs of the application. It also provides a means of removing member
links that have experienced failure. The LCAS assumes that in cases of capacity
initiation, increases or decreases, the construction or destruction of the end-to-end path
is the responsibility of the network and element management systems.
linktrace message The message sent by the initiator MEP of 802.1ag MAC Trace to the destination MEP.
(LTM) LTM includes the Time to Live (TTL) and the MAC address of the destination MEP2.
linktrace reply (LTR) For 802.1ag MAC Trace, the destination MEP replies with a response message to the
source MEP after the destination MEP receives the LTM, and the response message is
called LTR. LTR also includes the TTL that equals the result of the TTL of LTM
minus 1.
local area network A network formed by the computers and workstations within the coverage of a few
(LAN) square kilometers or within a single building, featuring high speed and low error rate.
Current LANs are generally based on switched Ethernet or Wi-Fi technology and run
at 1,000 Mbit/s (that is, 1 Gbit/s).
logical link control According to the IEEE 802 family of standards, Logical Link Control (LLC) is the
(LLC) upper sublayer of the OSI data link layer. The LLC is the same for the various
physical media (such as Ethernet, token ring, WLAN).
loopback (LB) A troubleshooting technique that returns a transmitted signal to its source so that the
signal or message can be analyzed for errors. The loopback can be a inloop or outloop.
loopback message The loopback packet sent by the node that supports 802.2ag MAC Ping to the
(LBM) destination node. LBM message carries its own sending time.
loopback reply (LBR) A response message involved in the 802.2ag MAC Ping function, with which the
destination MEP replies to the source MEP after the destination MEP receives the
LBM. The LBR carries the sending time of LBM, the receiving time of LBM and the
sending time of LBR.
loopback test Self-test of chips, including internal and external loopback. Loopback test is used to
test whether interfaces work normally.
loss measurement A method used to collect counter values applicable for ingress and egress service
(LM) frames where the counters maintain a count of transmitted and received data frames
between a pair of MEPs.
loss of signal (LOS) No transitions occurring in the received signal.
low voltage differential A low noise, low power, low amplitude method for high-speed (gigabits per second)
signal (LVDS) data transmission over copper wire.
M
MA maintenance association
MAC See Media Access Control.
MADM multiple add/drop multiplexer
MBB mobile broadband
MCF message communication function
MCR minimum cell rate
manual switching The action of manually switching traffic signals between a working channel and a
protection channel. Manual switching fails if the channel to which traffic is being
switched is faulty or an equal or higher priority switching command is in effect.
mean time between The average time between consecutive failures of a piece of equipment. It is a measure
failures (MTBF) of the reliability of the system.
mean time to repair The average time that a device will take to recover from a failure.
(MTTR)
message digest A hash function that is used in a variety of security applications to check message
algorithm 5 (MD5) integrity. MD5 processes a variable-length message into a fixed-length output of 128
bits. It breaks up an input message into 512-bit blocks (sixteen 32-bit little-endian
integers). After a series of processing, the output consists of four 32-bit words, which
are then cascaded into a 128-bit hash number.
mirroring The duplication of data for backup or to distribute network traffic among several
computers with identical data.
multi-segment pseudo A collection of multiple adjacent PW segments. Each PW segment is a point-to-point
wire (MS-PW) PW. The use of MS-PWs to bear services saves tunnel resources and can transport
services over different networks.
multicast A process of transmitting data packets from one source to many destinations. The
destination address of the multicast packet uses Class D address, that is, the IP address
ranges from 224.0.0.0 to 239.255.255.255. Each multicast address represents a
multicast group rather than a host.
multicast listener A protocol used by an IPv6 router to discover the multicast listeners on their directly
discovery (MLD) connected network segments, and to set up and maintain member relationships. On
IPv6 networks, after MLD is configured on the receiver hosts and the multicast router
to which the hosts are directly connected, the hosts can dynamically join related
groups and the multicast router can manage members on the local network.
multiframe alignment A distinctive signal inserted into every multiframe or once into every n multiframes,
signal (MFAS) always occupying the same relative position within the multiframe, and used to
establish and maintain multiframe alignment.
multiple spanning tree A type of spanning trees calculated by MSTP within an MST Region, to provide a
instance (MSTI) simply and fully connected active topology for frames classified as belonging to a
VLAN that is mapped to the MSTI by the MST Configuration. A VLAN cannot be
assigned to multiple MSTIs.
multiplex section An all-ONES characteristic or adapted information signal. It's generated to replace the
alarm indication signal normal traffic signal when it signal contains a defect condition in order to prevent
(MS-AIS) consequential downstream failures being declared or alarms being raised. AIS can be
identified as multiplex section alarm indication signal.
multiplex section A function, which is performed to provide capability for switching a signal between
protection (MSP) and including two multiplex section termination (MST) functions, from a "working" to
a "protection" channel.
multiplex section A function that generates the multiplex section overhead (MSOH) during the
termination (MST) formation of an SDH frame signal and that terminates the MSOH in the reverse
direction.
multiplexer (MUX) Equipment that combines a number of tributary channels onto a fewer number of
aggregate bearer channels, the relationship between the tributary and aggregate
channels being fixed.
multiplexing A procedure by which multiple lower order path layer signals are adapted into a higher
order path or the multiple higher order path layer signals are adapted into a multiplex
section.
multiprotocol label An Internet Protocol (IP) virtual private network (VPN) based on the multiprotocol
switching virtual label switching (MPLS) technology. It applies the MPLS technology for network
private network routers and switches, simplifies the routing mode of core routers, and combines
(MPLS VPN) traditional routing technology and label switching technology. It can be used to
construct the broadband Intranet and Extranet to meet various service requirements.
N
NAS network access server
NDF new data flag
NE network element
NEBS Network Equipment Building System
NHLFE next hop label forwarding entry
NLP normal link pulse
NM network management
NMI network maintenance interface
NNI network-to-network interface
NPC See network parameter control.
NPE network provider edge
NRT-VBR non-real-time variable bit rate
NRZ non-return to zero
NRZ code non-return-to-zero code
NRZI non-return to zero inverted
NSAP See network service access point.
NSF non-stop forwarding
NVRAM nonvolatile random access memory
network parameter During communications, UPC is implemented to monitor the actual traffic on each
control (NPC) virtual circuit that is input to the network. Once the specified parameter is exceeded,
measures will be taken to control. NPC is similar to UPC in function. The difference is
that the incoming traffic monitoring function is divided into UPC and NPC according
to their positions. UPC locates at the user/network interface, while NPC at the network
interface.
network segment Part of a network on which all message traffic is common to all nodes; that is, a
message broadcast from one node on the segment is received by all other nodes on the
segment.
network service access A network address defined by ISO, at which the OSI Network Service is made
point (NSAP) available to a Network service user by the Network service provider.
noise figure A measure of degradation of the signal-to-noise ratio (SNR), caused by components in
a radio frequency (RF) signal chain. The noise figure is defined as the ratio of the
output noise power of a device to the portion thereof attributable to thermal noise in
the input termination at standard noise temperature T0 (usually 290 K). The noise
figure is thus the ratio of actual output noise to that which would remain if the device
itself did not introduce noise. It is a number by which the performance of a radio
receiver can be specified.
non-GNE See non-gateway network element.
non-gateway network A network element that communicates with the NM application layer through the
element (non-GNE) gateway NE application layer.
O
O&M operation and maintenance
OADM See optical add/drop multiplexer.
OAM See operation, administration and maintenance.
OAM&P operation, administration, maintenance and provision
OAMPDU operation, administration and maintenance protocol data unit
OAMS Optical fiber line Automatic Monitoring System
OAU See optical amplifier unit.
OC ordinary clock
OCS optical core switching
OCh optical channel with full functionality
ODF optical distribution frame
ODU See outdoor unit.
ODUk optical channel data unit - k
OHP overhead processing
ONT See optical network terminal.
ONU See optical network unit.
OOF out of frame
OOS out of service
OPEX operating expense
OPS optical physical section
OPU See optical channel payload unit.
OPUk optical channel payload unit - k
OSC See optical supervisory channel.
OSI open systems interconnection
OSN optical switch node
OSNR See optical signal-to-noise ratio.
optical transponder A device or subsystem that converts accessed client signals into a G.694.1/G.694.2-
unit (OTU) compliant WDM wavelength.
orderwire A channel that provides voice communication between operation engineers or
maintenance engineers of different stations.
outdoor unit (ODU) The outdoor unit of the split-structured radio equipment. It implements frequency
conversion and amplification for radio frequency (RF) signals.
P
P2MP point-to-multipoint
P2P See point-to-point service.
PA power amplifier
PADR PPPoE active discovery request
PBX private branch exchange
PC personal computer
PCB See printed circuit board.
PCI See peripheral component interconnect.
PCM See pulse code modulation.
PCN product change notice
PCR See peak cell rate.
PDH See plesiochronous digital hierarchy.
PDU See power distribution unit.
PE See provider edge.
PET polyester
PGND cable A cable which connects the equipment and the protection grounding bar. Usually, one
half of the cable is yellow, whereas the other half is green.
PHB See per-hop behavior.
PHP penultimate hop popping
PIM-DM Protocol Independent Multicast - Dense Mode
PIM-SM Protocol Independent Multicast - Sparse Mode
PLL See phase-locked loop.
PM performance monitoring
PMD polarization mode dispersion
PMU power monitoring unit
PNNI private network-node interface
POH path overhead
PON passive optical network
POTS See plain old telephone service.
per-hop behavior IETF Diff-Serv workgroup defines forwarding behaviors of network nodes as per-hop
(PHB) behaviors (PHB), such as, traffic scheduling and policing. A device in the network
should select the proper PHB behaviors, based on the value of DSCP. At present, the
IETF defines four types of PHB. They are class selector (CS), expedited forwarding
(EF), assured forwarding (AF), and best-effort (BE).
performance threshold A limit for generating an alarm for a selected entity. When the measurement result
reaches or exceeds the preset alarm threshold, the performance management system
generates a performance alarm.
peripheral component A standard designed for the bus connecting the computer main board to peripheral
interconnect (PCI) devices. The PCI1.0 standard was released by Intel in 1992 and related standards have
been released by PCI-SIG since 1993. Peripheral component interconnect (PCI)
delivers I/O functionality for computers ranging from servers to workstations, PCs,
laptop PCs and mobile devices.
permanent virtual A circuit that can be established as an option to provide a dedicated circuit link
circuit (PVC) between two facilities. PVC configuration is usually preconfigured by the service
provider. Unlike SVCs, PVCs are usually very seldom broken/disconnected. A
permanent virtual circuit (PVC) is a virtual circuit established for repeated/continuous
use between the same DTE. In a PVC, the long-term association is identical to the data
transfer phase of a virtual call. Permanent virtual circuits eliminate the need for
repeated call set-up and clearing.
permanent virtual Virtual path that consists of PVCs.
path (PVP)
phase-locked loop A circuit that consists essentially of a phase detector that compares the frequency of a
(PLL) voltage-controlled oscillator with that of an incoming carrier signal or reference-
frequency generator. The output of the phase detector, after passing through a loop
filter, is fed back to the voltage-controlled oscillator to keep it exactly in phase with
the incoming or reference frequency.
ping test A test that is performed to send a data packet to the target IP address (a unique IP
address on the device on the network) to check whether the target host exists
according to the data packet of the same size returned from the target host.
plain old telephone The basic telephone service provided through the traditional cabling such as twisted
service (POTS) pair cables.
plesiochronous digital A multiplexing scheme of bit stuffing and byte interleaving. It multiplexes the
hierarchy (PDH) minimum rate 64 kit/s into rates of 2 Mbit/s, 34 Mbit/s, 140 Mbit/s, and 565 Mbit/s.
point-to-point service A service between two terminal users. In P2P services, senders and recipients are
(P2P) terminal users.
port VLAN ID (PVID) A default VLAN ID of a port. It is allocated to a data frame if the data frame carries
no VLAN tag when reaching the port.
power distribution unit A unit that performs AC or DC power distribution.
(PDU)
power supply unit A unit that converts the external power input into the power supply for internal use.
(PSU) Power supply units are classified into AC power units and DC power units.
pps See packet per second.
printed circuit board A board used to mechanically support and electrically connect electronic components
(PCB) using conductive pathways, tracks, or traces, etched from copper sheets laminated
onto a non-conductive substrate.
priority queuing (PQ) A queue scheduling algorithm based on the absolute priority. According to the PQ
algorithm, services of higher priorities are ensured with greater bandwidth, lower
latency, and less jitter. Packets of lower priorities must wait to be sent till all packets
of higher priorities are sent. In this manner, services of higher priorities are processed
earlier than others.
provider edge (PE) A device that is located in the backbone network of the MPLS VPN structure. A PE is
responsible for managing VPN users, establishing LSPs between PEs, and exchanging
routing information between sites of the same VPN. A PE performs the mapping and
forwarding of packets between the private network and the public channel. A PE can
be a UPE, an SPE, or an NPE.
pseudo random binary A sequence that is random in the sense that the value of each element is independent
sequence (PRBS) of the values of any of the other elements, similar to a real random sequence.
pseudo wire (PW) An emulated connection between two PEs for transmitting frames. The PW is
established and maintained by PEs through signaling protocols. The status information
of a PW is maintained by the two end PEs of a PW.
pseudo wire emulation An end-to-end Layer 2 transmission technology. It emulates the essential attributes of
edge-to-edge (PWE3) a telecommunication service such as ATM, FR or Ethernet in a packet switched
network (PSN). PWE3 also emulates the essential attributes of low speed time
division multiplexing (TDM) circuit and SONET/SDH. The simulation approximates
to the real situation.
pulse code modulation A method of encoding information in a signal by changing the amplitude of pulses.
(PCM) Unlike pulse amplitude modulation (PAM), in which pulse amplitude can change
continuously, pulse code modulation limits pulse amplitudes to several predefined
values. Because the signal is discrete, or digital, rather than analog, pulse code
modulation is more immune to noise than PAM.
Q
QPSK See quadrature phase shift keying.
QinQ See 802.1Q in 802.1Q.
quadrature phase shift A modulation method of data transmission through the conversion or modulation and
keying (QPSK) the phase determination of the reference signals (carrier). It is also called the fourth
period or 4-phase PSK or 4-PSK. QPSK uses four dots in the star diagram. The four
dots are evenly distributed on a circle. On these phases, each QPSK character can
perform two-bit coding and display the codes in Gray code on graph with the
minimum BER.
R
RADIUS See Remote Authentication Dial In User Service.
RAI remote alarm indication
RAN See radio access network.
RDI remote defect indication
RED See random early detection.
REG See regenerator.
REI remote error indication
Resource Reservation An extension to the RSVP protocol for setting up label switched paths (LSPs) in
Protocol-Traffic MPLS networks. The RSVP-TE protocol is used to establish and maintain the LSPs
Engineering (RSVP- by initiating label requests and allocating label binding messages. It also supports LSP
TE) rerouting and LSP bandwidth increasing.
RoHS restriction of the use of certain hazardous substances
Routing Information A simple routing protocol that is part of the TCP/IP protocol suite. It determines a
Protocol (RIP) route based on the smallest hop count between the source and destination. RIP is a
distance vector protocol that routinely broadcasts routing information to its
neighboring routers and is known to waste bandwidth.
radio access network The network that provides the connection between CPEs and the CN. It isolates the
(RAN) CN from wireless network.
radio network A device in a radio network subsystem that is in charge of controlling the usage and
controller (RNC) integrity of radio resources.
random early detection A packet loss algorithm used in congestion avoidance. It discards the packet according
(RED) to the specified higher limit and lower limit of a queue so that global TCP
synchronization resulting from traditional tail drop can be prevented.
real-time variable bit A parameter intended for real-time applications, such as compressed voice over IP
rate (rt-VBR) (VoIP) and video conferencing. The rt-VBR is characterized by a peak cell rate (PCR),
sustained cell rate (SCR), and maximum burst size (MBS). You can expect the source
device to transmit in bursts and at a rate that varies with time.
received signal level The signal level at a receiver input terminal.
(RSL)
received signal The received wide band power, including thermal noise and noise generated in the
strength indicator receiver, within the bandwidth defined by the receiver pulse shaping filter, for TDD
(RSSI) within a specified timeslot. The reference point for the measurement shall be the
antenna
reference clock A stable and high-precision autonomous clock that provides frequencies as a reference
for other clocks.
regenerator (REG) A piece of equipment or device that regenerates electrical signals.
remote optical A remote optical amplifier subsystem designed for applications where power supply
pumping amplifier and monitoring systems are unavailable. The ROPA subsystem is a power
(ROPA) compensation solution to the ultra-long distance long hop (LHP) transmission.
remote test unit (RTU) A subsystem capable of collecting, pre-processing, and sending data coming from the
field sensors to the SCU.
rt-VBR See real-time variable bit rate.
S
S-VLAN service virtual local area network
SAI service area identifier
SAPI source access point identifier
SAToP Structure-Agnostic Time Division Multiplexing over Packet
SC square connector
SCR sustainable cell rate
single-pair high-speed A symmetric digital subscriber line technology developed from HDSL, SDSL, and
digital subscriber line HDSL2, which is defined in ITU-T G.991.2. The SHDSL port is connected to the user
(SHDSL) terminal through the plain telephone subscriber line and uses trellis coded pulse
amplitude modulation (TC-PAM) technology to transmit high-speed data and provide
the broadband access service.
span The physical reach between two pieces of WDM equipment.
standard definition- Standard definition video signal transported by serial digital interface.
serial digital interface
signal (SD-SDI)
steering A protection switching mode defined in ITU-T G.8132, which is applicable to packet-
based T-MPLS ring networks and similar to SDH transoceanic multiplex section
protection (MSP). In this mode, the switching is triggered by the source and sink
nodes of a service.
synchronous digital A transmission scheme that follows ITU-T G.707, G.708, and G.709. SDH defines the
hierarchy (SDH) transmission features of digital signals, such as frame structure, multiplexing mode,
transmission rate level, and interface code. SDH is an important part of ISDN and B-
ISDN.
synchronous optical A high-speed network that provides a standard interface for communications carriers
network (SONET) to connect networks based on fiber optical cable. SONET is designed to handle
multiple data types (voice, video, and so on). It transmits at a base rate of 51.84
Mbit/s, but multiples of this base rate go as high as 2.488 Gbit/s.
synchronous transport An information structure used to support section layer connections in the SDH. It
module (STM) consists of information payload and Section Overhead (SOH) information fields
organized in a block frame structure which repeats every 125. The information is
suitably conditioned for serial transmission on the selected media at a rate which is
synchronized to the network. A basic STM is defined at 155 520 kbit/s. This is termed
STM-1. Higher capacity STMs are formed at rates equivalent to N times this basic
rate. STM capacities for N = 4, N = 16 and N = 64 are defined; higher values are
under consideration.
T
TAI tracking area identity
TC transmission convergence
TCI tag control information
TCM tandem connection monitor
TCN telecommunication network
TCP/IP Transmission Control Protocol/Internet Protocol
TD transmit degrade
TD-SCDMA See Time Division-Synchronous Code Division Multiple Access.
TDC tunable dispersion compensator
TDM See time division multiplexing.
TIM trail trace identifier mismatch
TL1 Transaction Language 1
time to live (TTL) A specified period of time for best-effort delivery systems to prevent packets from
looping endlessly.
tolerance Permissible degree of variation from a pre-set standard.
trTCM See two rate three color marker.
traceroute A program that prints the path to a destination. Traceroute sends a sequence of
datagrams with the time-to-live (TTL) set to 1,2, and so on, and uses ICMP time
exceeded messages that return to determine routers along the path.
traffic classification A function that enables you to classify traffic into different classes with different
priorities according to some criteria. Each class of traffic has a specified QoS in the
entire network. In this way, different traffic packets can be treated differently.
trail termination A TTSI uniquely identifies an LSP in the network. A TTSI is carried in the
source identifier connectivity verification (CV) packet for checking the connectivity of a trail. If it
(TTSI) matches the TTSI received by the sink point, the trail has no connectivity defect.
transmission delay The period from the time when a site starts to transmit a data frame to the time when
the site finishes the data frame transmission. It consists of the transmission latency and
the equipment forwarding latency.
tributary protection A function that uses a standby tributary processing board to protect N tributary
switching (TPS) processing boards.
two rate three color An algorithm that meters an IP packet stream and marks its packets based on two
marker (trTCM) rates, Peak Information Rate (PIR) and Committed Information Rate (CIR), and their
associated burst sizes to be either green, yellow, or red. A packet is marked red if it
exceeds the PIR. Otherwise it is marked either yellow or green depending on whether
it exceeds or does not exceed the CIR.
type-length-value An encoding type that features high efficiency and expansibility. It is also called
(TLV) Code-Length-Value (CLV). T indicates that different types can be defined through
different values. L indicates the total length of the value field. V indicates the actual
data of the TLV and is most important. TLV encoding features high expansibility. New
TLVs can be added to support new features, which is flexible in describing
information loaded in packets.
U
UART universal asynchronous receiver/transmitter
UAS unavailable second
UAT See unavailable time event.
UBR+ Unspecified Bit Rate Plus
UMC See Unified Menu Center.
UMTS See Universal Mobile Telecommunications System.
UNI See user-to-network interface.
UPC See usage parameter control.
UPE user-end provider edge
UPI user payload identifier
UPM uninterruptible power module
V
V-NNI virtual network-network interface
V-UNI See virtual user-network interface.
V.24 The physical layer interface specification between DTE and DCE defined by the ITU-
T. It complies with EIA/TIA-232.
V.35 The synchronous physical layer protocol defined by the ITU-T. It is used for
communication between network access devices and the packet-based network. V.35
is mainly used in America and Europe.
VB virtual bridge
VBR See variable bit rate.
VC trunk See virtual container trunk.
VCC See virtual channel connection.
VCCV virtual circuit connectivity verification
VCG See virtual concatenation group.
VCI virtual channel identifier
VCTRUNK A virtual concatenation group applied in data service mapping, also called the internal
port of a data service processing board.
VDSL very-high-data-rate digital subscriber line
VDSL2 See very-high-speed digital subscriber line 2.
VIP very important person
W
WAN wide area network
WCDMA See Wideband Code Division Multiple Access.
X
X.21 ITU-T standard for serial communications over synchronous digital lines. It is mainly
used in Europe and Japan.
X.25 A data link layer protocol. It defines the communication in the Public Data Network
(PDN) between a host and a remote terminal.
XCS cross-connect and synchronous timing board
Y
Y.1731 The OAM protocol introduced by the ITU-T. Besides the contents defined by
IEEE802.1ag, ITU-T Recommendation Y.173 also defines the following combined
OAM messages: Alarm Indication Signal (AIS), Remote Defect Indication (RDI),
Locked Signal (LCK), Test Signal, Automatic Protection Switching (APS),
Maintenance Communication Channel (MCC), Experimental (EXP), and Vendor
Specific (VSP) for fault management and performance monitoring, such as frame loss
measurement (LM), and delay measurement (DM).
Z
Z interface extension Extending the analogue subscriber to another place by extending the Z interface.