TN Alarm Description
Short Description
transmission...
Description
14/08/2015
Alarm Descriptions
OPERATING INSTRUCTIONS 5/1543HRA 901 20V13 Uen J
Alarm Descriptions MINILINK TN ETSI
Contents 1
Introduction
2
Safety Information
3
Preparations
3.1
Additional Preparations
4
Overview
4.1
Consequences
4.2
Alarm Analysis
4.3
Corrective Actions
4.4
Alarm Clearance
5
Alarms
5.1
AIS (Minor)
5.2
AIS (Critical)
5.3
AIS on Protection Line
5.4
AMS 15 Min Threshold Crossing
5.5
AMS 24 h Threshold Crossing
5.6
ATPC Capability
5.7
ATPC Capability (Far End)
5.8
Audit log FTP Transfer Failed
5.9
B1 BBE 15 Min Threshold Crossing
5.10
B1 BBE 24 h Threshold Crossing
5.11
B1 ES 15 Min Threshold Crossing
5.12
B1 ES 24 h Threshold Crossing
5.13
B1 SES 15 Min Threshold Crossing
5.14
B1 SES 24 h Threshold Crossing
5.15
B1 Unavailable Period
5.16
BBE 15 Min Threshold Crossing
5.17
BBE 24 h Threshold Crossing
5.18
BER (Major)
5.19
BER (Critical)
5.20
BID Missing
5.21
Blocked (Far End)
5.22
BR Pressed
5.23
Carrier Recovery Loss (Major)
5.24
Carrier Recovery Loss (Critical)
5.25
Clock Loss Of Reference
5.26
CLOS
5.27
Configuration Aborted
5.28
Configuration Failure (FarEnd)
http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
1/219
14/08/2015
Alarm Descriptions
5.29
Control System Failure (Minor)
5.30
Control System Failure (Major)
5.31
CTRLOR
5.32
Default Configuration Not Accepted
5.33
Def Xcon CCM
5.34
DEG (Minor)
5.35
DEG (Major)
5.36
DEGFCS
5.37
Degraded Service: HDLC or IM Group
5.38
Degraded Service: IM Group
5.39
Degraded Service: LAG
5.40
DEGTHEC
5.41
Dmod Clock (Major)
5.42
Dmod Clock (Critical)
5.43
Early Warning
5.44
Emergency Unlock Reset Key Required (Warning)
5.45
Emergency Unlock Reset Key Required (Major)
5.46
EOSMISSING
5.47
EOSMULTIPLE
5.48
Equipment Error or No Holdover Capable Board Provider
5.49
ES 15 Min Threshold Crossing
5.50
ES 24 h Threshold Crossing
5.51
Ethernet Down (Critical)
5.52
EXC
5.53
Excessive Temperature
5.54
EXM
5.55
Failed Logon Attempt
5.56
FAL License Missing (Major)
5.57
FAL License Missing (Critical)
5.58
File Integrity Violation (Warning)
5.59
File Integrity Violation (Minor)
5.60
File Integrity Violation (Major)
5.61
File Integrity Violation (Critical)
5.62
FOPR
5.63
Free Running Mode Entered
5.64
GIDERR
5.65
Group Timing Mismatch
5.66
Hardware Error: FAU
5.67
Hardware Error: Plugin Unit (Minor)
5.68
Hardware Error: Plugin Unit (Major)
5.69
Hardware Error: Plugin Unit (Critical)
5.70
Hardware Error: RAU
5.71
Hardware Error: SFP (Critical)
5.72
HCC
5.73
High BER (Major)
5.74
High BER (Critical)
5.75
High DM RTT Delay
5.76
High DM Variation RTT Delay
http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
2/219
14/08/2015
Alarm Descriptions
5.77
High Temperature: NPU
5.78
High Temperature: Plugin Unit
5.79
Hitless Phase
5.80
Holdover Mode Entered
5.81
ICC
5.82
IEEE1588 Incompatible Hardware
5.83
IF LOS R2L (Major)
5.84
IF LOS R2L (Critical)
5.85
In Repair
5.86
Incompatible Units: Plugin Unit
5.87
Incompatible Units: RAU
5.88
Insufficient Links
5.89
Insufficient Links (FarEnd)
5.90
Insufficient Resources (Major)
5.91
Insufficient Resources (Critical)
5.92
Interface/Port Status Not Up
5.93
Inter MMU Channel Failure
5.94
Internal Loss of Packets
5.95
Jitter Buffer Overrun
5.96
L2 Loop Detected
5.97
L2 External Loop Detected
5.98
Late Arriving Frames
5.99
LCASCRC
5.100
LFD
5.101
License Handling Is in an Unlocked Period (Minor)
5.102
License Handling Is in an Unlocked Period (Major)
5.103
Link Down
5.104
Link Fault
5.105
Link OAM Loopback
5.106
LOA
5.107
Locking State Lasting Longer than 30 Minutes
5.108
LOF (Critical)
5.109
LOF: RS (Critical)
5.110
LOF L2R (Major)
5.111
LOF L2R (Critical)
5.112
LOF R2L (Major)
5.113
LOF R2L (Critical)
5.114
LOM
5.115
LOMF (Major)
5.116
LOMF (Critical)
5.117
LOP (Major)
5.118
LOP (Critical)
5.119
LOS (Critical)
5.120
LOS: RAU IF (Major)
5.121
LOS: RAU IF (Critical)
5.122
LOS L2R (Major)
5.123
LOS L2R (Critical)
5.124
Loss of Cell Delineation: ATM
http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
3/219
14/08/2015
Alarm Descriptions
5.125
Loss of Cell Delineation: IMA Link
5.126
Loss of Continuity
5.127
Loss of Delay Synchronization
5.128
Loss of Grandmaster Traceability
5.129
Loss of IMA Frame
5.130
Loss of Keep Alive
5.131
Loss of Master Clock Protection
5.132
Loss of Network Reference Redundancy
5.133
Lost CCMs
5.134
Low BER
5.135
Low Input Voltage
5.136
Loss of Frames
5.137
Lower Layer Down
5.138
Maintenance Unlock Reset Key Required (Warning)
5.139
Maintenance Unlock Reset Key Required (Major)
5.140
Malformed Frames
5.141
Mismerge (Incorrect MA ID in CCM)
5.142
Mod Index
5.143
Mode Mismatch: MS
5.144
Mode Mismatch: MSP
5.145
No Holdover Protection
5.146
No Traffic: LAG
5.147
No Traffic Possible
5.148
Node Installation
5.149
NONLCAS
5.150
NPU Installation
5.151
OAM Local Errored Frame , ,
5.152
OAM Local Errored Frame Period , ,
5.153
OAM Local Errored Secs Summary , ,
5.154
OAM Local Errored Symbol Period , ,
5.155
OAM Remote Errored Frame , ,
5.156
OAM Remote Errored Frame Period , ,
5.157
OAM Remote Errored Secs Summary , ,
5.158
OAM Remote Errored Symbol Period , ,
5.159
OSPF LSA Database Overload
5.160
PFM
5.161
Phase Free Running Mode Entered
5.162
Phase Holdover Mode Entered
5.163
PLCR
5.164
PLCT
5.165
PLM (Major)
5.166
PLM (Critical)
5.167
Power Failure (Lower Input)
5.168
PPP Down
5.169
Protected Line Interface: EquipmentAlarm (Minor)
5.170
Protected Line Interface: EquipmentAlarm (Critical)
5.171
Protected Line Interface: CommunicationAlarm (Minor)
5.172
Protected Line Interface: CommunicationAlarm (Critical)
http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
4/219
14/08/2015
Alarm Descriptions
5.173
Protected Port
5.174
PTM
5.175
Radio Frame (Major)
5.176
Radio Frame (Critical)
5.177
Radio ID (Major)
5.178
Radio ID (Critical)
5.179
RAI
5.180
RAU Power Supply Changed
5.181
RCC (Major)
5.182
RCC (Critical)
5.183
RDI (Minor)
5.184
RDI (Major)
5.185
RDI Bit Set in CCM
5.186
Received Invalid CCM
5.187
Remote Failure Indication
5.188
Remote Loss of Frames
5.189
Remote Tx Switch Over
5.190
Reserved Position
5.191
RF Input Level (Critical)
5.192
RF Input Level Div (Minor)
5.193
RF Input Level Div (Major)
5.194
RF Input Level Main (Minor)
5.195
RF Input Level Main (Major)
5.196
RF Input Threshold
5.197
RF Input Threshold Protection
5.198
RF Output Level (Major)
5.199
RF Output Level (Critical)
5.200
RF Output Level ATPC
5.201
RLIME Oversubscription
5.202
RLIME Resource Group1 Oversubscription
5.203
RLIME Degraded Service
5.204
RLIME No Traffic
5.205
RLIME Reassembly Failure
5.206
Running Configuration Not Accepted
5.207
Rx AFC
5.208
RX Frequency (Major)
5.209
RX Frequency (Critical)
5.210
Rx IF Input
5.211
Rx Link Misconnected
5.212
Rx Unusable (FarEnd)
5.213
SDC DADE Calibration Mismatch or Not Calibrated
5.214
SDC Div Hardware Error
5.215
SDC Main Hardware Error
5.216
SES 15 Min Threshold Crossing
5.217
SES 24 h Threshold Crossing
5.218
SFP LOS (Major)
5.219
SFP LOS (Critical)
5.220
SFP Temperature High/Low (Critical)
http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
5/219
14/08/2015
Alarm Descriptions
5.221
SFP Temperature High/Low (Warning)
5.222
SFP Voltage High/Low (Critical)
5.223
SFP Voltage High/Low (Warning)
5.224
SFP TX Bias High/Low (Critical)
5.225
SFP TX Bias High/Low (Warning)
5.226
SFP TX Power High/Low (Critical)
5.227
SFP TX Power High/Low (Warning)
5.228
SFP RX Power High/Low (Critical)
5.229
SFP RX Power High/Low (Warning)
5.230
SQM
5.231
SQMULTIPLE
5.232
SQNC
5.233
SQNONCONT
5.234
SQOR
5.235
Squelch Threshold Reached
5.236
Starting Up (FarEnd)
5.237
Sync Problem
5.238
TIM (Major)
5.239
TIM (Critical)
5.240
TIM Line Side
5.241
TIM Radio Side
5.242
TLCR
5.243
TLCT
5.244
Traffic System Failure (Major)
5.245
Traffic System Failure (Critical)
5.246
TULOM
5.247
TX Frequency (Major)
5.248
TX Frequency (Critical)
5.249
Tx IF Input (Major)
5.250
Tx IF Input (Critical)
5.251
Tx Link Misconnected
5.252
TX Switch Over
5.253
Tx Unusable (FarEnd)
5.254
Unable to Protect: NPU
5.255
Unable to Protect: E1 (Minor)
5.256
Unable to Protect: E1 (Critical)
5.257
Unable to Protect: LPS (Major)
5.258
Unable to Protect: LPS (Critical)
5.259
Unable to Protect: MSP (Minor)
5.260
Unable to Protect: MSP (Critical)
5.261
Unable to Protect: RLIME
5.262
Unable to Protect: SWITCH (Major)
5.263
Unable to Protect: SWITCH (Critical)
5.264
Unable to Protect Failure on Active Port: LAN
5.265
Unable to Protect Failure on Both Ports: LAN
5.266
Unable to Protect Failure on Passive Port: LAN
5.267
Unable to Protect Manual Mode: LAN
5.268
Unable to Protect Port Not Connected to Switch: LAN
http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
6/219
14/08/2015
Alarm Descriptions
5.269
Unavailable Period
5.270
Unavailable State
5.271
Unavailable State Far End
5.272
Unequipped (Major)
5.273
Unequipped (Critical)
5.274
Unexpected MD Level in CCM
5.275
Unexpected MEP Condition
5.276
Unexpected Period in CCM
5.277
Unit Inaccessible: Plugin Unit
5.278
Unit Inaccessible: RMM
5.279
Unit Removed (Minor)
5.280
Unit Removed (Critical)
5.281
Unsupported Capability Profile
5.282
Unsupported Unit Type
5.283
UPM
5.284
User Input
5.285
Wrong NP Software
5.286
Wrong NPU Software
5.287
Wrong Position
5.288
Wrong Software: Plugin Unit
5.289
WST LOS L2R (Major)
5.290
WST LOS L2R (Critical)
5.291
WST LOS R2L (Major)
5.292
WST LOS R2L (Critical)
5.293
XPIC Cable Disconnected
5.294
XPIC LOS
Reference List
Abstract This document describes the alarms handled in the MINILINK TN in terms of definition, causes and suggested recovery action to be taken in order to remove the alarm causes.
1 Introduction This document describes the alarms for MINILINK TN. It also proposes actions to be taken upon reception of an alarm. When MINILINK TN is used in HighDensity Microwave Expansion (HDME) with MINILINK PT, the alarms originating from MINILINK PT are mapped to MINILINK TN alarms. This document does not describe the mapped alarms in HDME. If an alarm with Probable Cause equal to "RemoteAlarmInterface" is raised, refer to MINILINK PT CPI for the description of the alarm. For more information on the mapping mechanism, see Fault Management Operations, Reference [3].
2 Safety Information Make sure that the information in the following documents has been understood by the persons performing the procedures: http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
7/219
14/08/2015
Alarm Descriptions
Personal Health and Safety Information, Reference [8] System Safety Information, Reference [21] Supplementary Safety Information for MINILINK, Reference [20]
3 Preparations This section presents the preparations needed for a successful completion of the procedures in this instruction.
3.1 Additional Preparations Consider the following additional preparations: Read through all applicable sections and make sure referenced documents are available. Make sure you have access to the Network Element (NE) using MINILINK Craft. For more information, see Accessing a Network Element, Reference [1].
4 Overview Each alarm section begins with a short description of the alarm. The following information is also included as reported in the Notification List in MINILINK Craft: SpecificProblem The name of the alarm. Source AlarmType Severity
The source of the alarm.
The alarm type. The alarm types are specified in Fault Management Operations, Reference [3].
The severity of the alarm, for example, Critical or Minor. All severities are described in Fault Management Operations, Reference [3].
ProbableCause The probable cause of the alarm. The name of each alarm section can contain four parts: Specific Problem, Source, Alarm Type, and Severity. Only the parts that are necessary to specify a unique alarm are included in each heading. For example, the name of the alarm Hardware Error, with source equal to plugin unit and severity equal to critical, is named "Hardware Error: Plugin Unit (Critical)". Optionally, the list with information from the Notification List in MINILINK Craft is followed by subsections that describe the alarm in more detail, see below.
4.1 Consequences Section that describes what else occurs as a result of this alarm, informs if a switch occurs, and if there are any masked alarms.
4.2 Alarm Analysis Section describing how to find the root cause of the alarm.
4.3 Corrective Actions Section that describes which actions can be taken to recover the system. http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
8/219
14/08/2015
Alarm Descriptions
4.4 Alarm Clearance Section that describes how the alarm is cleared, automatically or as a result of corrective action.
5 Alarms This section describes all alarms listed alphabetically.
5.1 AIS (Minor) Alarm Indication Signal (AIS) The AIS indicates a transmission interruption in the path to the receiver, that is, there is a problem with the incoming traffic signal. This alarm indicates that the fault originates outside the receiving NE. SpecificProblem AIS Source
E1 E2/E3
MS/RS VC12 VC4
AlarmType
CommunicationAlarm
Severity
Minor
ProbableCause AlarmIndicationSignal 5.1.1 Consequences Service unavailable. 5.1.2 Alarm Analysis The AIS can be used for fault localization purposes and to deliver information of defects or faults across layers. The possible problems with the traffic signal are the following: The traffic signal becomes corrupt. The traffic signal is lost. This can occur between different NEs, for example, between two LTUs, but also within the NE, for example, between VC4 and VC12 in an LTU. The AIS is generated in both cases. To maintain transmission continuity, the NE replaces the missing or corrupt input signal with continuous binary ones, that is the AIS, and this signal is sent to the next NE. 5.1.3 Corrective Actions
http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
9/219
14/08/2015
Alarm Descriptions
Figure 1 Workflow for AIS Alarm Corrective Actions Do the following: 1. Check that the configuration is correct on the farend. Take corrective actions as needed. 2. Check the line status on the nearend and the farend. Take corrective actions as needed. 3. Check the alarm conditions on the nearend and the farend. Take corrective actions as needed. 4. Check the status of the radio link between the nearend and the farend. Take corrective actions as needed. 5. Repeat the steps above for all sections between intermediate elements on the path. http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
10/219
14/08/2015
Alarm Descriptions
5.1.4 Alarm Clearance The AIS is cleared when the NE that is transmitting the AIS receives a valid traffic signal.
5.2 AIS (Critical) Alarm Indication Signal (AIS) The AIS indicates a transmission interruption in the path to the receiver, that is, there is a problem with the incoming traffic signal. This alarm indicates that the fault originates outside the receiving NE. SpecificProblem AIS Source
Framed E1
AlarmType
CommunicationAlarm
Severity
Critical
ProbableCause AlarmIndicationSignal 5.2.1 Consequences Service unavailable. 5.2.2 Alarm Analysis The AIS can be used for fault localization purposes and to deliver information of defects or faults across layers. The possible problems with the traffic signal are the following: The traffic signal becomes corrupt. The traffic signal is lost. This can occur between different NEs, for example, between two LTUs, but also within the NE, for example, between VC4 and VC12 in an LTU. The AIS is generated in both cases. To maintain transmission continuity, the NE replaces the missing or corrupt input signal with continuous binary ones, that is the AIS, and this signal is sent to the next NE. 5.2.3 Corrective Actions
http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
11/219
14/08/2015
Alarm Descriptions
Figure 2 Workflow for AIS Alarm Corrective Actions Do the following: 1. Check that the configuration is correct on the farend. Take corrective actions as needed. 2. Check the line status on the nearend and the farend. Take corrective actions as needed. 3. Check the alarm conditions on the nearend and the farend. Take corrective actions as needed. 4. Check the status of the radio link between the nearend and the farend. Take corrective actions as needed. 5. Repeat the steps above for all sections between intermediate elements on the path. http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
12/219
14/08/2015
Alarm Descriptions
5.2.4 Alarm Clearance The AIS is cleared when the NE that is transmitting the AIS receives a valid traffic signal.
5.3 AIS on Protection Line Alarm Indication Signal (AIS) The AIS indicates a transmission interruption in the path to the receiver, that is, there is a problem with the incoming traffic signal. This alarm indicates that the fault originates outside the receiving NE. SpecificProblem AIS Source
E1
AlarmType
CommunicationAlarm
Severity
Minor
ProbableCause Indeterminate 5.3.1 Consequences Service unavailable. 5.3.2 Alarm Analysis The AIS can be used for fault localization purposes and to deliver information of defects or faults across layers. The possible problems with the traffic signal are the following: The traffic signal becomes corrupt. The traffic signal is lost. This can occur between different NEs, for example, between two LTUs, but also within the NE, for example, between VC4 and VC12 in an LTU. The AIS is generated in both cases. To maintain transmission continuity, the NE replaces the missing or corrupt input signal with continuous binary ones, that is the AIS, and this signal is sent to the next NE. 5.3.3 Corrective Actions
http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
13/219
14/08/2015
Alarm Descriptions
Figure 3 Workflow for AIS Alarm Corrective Actions Do the following: 1. Check that the configuration is correct on the farend. Take corrective actions as needed. 2. Check the line status on the nearend and the farend. Take corrective actions as needed. 3. Check the alarm conditions on the nearend and the farend. Take corrective actions as needed. 4. Check the status of the radio link between the nearend and the farend. Take corrective actions as needed. 5. Repeat the steps above for all sections between intermediate elements on the path. http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
14/219
14/08/2015
Alarm Descriptions
5.3.4 Alarm Clearance The AIS is cleared when the NE that is transmitting the AIS receives a valid traffic signal.
5.4 AMS 15 Min Threshold Crossing Adaptive Modulation Seconds (AMS) The terminal uses the minimum modulation longer time than the configured 15 minute threshold. The threshold is crossed during the current 15 minute interval. Applicable for RAU IF (1+0). Applicable for SWITCH (1+1). SpecificProblem AMS 15 m threshold crossing Source
RAU IF (1+0) SWITCH
AlarmType
QualityOfServiceAlarm
Severity
Minor
ProbableCause ThresholdCrossed 5.4.1 Consequences Decreased traffic capacity for a longer time than expected. 5.4.2 Corrective Actions The problem can be temporary, but if the alarm continues over consecutive 15 min intervals, try the following actions: 1. Verify the Radio Frequency (RF) input power level: it must be at least 5 dB above the 106 Bit Error Ratio (BER) threshold for the current configuration during good weather conditions. See link budget calculation for the correct level. 2. Check the antenna alignment, see Installing Outdoor Equipment, Reference [5]. 3. Check if obstacles are placed in the radio path between the two hops' antennas (at clear sky conditions). 4. Verify that the Radio Network Planning is correct. 5.4.3 Alarm Clearance The alarm is cleared when the time spent in the minimum modulation at the end of the interval is less than the AMS 15 min reset threshold.
5.5 AMS 24 h Threshold Crossing Adaptive Modulation Seconds (AMS) The terminal uses the minimum modulation longer time than the configured 24 hour threshold. Applicable for RAU IF (1+0). http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
15/219
14/08/2015
Alarm Descriptions
Applicable for SWITCH (1+1). SpecificProblem AMS 24 h threshold crossing Source
RAU IF (1+0) SWITCH
AlarmType
QualityOfServiceAlarm
Severity
Minor
ProbableCause ThresholdCrossed 5.5.1 Consequences Decreased traffic capacity for a longer time than expected. 5.5.2 Corrective Actions Try the following actions: 1. Verify the Radio Frequency (RF) input power level: it must be at least 5 dB above the 106 Bit Error Ratio (BER) threshold for the current configuration during good weather conditions. See link budget calculation for the correct level. 2. Check the antenna alignment, see Installing Outdoor Equipment, Reference [5]. 3. Check if obstacles are placed in the radio path between the two hops' antennas (at clear sky conditions). 4. Verify that the Radio Network Planning is correct. 5.5.3 Alarm Clearance The alarm is not cleared automatically. To clear it do a warm restart, see Troubleshooting, Reference [22].
5.6 ATPC Capability Automatic Transmit Power Control (ATPC) The terminal is configured for ATPC, but the RAU does not support ATPC. This alarm is activated only if ATPC is turned on (any direction). SpecificProblem ATPC Capability Source
RAU
AlarmType
EquipmentAlarm
Severity
Major
ProbableCause ReplacebleUnitTypeMismatch 5.6.1 Consequences It is not possible to use ATPC functionality. 5.6.2 Corrective Actions http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
16/219
14/08/2015
Alarm Descriptions
Replace the RAU to one with ATPC support, see Replacing a Radio Unit, Reference [16]. 5.6.3 Alarm Clearance The alarm is cleared when ATPC is disabled or if the RAU is replaced to a RAU with ATPC support.
5.7 ATPC Capability (Far End) Automatic Transmit Power Control (ATPC) The terminal on the farend is configured for ATPC, but at least one of the plugin units does not support ATPC. SpecificProblem ATPC Capability (Far End) Source
All MMUs
AlarmType
EquipmentAlarm
Severity
Major
ProbableCause ReplacebleUnitTypeMismatch 5.7.1 Consequences It is not possible to enable ATPC functionality. 5.7.2 Corrective Actions Replace farend terminal to one with ATPC support, see the relevant Replacing document. 5.7.3 Alarm Clearance The alarm is cleared when ATPC is disabled or if the farend terminal is replaced to one with ATPC support.
5.8 Audit log FTP Transfer Failed The alarm is raised if the transfer of the audit log to the active FTP server fails. SpecificProblem FTP transfer of the audit log file failed Source
NE
AlarmType
EquipmentAlarm
Severity
Warning
ProbableCause ConnectionEstablishmentError 5.8.1 Consequences The audit log is not uploaded to the active FTP server. 5.8.2 Corrective Actions Manually retrieve the audit log and check the FTP server configuration. 5.8.3 Alarm Clearance http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
17/219
14/08/2015
Alarm Descriptions
The alarm is automatically cleared the next time the audit log is successfully transferred to the active FTP server. The alarm can also be cleared by disabling the alarm in MINILINK Craft.
5.9 B1 BBE 15 Min Threshold Crossing Background Block Error (BBE) The Synchronous Digital Hierarchy (SDH) BBE counter threshold, set for 15 min time windows, is crossed the last 15 minutes. The BBE represents the number of Synchronous Transport Module level 1 (STM1) frames containing at least one error, and is computed by the MMU when the operator enables G.826 performance monitoring. The alarm is raised when the BBE counter value crosses the BBE threshold set by the operator. This value is configured within the G.826 performance 15 minutes monitoring options. SpecificProblem B1 BBE 15 min threshold crossing Source
RADIO RS
AlarmType
QualityOfServiceAlarm
Severity
Major
ProbableCause ThresholdCrossed 5.9.1 Consequences Degraded traffic. 5.9.2 Corrective Actions The problem can be temporary, but if the alarm continues over consecutive 15 min intervals, try the following actions: 1. Check if obstacles are placed in the radio path between the two hops' antennas (at clear sky conditions). 2. Verify that the received signal power is as expected (by performing a link budget calculation). 3. Check that no interference signal is present. 4. Replace the MMU, see Replacing an MMU, Reference [13] or Replacing an MMU2 CS, Reference [14]. 5. Replace the RAU, see Replacing a Radio Unit, Reference [16]. 5.9.3 Alarm Clearance The alarm is cleared at the next 15 minutes interval where the BBE counter threshold no longer is crossed.
5.10 B1 BBE 24 h Threshold Crossing Background Block Error (BBE) The Synchronous Digital Hierarchy (SDH) BBE counter threshold, set for 24 h time windows, is crossed the last 24 hours. The BBE represents the number of Synchronous Transport Module level 1 (STM1) frames containing at least one error, and is computed by the MMU when the operator enables G.826 performance monitoring. The alarm is raised when the BBE counter value crosses the BBE threshold set by the operator. This value is configured within the G.826 performance 24 hours monitoring options. http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
18/219
14/08/2015
Alarm Descriptions
SpecificProblem B1 BBE 24 h threshold crossing Source
RADIO RS
AlarmType
QualityOfServiceAlarm
Severity
Major
ProbableCause ThresholdCrossed 5.10.1 Consequences Degraded traffic. 5.10.2 Corrective Actions The problem can be temporary, but if the alarm continues over consecutive 24 h intervals, try the following actions: 1. Check if obstacles are placed in the radio path between the two hops' antennas (at clear sky conditions). 2. Verify that the received signal power is as expected (by preforming a link budget calculation). 3. Check that no interference signal is present. 4. Replace the MMU, see Replacing an MMU, Reference [13] or Replacing an MMU2 CS, Reference [14]. 5. Replace the RAU, see Replacing a Radio Unit, Reference [16]. 5.10.3 Alarm Clearance The alarm is cleared at the next 24 hours interval where the BBE counter threshold no longer is crossed.
5.11 B1 ES 15 Min Threshold Crossing Errored Seconds (ES) The Synchronous Digital Hierarchy (SDH) ES counter threshold, set for 15 min time windows, is crossed the last 15 minutes. The ES represents a second in which one or more Synchronous Transport Module level 1 (STM1) frames contain at least one error, and is computed by the MMU when the operator enables G.826 performance monitoring. The alarm is raised when the ES counter value crosses the ES threshold set by the operator. This value is configured within the G.826 performance 15 minutes monitoring options. SpecificProblem B1 ES 15 min threshold crossing Source
RADIO RS
AlarmType
QualityOfServiceAlarm
Severity
Minor
ProbableCause ThresholdCrossed 5.11.1 Consequences This alarm indicates degraded traffic. If the problem continues, it can lead to B1 SES 15 min threshold crossing, see Section 5.13.
http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
19/219
14/08/2015
Alarm Descriptions
5.11.2 Corrective Actions The problem can be temporary, but if the alarm continues over consecutive 15 min intervals, try the following actions: 1. Check if obstacles are placed in the radio path between the two hops' antennas (at clear sky conditions). 2. Verify that the received signal power is as expected (by preforming a link budget calculation). 3. Check that no interference signal is present. 4. Replace the MMU, see Replacing an MMU, Reference [13] or Replacing an MMU2 CS, Reference [14]. 5. Replace the RAU, see Replacing a Radio Unit, Reference [16]. 5.11.3 Alarm Clearance The alarm is cleared at the next 15 minutes interval where the ES counter threshold no longer is crossed.
5.12 B1 ES 24 h Threshold Crossing Errored Seconds (ES) The Synchronous Digital Hierarchy (SDH) ES counter threshold, set for 24 h time windows, is crossed. The ES represents a second in which one or more Synchronous Transport Module level 1 (STM1) frames contain at least one error, and is computed by the TRU when the operator enables G.826 performance monitoring. The alarm is raised when the ES counter value crosses the ES threshold set by the operator. This value is configured within the G.826 performance 24 hours monitoring options. SpecificProblem B1 ES 24 h threshold crossing Source
RADIO RS
AlarmType
QualityOfServiceAlarm
Severity
Minor
ProbableCause ThresholdCrossed 5.12.1 Consequences This alarm indicates degraded traffic. If the problem continues, it can lead to B1 SES 24 h threshold crossing, see Section 5.14. 5.12.2 Corrective Actions The problem can be temporary, but if the alarm continues over consecutive 24 h intervals, try the following actions: 1. Check if obstacles are placed in the radio path between the two hops' antennas (at clear sky conditions). 2. Verify that the received signal power is as expected (by preforming a link budget calculation). 3. Check that no interference signal is present. 4. Replace the MMU, see Replacing an MMU, Reference [13] or Replacing an MMU2 CS, Reference [14]. 5. Replace the RAU, see Replacing a Radio Unit, Reference [16]. http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
20/219
14/08/2015
Alarm Descriptions
5.12.3 Alarm Clearance The alarm is cleared at the next 24 hour interval where the ES counter threshold no longer is crossed.
5.13 B1 SES 15 Min Threshold Crossing Severely Errored Seconds (SES) The Synchronous Digital Hierarchy (SDH) SES counter threshold, set for 15 min time windows, is crossed. The SES represents a second in which more than 30% of the Synchronous Transport Module level 1 (STM1) frames contain at least one error, and is computed by the MMU when the operator enables G.826 performance monitoring. The alarm is raised when the SES counter value crosses the SES threshold set by the operator. This value is configured within the G.826 performance 15 minutes monitoring options. SpecificProblem B1 SES 15 min threshold crossing Source
RADIO RS
AlarmType
QualityOfServiceAlarm
Severity
Major
ProbableCause ThresholdCrossed 5.13.1 Consequences Degraded traffic. 5.13.2 Corrective Actions Try the following actions: 1. Check if obstacles are placed in the radio path between the two hops' antennas (at clear sky conditions). 2. Verify that the received signal power is as expected (by preforming a link budget calculation). 3. Check that no interference signal is present. 4. Replace the MMU, see Replacing an MMU, Reference [13] or Replacing an MMU2 CS, Reference [14]. 5. Replace the RAU, see Replacing a Radio Unit, Reference [16]. 5.13.3 Alarm Clearance The alarm is cleared at the next 15 minutes interval where the SES counter threshold no longer is crossed.
5.14 B1 SES 24 h Threshold Crossing Severely Errored Seconds (SES) The Synchronous Digital Hierarchy (SDH) SES counter threshold, set for 24 h time windows, is crossed. The SES represents a second in which more than 30% of the Synchronous Transport Module level 1 (STM1) frames contain at least one error, and is computed by the MMU when the operator enables G.826 performance monitoring. The alarm is raised when the SES counter value crosses the SES threshold set by the operator. This value is configured within the G.826 performance 24 hours monitoring options. http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
21/219
14/08/2015
Alarm Descriptions
SpecificProblem B1 SES 24 h threshold crossing Source
RADIO RS
AlarmType
QualityOfServiceAlarm
Severity
Major
ProbableCause ThresholdCrossed 5.14.1 Consequences Degraded traffic. 5.14.2 Corrective Actions Try the following actions: 1. Check if obstacles are placed in the radio path between the two hops' antennas (at clear sky conditions). 2. Verify that the received signal power is as expected (by preforming a link budget calculation). 3. Check that no interference signal is present. 4. Replace the MMU, see Replacing an MMU, Reference [13] or Replacing an MMU2 CS, Reference [14]. 5. Replace the RAU, see Replacing a Radio Unit, Reference [16]. 5.14.3 Alarm Clearance The alarm is cleared at the next 24 hour interval where the SES counter threshold no longer is crossed.
5.15 B1 Unavailable Period The Synchronous Digital Hierarchy (SDH) Unavailable Period counter threshold is crossed. The hop is in unavailability status, since 10 consecutive Severely Errored Seconds (SES) are detected. SpecificProblem B1 Unavailable Period Source
RADIO RS
AlarmType
QualityOfServiceAlarm
Severity
Major
ProbableCause PerformanceDegraded 5.15.1 Consequences Traffic Loss. 5.15.2 Corrective Actions Perform the following actions: 1. Check if obstacles are placed in the radio path between the two hop’s antennas (at clear sky conditions). 2. Verify that the received signal power is as expected (by preforming a link budget calculation). http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
22/219
14/08/2015
Alarm Descriptions
3. Check that no interference signal is present. 4. Replace the MMU, see Replacing an MMU, Reference [13] or Replacing an MMU2 CS, Reference [14]. 5. Replace the RAU, see Replacing a Radio Unit, Reference [16]. 5.15.3 Alarm Clearance The alarm is cleared when the hop exits from the unavailability status. This occurs when 10 consecutive nonSES are detected.
5.16 BBE 15 Min Threshold Crossing Background Block Error (BBE) BBE threshold crossing for 15 min composite performance monitoring. The alarm is raised when the BBE counter value crosses the BBE threshold set by the operator. Applicable for RAU IF (1+0). Applicable for SWITCH (1+1). SpecificProblem BBE 15 min threshold crossing Source
RAU IF (1+0) SWITCH
AlarmType
QualityOfServiceAlarm
Severity
Major
ProbableCause ThresholdCrossed 5.16.1 Consequences Degraded traffic. 5.16.2 Corrective Actions The problem can be temporary, but if the alarm continues over consecutive 15 min intervals, try the following actions: 1. Check if obstacles are placed in the radio path between the two hops' antennas (at clear sky conditions). 2. Verify that the received signal power is as expected (by preforming a link budget calculation). 3. Check that no interference signal is present. 4. Replace the MMU, see Replacing an MMU, Reference [13] or Replacing an MMU2 CS, Reference [14]. 5. Replace the RAU, see Replacing a Radio Unit, Reference [16]. 5.16.3 Alarm Clearance The alarm is cleared at the next 15 minutes interval where the BBE counter threshold no longer is crossed. http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
23/219
14/08/2015
Alarm Descriptions
5.17 BBE 24 h Threshold Crossing Background Block Error (BBE) BBE threshold crossing for 24 hour composite performance monitoring. The alarm is raised when the BBE counter value crosses the BBE threshold set by the operator. Applicable for RAU IF (1+0). Applicable for SWITCH (1+1). SpecificProblem BBE 24 h threshold crossing Source
RAU IF (1+0) SWITCH
AlarmType
QualityOfServiceAlarm
Severity
Major
ProbableCause ThresholdCrossed 5.17.1 Consequences Degraded traffic. 5.17.2 Corrective Actions The problem can be temporary, but if the alarm continues over consecutive 24 h intervals, try the following actions: 1. Check if obstacles are placed in the radio path between the two hops' antennas (at clear sky conditions). 2. Verify that the received signal power is as expected (by performing a link budget calculation). 3. Check that no interference signal is present. 4. Replace the MMU, see Replacing an MMU, Reference [13] or Replacing an MMU2 CS, Reference [14]. 5. Replace the RAU, see Replacing a Radio Unit, Reference [16]. 5.17.3 Alarm Clearance The alarm is cleared at the next 24 hours interval where the BBE counter threshold no longer is crossed.
5.18 BER (Major) Bit Error Ratio (BER) The BER calculated by the Forward Error Correction (FEC) for the received signal exceeds the BER alarm threshold. The incoming signal is so corrupt that the FEC is unable to correct the incoming traffic. Applicable for RAU IF (1+1). SpecificProblem BER http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
24/219
14/08/2015
Alarm Descriptions
Source
RAU IF
AlarmType
Communication
Severity
Major
ProbableCause DegradedSignal 5.18.1 Consequences Radio Protection Switch selects the other demodulation path if its signal quality is better. 5.18.2 Corrective Actions Note: Make sure that the Switch Mode is set to Manual on both the nearend and the farend terminal before troubleshooting. Perform all the actions on the active unit. Set Switch Mode to Auto once the troubleshooting is completed.
Do the following: 1. Verify that the RF input power on the receiving RAU is at least 5 dB above the threshold for BER 106 for the current configuration. See link budget calculation for the correct level. If the RF input power is not at least 5 dB above the threshold, go to Step 2. If the RF input power is at least 5 dB above the threshold, go to Step 12. 2. Perform an RF loop test on the nearend RAU. Turn off the RAU transmitter on the farend during the test. If the RF input power is not about 50 dBm (± 10 dB) during the test, replace the RAU on the nearend. Describe the fault on the Blue Tag and send it to the Repair Center together with the faulty RAU. If the input power is about 50 dBm (± 10 dB) during the test, go to Step 3. 3. Check fading conditions and weather circumstances. If link performance is not affected by propagation issues, go to Step 4. If link performance is affected by propagation issues, consult the transmission design department on how to address the link budget. 4. Check the alarms and status of the farend terminal. If there are no alarms raised on the farend terminal, go to Step 5. If there are alarms raised on the farend terminal, find the root causes of these alarms first, and take corrective actions according to the alarm description. If the BER alarm is still raised on the nearend terminal after clearing the alarms on the farend terminal, go to Step 5. 5. Verify that the nearend terminal configuration matches the farend terminal configuration. If the configuration is not correct, reconfigure the nearend terminal and the farend terminal according to the Site Installation Documentation (SID). If the configuration is correct, go to Step 6. 6. Perform an RF loop test on the farend RAU. Turn off the RAU transmitter on the nearend during the test. If the RF input power is not about 50 dBm (± 10 dB) during the test, replace the RAU on the farend. Describe the fault on the Blue Tag and send it to the Repair Center together with the faulty RAU. If the RF input power is about 50 dBm (± 10 dB) during the test, go to Step 7. http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
25/219
14/08/2015
Alarm Descriptions
7. Check for possible obstacles interfering with the line of sight and check that the antennas are mounted at the correct height according to the link budget planning. If there are obstacles or the antennas are not mounted at the correct height, consult the network design department to review the link budget planning. If there are no obstacles in the line of sight and the antennas are mounted at the correct height, go to Step 8. 8. Make sure the antennas are aligned correctly on the nearend and the farend to meet the link budget target. If the antennas are not aligned correctly, take corrective actions. If the antennas are aligned correctly, go to Step 9. 9. Verify that the RAUs are correctly mounted on the antennas, that any flexible waveguides are not damaged, and that correct polarization is set on both sides of the hop. If you find any problem, take corrective actions. If you do not find any problems, go to Step 10. 10. Replace the antenna on the nearend. If the BER alarm is not cleared after the replacement, reinstall the initial antenna and go to Step 11. If the BER alarm is cleared after the replacement, describe the fault on the Blue Tag and send it to the Repair Center together with the faulty antenna. 11. Replace the antenna on the farend. Describe the fault on the Blue Tag and send it to the Repair Center together with the faulty antenna. 12. Verify that the nearend terminal configuration matches the farend terminal configuration. If the configuration is not correct, reconfigure the nearend terminal and the farend terminal according to the Site Installation Documentation (SID). If the configuration is correct, go to Step 13. 13. Perform a cold restart of the MMU and the RAU on the nearend. Restart MINILINK Craft.
Caution! A cold restart will disturb the traffic. If the BER alarm is not cleared after the restart, go to Step 14. If the BER alarm is cleared after the restart, monitor the hop for further BER alarms. If the alarm is raised again while the RF input level is higher than the threshold level for BER 106 for the current configuration, go to Step 14. 14. Perform an IF loop test on the nearend MMU. If the BER alarm is not cleared during the test, replace the MMU on the nearend. Describe the fault on the Blue Tag and send it to the Repair Center together with the faulty MMU. If the BER alarm is cleared during the test, go to Step 15. 15. Perform an RF loop test on the nearend RAU. Turn off the RAU transmitter on the farend during the test. If the BER alarm is not cleared during the test, go to Step 23. If the BER alarm is cleared during the test, go to Step 16. 16. Check the alarms and status of the farend terminal. http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
26/219
14/08/2015
Alarm Descriptions
If there are no alarms raised on the farend terminal, go to Step 17. If there are alarms raised on the farend terminal, find the root causes of these alarms first, and take corrective actions according to the alarm description. If the BER alarm is still raised on the nearend terminal after clearing the alarms on the farend terminal, go to Step 17. 17. Perform an RX loop test on the farend. If the BER alarm is not cleared during the test, go to Step 18. If the BER alarm is cleared, review the quality of the incoming traffic on the farend MMU line side. 18. Perform an interference test, see Verifying an Installation, Reference [24]. If there is no interference during the test, go to Step 19. If there is any interference during the test, consult the transmission design department to review network planning and link budget. 19. Replace the MMU on the farend. If the BER alarm is not cleared on the nearend after the replacement, reuse the initial MMU on the farend, and go to Step 20. If the BER alarm is cleared on the nearend after the replacement, describe the fault on the Blue Tag and send it to the Repair Center together with the faulty MMU. 20. Replace the RAU on the farend. If the BER alarm is not cleared on the nearend after the replacement, reuse the initial RAU on the farend, and go to Step 21. If the BER alarm is cleared on the nearend after the replacement, describe the fault on the Blue Tag and send it to the Repair Center together with the faulty RAU. 21. Check the radio cable for interference on the IF signal between the MMU and the RAU on the farend terminal with a SiteMaster or a Spectrum Analyzer. Make sure that there is no interference in the frequency range of 0–400 MHz. If there is no interference, go to Step 22. If there is any interference, check the cables for damages and replace the cables if needed. Monitor the interfering source and remove it if possible, or reroute the IF cables not to be disturbed by the interfering source. 22. Replace the radio cables and the connectors between the MMU and the RAU on the farend terminal. 23. Replace the RAU on the nearend. If the BER alarm is not cleared on the nearend after the replacement, reuse the initial RAU, and go to Step 24. If the BER alarm is cleared on the nearend after the replacement, describe the fault on the Blue Tag and send it to the Repair Center together with the faulty RAU. 24. Check the radio cable for interference on the IF signal between the MMU and the RAU on the nearend terminal with a SiteMaster or a Spectrum Analyzer. Make sure that there is no interference in the frequency range of 0–400 MHz. If there is no interference, go to Step 25. If there is any interference, check the cables for damages and replace the cables if needed. Monitor the interfering source and remove it if possible, or reroute the IF cables not to be disturbed by the interfering source. 25. Replace the radio cables and the connectors between the MMU and the RAU on the farend terminal. For more information on how to replace the RAU, see Replacing a Radio Unit, Reference [16]. http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
27/219
14/08/2015
Alarm Descriptions
For more information on antenna alignment and antenna installation, see Installing Outdoor Equipment, Reference [5]. For more information on how to replace the MMU, see Replacing an MMU, Reference [13]. 5.18.3 Alarm Clearance The alarm is cleared when the BER estimation is below the BER alarm threshold.
5.19 BER (Critical) Bit Error Ratio (BER) The BER calculated by the Forward Error Correction (FEC) for the received signal exceeds the BER alarm threshold. The incoming signal is so corrupt that the FEC is unable to correct the incoming traffic. Applicable for RAU IF (1+0). SpecificProblem BER Source
RAU IF
AlarmType
Communication
Severity
Critical
ProbableCause DegradedSignal 5.19.1 Consequences Degradation of signal quality. Only for Plesiochronous Digital Hierarchy (PDH). 5.19.2 Corrective Actions Do the following: 1. Verify that the RF input power on the receiving RAU is at least 5 dB above the threshold for BER 106 for the current configuration. See link budget calculation for the correct level. If the RF input power is not at least 5 dB above the threshold, go to Step 2. If the RF input power is at least 5 dB above the threshold, go to Step 12. 2. Perform an RF loop test on the nearend RAU. Turn off the RAU transmitter on the farend during the test. If the RF input power is not about 50 dBm (± 10 dB) during the test, replace the RAU on the nearend. Describe the fault on the Blue Tag and send it to the Repair Center together with the faulty RAU. If the input power is about 50 dBm (± 10 dB) during the test, go to Step 3. 3. Check fading conditions and weather circumstances. If link performance is not affected by propagation issues, go to Step 4. If link performance is affected by propagation issues, consult the transmission design department on how to address the link budget. 4. Check the alarms and status of the farend terminal. If there are no alarms raised on the farend terminal, go to Step 5. If there are alarms raised on the farend terminal, find the root causes of these alarms http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
28/219
14/08/2015
Alarm Descriptions
first, and take corrective actions according to the alarm description. If the BER alarm is still raised on the nearend terminal after clearing the alarms on the farend terminal, go to Step 5. 5. Verify that the nearend terminal configuration matches the farend terminal configuration. If the configuration is not correct, reconfigure the nearend terminal and the farend terminal according to the Site Installation Documentation (SID). If the configuration is correct, go to Step 6. 6. Perform an RF loop test on the farend RAU. Turn off the RAU transmitter on the nearend during the test. If the RF input power is not about 50 dBm (± 10 dB) during the test, replace the RAU on the farend. Describe the fault on the Blue Tag and send it to the Repair Center together with the faulty RAU. If the RF input power is about 50 dBm (± 10 dB) during the test, go to Step 7. 7. Check for possible obstacles interfering with the line of sight and check that the antennas are mounted at the correct height according to the link budget planning. If there are obstacles or the antennas are not mounted at the correct height, consult the network design department to review the link budget planning. If there are no obstacles in the line of sight and the antennas are mounted at the correct height, go to Step 8. 8. Make sure the antennas are aligned correctly on the nearend and the farend to meet the link budget target. If the antennas are not aligned correctly, take corrective actions. If the antennas are aligned correctly, go to Step 9. 9. Verify that the RAUs are correctly mounted on the antennas, that any flexible waveguides are not damaged, and that correct polarization is set on both sides of the hop. If you find any problem, take corrective actions. If you do not find any problems, go to Step 10. 10. Replace the antenna on the nearend. If the BER alarm is not cleared after the replacement, reinstall the initial antenna and go to Step 11. If the BER alarm is cleared after the replacement, describe the fault on the Blue Tag and send it to the Repair Center together with the faulty antenna. 11. Replace the antenna on the farend. Describe the fault on the Blue Tag and send it to the Repair Center together with the faulty antenna. 12. Verify that the nearend terminal configuration matches the farend terminal configuration. If the configuration is not correct, reconfigure the nearend terminal and the farend terminal according to the Site Installation Documentation (SID). If the configuration is correct, go to Step 13. 13. Perform a cold restart of the MMU and the RAU on the nearend. Restart MINILINK Craft.
Caution! A cold restart will disturb the traffic. If the BER alarm is not cleared after the restart, go to Step 14. If the BER alarm is cleared after the restart, monitor the hop for further BER alarms. If http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
29/219
14/08/2015
Alarm Descriptions
the alarm is raised again while the RF input level is higher than the threshold level for BER 106 for the current configuration, go to Step 14. 14. Perform an IF loop test on the nearend MMU. If the BER alarm is not cleared during the test, replace the MMU on the nearend. Describe the fault on the Blue Tag and send it to the Repair Center together with the faulty MMU. If the BER alarm is cleared during the test, go to Step 15. 15. Perform an RF loop test on the nearend RAU. Turn off the RAU transmitter on the farend during the test. If the BER alarm is not cleared during the test, go to Step 23. If the BER alarm is cleared during the test, go to Step 16. 16. Check the alarms and status of the farend terminal. If there are no alarms raised on the farend terminal, go to Step 17. If there are alarms raised on the farend terminal, find the root causes of these alarms first, and take corrective actions according to the alarm description. If the BER alarm is still raised on the nearend terminal after clearing the alarms on the farend terminal, go to Step 17. 17. Perform an RX loop test on the farend. If the BER alarm is not cleared during the test, go to Step 18. If the BER alarm is cleared, review the quality of the incoming traffic on the farend MMU line side. 18. Perform an interference test, see Verifying an Installation, Reference [24]. If there is no interference during the test, go to Step 19. If there is any interference during the test, consult the transmission design department to review network planning and link budget. 19. Replace the MMU on the farend. If the BER alarm is not cleared on the nearend after the replacement, reuse the initial MMU on the farend, and go to Step 20. If the BER alarm is cleared on the nearend after the replacement, describe the fault on the Blue Tag and send it to the Repair Center together with the faulty MMU. 20. Replace the RAU on the farend. If the BER alarm is not cleared on the nearend after the replacement, reuse the initial RAU on the farend, and go to Step 21. If the BER alarm is cleared on the nearend after the replacement, describe the fault on the Blue Tag and send it to the Repair Center together with the faulty RAU. 21. Check the radio cable for interference on the IF signal between the MMU and the RAU on the farend terminal with a SiteMaster or a Spectrum Analyzer. Make sure that there is no interference in the frequency range of 0–400 MHz. If there is no interference, go to Step 22. If there is any interference, check the cables for damages and replace the cables if needed. Monitor the interfering source and remove it if possible, or reroute the IF cables not to be disturbed by the interfering source. 22. Replace the radio cables and the connectors between the MMU and the RAU on the farend terminal. 23. Replace the RAU on the nearend. If the BER alarm is not cleared on the nearend after the replacement, reuse the initial http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
30/219
14/08/2015
Alarm Descriptions
RAU, and go to Step 24. If the BER alarm is cleared on the nearend after the replacement, describe the fault on the Blue Tag and send it to the Repair Center together with the faulty RAU. 24. Check the radio cable for interference on the IF signal between the MMU and the RAU on the nearend terminal with a SiteMaster or a Spectrum Analyzer. Make sure that there is no interference in the frequency range of 0–400 MHz. If there is no interference, go to Step 25. If there is any interference, check the cables for damages and replace the cables if needed. Monitor the interfering source and remove it if possible, or reroute the IF cables not to be disturbed by the interfering source. 25. Replace the radio cables and the connectors between the MMU and the RAU on the farend terminal. For more information on how to replace the RAU, see Replacing a Radio Unit, Reference [16]. For more information on antenna alignment and antenna installation, see Installing Outdoor Equipment, Reference [5]. For more information on how to replace the MMU, see Replacing an MMU, Reference [13]. 5.19.3 Alarm Clearance The alarm is cleared when the BER estimation is below the BER alarm threshold.
5.20 BID Missing The AMM backplane ID (serial number) can not be read. Source
AMM backplane or plugin unit
AlarmType
EquipmentAlarm
Severity
Warning
ProbableCause Corrupt/broken AMM backplane or plugin unit
Figure 4 Example of the BID Missing Alarm in MINILINK Craft
http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
31/219
14/08/2015
Alarm Descriptions
5.20.1 Consequences No impact on traffic. 5.20.2 Corrective Actions Replace or check the applicable HW. 5.20.3 Alarm Clearance The alarm is cleared when the corrupt or broken HW has been replaced.
5.21 Blocked (Far End) The farend Inverse Multiplexer over ATM (IMA) group has been blocked (inhibited by the Management System). SpecificProblem Blocked (Far End) Source
IMA Group
AlarmType
CommunicationAlarm
Severity
Major
ProbableCause RemoteAlarmInterface 5.21.1 Consequences No Asynchronous Transfer Mode (ATM) traffic can be transmitted over the specific IMA group before both the nearend and farend groups become operational. 5.21.2 Corrective Actions Unblock the farend group. 5.21.3 Alarm Clearance The alarm is cleared when farend IMA group has been unblocked.
5.22 BR Pressed Board Removal (BR) button is pressed, which is a request to take the plugin unit out of service. The plugin unit can then be removed. The BR button must always be pressed before removing a plugin unit, otherwise, the NE might show unstable behavior. SpecificProblem BR Pressed Source
Plugin Unit
AlarmType
EquipmentAlarm
Severity
Critical
ProbableCause ReplacableUnitProblem 5.22.1 Consequences The BR (yellow) LED is ON. The plugin unit gets operational status Out of Service and all traffic http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
32/219
14/08/2015
Alarm Descriptions
related alarms for this plugin unit are disabled. For information on the location of the BR button and BR LED, see LED Descriptions, Reference [6]. 5.22.2 Corrective Actions If the plugin unit is removed permanently, follow the instructions in Removing a PlugIn Unit, Reference [10]. If the plugin unit is replaced by another unit with the same function, follow the instructions in the relevant Replacing document. 5.22.3 Alarm Clearance The alarm is cleared when the plugin unit is removed. The alarm is also cleared if the BR button is pressed once again.
5.23 Carrier Recovery Loss (Major) The Synchronous Digital Hierarchy (SDH) carrier signal cannot be recovered at the demodulator. The 140 MHz spectrum coming from the receiving RAU is too low or too corrupted to lock the carrier. It is generally caused by deep fading. The alarm can also be caused by the following events: Transmission problem on the hop other side Tx. Deep fading on the radio path. SpecificProblem Carrier Recovery Loss Source
RAU IF (1+1)
AlarmType
CommunicationAlarm
Severity
Major
ProbableCause ReceiverFailure 5.23.1 Consequences The system switches on the standby faultless MMU. 5.23.2 Corrective Actions Perform the following actions: 1. Verify that the transmitter on hop other side is correctly working. 2. Verify the frequency settings on the Tx and Rx. 3. Verify the Radio Frequency (RF) input power level: it must be at least 5 dB above the 106 Bit Error Ratio (BER) threshold for the current configuration. See link budget calculation for the correct level. 4. Increase the RF input power level (if possible) by acting on the farend output power. 5. Check the antenna alignment, see Installing Outdoor Equipment, Reference [5]. 6. Verify the link budget calculation. 7. Check for presence of RF interferers. 8. Check for presence of Intermediate Frequency (IF) interferers (and eventually the RF coaxial http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
33/219
14/08/2015
Alarm Descriptions
cable shielding). 9. Evaluate the presence of selective (multipath) fading. 10. Perform an IF loop on the MMU, see Fault Management Operations, Reference [3]. If the alarm is still present then replace the active MMU, see Replacing an MMU, Reference [13] or Replacing an MMU2 CS, Reference [14]. 11. Perform an RF loop on the RAU, see Fault Management Operations, Reference [3]. If the alarm is still present then replace the active RAU, see Replacing a Radio Unit, Reference [16]. 12. Execute troubleshooting as step 10 and 11 on the farend and act consequently. 5.23.3 Alarm Clearance The alarm is cleared when a good quality signal is received.
5.24 Carrier Recovery Loss (Critical) The Synchronous Digital Hierarchy (SDH) carrier signal cannot be recovered at the demodulator. The 140 MHz spectrum coming from the receiving RAU is too low or too corrupted to lock the carrier. It is generally caused by deep fading. The alarm can also be caused by the following events: Transmission problem on the hop other side Tx Deep fading on the radio path SpecificProblem Carrier Recovery Loss Source
RAU IF (1+0)
AlarmType
CommunicationAlarm
Severity
Critical
ProbableCause ReceiverFailure 5.24.1 Consequences Traffic is lost on the line side and an Alarm Indication Signal (AIS) is sent. 5.24.2 Corrective Actions Perform the following actions: 1. Verify that the transmitter on hop other side is correctly working. 2. Verify the frequency settings on the Tx and Rx. 3. Verify the Radio Frequency (RF) input power level: it must be at least 5 dB above the 106 Bit Error Ratio (BER) threshold for the current configuration. See link budget calculation for the correct level. 4. Increase the RF input power level (if possible) by acting on the farend output power. 5. Check the antenna alignment, see Installing Outdoor Equipment, Reference [5]. 6. Verify the link budget calculation. 7. Check for presence of RF interferers. 8. Check for presence of Intermediate Frequency (IF) interferers (and eventually the RF coaxial cable shielding). http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
34/219
14/08/2015
Alarm Descriptions
9. Evaluate the presence of selective (multipath) fading. 10. Perform an IF loop on the MMU, see Fault Management Operations, Reference [3]. If the alarm is still present then replace the active MMU, see Replacing an MMU, Reference [13] or Replacing an MMU2 CS, Reference [14]. 11. Perform an RF loop on the RAU, see Fault Management Operations, Reference [3]. If the alarm is still present then replace the active RAU, see Replacing a Radio Unit, Reference [16]. 12. Execute troubleshooting as step 10 and 11 on the farend and act consequently. 5.24.3 Alarm Clearance The alarm is cleared when a good quality signal is received.
5.25 Clock Loss Of Reference The alarm is raised with LTU 155 when the following conditions occur at the same time: Network Synchronization function is disabled. LTU 155 is configured to use Rx signal as clock source. There is no valid incoming STM1 signal to the LTU 155. SpecificProblem Clock Loss Of Reference Source
MS/RS
AlarmType
EquipmentAlarm
Severity
Minor
ProbableCause Indeterminate 5.25.1 Consequences No clock source available for the LTU 155. 5.25.2 Corrective Actions Enable Network Synchronization function or provide valid STM1 signal for the LTU 155. 5.25.3 Alarm Clearance The alarm is cleared when Network Synchronization function is enabled or there is valid incoming STM1 signal to the LTU 155.
5.26 CLOS Client Signal Loss (CLOS) A client management frame (PTI = 001b) signaling Loss of Client Signal (LCS) (UPI = 00000001b) is received. SpecificProblem CLOS Source
GFP
AlarmType
CommunicationAlarm
Severity
Critical
http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
35/219
14/08/2015
Alarm Descriptions
ProbableCause LossOfSignal 5.26.1 Consequences Interface down. 5.26.2 Corrective Actions Remove failure in the Far End. 5.26.3 Alarm Clearance The alarm is cleared when communication is recovered.
5.27 Configuration Aborted The farend tries to use Inverse Multiplexer over ATM (IMA) configuration parameters not compatible with the nearend configuration. SpecificProblem Configuration Aborted Source
IMA Group
AlarmType
CommunicationAlarm
Severity
Major
ProbableCause ConfigurationOrCustomizationError 5.27.1 Consequences No Asynchronous Transfer Mode (ATM) traffic can be transmitted over the specific IMA group before both the nearend and farend groups become operational. 5.27.2 Corrective Actions Check the farend IMA configuration: M (IMA Frame Size) = 128, Symmetric Configuration and Operation. 5.27.3 Alarm Clearance The alarm is cleared when the farend configuration is accepted by the nearend.
5.28 Configuration Failure (FarEnd) The farend does not accept the configuration parameters of the nearend Inverse Multiplexer over ATM (IMA) device and reports unacceptable configuration parameters. SpecificProblem Configuration Failure (FarEnd) Source
IMA Group
AlarmType
CommunicationAlarm
Severity
Major
ProbableCause ConfigurationOrCustomizationError
http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
36/219
14/08/2015
Alarm Descriptions
5.28.1 Consequences No Asynchronous Transfer Mode (ATM) traffic can be transmitted over the specific IMA group before both the nearend and farend groups become operational. 5.28.2 Corrective Actions Check the farend IMA configuration: M (IMA Frame Size) = 128, Symmetric Configuration and Operation. 5.28.3 Alarm Clearance The alarm is cleared when the nearend configuration is accepted by the farend.
5.29 Control System Failure (Minor) SpecificProblem Control Failure Source
NE SAU
AlarmType
EquipmentAlarm
Severity
Minor
ProbableCause CommunicationsSubsystemFailure
5.30 Control System Failure (Major) A malfunction related to management, the NPU or the control bus fails. SpecificProblem Control Failure Source
NE
AlarmType
EquipmentAlarm
Severity
Major
ProbableCause CommunicationsSubsystemFailure 5.30.1 Consequences The management functionality is reduced or unavailable. 5.30.2 Corrective Actions Try the following: Access the NE locally, see Accessing a Network Element, Reference [1]. 1. Check the site LAN port configuration. 2. Check the alarm list. Replace the NPU if it is damaged, see Replacing an NPU, Reference [15]. 5.30.3 Alarm Clearance http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
37/219
14/08/2015
Alarm Descriptions
The alarm is cleared when the management functionality is working again.
5.31 CTRLOR Undefined control word on one or more Virtual Containers (VCs). SpecificProblem CTRLOR Source
VCG/LCAS NonStandard Alarms
AlarmType
CommunicationAlarm
Severity
Major
ProbableCause CommunicationsProtocolError
5.32 Default Configuration Not Accepted The MMU/RAU/SFP could not accept the default configuration. This can be caused by an error in the configuration file or by a hardware error. The service (yellow) LED flashes during this alarm. SpecificProblem Default configuration not accepted Source
All MMUs
All RAUs All SFPs
AlarmType
EquipmentAlarm
Severity
Major
ProbableCause ReplaceableUnitTypeMismatch 5.32.1 Consequences Failure to manage the plugin unit or the entire node. 5.32.2 Alarm Clearance The alarm is cleared when the configuration file is accepted.
5.33 Def Xcon CCM The Maintenance End Point (MEP) has received at least one Continuity Check Message (CCM) from either another Maintenance Association (MA) ID or a lower Maintenance Domain (MD) level, the CCM interval of which has not yet timed out. Note: This alarm is only available when using the IEEE 802.1ag standard for Connectivity Fault Management (CFM). SpecificProblem Def Xcon CCM Source
LAN with MEP
WAN with MEP LAG with MEP
http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
38/219
14/08/2015
Alarm Descriptions
AlarmType
CommunicationAlarm
Severity
Major
ProbableCause PathTraceMismatch 5.33.1 Corrective Actions No corrective action is required.
5.34 DEG (Minor) Degraded Signal (DEG) Probable cause: incoming signal of this layer violates the signal degradation threshold. SpecificProblem DEG Source
AU4 MS TU3
TU12 VC3 VC4 VC12
AlarmType
CommunicationAlarm
Severity
Minor
ProbableCause DegradedSignal 5.34.1 Consequences Service degraded. 5.34.2 Corrective Actions Check link connection of this layer.
5.35 DEG (Major) Degraded Signal (DEG) The incoming signal violates the degraded defect threshold for a period longer than the defined monitoring period. SpecificProblem DEG Source
MS/RS
VC12 VC4
http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
39/219
14/08/2015
Alarm Descriptions
AlarmType
QualityOfServiceAlarm
Severity
Major
ProbableCause DegradedSignal 5.35.1 Consequences The service is degraded. 5.35.2 Corrective Actions Check and correct the link connection of the faulty layer. 5.35.3 Alarm Clearance The alarm is cleared when the incoming signal is below the degraded defect threshold.
5.36 DEGFCS Degraded Frame Check Sequence (DEGFCS) An excessive number of frames with FCS error is received. The threshold for this alarm is configurable. SpecificProblem DEGFCS Source
GFP
AlarmType
QualityOfServiceAlarm
Severity
Critical
ProbableCause PerformanceDegraded 5.36.1 Consequences Interface down. 5.36.2 Corrective Actions 1. Check the Bit Error Ratio (BER), see Troubleshooting, Reference [22]. 2. Check the source. 5.36.3 Alarm Clearance A less than 1/10 threshold number of frames with FCS error is received. The threshold for this alarm is configurable.
5.37 Degraded Service: HDLC or IM Group One or several (but not all) Inverse Multiplexer (IM) interfaces are down, leading to decreased speed on the bridge connection. SpecificProblem Degraded service Source
HDLC
http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
40/219
14/08/2015
Alarm Descriptions
IM Group
AlarmType
CommunicationAlarm
Severity
Major
ProbableCause Unavailable 5.37.1 Corrective Actions 1. Check the Bit Error Ratio (BER). 2. Check the source.
5.38 Degraded Service: IM Group The defined threshold for discarded frames on the Inverse Multiplexer (IM) group layer is exceeded. SpecificProblem Degraded service Source
IM Group
AlarmType
QualityOfServiceAlarm
Severity
Major
ProbableCause DegradedSignal
5.39 Degraded Service: LAG For one or more ports but not all the ports allocated to the link aggregation group, the link is down. SpecificProblem Degraded Service Source
LAG
AlarmType
CommunicationAlarm
Severity
Major
ProbableCause Unavailable Note: When Extended Buffer is enabled, this alarm is suppressed.
5.40 DEGTHEC Degraded tHEC. An excessive number of frames with tHEC error is received. The threshold for this alarm is configurable. SpecificProblem DEGTHEC Source
GFP
AlarmType
QualityOfServiceAlarm
Severity
Critical
ProbableCause PerformanceDegraded
http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
41/219
14/08/2015
Alarm Descriptions
5.40.1 Consequences Interface down. 5.40.2 Corrective Actions 1. Check the Bit Error Ratio (BER), see Troubleshooting, Reference [22]. 2. Check the source. 5.40.3 Alarm Clearance A less than 1/10 threshold number of frames with tHEC error is received. The threshold for this alarm is configurable.
5.41 Dmod Clock (Major) The internal data rate of the MMU does not correspond to the received data rate. This fault causes bit slip in the composite bit stream. Probable causes for the fault: faulty MMU or fading. Applicable for RAU IF (1+1). SpecificProblem Dmod Clock Source
RAU IF
AlarmType
EquipmentAlarm
Severity
Major
ProbableCause TimingProblem 5.41.1 Consequences This condition can lead to Unable to Protect or hitless switching not working, if a switch needs to be done later. 5.41.2 Corrective Actions If the problem is caused by fading when space diversity is used, the system is probably able to correct itself and no action is necessary. Otherwise, try the following: Make a manual switch. Test the radio hop. 5.41.3 Alarm Clearance The alarm is cleared when the internal data rate of the MMU matches the received data rate.
5.42 Dmod Clock (Critical) The Internal data rate of the MMU does not correspond to the received data rate. This fault causes bit slip in the composite bit stream. Probable causes for the fault: faulty MMU or fading.
http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
42/219
14/08/2015
Alarm Descriptions
Applicable for RAU IF (1+0). SpecificProblem Dmod Clock Source
RAU IF
AlarmType
EquipmentAlarm
Severity
Critical
ProbableCause TimingProblem 5.42.1 Consequences Traffic Loss. 5.42.2 Corrective Actions Test the radio hop. 5.42.3 Alarm Clearance The alarm is cleared when the internal data rate of the MMU matches the received data rate.
5.43 Early Warning The threshold for early warning is passed. Probable causes are the following: Fading (flat or selective). Bad antenna alignment. Link budget calculation not correct. Presence of Interferers. SpecificProblem Early Warning Source
RAU IF
AlarmType
CommunicationAlarm
Severity
Minor
ProbableCause DegradedSignal 5.43.1 Consequences Degradation of the signal quality. 5.43.2 Corrective Actions Perform the following actions: Note: If the alarm occurs in a 1+1 protected terminal, make sure that the Switch Mode is set to Manual on both the nearend and the farend terminal before troubleshooting. Take all actions on the active unit. Set Switch Mode to Auto once the troubleshooting is completed.
1. Verify that the RF input power on the receiving RAU is at least 10 dB above the threshold for BER 106 for the current configuration. See link budget calculation for the correct level. http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
43/219
14/08/2015
Alarm Descriptions
If the RF input power is not at least 10 dB above the threshold, go to Step 2. If the RF input power is at least 10 dB above the threshold, go to Step 12. 2. Perform an RF loop test on the nearend RAU. Turn off the RAU transmitter on the farend during the test. If the RF input power is not about 50 dBm (± 10 dB) during the test, replace the RAU on the nearend. Describe the fault on the Blue Tag and send it to the Repair Center together with the faulty RAU. If the RF input power is about 50 dBm (± 10 dB) during the test, go to Step 3. 3. Check fading conditions and weather circumstances. If link performance is not affected by propagation issues, go to Step 4. If link performance is affected by propagation issues, consult the transmission design department on how to address the link budget. 4. Check the alarms and status of the farend terminal. If there are no alarms raised on the farend terminal, go to Step 5. If there are alarms raised on the farend terminal, find the root causes of these alarms first, and take corrective actions according to the alarm description. If the BER alarm is still raised on the nearend terminal after clearing the alarms on the farend terminal, go to Step 5. 5. Verify that the nearend terminal configuration matches the farend terminal configuration. If the configuration is not correct, reconfigure the nearend terminal and the farend terminal according to the Site Installation Documentation (SID). If the configuration is correct, go to Step 6. 6. Perform an RF loop test on the farend RAU. Turn off the RAU transmitter on the nearend during the test. If the RF input power is not about 50 dBm (± 10 dB) during the test, replace the RAU on the farend. Describe the fault on the Blue Tag and send it to the Repair Center together with the faulty RAU. If the RF input power is about 50 dBm (± 10 dB) during the test, go to Step 7. 7. Check for possible obstacles interfering with the line of sight and check that the antennas are mounted at the correct height according to the link budget. If there are obstacles or the antennas are not mounted at the correct height, consult the network design department to review the link budget planning. If there are no obstacles in the line of sight and the antennas are mounted at the correct height, go to Step 8. 8. Make sure the antennas are aligned correctly on the nearend and the farend to meet the link budget target. If the antennas are not aligned correctly, take corrective actions. If the antennas are aligned correctly, go to Step 9. 9. Verify that the RAUs are correctly mounted on the antennas, that any flexible waveguides are not damaged, and that correct polarization is set on both sides of the hop. If you find any problem, take corrective actions. If you do not find any problems, go to Step 10. 10. Replace the antenna on the nearend. If the BER alarm is not cleared after the replacement, reinstall the initial antenna, and go to Step 11. If the BER alarm is cleared after the replacement, describe the fault on the Blue Tag and http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
44/219
14/08/2015
Alarm Descriptions
send it to the Repair Center together with the faulty antenna. 11. Replace the antenna on the farend. Describe the fault on the Blue Tag and send it to the Repair Center together with the faulty antenna. 12. Verify that the nearend terminal configuration matches the farend terminal configuration. If the configuration is not correct, reconfigure the nearend terminal and the farend terminal according to the Site Installation Documentation (SID). If the configuration is correct, go to Step 13. 13. Perform a cold restart of the MMU and the RAU on the nearend. Restart MINILINK Craft.
Caution! A cold restart will disturb the traffic. If the BER alarm is not cleared after the restart, go to Step 14. If the BER alarm is cleared after the restart, monitor the hop for further BER alarms. If the alarm is raised again while the RF input level is higher than the threshold level for BER 106 for the current configuration, go to Step 14. 14. Perform an IF loop test on the nearend MMU. If the BER alarm is not cleared during the test, replace the MMU on the nearend. Describe the fault on the Blue Tag and send it to the Repair Center together with the faulty MMU. If the BER alarm is cleared during the test, go to Step 15. 15. Perform an RF loop test on the nearend RAU. Turn off the RAU transmitter on the farend during the test. If the BER alarm is not cleared during the test, go to Step 23. If the BER alarm is cleared during the test, go to Step 16. 16. Check the alarms and status of the farend terminal. If there are no alarms raised on the farend terminal, go to Step 17. If there are alarms raised on the farend terminal, find the root causes of these alarms first, and take corrective actions according to the alarm description. If the BER alarm is still raised on the nearend terminal after clearing the alarms on the farend terminal, go to Step 17. 17. Perform an RX loop test on the farend. If the BER alarm is not cleared during the test, go to Step 18. If the BER alarm is cleared, review the quality of the incoming traffic on the farend MMU line side. 18. Perform an interference test, see Verifying an Installation, Reference [24]. If there is no interference during the test, go to Step 19. If there is any interference during the test, consult the transmission design department to review network planning and link budget. 19. Replace the MMU on the farend. If the BER alarm is not cleared on the nearend after the replacement, reuse the initial MMU on the farend, and go to Step 20. If the BER alarm is cleared on the nearend after the replacement, describe the fault on the Blue Tag and send it to the Repair Center together with the faulty MMU. 20. Replace the RAU on the farend. http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
45/219
14/08/2015
Alarm Descriptions
If the BER alarm is not cleared on the nearend after the replacement, reuse the initial RAU on the farend, and go to Step 21. If the BER alarm is cleared on the nearend after the replacement, describe the fault on the Blue Tag and send it to the Repair Center together with the faulty RAU. 21. Check the radio cable for interference on the IF signal between the MMU and the RAU on the farend terminal with a SiteMaster or a Spectrum Analyzer. Make sure that there is no interference in the frequency range of 0–400 MHz. If there is no interference, go to Step 22. If there is any interference, check the cables for damages and replace the cables if needed. Monitor the interfering source and remove it if possible, or reroute the IF cables not to be disturbed by the interfering source. 22. Replace the radio cables and the connectors between the MMU and the RAU on the farend terminal. 23. Replace the RAU on the nearend. If the BER alarm is not cleared on the nearend after the replacement, reuse the initial RAU, and go to Step 24. If the BER alarm is cleared on the nearend after the replacement, describe the fault on the Blue Tag and send it to the Repair Center together with the faulty RAU. 24. Check the radio cable for interference on the IF signal between the MMU and the RAU on the nearend terminal with a SiteMaster or a Spectrum Analyzer. Make sure that there is no interference in the frequency range of 0–400 MHz. If there is no interference, go to Step 25. If there is any interference, check the cables for damages and replace the cables if needed. Monitor the interfering source and remove it if possible, or reroute the IF cables not to be disturbed by the interfering source. 25. Replace the radio cables and the connectors between the MMU and the RAU on the farend terminal. For more information on how to replace the RAU, see Replacing a Radio Unit, Reference [16]. For more information on antenna alignment and antenna installation, see Installing Outdoor Equipment, Reference [5]. For more information on how to replace the MMU, see Replacing an MMU, Reference [13]. 5.43.3 Alarm Clearance The alarm is cleared when the BER estimation is below the threshold.
5.44 Emergency Unlock Reset Key Required (Warning) The number of available Emergency Unlock tokens decreased to one, because the user entered Emergency Unlock period. When entering Emergency Unlock period again, the tokens run out and the severity of this alarm is changed to Major. SpecificProblem Emergency Unlock Reset Key Required Source
License Handler
AlarmType
OperationalViolation
Severity
Warning
ProbableCause Unavailable http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
46/219
14/08/2015
Alarm Descriptions
5.44.1 Corrective Actions Install Emergency Unlock Refill licenses, see Installing and Managing Licenses, Reference [4]. 5.44.2 Alarm Clearance The alarm is cleared as soon as the user installs at least one Emergency Refill license.
5.45 Emergency Unlock Reset Key Required (Major) No Emergency Unlock tokens available, because the user entered Emergency Unlock period several times. When an Emergency Unlock Refill license is installed, the severity of this alarm is changed to Warning. SpecificProblem Emergency Unlock Reset Key Required Source
License Handler
AlarmType
OperationalViolation
Severity
Major
ProbableCause Unavailable 5.45.1 Corrective Actions Install Emergency Unlock Refill licenses, see Installing and Managing Licenses, Reference [4]. 5.45.2 Alarm Clearance The alarm is cleared as soon as the user installs at least one Emergency Refill license.
5.46 EOSMISSING End Of Sequence (EOS) None of the Virtual Containers (VCs) belonging to the Virtual Concatenation Groups (VCGs) received EOS. SpecificProblem EOSMISSING Source
VCG/LCAS NonStandard Alarms
AlarmType
CommunicationAlarm
Severity
Minor
ProbableCause CommunicationsProtocolError
5.47 EOSMULTIPLE End Of Sequence (EOS) More than one Virtual Container (VC) belonging to the Virtual Concatenation Group (VCG) received EOS. SpecificProblem EOSMULTIPLE Source
VCG/LCAS NonStandard Alarms
AlarmType
CommunicationAlarm
http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
47/219
14/08/2015
Alarm Descriptions
Severity
Minor
ProbableCause CommunicationsProtocolError
5.48 Equipment Error or No Holdover Capable Board Provider SpecificProblem Equipment error or no holdover capable board provider Source
NE
AlarmType
CommunicationAlarm
Severity
Critical
ProbableCause ClockSynchronisationProblem
5.49 ES 15 Min Threshold Crossing Errored Seconds (ES) The Plesiochronous Digital Hierarchy (PDH) ES counter threshold, set for 15 min time window, is crossed the last 15 minutes. An Errored Second is a onesecond period with one or more errored blocks, or at least one defect. Applicable for RAU IF (1+0). Applicable for SWITCH (1+1). SpecificProblem ES 15 min threshold crossing Source
RAU IF (1+0) SWITCH
AlarmType
QualityOfServiceAlarm
Severity
Minor
ProbableCause ThresholdCrossed 5.49.1 Consequences This alarm indicates degraded traffic. If the problem continues, it can lead to SES 15 min threshold crossing, see Section 5.216. 5.49.2 Corrective Actions The problem can be temporary, but if the alarm continues over consecutive 15 min intervals, try the following actions: 1. Check if obstacles are placed in the radio path between the two hops' antennas (at clear sky conditions). 2. Verify that the received signal power is as expected (by performing a link budget calculation). 3. Check that no interference signal is present. 4. Replace the MMU, see Replacing an MMU, Reference [13] or Replacing an MMU2 CS, Reference [14]. 5. Replace the RAU, see Replacing a Radio Unit, Reference [16]. http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
48/219
14/08/2015
Alarm Descriptions
5.49.3 Alarm Clearance The alarm is cleared at the next 15 minutes interval where the ES counter threshold no longer is crossed.
5.50 ES 24 h Threshold Crossing Errored Seconds (ES) The Plesiochronous Digital Hierarchy (PDH) ES counter threshold, set for 24 h time window, is crossed the last 24 hours. An Errored Second is a onesecond period with one or more errored blocks, or at least one defect. Applicable for RAU IF (1+0). Applicable for SWITCH (1+1). SpecificProblem ES 24 h threshold crossing Source
RAU IF (1+0) SWITCH
AlarmType
QualityOfServiceAlarm
Severity
Minor
ProbableCause ThresholdCrossed 5.50.1 Consequences This alarm indicates degraded traffic. If the problem continues, it can lead to SES 24 h threshold crossing, see Section 5.217. 5.50.2 Corrective Actions The problem can be temporary, but if the alarm continues over consecutive 24 h intervals, try the following actions: 1. Check if obstacles are placed in the radio path between the two hops' antennas (at clear sky conditions). 2. Verify that the received signal power is as expected (by performing a link budget calculation). 3. Check that no interference signal is present. 4. Replace the MMU, see Replacing an MMU, Reference [13] or Replacing an MMU2 CS, Reference [14]. 5. Replace the RAU, see Replacing a Radio Unit, Reference [16]. 5.50.3 Alarm Clearance The alarm is cleared at the next 24 hours interval where the ES counter threshold no longer is crossed.
5.51 Ethernet Down (Critical) Problem has been detected on the L1 caused by Ethernet carrier not detected. This alarm can be caused by an Ethernet cable problem, configuration error or power down on the connected device. http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
49/219
14/08/2015
Alarm Descriptions
SpecificProblem Ethernet down Source
Bridge
Ethernet Bridge LAN
AlarmType
CommunicationAlarm
Severity
Critical
ProbableCause Unavailable 5.51.1 Consequences No Carrier Detected on the Ethernet Port. No Ethernet connection. 5.51.2 Corrective Actions
http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
50/219
14/08/2015
Alarm Descriptions
Figure 5 Workflow for Ethernet Down Alarm Corrective Actions Try the following: 1. Make sure that the administrative status is set to Up on the appropriate port for the ETU or the NPU. 2. Onsite action: Check that the Ethernet cable connected to the appropriate port is not damaged. 3. Onsite action: Perform a cold restart of the ETU or the NPU. 4. Onsite action: Replace the ETU or the NPU. Describe the fault on the Blue Tag and send it to the Repair Center together with the faulty ETU or NPU. For more information on how to replace the ETU, see Replacing an LTU, ETU, or SAU3, Reference [12]. http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
51/219
14/08/2015
Alarm Descriptions
For more information on how to replace the NPU, see Replacing an NPU, Reference [15]. 5.51.3 Alarm Clearance The alarm is cleared when a carrier is detected on the Ethernet port.
5.52 EXC In case of Poisson distribution of errors assumed, the Bit Error Ratio (BER) exceeds the threshold for excessive errors. SpecificProblem EXC Source
AU4 MS TU3
TU12 VC3 VC4 VC12
AlarmType
CommunicationAlarm
Severity
Major
ProbableCause ExcessiveBitErrorRate 5.52.1 Consequences Service unavailable. 5.52.2 Corrective Actions This is a transmission error. The alarm ceases if the alarm condition ceases. That is, check the cause for this situation on the link.
5.53 Excessive Temperature The unit reaches an excessive temperature. This can be caused by fan failure, too high ambient temperature, component failure, or air flow blocking. SpecificProblem Excessive Temperature Source
Plugin Unit
AlarmType
EquipmentAlarm
Severity
Critical
ProbableCause HighTemperature 5.53.1 Consequences
http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
52/219
14/08/2015
Alarm Descriptions
Both control and traffic functions are shut down (operational status Out of Service) to reduce dissipated power to a minimum. This is done to avoid permanent damage. 5.53.2 Corrective Actions Try the following: Check that the fan is working properly, see LED Descriptions, , Reference [6]. Check the ambient temperature and take measures if it is too high. Check for component failure alarms and take care of any problems. Make sure that the air flow is not blocked. 5.53.3 Alarm Clearance The alarm is cleared when the temperature goes below the high temperature threshold for the plugin unit.
5.54 EXM Extended Header Identifier Mismatch (EXM) The Extended Header Identifier (EXI) field in a received frame does not match the configured value. SpecificProblem EXM Source
GFP
AlarmType
CommunicationAlarm
Severity
Major
ProbableCause PayloadTypeMismatch
5.55 Failed Logon Attempt The alarm is raised if there are three consecutive failed logon attempts. SpecificProblem Security issue on logon Source
NE
AlarmType
CommunicationAlarm
Severity
Warning
ProbableCause ConnectionEstablishmentError 5.55.1 Consequences The alarm can be an indication of a potential security threat. 5.55.2 Corrective Actions If necessary, disable local access to the NE. 5.55.3 Alarm Clearance The alarm is cleared either manually in MINILINK Craft or automatically after a warm or cold restart. http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
53/219
14/08/2015
Alarm Descriptions
5.56 FAL License Missing (Major) A license for a license controlled feature, with the specified product number, is missing. The NE is in an unlocked period or the license controlled feature is not locked. SpecificProblem FAL License Missing Source
NE
AlarmType
Operational Violation
Severity
Major
ProbableCause DenialOfService 5.56.1 Consequences A warning is issued on the Licenses page in MINILINK Craft. 5.56.2 Corrective Actions Install the corresponding license for the license controlled feature by following the instructions in Installing and Managing Licenses, Reference [4]. 5.56.3 Alarm Clearance The alarm is cleared as soon as the corresponding license is installed.
5.57 FAL License Missing (Critical) A license for a license controlled feature, with the specified product number, is missing. The NE is in locked period and the license controlled feature is locked. SpecificProblem FAL License Missing Source
NE
AlarmType
Operational Violation
Severity
Critical
ProbableCause DenialOfService 5.57.1 Consequences An error is issued on the Licenses page in MINILINK Craft. 5.57.2 Corrective Actions Install the corresponding license for the license controlled feature by following the instructions in Installing and Managing Licenses, Reference [4]. 5.57.3 Alarm Clearance The alarm is cleared as soon as the corresponding license is installed or when entering an unlocked period. Entering an unlocked period is possible in one of the following ways: Usertriggered unlock. http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
54/219
14/08/2015
Alarm Descriptions
Upgrading from an unlocked mode SW release to a locked mode SW release, that is, upgrading from releases before MINILINK TN 5.3 to MINILINK TN 5.3 or later release. Upgrading from a locked mode SW release to a new main locked mode SW release.
5.58 File Integrity Violation (Warning) The alarm is raised if the internal files of the NE are modified. For more information about the alarm cause and the applied severity, see the File Integrity Violation report. SpecificProblem File Integrity Violation Source
NE
AlarmType
EnvironmentalAlarm
Severity
Warning
ProbableCause FileError 5.58.1 Alarm Clearance The alarm is cleared and the file integrity monitoring function is also disabled when the File Integrity Violation is not selected on the Security – Alarm Handling page in MINILINK Craft or when the CLI command set‐file‐integrity‐alarm off is used.
5.59 File Integrity Violation (Minor) The alarm is raised if the internal files of the NE are modified. For more information about the alarm cause and the applied severity, see the File Integrity Violation report. SpecificProblem File Integrity Violation Source
NE
AlarmType
EnvironmentalAlarm
Severity
Minor
ProbableCause FileError 5.59.1 Alarm Clearance The alarm is cleared and the file integrity monitoring function is also disabled when the File Integrity Violation is not selected on the Security – Alarm Handling page in MINILINK Craft or when the CLI command set‐file‐integrity‐alarm off is used.
5.60 File Integrity Violation (Major) The alarm is raised if the internal files of the NE are modified. For more information about the alarm cause and the applied severity, see the File Integrity Violation report. SpecificProblem File Integrity Violation Source
NE
http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
55/219
14/08/2015
Alarm Descriptions
AlarmType
EnvironmentalAlarm
Severity
Major
ProbableCause FileError 5.60.1 Alarm Clearance The alarm is cleared and the file integrity monitoring function is also disabled when the File Integrity Violation is not selected on the Security – Alarm Handling page in MINILINK Craft or when the CLI command set‐file‐integrity‐alarm off is used.
5.61 File Integrity Violation (Critical) The alarm is raised if the internal files of the NE are modified. For more information about the alarm cause and the applied severity, see the File Integrity Violation report. SpecificProblem File Integrity Violation Source
NE
AlarmType
EnvironmentalAlarm
Severity
Critical
ProbableCause FileError 5.61.1 Alarm Clearance The alarm is cleared and the file integrity monitoring function is also disabled when the File Integrity Violation is not selected on the Security – Alarm Handling page in MINILINK Craft or when the CLI command set‐file‐integrity‐alarm off is used.
5.62 FOPR Failure on Protocol Receive (FOPR) One or more Link Capacity Adjustment Scheme (LCAS) control packets with CRC (Cyclic Redundancy Check) error is received on any of the Virtual Containers (VCs) belonging to the Virtual Concatenation Group (VCG). SpecificProblem FOPR Source
VCG/LCAS Standard Alarms
AlarmType
CommunicationAlarm
Severity
Minor
ProbableCause CommunicationsProtocolError 5.62.1 Corrective Actions Perform the following actions: 1. Check the Bit Error Ratio (BER), see Troubleshooting, Reference [22]. 2. Check the source.
http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
56/219
14/08/2015
Alarm Descriptions
5.63 Free Running Mode Entered The network synchronization function enters the free running status. SpecificProblem Free running mode entered Source
NE
AlarmType
CommunicationAlarm
Severity
Critical
ProbableCause LossOfSynchronisation 5.63.1 Consequences The synchronization output signal is squelched or the appropriate Synchronization Status Message (SSM) value is propagated on interfaces supporting SSM. 5.63.2 Corrective Actions No action required. 5.63.3 Alarm Clearance The alarm is cleared when the network synchronization function enters locked status.
5.64 GIDERR Group ID Error (GIDERR) Active channels (VCs) in a Virtual Concatenation Group (VCG) have a different Group ID. SpecificProblem GIDERR Source
VCG/LCAS Standard Alarms
AlarmType
CommunicationAlarm
Severity
Minor
ProbableCause CommunicationsProtocolError 5.64.1 Corrective Actions Check the source.
5.65 Group Timing Mismatch The farend transmit clock is different from the nearend transmit clock mode. Since the AAU supports only the Common Transmit Clock (CTC) it is likely that the farend transmit clock has been set to the ITC. SpecificProblem Group Timing Mismatch Source
IMA Group
AlarmType
CommunicationAlarm
Severity
Critical
http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
57/219
14/08/2015
Alarm Descriptions
5.65.1 Consequences No Asynchronous Transfer Mode (ATM) traffic can be transmitted over the specific Inverse Multiplexer over ATM (IMA) group before both the nearend and farend groups become operational. 5.65.2 Alarm Analysis The farend transmit clock could be set in ITC mode instead of CTC, which is the only mode supported by the AAU. 5.65.3 Corrective Actions Check if the farend transmit clock is set to CTC. 5.65.4 Alarm Clearance The alarm is cleared when both the nearend and farend are configured with the same transmit clock mode (CTC).
5.66 Hardware Error: FAU Fan Unit (FAU) A malfunction related to hardware. SpecificProblem Hardware Error Source
FAU
AlarmType
EquipmentAlarm
Severity
Critical
ProbableCause CoolingFanFailure 5.66.1 Consequences A hardware error on the FAU may additionally result in malfunction due to High Temperature (see Section 5.77) or Excessive Temperature (see Section 5.53) in other units in the NE. 5.66.2 Corrective Actions
http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
58/219
14/08/2015
Alarm Descriptions
Figure 6 Workflow for Hardware Error: FAU Alarm Corrective Actions Note: To clear the alarm, perform all the corrective actions below onsite.
Do the following: 1. Verify that the FAU is correctly mounted in the AMM. 2. If the FAU is fed with a separate power supply cable, verify that the cable is correctly connected and that it supplies the correct power according to FAU requirement. 3. Replace the FAU, see Replacing a Fan Unit, Reference [11].
http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
59/219
14/08/2015
Alarm Descriptions
5.66.3 Alarm Clearance The alarm is cleared when a working FAU is installed.
5.67 Hardware Error: Plugin Unit (Minor) A control system failure related to hardware error. SpecificProblem Hardware Error Source
Plugin Unit
AlarmType
EquipmentAlarm
Severity
Minor
ProbableCause ReplaceableUnitProblem 5.67.1 Consequences Not possible to manage the Plugin Unit (PIU). 5.67.2 Corrective Actions
Figure 7 Workflow for Hardware Error: Plugin Unit Alarm Corrective Actions http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
60/219
14/08/2015
Alarm Descriptions
Try the following: 1. Perform a cold restart of the PIU.
Caution! A cold restart will disturb the traffic. Onsite action: If Hardware Error alarm is not cleared, replace the PIU. Describe the fault on the Blue Tag and send it to the Repair Center together with the faulty PIU. Onsite action: If Hardware Error alarm is cleared, monitor the PIU for further Hardware Error alarms. If the alarm is raised again, replace the PIU. Describe the fault on the Blue Tag and send it to the Repair Center together with the faulty PIU. For more information on how to replace the faulty PIU, see applicable CPI under HW Management folder. 5.67.3 Alarm Clearance The alarm is cleared when it is possible to manage the PIU.
5.68 Hardware Error: Plugin Unit (Major) A traffic or power system failure related to hardware error. Applicable for the standby terminal in a 1+1 configuration. SpecificProblem Hardware Error Source
Plugin Unit
AlarmType
EquipmentAlarm
Severity
Major
ProbableCause ReplaceableUnitProblem 5.68.1 Consequences The Plugin Unit (PIU) is not working. 5.68.2 Corrective Actions
http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
61/219
14/08/2015
Alarm Descriptions
Figure 8 Workflow for Hardware Error: Plugin Unit Alarm Corrective Actions Try the following: 1. Perform a cold restart of the PIU.
Caution! A cold restart will disturb the traffic. Onsite action: If Hardware Error alarm is not cleared, replace the PIU. Describe the fault on the Blue Tag and send it to the Repair Center together with the faulty PIU. Onsite action: If Hardware Error alarm is cleared, monitor the PIU for further Hardware Error alarms. If the alarm is raised again, replace the PIU. Describe the fault on the Blue Tag and send it to the Repair Center together with the faulty PIU. For more information on how to replace the faulty PIU, see applicable CPI under HW Management folder.
5.69 Hardware Error: Plugin Unit (Critical) A traffic or power system failure related to hardware error. http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
62/219
14/08/2015
Alarm Descriptions
Applicable for 1+0 configuration and for the active terminal in a 1+1 configuration. SpecificProblem Hardware Error Source
Plugin Unit
AlarmType
EquipmentAlarm
Severity
Critical
ProbableCause ReplaceableUnitProblem 5.69.1 Consequences The Plugin Unit (PIU) is not working. 5.69.2 Corrective Actions
Figure 9 Workflow for Hardware Error: Plugin Unit Alarm Corrective Actions Try the following: 1. Perform a cold restart of the PIU.
http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
63/219
14/08/2015
Alarm Descriptions
Caution! A cold restart will disturb the traffic. Onsite action: If Hardware Error alarm is not cleared, replace the PIU. Describe the fault on the Blue Tag and send it to the Repair Center together with the faulty PIU. Onsite action: If Hardware Error alarm is cleared, monitor the PIU for further Hardware Error alarms. If the alarm is raised again, replace the PIU. Describe the fault on the Blue Tag and send it to the Repair Center together with the faulty PIU. For more information on how to replace the faulty PIU, see applicable CPI under HW Management folder.
5.70 Hardware Error: RAU The RAU has a hardware error. SpecificProblem Hardware Error Source
RAU
AlarmType
EquipmentAlarm
Severity
Critical
ProbableCause ReplaceableUnitProblem 5.70.1 Consequences Traffic Loss. 5.70.2 Corrective Actions
http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
64/219
14/08/2015
Alarm Descriptions
Figure 10 Workflow for Hardware Error: RAU Alarm Corrective Actions Do the following: 1. Perform a cold restart of the RAU and restart MINILINK Craft.
Caution! A cold restart will disturb the traffic. Onsite action: If the Hardware Error alarm is not cleared after the restart, replace the RAU. Describe the fault on the Blue Tag and send it to the Repair Center together with the faulty RAU. Onsite action: If the Hardware Error alarm is cleared, monitor the RAU for further Hardware Error alarms. If the alarm is raised again, replace the RAU. Describe the fault on the Blue Tag and send it to the Repair Center together with the faulty RAU. For more information on how to replace the RAU, see Replacing a Radio Unit, Reference [16].
5.71 Hardware Error: SFP (Critical) The SFP module has a hardware error and must be replaced. Applicable for 1+0 configuration and for http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
65/219
14/08/2015
Alarm Descriptions
the active terminal in a 1+1 configuration. SpecificProblem Hardware Error at Source
SFP
AlarmType
EquipmentAlarm
Severity
Critical
ProbableCause ReplaceableUnitProblem 5.71.1 Consequences Traffic Loss. 5.71.2 Corrective Actions
Figure 11 Workflow for Hardware Error: SFP Alarm Corrective Actions Note: To clear the alarm, perform the corrective action below onsite.
Replace the SFP module, see Replacing an SFP, Reference [18].
5.72 HCC Hop Communication Channel (HCC) Communication is lost on the HCC, between the MMU and the farend MMU. SpecificProblem HCC Source
All MMUs
AlarmType
CommunicationAlarm
Severity
Major
http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
66/219
14/08/2015
Alarm Descriptions
ProbableCause Unavailable 5.72.1 Consequences It is not possible to access the Far End. 5.72.2 Corrective Actions
Figure 12 Workflow for HCC Alarm Corrective Actions, Part 1
http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
67/219
14/08/2015
Alarm Descriptions
Figure 13 Workflow for HCC Alarm Corrective Actions, Part 2
http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
68/219
14/08/2015
Alarm Descriptions
Figure 14 Workflow for HCC Alarm Corrective Actions, Part 3
http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
69/219
14/08/2015
Alarm Descriptions
Figure 15 Workflow for HCC Alarm Corrective Actions, Part 4 Perform the following steps: 1. Make sure that the configuration of the nearend and the farend is according to the Site Installation Documentation (SID). If the configuration of the nearend and the farend is according to the SID, go to Step 2. If the configuration of the nearend and the farend is not according to the SID, take corrective actions. If the HCC alarm is not cleared after the correction, go to Step 2. 2. Check the RF input level. If the RF input level is according to the link budget, go Step 3. If the RF input level is not according to the link budget, go to Step 4. http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
70/219
14/08/2015
Alarm Descriptions
If the RF input level is above 30 dBm, consult network design department to address upfading. 3. Perform a cold restart of the MMU and restart MINILINK Craft.
Caution! A cold restart will disturb the traffic. If the HCC alarm is cleared after the restart, monitor the hop for further HCC alarms. If the HCC alarm reoccurs, go to Step 13. If the HCC alarm is not cleared after the restart, go to Step 13. 4. Make sure that the RF output level of the nearend and the farend is according to the link budget planning. If the RF output level of the nearend and the farend is according to the link budget planning, go to Step 5. If the RF output level of the nearend and the farend is not according to the link budget planning, consult the transmission design department for corrective actions. 5. Check if the RF input level is below the threshold level for BER 106 for the current configuration. If the RF input level is below the threshold level for BER 106 for the current configuration, go to Step 6. If the RF input level is not below the threshold level for BER 106 for the current configuration, go to Step 13. 6. Onsite action: Perform an RF loop test on the nearend RAU. Turn off the RAU transmitter on the farend during the test. If the RF input power is about 50 dBm (± 10 dB) on the nearend RAU during the test, go to Step 7. If the RF input power is not about 50 dBm (± 10 dB) on the nearend RAU during the test, replace the RAU on the nearend. Describe the fault on the Blue Tag and send it to the Repair Center together with the faulty RAU. Note: HCC alarms will be automatically masked during an RF loop test, that is, HCC alarm disappears during the loop test. The RF loop test cannot be used to define the faulty unit. The RF loop test only shows if the RF input level is correct.
7. Check if RF Output Level alarm is active on the farend RAU. Onsite action: If the RF Output Level alarm is active, replace the RAU on the farend. Describe the fault on the Blue Tag and send it to the Repair Center together with the faulty RAU. If the RF Output Level alarm is not active, go to Step 8. 8. Onsite action: Check fading conditions and weather circumstances. If link performance is affected by propagation issues, consult the transmission design department on how to address the link budget. If link performance is not affected by propagation issues, go to Step 9. 9. Onsite action: Check for possible obstacles interfering with the line of sight. If there are obstacles, consult the transmission design department. http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
71/219
14/08/2015
Alarm Descriptions
If there are no obstacles, go to Step 10. 10. Onsite action: Make sure the antennas are aligned correctly on the nearend and the farend to meet the link budget target. If the antennas are aligned correctly, go to Step 11. If the antennas are not aligned correctly, take corrective actions. 11. Check the status of the RF input level, that can be stable or can vary over time indicating multipath fading. If you are unsure, monitor the RF input level for 24 hours to find cyclic variations. If the RF input level is stable, go to Step 12. If the RF input level decrease is intermittent or periodic, consult the transmission design department to analyze the possible multipath fading. 12. Onsite action: Perform an RF loop test on the farend RAU. Turn off the RAU transmitter on the nearend during the test. If the RF input power is about 50 dBm (± 10 dB) on the farend RAU during the test, go to Step 17. If the RF input power is not about 50 dBm (± 10 dB) on the farend RAU during the test, replace the RAU on the farend. Describe the fault on the Blue Tag and send it to the Repair Center together with the faulty RAU. Note: HCC alarms will be automatically masked during an RF loop test, that is, HCC alarm disappears during the loop test. The RF loop test cannot be used to define the faulty unit. The RF loop test only shows if the RF input level is correct.
13. Onsite action: Perform an interference test, see Verifying an Installation, Reference [24]. Record the highest received RF input level while scanning the whole bandwidth and compare it to the acceptable interference values. If the received RF input level exceeds the defined value, consult the transmission design department. If the received RF input level does not exceed the defined value, go to Step 14. 14. Onsite action: Replace the MMU on the nearend. If the HCC alarm is cleared after the replacement, describe the fault on the Blue Tag and send it to the Repair Center together with the faulty MMU. If the HCC alarm is not cleared after the replacement, reuse the initial MMU, and go to Step 15. 15. Onsite action: Replace the MMU on the farend. If the HCC alarm is cleared after the replacement, describe the fault on the Blue Tag and send it to the Repair Center together with the faulty MMU. If the HCC alarm is not cleared after the replacement, reuse the initial MMU, and go to Step 16. 16. Onsite action: Replace the RAU on the nearend. If the HCC alarm is cleared after the replacement, describe the fault on the Blue Tag and send it to the Repair Center together with the faulty RAU. If the HCC alarm is not cleared after the replacement, reuse the initial RAU, and go to Step 17. 17. Onsite action: Replace the RAU on the farend. If the HCC alarm is cleared after the replacement, describe the fault on the Blue Tag and send it to the Repair Center together with the faulty RAU. http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
72/219
14/08/2015
Alarm Descriptions
If the HCC alarm is not cleared after the replacement, reuse the initial RAU, and go to Step 18. 18. Onsite action: Make sure that the polarization on the nearend and the farend is set according to the link budget planning. If the polarization on the nearend and the farend is correctly set, go to Step 19. If the polarization on the nearend and the farend is not correctly set, take corrective actions. 19. Onsite action: Replace the antenna on the nearend. If the HCC alarm is cleared after the replacement, describe the fault on the Blue Tag and send it to the Repair Center together with the faulty antenna. If the HCC alarm is not cleared after the replacement, reinstall the initial antenna, and go to Step 20. 20. Onsite action: Replace the antenna on the farend. Describe the fault on the Blue Tag and send it to the Repair Center together with the faulty antenna. For more information on how to replace the RAU, see Replacing a Radio Unit, Reference [16]. For more information on antenna alignment and antenna installation, see Installing Outdoor Equipment, Reference [5]. For more information on how to replace the MMU, see Replacing an MMU, Reference [13]. 5.72.3 Alarm Clearance The alarm is cleared when access to the Far End is recovered.
5.73 High BER (Major) Bit Error Ratio (BER) The threshold for Synchronous Digital Hierarchy (SDH) High BER is passed (BER threshold level). Probable causes are the following: Fading (flat or selective) Bad antenna alignment Link budget calculation not correct Presence of Interferers SpecificProblem High BER Source
RAU IF (1+1)
AlarmType
CommunicationAlarm
Severity
Major
ProbableCause DegradedSignal 5.73.1 Consequences The Radio Protection Switch selects the other demodulation path if its signal quality is better. 5.73.2 Corrective Actions Note: Make sure that the Switch Mode is set to Manual on both the nearend and the farend http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
73/219
14/08/2015
Alarm Descriptions
terminal before troubleshooting. Perform all the actions on the active unit. Set Switch Mode to Auto once the troubleshooting is completed.
Perform the following actions: 1. Verify that the RF input power on the receiving RAU is at least 5 dB above the threshold for BER 106 for the current configuration. See link budget calculation for the correct level. If the RF input power is not at least 5 dB above the threshold, go to Step 2. If the RF input power is at least 5 dB above the threshold, go to Step 12. 2. Perform an RF loop test on the nearend RAU. Turn off the RAU transmitter on the farend during the test. If the RF input power is not about 50 dBm (± 10 dB) during the test, replace the RAU on the nearend. Describe the fault on the Blue Tag and send it to the Repair Center together with the faulty RAU. If the RF input power is about 50 dBm (± 10 dB) during the test, go to Step 3. 3. Check fading conditions and weather circumstances. If link performance is not affected by propagation issues, go to Step 4. If link performance is affected by propagation issues, consult the transmission design department on how to address the link budget. 4. Check the alarms and status of the farend terminal. If there are no alarms raised on the farend terminal, go to Step 5. If there are alarms raised on the farend terminal, find the root causes of these alarms first, and take corrective actions according to the alarm description. If the BER alarm is still raised on the nearend terminal after clearing the alarms on the farend terminal, go to Step 5. 5. Verify that the nearend terminal configuration matches the farend terminal configuration. If the configuration is not correct, reconfigure the nearend terminal and the farend terminal according to the Site Installation Documentation (SID). If the configuration is correct, go to Step 6. 6. Perform an RF loop test on the farend RAU. Turn off the RAU transmitter on the nearend during the test. If the RF input power is not about 50 dBm (± 10 dB) during the test, replace the RAU on the farend. Describe the fault on the Blue Tag and send it to the Repair Center together with the faulty RAU. If the RF input power is about 50 dBm (± 10 dB) during the test, go to Step 7. 7. Check for possible obstacles interfering with the line of sight and check that the antennas are mounted at the correct height according to the link budget. If there are obstacles or the antennas are not mounted at the correct height, consult the network design department to review the link budget planning. If there are no obstacles in the line of sight and the antennas are mounted at the correct height, go to Step 8. 8. Make sure the antennas are aligned correctly on the nearend and the farend to meet the link budget target. If the antennas are not aligned correctly, take corrective actions. If the antennas are aligned correctly, go to Step 9. 9. Verify that the RAUs are correctly mounted on the antennas, that any flexible waveguides are http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
74/219
14/08/2015
Alarm Descriptions
not damaged, and that correct polarization is set on both sides of the hop. If you find any problem, take corrective actions. If you do not find any problems, go to Step 10. 10. Replace the antenna on the nearend. If the BER alarm is not cleared after the replacement, reinstall the initial antenna and go to Step 11. If the BER alarm is cleared after the replacement, describe the fault on the Blue Tag and send it to the Repair Center together with the faulty antenna. 11. Replace the antenna on the farend. Describe the fault on the Blue Tag and send it to the Repair Center together with the faulty antenna. 12. Verify that the nearend terminal configuration matches the farend terminal configuration. If the configuration is not correct, reconfigure the nearend terminal and the farend terminal according to the Site Installation Documentation (SID). If the configuration is correct, go to Step 13. 13. Perform a cold restart of the MMU and the RAU on the nearend. Restart MINILINK Craft.
Caution! A cold restart will disturb the traffic. If the BER alarm is not cleared after the restart, go to Step 14. If the BER alarm is cleared after the restart, monitor the hop for further BER alarms. If the alarm is raised again while the RF input level is higher than the threshold level for BER 106 for the current configuration, go to Step 14. 14. Perform an IF loop test on the nearend MMU. If the BER alarm is not cleared during the test, replace the MMU on the nearend. Describe the fault on the Blue Tag and send it to the Repair Center together with the faulty MMU. If the BER alarm is cleared during the test, go to Step 15. 15. Perform an RF loop test on the nearend RAU. Turn off the RAU transmitter on the farend during the test. If the BER alarm is not cleared during the test, go to Step 23. If the BER alarm is cleared during the test, go to Step 16. 16. Check the alarms and status of the farend terminal. If there are no alarms raised on the farend terminal, go to Step 17. If there are alarms raised on the farend terminal, find the root causes of these alarms first, and take corrective actions according to the alarm description. If the BER alarm is still raised on the nearend terminal after clearing the alarms on the farend terminal, go to Step 17. 17. Perform an RX loop test on the farend. If the BER alarm is not cleared during the test, go to Step 18. If the BER alarm is cleared, review the quality of the incoming traffic on the farend MMU line side. 18. Perform an interference test, see Verifying an Installation, Reference [24]. If there is no interference during the test, go to Step 19. http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
75/219
14/08/2015
Alarm Descriptions
If there is any interference during the test, consult the transmission design department to review network planning and link budget. 19. Replace the MMU on the farend. If the BER alarm is not cleared on the nearend after the replacement, reuse the initial MMU on the farend, and go to Step 20. If the BER alarm is cleared on the nearend after the replacement, describe the fault on the Blue Tag and send it to the Repair Center together with the faulty MMU. 20. Replace the RAU on the farend. If the BER alarm is not cleared on the nearend after the replacement, reuse the initial RAU on the farend, and go to Step 21. If the BER alarm is cleared on the nearend after the replacement, describe the fault on the Blue Tag and send it to the Repair Center together with the faulty RAU. 21. Check the radio cable for interference on the IF signal between the MMU and the RAU on the farend terminal with a SiteMaster or a Spectrum Analyzer. Make sure that there is no interference in the frequency range of 0–400 MHz. If there is no interference, go to Step 22. If there is any interference, check the cables for damages and replace the cables if needed. Monitor the interfering source and remove it if possible, or reroute the IF cables not to be disturbed by the interfering source. 22. Replace the radio cables and the connectors between the MMU and the RAU on the farend terminal. 23. Replace the RAU on the nearend. If the BER alarm is not cleared on the nearend after the replacement, reuse the initial RAU, and go to Step 24. If the BER alarm is cleared on the nearend after the replacement, describe the fault on the Blue Tag and send it to the Repair Center together with the faulty RAU. 24. Check the radio cable for interference on the IF signal between the MMU and the RAU on the nearend terminal with a SiteMaster or a Spectrum Analyzer. Make sure that there is no interference in the frequency range of 0–400 MHz. If there is no interference, go to Step 25. If there is any interference, check the cables for damages and replace the cables if needed. Monitor the interfering source and remove it if possible, or reroute the IF cables not to be disturbed by the interfering source. 25. Replace the radio cables and the connectors between the MMU and the RAU on the farend terminal. For more information on how to replace the RAU, see Replacing a Radio Unit, Reference [16]. For more information on antenna alignment and antenna installation, see Installing Outdoor Equipment, Reference [5]. For more information on how to replace the MMU, see Replacing an MMU, Reference [13]. 5.73.3 Alarm Clearance The alarm is cleared when the BER estimation is below the threshold.
5.74 High BER (Critical) Bit Error Ratio (BER) http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
76/219
14/08/2015
Alarm Descriptions
The threshold for Synchronous Digital Hierarchy (SDH) High BER is passed (BER threshold level). Probable causes for this are: Fading (flat or selective) Bad antenna alignment Link budget calculation not correct Presence of Interferers SpecificProblem High BER Source
RAU IF (1+0)
AlarmType
CommunicationAlarm
Severity
Critical
ProbableCause DegradedSignal 5.74.1 Consequences Degradation of the quality of the traffic signal line side. 5.74.2 Corrective Actions Perform the following actions: 1. Verify that the RF input power on the receiving RAU is at least 5 dB above the threshold for BER 106 for the current configuration. See link budget calculation for the correct level. If the RF input power is not at least 5 dB above the threshold, go to Step 2. If the RF input power is at least 5 dB above the threshold, go to Step 12. 2. Perform an RF loop test on the nearend RAU. Turn off the RAU transmitter on the farend during the test. If the RF input power is not about 50 dBm (± 10 dB) during the test, replace the RAU on the nearend. Describe the fault on the Blue Tag and send it to the Repair Center together with the faulty RAU. If the RF input power is about 50 dBm (± 10 dB) during the test, go to Step 3. 3. Check fading conditions and weather circumstances. If link performance is not affected by propagation issues, go to Step 4. If link performance is affected by propagation issues, consult the transmission design department on how to address the link budget. 4. Check the alarms and status of the farend terminal. If there are no alarms raised on the farend terminal, go to Step 5. If there are alarms raised on the farend terminal, find the root causes of these alarms first, and take corrective actions according to the alarm description. If the BER alarm is still raised on the nearend terminal after clearing the alarms on the farend terminal, go to Step 5. 5. Verify that the nearend terminal configuration matches the farend terminal configuration. If the configuration is not correct, reconfigure the nearend terminal and the farend terminal according to the Site Installation Documentation (SID). If the configuration is correct, go to Step 6. 6. Perform an RF loop test on the farend RAU. Turn off the RAU transmitter on the nearend during the test. http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
77/219
14/08/2015
Alarm Descriptions
If the RF input power is not about 50 dBm (± 10 dB) during the test, replace the RAU on the farend. Describe the fault on the Blue Tag and send it to the Repair Center together with the faulty RAU. If the RF input power is about 50 dBm (± 10 dB) during the test, go to Step 7. 7. Check for possible obstacles interfering with the line of sight and check that the antennas are mounted at the correct height according to the link budget. If there are obstacles or the antennas are not mounted at the correct height, consult the network design department to review the link budget planning. If there are no obstacles in the line of sight and the antennas are mounted at the correct height, go to Step 8. 8. Make sure the antennas are aligned correctly on the nearend and the farend to meet the link budget target. If the antennas are not aligned correctly, take corrective actions. If the antennas are aligned correctly, go to Step 9. 9. Verify that the RAUs are correctly mounted on the antennas, that any flexible waveguides are not damaged, and that correct polarization is set on both sides of the hop. If you find any problem, take corrective actions. If you do not find any problems, go to Step 10. 10. Replace the antenna on the nearend. If the BER alarm is not cleared after the replacement, reinstall the initial antenna and go to Step 11. If the BER alarm is cleared after the replacement, describe the fault on the Blue Tag and send it to the Repair Center together with the faulty antenna. 11. Replace the antenna on the farend. Describe the fault on the Blue Tag and send it to the Repair Center together with the faulty antenna. 12. Verify that the nearend terminal configuration matches the farend terminal configuration. If the configuration is not correct, reconfigure the nearend terminal and the farend terminal according to the Site Installation Documentation (SID). If the configuration is correct, go to Step 13. 13. Perform a cold restart of the MMU and the RAU on the nearend. Restart MINILINK Craft.
Caution! A cold restart will disturb the traffic. If the BER alarm is not cleared after the restart, go to Step 14. If the BER alarm is cleared after the restart, monitor the hop for further BER alarms. If the alarm is raised again while the RF input level is higher than the threshold level for BER 106 for the current configuration, go to Step 14. 14. Perform an IF loop test on the nearend MMU. If the BER alarm is not cleared during the test, replace the MMU on the nearend. Describe the fault on the Blue Tag and send it to the Repair Center together with the faulty MMU. If the BER alarm is cleared during the test, go to Step 15. 15. Perform an RF loop test on the nearend RAU. Turn off the RAU transmitter on the farend during the test. http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
78/219
14/08/2015
Alarm Descriptions
If the BER alarm is not cleared during the test, go to Step 23. If the BER alarm is cleared during the test, go to Step 16. 16. Check the alarms and status of the farend terminal. If there are no alarms raised on the farend terminal, go to Step 17. If there are alarms raised on the farend terminal, find the root causes of these alarms first, and take corrective actions according to the alarm description. If the BER alarm is still raised on the nearend terminal after clearing the alarms on the farend terminal, go to Step 17. 17. Perform an RX loop test on the farend. If the BER alarm is not cleared during the test, go to Step 18. If the BER alarm is cleared, review the quality of the incoming traffic on the farend MMU line side. 18. Perform an interference test, see Verifying an Installation, Reference [24]. If there is no interference during the test, go to Step 19. If there is any interference during the test, consult the transmission design department to review network planning and link budget. 19. Replace the MMU on the farend. If the BER alarm is not cleared on the nearend after the replacement, reuse the initial MMU on the farend, and go to Step 20. If the BER alarm is cleared on the nearend after the replacement, describe the fault on the Blue Tag and send it to the Repair Center together with the faulty MMU. 20. Replace the RAU on the farend. If the BER alarm is not cleared on the nearend after the replacement, reuse the initial RAU on the farend, and go to Step 21. If the BER alarm is cleared on the nearend after the replacement, describe the fault on the Blue Tag and send it to the Repair Center together with the faulty RAU. 21. Check the radio cable for interference on the IF signal between the MMU and the RAU on the farend terminal with a SiteMaster or a Spectrum Analyzer. Make sure that there is no interference in the frequency range of 0–400 MHz. If there is no interference, go to Step 22. If there is any interference, check the cables for damages and replace the cables if needed. Monitor the interfering source and remove it if possible, or reroute the IF cables not to be disturbed by the interfering source. 22. Replace the radio cables and the connectors between the MMU and the RAU on the farend terminal. 23. Replace the RAU on the nearend. If the BER alarm is not cleared on the nearend after the replacement, reuse the initial RAU, and go to Step 24. If the BER alarm is cleared on the nearend after the replacement, describe the fault on the Blue Tag and send it to the Repair Center together with the faulty RAU. 24. Check the radio cable for interference on the IF signal between the MMU and the RAU on the nearend terminal with a SiteMaster or a Spectrum Analyzer. Make sure that there is no interference in the frequency range of 0–400 MHz. If there is no interference, go to Step 25. If there is any interference, check the cables for damages and replace the cables if needed. Monitor the interfering source and remove it if possible, or reroute the IF cables not to be disturbed by the interfering source. http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
79/219
14/08/2015
Alarm Descriptions
25. Replace the radio cables and the connectors between the MMU and the RAU on the farend terminal. For more information on how to replace the RAU, see Replacing a Radio Unit, Reference [16]. For more information on antenna alignment and antenna installation, see Installing Outdoor Equipment, Reference [5]. For more information on how to replace the MMU, see Replacing an MMU, Reference [13]. 5.74.3 Alarm Clearance The alarm is cleared when the BER estimation is below the threshold.
5.75 High DM RTT Delay The Delay Measurement (DM) Round Trip Time (RTT) Delay at the Nth percentile is above the configured threshold, where N can be configured between 1 and 100 (default value is 95). SpecificProblem High DM RTT delay Source
Session with MEP
AlarmType
QualityOfServiceAlarm
Severity
Major
ProbableCause ThresholdCrossed 5.75.1 Corrective Actions No corrective action is required.
5.76 High DM Variation RTT Delay The Delay Measurement Variation (DMV) Round Trip Time (RTT) Delay variation at the Nth percentile is above the configured threshold, where N can be configured between 1 and 100 (default value is 95). SpecificProblem High DM Variation RTT delay Source
Session with MEP
AlarmType
QualityOfServiceAlarm
Severity
Major
ProbableCause ThresholdCrossed 5.76.1 Corrective Actions No corrective action is required.
5.77 High Temperature: NPU The unit reaches an abnormal temperature. This can be caused by fan failure, too high ambient temperature, component failure, or air flow blocking.
http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
80/219
14/08/2015
Alarm Descriptions
SpecificProblem High Temperature Source
NPU
AlarmType
EquipmentAlarm
Severity
Critical
ProbableCause HighTemperature 5.77.1 Consequences The control system functions are shut down (operational status Reduced Service). This gives a graceful degradation through controlled protection switch in a 1+1. Alarms are sent in a 1+0, but the traffic is still active. 5.77.2 Corrective Actions Try the following: Check that the fan is working properly, see LED Descriptions, Reference [6]. Check the ambient temperature and take measures if it is too high. Check for component failure alarms and take care of any problems. Make sure that the air flow is not blocked. 5.77.3 Alarm Clearance The alarm is cleared when the temperature is stable for 60 seconds below the high temperature threshold for the plugin unit.
5.78 High Temperature: Plugin Unit The unit has reached an abnormal temperature. This can be caused by fan failure, too high ambient temperature, component failure, or air flow blocking. SpecificProblem High Temperature Source
Plugin Unit
AlarmType
EquipmentAlarm
Severity
Minor
ProbableCause HighTemperature 5.78.1 Consequences The control system functions are shut down (operational status Reduced Service). This gives a graceful degradation through controlled protection switch in a 1+1. Alarms are sent in a 1+0, but the traffic is still active. 5.78.2 Corrective Actions Try the following: Check that the fan is working properly, see LED Descriptions, Reference [6]. Check the ambient temperature and take measures if it is too high. http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
81/219
14/08/2015
Alarm Descriptions
Check for component failure alarms and take care of any problems. Make sure that the air flow is not blocked. 5.78.3 Alarm Clearance The alarm is cleared when the temperature is stable for 60 seconds below the high temperature threshold for the plugin unit.
5.79 Hitless Phase Failure of synchronizing of the received traffic in the two MMUs with a duration longer than the time given by Fade Notification Timer. SpecificProblem Hitless Phase Source
SWITCH
AlarmType
EquipmentAlarm
Severity
Warning
ProbableCause ProtectionPathFailure
5.80 Holdover Mode Entered The node enters Holdover mode due to loss of network synchronization reference. SpecificProblem Holdover mode entered Source
NE
AlarmType
CommunicationAlarm
Severity
Major
ProbableCause LossOfSynchronisation 5.80.1 Consequences When the node is in Holdover mode it has no network synchronization reference available. Synchronization output signals are squelched or the appropriate Synchronization Status Message (SSM) value is propagated on interfaces supporting SSM. 5.80.2 Corrective Actions If the node is in holdover mode for an extensive time, check the reason why the network synchronization is not available. If required, reconfigure the node to use another synchronization reference. 5.80.3 Alarm Clearance The alarm is cleared when the network synchronization function enters locked status.
5.81 ICC Internal Communication Channel (ICC) Communication is lost on the ICC, between two MMUs in the same terminal. http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
82/219
14/08/2015
Alarm Descriptions
Possible cause: the software or hardware of the MMUs is not compatible. SpecificProblem ICC Source
MMU2 B/C/E/F
AlarmType
CommunicationAlarm
Severity
Major
5.81.1 Consequences Unable to Protect. 5.81.2 Corrective Actions Try the following: 1. Check the software and hardware of the MMUs. 2. Upgrade software or replace one MMU to achieve compatibility. 5.81.3 Alarm Clearance The alarm is cleared when communication is recovered.
5.82 IEEE1588 Incompatible Hardware The alarm is raised if the NE has IEEE1588 configuration, but the Rstate of the NPU is not compatible with IEEE1588. SpecificProblem IEEE1588 Incompatible Hardware Source
NE
AlarmType
EquipmentAlarm
Severity
Critical
ProbableCause ReplaceableUnitTypeMismatch 5.82.1 Consequences The NE disables its IEEE1588 frequency and phase synchronization function. 5.82.2 Corrective Actions Replace the NPU with an NPU that supports IEEE1588. For more information, see Replacing an NPU, Reference [15]. For more information on feature and equipment compatibility, see the Compatibility document in the Planning folder of the MINILINK TN CPI library. 5.82.3 Alarm Clearance The alarm is cleared when the NPU is replaced with an NPU that supports IEEE1588 or when the IEEE1588 configuration is removed.
5.83 IF LOS R2L (Major) http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
83/219
14/08/2015
Alarm Descriptions
The failure is caused by loss of the receiving Intermediate Frequency (IF) signal from the RAU to the MMU (only for MMU2 E/F and MMU3 B). The alarm can be caused by the following events: Loss of signal from the RAU to the MMU. A hardware MMU failure in the MMU IF block or the demodulator itself. Applicable for the standby terminal in a 1+1 configuration. SpecificProblem IF LOS R2L Source
RAU IF (1+1)
AlarmType
CommunicationAlarm
Severity
Major
ProbableCause LossOfSignal 5.83.1 Consequences Loss of received signal: hitless switch on the faultless Rx. 5.83.2 Corrective Actions
http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
84/219
14/08/2015
Alarm Descriptions
Figure 16 Workflow for IF LOS R2L Alarm Corrective Actions Perform the following actions: 1. Perform an IF loop test on the MMU, see Fault Management Operations, Reference [3]. Onsite action: If the IF LOS R2L alarm is not cleared during the test, replace the MMU. Describe the fault on the Blue Tag and send it to the Repair Center together with the faulty MMU. If the IF LOS R2L alarm is cleared during the test, go to Step 2. 2. Onsite action: Replace the RAU. If the IF LOS R2L alarm is not cleared, reuse the initial RAU. Go to Step 3. If the IF LOS R2L alarm is cleared, describe the fault on the Blue Tag and send it to the http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
85/219
14/08/2015
Alarm Descriptions
Repair Center together with the faulty RAU. 3. Onsite action: Check and replace the radio cabling between the RAU and the MMU. For more information on how to replace the MMU, see Replacing an MMU, Reference [13]. For more information on how to replace the RAU, see Replacing a Radio Unit, Reference [16]. 5.83.3 Alarm Clearance The alarm is cleared when the MMU demodulator receives a valid signal.
5.84 IF LOS R2L (Critical) The failure is caused by loss of the receiving Intermediate Frequency (IF) signal from the RAU to the MMU (only for MMU2 E/F and MMU3 B). The alarm can be caused by the following events: Loss of signal from the RAU to the MMU. A hardware MMU failure in the MMU IF block or the demodulator itself. Applicable for 1+0 configuration and for the active terminal in a 1+1 configuration. SpecificProblem IF LOS R2L Source
RAU IF (1+0)
AlarmType
CommunicationAlarm
Severity
Critical
ProbableCause LossOfSignal 5.84.1 Consequences Loss of received signal: traffic is lost on the line side. 5.84.2 Corrective Actions
http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
86/219
14/08/2015
Alarm Descriptions
Figure 17 Workflow for IF LOS R2L Alarm Corrective Actions Perform the following actions: 1. Perform an IF loop test on the MMU, see Fault Management Operations, Reference [3]. Onsite action: If the IF LOS R2L alarm is not cleared during the test, replace the MMU. Describe the fault on the Blue Tag and send it to the Repair Center together with the faulty MMU. If the IF LOS R2L alarm is cleared during the test, go to Step 2. 2. Onsite action: Replace the RAU. If the IF LOS R2L alarm is not cleared, reuse the initial RAU. Go to Step 3. If the IF LOS R2L alarm is cleared, describe the fault on the Blue Tag and send it to the http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
87/219
14/08/2015
Alarm Descriptions
Repair Center together with the faulty RAU. 3. Onsite action: Check and replace the radio cabling between the RAU and the MMU. For more information on how to replace the MMU, see Replacing an MMU, Reference [13]. For more information on how to replace the RAU, see Replacing a Radio Unit, Reference [16]. 5.84.3 Alarm Clearance The alarm is cleared when the MMU demodulator receives a valid signal.
5.85 In Repair The alarm is raised if a configured unit is removed from the slot. SpecificProblem In Repair (Only applicable if source is Plugin unit or RAU)
In Repair at (Only applicable if source is SFP)
Source
Plugin Unit
SFP RAU
AlarmType
EquipmentAlarm
Severity
Critical
ProbableCause ReplaceableUnitProblem 5.85.1 Consequences The unit is not operating. 5.85.2 Corrective Actions Insert a unit. 5.85.3 Alarm Clearance The alarm is cleared when a unit is inserted in the slot.
5.86 Incompatible Units: Plugin Unit SpecificProblem Incompatible Units Source
Plugin Unit
AlarmType
EquipmentAlarm
Severity
Critical
ProbableCause ReplacebleUnitTypeMismatch
5.87 Incompatible Units: RAU The RAU in use is incompatible with the connected MMU. http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
88/219
14/08/2015
Alarm Descriptions
SpecificProblem Incompatible Units Source
RAU
AlarmType
EquipmentAlarm
Severity
Major
ProbableCause ReplacebleUnitTypeMismatch 5.87.1 Consequences It is not possible to configure the radio terminal. 5.87.2 Corrective Actions Replace the RAU with one of compatible type, see Replacing a Radio Unit, Reference [16]. 5.87.3 Alarm Clearance The alarm is cleared when the RAU is replaced with one of compatible type.
5.88 Insufficient Links The nearend does not have enough active links in neither the transmit nor the receive directions (less than PTx transmit or PRx receive links are active). SpecificProblem Insufficient links Source
IMA Group
AlarmType
CommunicationAlarm
Severity
Critical
ProbableCause ConfigurationOrCustomizationError 5.88.1 Consequences No Asynchronous Transfer Mode (ATM) traffic can be transmitted over the specific Inverse Multiplexer over ATM (IMA) group before both the nearend and farend groups become operational. 5.88.2 Alarm Analysis The nearend does not have enough active links in both directions. This can be caused by one or more faults affecting the links of the groups or because not enough links have been configured in the group. 5.88.3 Corrective Actions Check if any alarm is reported on the IMA links of the specific group. If no alarms affect the IMA links, add one or more links to the group to reach the required minimum number of links. 5.88.4 Alarm Clearance The alarm is cleared when the nearend terminal has the required number of active links.
5.89 Insufficient Links (FarEnd) The farend does not have enough active links in the transmit and/or receive directions and reports http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
89/219
14/08/2015
Alarm Descriptions
that less than PTx transmit or PRx receive links are active. SpecificProblem Insufficient links (FarEnd) Source
IMA Group
AlarmType
CommunicationAlarm
Severity
Critical
ProbableCause ConfigurationOrCustomizationError 5.89.1 Consequences No Asynchronous Transfer Mode (ATM) traffic can be transmitted over the specific Inverse Multiplexer over ATM (IMA) group before both the nearend and farend groups become operational. 5.89.2 Alarm Analysis The farend does not have enough active links in both directions. This can be caused by one or more faults affecting the links of the groups or because not enough links have been configured in the group. 5.89.3 Corrective Actions Check if any alarm is reported on the IMA links of the specific group. If no alarms affect the IMA links, add one or more links to the group to reach the required minimum number of links. 5.89.4 Alarm Clearance No faults affect IMA links of the specific group if it holds the required minimum of active links.
5.90 Insufficient Resources (Major) The RAU does not support the current configuration. SpecificProblem Insufficient resources Source
RAU
AlarmType
EquipmentAlarm
Severity
Major
ProbableCause ReplaceableUnitTypeMismatch 5.90.1 Consequences The transmitter is active or can be activated, but the radio link can have degraded performance. 5.90.2 Corrective Actions Try one of the following: Select a frame format supported by the current RAU. One way to do this is to select a frame format where the modulation has lower constellation order in the same channel spacing, for example, change from 512 QAM to 256 QAM with channel spacing 28 MHz. Replace the RAU with a new RAU supporting the current frame format, that is, a RAU that has a better phase noise grade. For more information, see Replacing a Radio Unit, Reference [16].
http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
90/219
14/08/2015
Alarm Descriptions
5.90.3 Alarm Clearance The alarm is cleared in either of the following cases: The frame format is changed to one that is supported by the current RAU. The RAU is replaced with one that supports the current frame format.
5.91 Insufficient Resources (Critical) The NE does not have the resources to handle this Plugin Unit. SpecificProblem Insufficient resources Source
PlugIn Unit
RAU SFP
AlarmType
EquipmentAlarm
Severity
Critical
ProbableCause ReplaceableUnitTypeMismatch 5.91.1 Corrective Actions If the source of the alarm is a RAU, try one of the following: Replace the RAU with one that does not require more than 37 W of input power, see Replacing a Radio Unit, Reference [16]. Replace the MMU with one that supports more than 37 W of output power, see Replacing an MMU, Reference [13]. 5.91.2 Alarm Clearance If the source of the alarm is a RAU, the alarm is cleared in either of the following cases: The RAU is replaced with one that does not require more than 37 W of input power. The MMU is replaced with one that supports more than 37 W of output power.
5.92 Interface/Port Status Not Up One or more remote Maintenance End Points (MEPs) report that Interface Status Type Length Value (TLV) is not isUp (interface status Up), or one or more remote MEPs report that Port Status TLV is not psUp (port status Up). Note: This alarm is only available when using the IEEE 802.1ag standard for Connectivity Fault Management (CFM). SpecificProblem Interface/Port status not Up Source
LAN with MEP
WAN with MEP LAG with MEP
http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
91/219
14/08/2015
Alarm Descriptions
AlarmType
CommunicationAlarm
Severity
Warning
ProbableCause RemoteAlarmInterface 5.92.1 Corrective Actions No corrective action is required.
5.93 Inter MMU Channel Failure High level fault on inter MMU2 E/F communication of Regenerator Section (RS). Only valid when protected. SpecificProblem Inter MMU Channel Failure Source
MMU2 E/F
AlarmType
CommunicationAlarm
Severity
Major
ProbableCause LossOfFrame
5.94 Internal Loss of Packets The alarm is raised when more packets than the given threshold are lost on the interconnection between two protected Ethernet bridges (NPUs). SpecificProblem Internal Loss of Packets Source
NPU
AlarmType
CommunicationAlarm
Severity
Warning
ProbableCause DegradedSignal 5.94.1 Consequences Traffic is lost between the two NPUs. Probable causes of traffic loss between the two NPUs are one of the following: Oversubscription of the front ports of the NPU with the passive Ethernet switch front by the ports of the NPU with the active Ethernet switch. The connection between the two NPUs is lost, in which case a protection switch takes place. 5.94.2 Corrective Actions Depending on the cause of traffic loss, perform one of the following corrective actions: In case of oversubscription of the front ports, check the traffic flows between the ports of the NPUs. In case of connection problems between the two NPUs, replace the NPU in the secondary slot. If the problem still remains, replace the NPU in the primary slot while the traffic is on the NPU in the secondary slot. http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
92/219
14/08/2015
Alarm Descriptions
For more information about the primary and the secondary slot, see Recommendations for Positioning of PlugIn Units, Reference [9]. Make sure the backplane of the subrack is not damaged. 5.94.3 Alarm Clearance The alarm is cleared when the packet loss on the interconnection between the two Ethernet bridges (NPUs) is below the given threshold.
5.95 Jitter Buffer Overrun The alarm is raised if the percentage of frames, causing Jitter Buffer Overrun, stays above a defined threshold for 2.5 seconds. SpecificProblem Jitter Buffer Overrun Source
CES
AlarmType
QualityOfServiceAlarm
Severity
Major
ProbableCause Unavailable 5.95.1 Consequences Frames are dropped in case of jitter buffer overrun. Dropped frames are replaced with filler data (0xFF). 5.95.2 Corrective Actions Improve the jitter performance of the network or reconfigure the parameters for the jitter buffer to match the network performance. 5.95.3 Alarm Clearance The alarm is cleared when no cases of Jitter Buffer Overrun are detected for 10 seconds.
5.96 L2 Loop Detected Layer 2 Ethernet loops are detected by sending test frames to multicast or broadcast addresses in the network. The alarm is raised when the NE receives a test frame sent by itself. SpecificProblem L2 Loop Detected Source
NE
AlarmType
CommunicationAlarm
Severity
Critical
ProbableCause ConfigurationOrCustomizationError 5.96.1 Consequences Risk of traffic congestion in the Layer 2 domain. http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
93/219
14/08/2015
Alarm Descriptions
5.96.2 Corrective Actions Eliminate the Layer 2 loop by modifying existing Layer 2 connections. 5.96.3 Alarm Clearance The alarm is cleared when the NE does not detect test frames sent by itself for a period configured by the user. This threshold period is set when enabling the loop detection, its default value is 60 seconds.
5.97 L2 External Loop Detected Layer 2 Ethernet loops are detected by sending test frames to multicast or broadcast addresses in the network. The alarm is raised when the NE receives a test frame sent by itself, on the sender port. The NE is not part of the detected Layer 2 loop, but it is connected to the Layer 2 domain where the Layer 2 loop occurred. SpecificProblem L2 External Loop Detected Source
NE
AlarmType
CommunicationAlarm
Severity
Major
ProbableCause ConfigurationOrCustomizationError 5.97.1 Consequences Risk of traffic congestion in the Layer 2 domain. 5.97.2 Corrective Actions Eliminate the Layer 2 loop by modifying existing Layer 2 connections. 5.97.3 Alarm Clearance The alarm is cleared when the NE does not detect test frames sent by itself for a period configured by the user. This threshold period is set when enabling the loop detection, its default value is 60 seconds.
5.98 Late Arriving Frames The alarm is raised if the percentage of frames, arriving too late to be handled, exceeds a defined threshold for 2.5 seconds. SpecificProblem Late Arriving Frames Source
CES
AlarmType
QualityofServiceAlarm
Severity
Major
ProbableCause Unavailable 5.98.1 Consequences Frames that arrive late are dropped and replaced by filler data (0xFF). http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
94/219
14/08/2015
Alarm Descriptions
5.98.2 Corrective Actions Check and improve the network performance. 5.98.3 Alarm Clearance The alarm is cleared when the percentage of frames, arriving too late to be handled, stays below a defined threshold for 10 seconds.
5.99 LCASCRC Link Capacity Adjustment Scheme Cyclic Redundancy Check (LCASCRC) One or more LCAS control packets with Cyclic Redundancy Check (CRC) error is received on any of the Virtual Containers (VCs) belonging to the Virtual Concatenation Group (VCG). SpecificProblem LCASCR Source
VCG/LCAS Standard Alarms
AlarmType
CommunicationAlarm
Severity
Minor
ProbableCause CommunicationsProtocolError 5.99.1 Corrective Actions Perform the following actions: 1. Check the Bit Error Ratio (BER), see Troubleshooting, Reference [22]. 2. Check the source.
5.100 LFD Loss of Frame Delineation (LFD) The Generic Framing Procedure (GFP) delineation state machine has left the SYNC state. SpecificProblem LFD Source
GFP
AlarmType
CommunicationAlarm
Severity
Critical
ProbableCause FramingError 5.100.1 Consequences Interface down. 5.100.2 Corrective Actions Perform the following actions: 1. Check the Bit Error Ratio (BER), see Troubleshooting, Reference [22]. 2. Check the source. http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
95/219
14/08/2015
Alarm Descriptions
5.100.3 Alarm Clearance The alarm is cleared when the traffic recovers and the GFP delineation state machine changes to SYNC state. Communication recovers.
5.101 License Handling Is in an Unlocked Period (Minor) The NE is in an unlocked period, but there are no license violations. This alarm is raised when the unlocked period is entered and repeated when half of the time is consumed. After half of the time, the alarm is repeated every 8 hours periodically. If any license controlled feature is configured but no related license is installed, the severity of this alarm is changed to Major. For more information, see Section 5.102. SpecificProblem License handling is in an unlocked period, there are no license violations. Source
License Handler
AlarmType
OperationalViolation
Severity
Minor
ProbableCause Unavailable 5.101.1 Alarm Clearance The alarm is cleared as soon as the user exits the unlocked period or the unlocked period expires.
5.102 License Handling Is in an Unlocked Period (Major) The NE is in an unlocked period and there are license violations. There are features used which require licenses and the required licenses have not been installed yet. This alarm is raised when the unlocked period is entered and repeated when half of the time is consumed. After half of the time, the alarm is repeated every 8 hours periodically. If the required licenses are installed or none of the license controlled features is configured, the severity of this alarm is changed to Minor. For more information, see Section 5.101. SpecificProblem License handling is in an unlocked period, there are license violations. Source
License Handler
AlarmType
OperationalViolation
Severity
Major
ProbableCause Unavailable 5.102.1 Corrective Actions Install the required licenses, see Installing and Managing Licenses, Reference [4]. 5.102.2 Alarm Clearance The alarm is cleared as soon as the user exits the unlocked period or the unlocked period expires.
5.103 Link Down http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
96/219
14/08/2015
Alarm Descriptions
Problem has been detected on the L1 caused by Ethernet carrier not detected. This alarm can be caused by an Ethernet cable problem, configuration error or power down on the connected device. SpecificProblem Link Down Source
SITELAN
AlarmType
CommunicationAlarm
Severity
Minor
ProbableCause Unavailable 5.103.1 Consequences No Carrier Detected on the Ethernet Port. No Ethernet connection. 5.103.2 Corrective Actions
http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
97/219
14/08/2015
Alarm Descriptions
Figure 18 Workflow for Link Down Alarm Corrective Actions Try the following: 1. Make sure that the administrative status is set to Up on the appropriate port for the NPU. 2. Onsite action: Check that the Ethernet cable connected to the appropriate port is not damaged. 3. Onsite action: Perform a cold restart of the NPU. 4. Onsite action: Replace the NPU. Describe the fault on the Blue Tag and send it to the Repair Center together with the faulty NPU. For more information on how to replace the NPU, see Replacing an NPU, Reference [15].
http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
98/219
14/08/2015
Alarm Descriptions
5.103.3 Alarm Clearance The alarm is cleared when a carrier is detected on the Ethernet port.
5.104 Link Fault This alarm is raised when a Link OAM detects a link fault at an interface. The alarm can also be caused by a Link Fault message received from another link OAMenabled entity. In this case, the alarm remains active even if the link is OK in both directions. SpecificProblem Link fault Source
LAN
AlarmType
CommunicationAlarm
Severity
Critical
ProbableCause Unavailable 5.104.1 Consequences No Carrier Detected in Tx direction on the Ethernet Port. 5.104.2 Corrective Actions Try the following: 1. Disconnect the Ethernet cable. 2. Check the Ethernet cable for damages and replace it if necessary. 3. Reconnect the Ethernet cable. 4. Check the site LAN port configuration. 5.104.3 Alarm Clearance The alarm is cleared when the following is true: No Link Fault message received from another link OAMenabled entity. The Ethernet cable is disconnected and reconnected. A carrier is detected on the Ethernet port.
5.105 Link OAM Loopback A Link OAM loopback can be set at interface by remote Link OAM and the interface is not able to transmit user traffic. This alarm is raised whenever such loopback is set at an interface by remote Link OAM. SpecificProblem OAM loopback set by remote Source
LAN
AlarmType
CommunicationAlarm
Severity
Critical
ProbableCause Unavailable
http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
99/219
14/08/2015
Alarm Descriptions
5.105.1 Consequences Egress traffic discarded and ingress traffic loop back to the remote peer on the Ethernet Port. 5.105.2 Corrective Actions Try to remove the Link OAM loop on the peer link OAM entity. If Link OAM functionality is not needed, it can be disabled. 5.105.3 Alarm Clearance The alarm is cleared when link OAM loopback is removed or Link OAM session is terminated.
5.106 LOA Loss of Alignment (LOA) LOA for channels with traffic. The differential delay for at least one channel cannot be aligned. SpecificProblem LOA Source
VCG/LCAS Standard Alarms
AlarmType
CommunicationAlarm
Severity
Critical
ProbableCause FramingError
5.107 Locking State Lasting Longer than 30 Minutes The alarm is raised if the node invalidates a synchronization reference due to instability of the synchronization reference. SpecificProblem Synchronization Reference Failed Source
NE
AlarmType
CommunicationAlarm
Severity
Major
ProbableCause LossOfSynchronisation 5.107.1 Consequences When a synchronization reference becomes unavailable, the node selects another synchronization reference. If there is no synchronization reference available that can be used, the node enters Holdover mode. 5.107.2 Corrective Actions The node cannot enter locked status because of instable network synchronization reference. Check the stability of the synchronization reference. 5.107.3 Alarm Clearance The alarm is cleared when the network synchronization reference is available again. http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
100/219
14/08/2015
Alarm Descriptions
5.108 LOF (Critical) Loss of Frame Alignment (LOF) Probable causes for this are as follows: Fiber broken. Fiber power mismatch. The connect rate of the device mismatch. SpecificProblem LOF Source
E2/E3
Framed E1 MS
AlarmType
CommunicationAlarm
Severity
Critical
ProbableCause LossOfFrame 5.108.1 Consequences Traffic block. 5.108.2 Corrective Actions Check fiber connection or farend device. 5.108.3 Alarm Clearance The alarm is cleared when the communication recovers.
5.109 LOF: RS (Critical) Loss Of Frame Alignment (LOF) The Frame Alignment Signal (FAS) is not found. SpecificProblem LOF Source
RS
AlarmType
CommunicationAlarm
Severity
Critical
ProbableCause LossOfFrame 5.109.1 Consequences Service unavailable. 5.109.2 Corrective Actions http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
101/219
14/08/2015
Alarm Descriptions
Cease the particular transmission error.
5.110 LOF L2R (Major) The input traffic on the Line interface is corrupted. There is a loss of frame on the receiving line (only for MMU2 E/F). SpecificProblem LOF L2R Source
LINE RS (1+1 EEP/ELP)
AlarmType
CommunicationAlarm
Severity
Major
ProbableCause LossOfFrame 5.110.1 Consequences An AIS is propagated to the radio side. The system switches to the faultless interface. 5.110.2 Corrective Actions Perform the following actions: 1. Check the cable and connector Line side on the MMU. 2. If possible, perform a loop on the external equipment feeding the Line interface of the MMU, see Fault Management Operations, Reference [3]. If no alarm is detected on the external equipment then replace the MMU, see Replacing an MMU, Reference [13]. 3. Replace the MMU, see Replacing an MMU, Reference [13]. 5.110.3 Alarm Clearance The alarm is cleared when the frame alignment on the incoming signal is possible again.
5.111 LOF L2R (Critical) The input traffic on the Line interface is corrupted. There is a loss of frame on the receiving line (only for MMU2 E/F). SpecificProblem LOF L2R Source
LINE RS (1+0, 1+1 SI)
AlarmType
CommunicationAlarm
Severity
Critical
ProbableCause LossOfFrame 5.111.1 Consequences An Alarm Indication Signal (AIS) is propagated to the radio side. As a consequence traffic is lost on the radio side. 5.111.2 Corrective Actions Perform the following actions: http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
102/219
14/08/2015
Alarm Descriptions
1. Check the cable and connector Line side on the MMU. 2. If possible, perform a loop on the external equipment feeding the Line interface of the MMU, see Fault Management Operations, Reference [3]. If no alarm is detected on the external equipment then replace the MMU, see Replacing an MMU, Reference [13]. 3. Replace the MMU, see Replacing an MMU, Reference [13]. 5.111.3 Alarm Clearance The alarm is cleared when the frame alignment on the incoming signal is possible again.
5.112 LOF R2L (Major) Loss Of Frame (LOF) LOF on the transmitting line (only for MMU2 E/F). Probable causes are the following: Fading (flat or selective) Bad antenna alignment Link budget calculation not correct Presence of interferers SpecificProblem LOF R2L Source
RAU IF(1+1)
AlarmType
CommunicationAlarm
Severity
Major
ProbableCause LossOfFrame 5.112.1 Consequences An Alarm Indication Signal (AIS) is propagated to the line side. The Radio Protection Switch chooses the other MMU if its signal quality is better. 5.112.2 Corrective Actions Perform the following actions: 1. Verify the Radio Frequency (RF) input power level: it must be at least 5 dB above the 106 Bit Error Ratio (BER) threshold for the current configuration. See link budget calculation for the correct level. 2. Increase the RF input power level (if possible) by acting on the farend output power. 3. Check the antenna alignment, see Installing Outdoor Equipment, Reference [5]. 4. Verify the link budget calculation. 5. Check for presence of RF interferers. 6. Check for presence of Intermediate Frequency (IF) interferers (and eventually the RF coaxial cable shielding). 7. Evaluate the presence of selective (multipath) fading. 8. Perform an IF loop on the MMU, see Fault Management Operations, Reference [3]. If the alarm is still present then replace the active MMU, see Replacing an MMU, Reference [13]. http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
103/219
14/08/2015
Alarm Descriptions
9. Perform an RF loop on the RAU, see Fault Management Operations, Reference [3]. If the alarm is still present then replace the active RAU, see Replacing a Radio Unit, Reference [16]. 10. Execute troubleshooting as step 8and 9 on the farend and act consequently. 5.112.3 Alarm Clearance The alarm is cleared when the frame alignment on the incoming radio signal is possible again.
5.113 LOF R2L (Critical) Loss Of Frame (LOF) LOF on the transmitting line (only for MMU2 E/F). Probable causes for this are: Fading (flat or selective). Bad antenna alignment. Link budget calculation not correct. Presence of interferers. SpecificProblem LOF R2L Source
RAU IF(1+0)
AlarmType
CommunicationAlarm
Severity
Critical
ProbableCause LossOfFrame 5.113.1 Consequences An Alarm Indication Signal (AIS) is propagated to the line side. As a consequence the traffic is lost on the line side. 5.113.2 Corrective Actions Perform the following actions: 1. Verify the Radio Frequency (RF) input power level: it must be at least 5 dB above the 106 Bit Error Ratio (BER) threshold for the current configuration. See link budget calculation for the correct level. 2. Increase the RF input power level (if possible) by acting on the farend output power. 3. Check the antenna alignment, see Installing Outdoor Equipment, Reference [5]. 4. Verify the link budget calculation. 5. Check for presence of RF interferers. 6. Check for presence of Intermediate Frequency (IF) interferers (and eventually the RF coaxial cable shielding). 7. Evaluate the presence of selective (multipath) fading. 8. Perform an IF loop on the MMU, see Fault Management Operations, Reference [3]. If the alarm is still present then replace the active MMU, see Replacing an MMU, Reference [13]. 9. Perform an RF loop on the RAU, see Fault Management Operations, Reference [3]. If the alarm is still present then replace the active RAU, see Replacing a Radio Unit, Reference [16]. http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
104/219
14/08/2015
Alarm Descriptions
10. Execute troubleshooting as step 8and 9 on the farend and act consequently. 5.113.3 Alarm Clearance The alarm is cleared when the frame alignment on the incoming radio signal is possible again.
5.114 LOM Loss of Multiframe (LOM) The 2stage multiframe alignment used for virtual concatenation is lost. SpecificProblem LOM Source
VC12
VC3 VC4
AlarmType
CommunicationAlarm
Severity
Major
ProbableCause LossOfMultiFrame 5.114.1 Corrective Actions Perform the following actions: 1. Check the Bit Error Ratio (BER), see Troubleshooting, Reference [22]. 2. Check the source.
5.115 LOMF (Major) Loss of Multiframe (LOMF) SpecificProblem LOMF Source
VC4
AlarmType
CommunicationAlarm
Severity
Major
ProbableCause LossOfMultiFrame
5.116 LOMF (Critical) Loss of Multiframe (LOMF) SpecificProblem LOMF Source
Framed E1
AlarmType
CommunicationAlarm
Severity
Critical
ProbableCause LossOfMultiFrame http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
105/219
14/08/2015
Alarm Descriptions
5.117 LOP (Major) Loss of Pointer (LOP) The incoming signal is corrupted so the pointer cannot be located in the signal. SpecificProblem LOP Source
AU4
TU3 TU12
AlarmType
CommunicationAlarm
Severity
Major
ProbableCause LossOfPointer 5.117.1 Consequences The service is unavailable. 5.117.2 Corrective Actions Check and correct the link connection of the faulty layer. 5.117.3 Alarm Clearance The alarm is cleared when the incoming signal is not corrupted anymore and the pointer can be located in the incoming signal.
5.118 LOP (Critical) Loss of Pointer (LOP) The incoming signal is corrupted, so the pointer cannot be located in the signal. SpecificProblem LOP Source
VC4 VC12
AlarmType
CommunicationAlarm
Severity
Critical
ProbableCause LossOfPointer 5.118.1 Consequences The service is unavailable. 5.118.2 Corrective Actions Check and correct the link connection of the faulty layer. http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
106/219
14/08/2015
Alarm Descriptions
5.118.3 Alarm Clearance The alarm is cleared then the incoming signal is not corrupted anymore, and the pointer can be located in the incoming signal.
5.119 LOS (Critical) Loss of Signal (LOS) LOS is detected on the incoming traffic on the line interface. SpecificProblem LOS Source
E1 MS/RS
AlarmType
CommunicationAlarm
Severity
Critical
ProbableCause LossOfSignal 5.119.1 Consequences The service is unavailable. 5.119.2 Corrective Actions
http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
107/219
14/08/2015
Alarm Descriptions
Figure 19 Workflow for LOS Alarm Corrective Actions Do the following: 1. Perform a local loop on the corresponding interface of the nearend Plugin Unit (PIU). Onsite action: If the LOS alarm is not cleared, replace the PIU on the nearend. Describe the fault on the Blue Tag and send it to the Repair Center together with the faulty PIU. If the LOS alarm is cleared, go to Step 2. 2. Perform a line loop on the interface of the farend PIU. If the LOS alarm is not cleared, go to Step 3. Onsite action: If the LOS alarm is cleared, replace the PIU on the farend. Describe the fault on the Blue Tag and send it to the Repair Center together with the faulty PIU. http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
108/219
14/08/2015
Alarm Descriptions
3. Onsite action: Check and replace the transmission media between the nearend PIU and the farend PIU as needed. For more information on how to replace the faulty PIU, see applicable CPI under HW Management folder. 5.119.3 Alarm Clearance The alarm is cleared when traffic is detected in the incoming signal.
5.120 LOS: RAU IF (Major) Loss of Signal (LOS) The failure is caused by loss of received Intermediate Frequency (IF) signal from the RAU to the MMU. The alarm can be caused by the following events: Loss of signal from the RAU to the MMU. A hardware MMU failure in the MMU IF block or the demodulator itself. Applicable for the standby terminal in a 1+1 configuration. SpecificProblem LOS Source
RAU IF
AlarmType
CommunicationAlarm
Severity
Major
ProbableCause LossOfSignal 5.120.1 Consequences Loss of received signal: traffic is lost on the line side. 5.120.2 Corrective Actions
http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
109/219
14/08/2015
Alarm Descriptions
Figure 20 Workflow for LOS: RAU IF Alarm Corrective Actions Do the following: 1. Perform an IF loop test on the MMU, see Fault Management Operations, Reference [3]. Onsite action: If the LOS: RAU IF alarm is not cleared during the test, replace the MMU. Describe the fault on the Blue Tag and send it to the Repair Center together with the faulty MMU. If the LOS: RAU IF alarm is cleared during the test, go to Step 2. 2. Onsite action: Replace the RAU. If the LOS: RAU IF alarm is not cleared, reuse the initial RAU. Go to Step 3. If the LOS: RAU IF alarm is cleared, describe the fault on the Blue Tag and send it to the http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
110/219
14/08/2015
Alarm Descriptions
Repair Center together with the faulty RAU. 3. Onsite action: Check and replace the radio cabling between the RAU and the MMU. For more information on how to replace the MMU, see Replacing an MMU, Reference [13]. For more information on how to replace the RAU, see Replacing a Radio Unit, Reference [16]. 5.120.3 Alarm Clearance The alarm is cleared when the MMU demodulator receives a valid signal.
5.121 LOS: RAU IF (Critical) Loss of Signal (LOS) The failure is caused by loss of received Intermediate Frequency (IF) signal from the RAU to the MMU. The alarm can be caused by the following events: Loss of signal from the RAU to the MMU. A hardware MMU failure in the MMU IF block or the demodulator itself. Applicable for 1+0 configuration and for the active terminal in a 1+1 configuration. SpecificProblem LOS Source
RAU IF
AlarmType
CommunicationAlarm
Severity
Critical
ProbableCause LossOfSignal 5.121.1 Consequences Loss of received signal: traffic is lost on the line side. 5.121.2 Corrective Actions
http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
111/219
14/08/2015
Alarm Descriptions
Figure 21 Workflow for LOS: RAU IF Alarm Corrective Actions Do the following: 1. Perform an IF loop test on the MMU, see Fault Management Operations, Reference [3]. Onsite action: If the LOS: RAU IF alarm is not cleared during the test, replace the MMU. Describe the fault on the Blue Tag and send it to the Repair Center together with the faulty MMU. If the LOS: RAU IF alarm is cleared during the test, go to Step 2. 2. Onsite action: Replace the RAU. If the LOS: RAU IF alarm is not cleared, reuse the initial RAU. Go to Step 3. If the LOS: RAU IF alarm is cleared, describe the fault on the Blue Tag and send it to the http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
112/219
14/08/2015
Alarm Descriptions
Repair Center together with the faulty RAU. 3. Onsite action: Check and replace the radio cabling between the RAU and the MMU. For more information on how to replace the MMU, see Replacing an MMU, Reference [13]. For more information on how to replace the RAU, see Replacing a Radio Unit, Reference [16]. 5.121.3 Alarm Clearance The alarm is cleared when the MMU demodulator receives a valid signal.
5.122 LOS L2R (Major) Loss of received signal at the line interface (only for MMU2 E/F and MMU3 B). Applicable for the standby interface in 1+1 Enhanced Equipment Protection (EEP)/Equipment and Line Protection (ELP). SpecificProblem LOS L2R Source
LINE RS (1+1 EEP/ELP)
AlarmType
CommunicationAlarm
Severity
Major
ProbableCause LossOfSignal 5.122.1 Consequences The protection is lost. 5.122.2 Corrective Actions
http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
113/219
14/08/2015
Alarm Descriptions
Figure 22 Workflow for LOS L2R (Major) Alarm Corrective Actions Do the following: 1. Perform a local loop on the line interface of the nearend MMU. Onsite action: If the LOS L2R alarm is not cleared, replace the MMU on the nearend. Describe the fault on the Blue Tag and send it to the Repair Center together with the faulty MMU. If the LOS L2R alarm is cleared, go to Step 2. 2. Perform a line loop on the active interface of the farend PIU. If the LOS L2R alarm is not cleared, go to Step 3. Onsite action: If the LOS L2R alarm is cleared, replace the active PIU on the farend. Describe the fault on the Blue Tag and send it to the Repair Center together with the faulty http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
114/219
14/08/2015
Alarm Descriptions
PIU. 3. Onsite action: Check and replace the transmission media between the nearend MMU and the farend PIU as needed. For more information on how to replace the MMU, see Replacing an MMU, Reference [13]. For more information on how to replace the faulty PIU, see applicable CPI under HW Management folder. 5.122.3 Alarm Clearance The alarm is cleared when a valid signal is detected in the line interface.
5.123 LOS L2R (Critical) Loss of received signal at the line interface (only for MMU2 E/F and MMU3 B). Applicable for 1+0, 1+1 Single Interface (SI), and the active interface in 1+1 Enhanced Equipment Protection (EEP)/Equipment and Line Protection (ELP). SpecificProblem LOS L2R Source
LINE RS (1+0, 1+1 SI)
AlarmType
CommunicationAlarm
Severity
Critical
ProbableCause LossOfSignal 5.123.1 Consequences Loss of received signal: traffic is lost on the radio side. 5.123.2 Corrective Actions
http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
115/219
14/08/2015
Alarm Descriptions
Figure 23 Workflow for LOS L2R (Critical) Alarm Corrective Actions Do the following: 1. Perform a local loop on the line interface of the nearend MMU. Onsite action: If the LOS L2R alarm is not cleared, replace the MMU on the nearend. Describe the fault on the Blue Tag and send it to the Repair Center together with the faulty MMU. If the LOS L2R alarm is cleared, go to Step 2. 2. Perform a line loop on the interface of the farend PIU. If the LOS L2R alarm is not cleared, go to Step 3. Onsite action: If the LOS L2R alarm is cleared, replace the PIU on the farend. Describe the fault on the Blue Tag and send it to the Repair Center together with the faulty PIU. http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
116/219
14/08/2015
Alarm Descriptions
3. Onsite action: Check and replace the transmission media between the nearend MMU and the farend PIU as needed. For more information on how to replace the MMU, see Replacing an MMU, Reference [13]. For more information on how to replace the faulty PIU, see applicable CPI under HW Management folder. 5.123.3 Alarm Clearance The alarm is cleared when a valid signal is detected in the line interface.
5.124 Loss of Cell Delineation: ATM Asynchronous Transfer Mode (ATM) Cells cannot be extracted from the E1 Link configured as a G.804 ATM interface. SpecificProblem Loss of Cell Delineation Source
ATM
AlarmType
CommunicationAlarm
Severity
Critical
ProbableCause TransmissionError 5.124.1 Consequences There is no ATM traffic in the Rx direction of the specific ATM Interface. 5.124.2 Alarm Analysis The network equipment connected to E1 is not configured for ATM service or physical failure at the E1 interface (Loss Of Signal (LOS)/Loss Of Frame (LOF)/Alarm Indication Signal (AIS)). 5.124.3 Corrective Actions Check the configuration of the network equipment interface connected to the specific E1 interface. 5.124.4 Alarm Clearance The alarm is cleared when the transmission convergence is able to delineate and extract ATM cells from the specific link.
5.125 Loss of Cell Delineation: IMA Link Asynchronous Transfer Mode (ATM) Cells cannot be extracted from the E1 Link configured as an Inverse Multiplexer over ATM (IMA) Link. SpecificProblem Loss of Cell Delineation Source
IMA Link
AlarmType
CommunicationAlarm
Severity
Critical
ProbableCause TransmissionError http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
117/219
14/08/2015
Alarm Descriptions
5.125.1 Consequences No ATM traffic can be received from the specific IMA Link. Related IMA groups can also be affected by the fault: in case the IMA group goes below the "minimum number of (active) links" no ATM traffic can flow at all through the group. In this case the operational status of related ATMIMA (IMA group) and ATM goes to down. If the IMA group still have a minimum number of links it can still receive the guaranteed bandwidth of traffic. 5.125.2 Alarm Analysis The network equipment connected to E1 is not configured for ATM service or physical failure at the E1 interface (Loss Of Signal (LOS)/Loss Of Frame (LOF)/Alarm Indication Signal (AIS)). 5.125.3 Corrective Actions Check the configuration of the network equipment interface connected to the specific link. 5.125.4 Alarm Clearance The alarm is cleared when the transmission convergence is able to delineate and extract ATM cells from the specific link.
5.126 Loss of Continuity A Maintenance End Point (MEP) does not receive Continuity Check Message (CCM) frames from a peer MEP during an interval equal to 3.5 times the CCM transmission period configured at the MEP. Note: This alarm is only available when using the ITUT Y.1731 standard for Connectivity Fault Management (CFM). SpecificProblem Loss Of Continuity Source
LAN with MEP
WAN with MEP LAG with MEP
AlarmType
CommunicationAlarm
Severity
Major
ProbableCause LossOfFrame 5.126.1 Corrective Actions No corrective action is required.
5.127 Loss of Delay Synchronization The link has a delay higher than the tolerable link differential delay (25 msec) with respect to the other links in the group. SpecificProblem Loss of Delay Synchronization Source
IMA Link
AlarmType
CommunicationAlarm
http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
118/219
14/08/2015
Severity
Alarm Descriptions
Critical
ProbableCause DegradedSignal 5.127.1 Consequences No Asynchronous Transfer Mode (ATM) traffic can be received from the specific Inverse Multiplexer over ATM (IMA) Link. Related IMA groups can also be affected by the fault: in case the IMA group goes below the "minimum number of (active) links" no ATM traffic can flow at all through the group. In this case the operational status of related ATMIMA (IMA group) and ATM goes to down. If the IMA group still have a minimum number of links it can still receive the guaranteed bandwidth of traffic. 5.127.2 Alarm Analysis Links belonging to the group have different paths in the network causing an excessive differential delay among the links. 5.127.3 Corrective Actions Try to reduce differential delays by using other links. 5.127.4 Alarm Clearance The alarm is cleared when the differential delay of the link sinks below the limit threshold (25 msec).
5.128 Loss of Grandmaster Traceability The NE has lost frequency (G.8265.1 mode) or phase (IEEE 1588v2 mode) traceability to the Grandmaster. SpecificProblem Loss of Grandmaster Traceability Source
NE
AlarmType
CommunicationAlarm
Severity
Major
ProbableCause Unavailable 5.128.1 Consequences The 1588v2 function enters into Holdover or Free Running Mode, and cannot be used as a Netsynch reference. 5.128.2 Corrective Actions Check the availability of Master Clocks and configure another Master if needed. 5.128.3 Alarm Clearance The alarm is cleared when Grandmaster traceability is recovered.
5.129 Loss of IMA Frame Persistence of a LIF defect at the nearend (more than 2.5 +/ 0.5 sec). Inverse Multiplexer over ATM (IMA) device can not find IMA ICP Cells delimiting IMA Frames. http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
119/219
14/08/2015
Alarm Descriptions
SpecificProblem Loss of IMA Frame Source
IMA Link
AlarmType
CommunicationAlarm
Severity
Critical
ProbableCause LossOfFrame 5.129.1 Consequences No Asynchronous Transfer Mode (ATM) traffic can be received from the specific IMA Link. Related IMA groups can also be affected by the fault: in case the IMA group goes below the "minimum number of (active) links" no ATM traffic can flow at all through the group. In this case the operational status of related ATMIMA (IMA group) and ATM goes to down. If the IMA group still have a minimum number of links it can still receive the guaranteed bandwidth of traffic. 5.129.2 Alarm Analysis The farend link is not configured as an IMA Link. 5.129.3 Corrective Actions Check the farend link configuration. 5.129.4 Alarm Clearance The alarm is cleared when the IMA device can receive ICP cells from the farend link.
5.130 Loss of Keep Alive Loss of keepalive frames is detected. SpecificProblem Loss of keep alive Source
IM Group
AlarmType
CommunicationAlarm
Severity
Critical
ProbableCause Unavailable
5.131 Loss of Master Clock Protection The NE has lost the connectivity to the redundant (backup) Master Clock. SpecificProblem Loss of Master Clock Protection Source
NE
AlarmType
CommunicationAlarm
Severity
Warning
ProbableCause Unavailable 5.131.1 Consequences Grandmaster traceability is still kept but the PTP connectivity is no longer protected. http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
120/219
14/08/2015
Alarm Descriptions
5.131.2 Corrective Actions Check the availability of Master Clocks and configure another Master if needed. 5.131.3 Alarm Clearance The alarm is cleared when connectivity to a backup Master is recovered.
5.132 Loss of Network Reference Redundancy The node lost its redundant (backup) network synchronization reference. SpecificProblem Loss of network reference redundancy Source
NE
AlarmType
CommunicationAlarm
Severity
Warning
ProbableCause ClockSynchronisationProblem 5.132.1 Consequences When the node only has one network synchronization reference available it is considered vulnerable and if the last synchronization reference is lost it puts the node in holdover. 5.132.2 Corrective Actions No corrective action is required. 5.132.3 Alarm Clearance The alarm is cleared when a redundant network synchronization reference is available again.
5.133 Lost CCMs The Maintenance End Point (MEP) does not receive valid Continuity Check Message (CCM) frames from at least one of the remote MEPs. Note: This alarm is only available when using the IEEE 802.1ag standard for Connectivity Fault Management (CFM). SpecificProblem Lost CCMs Source
LAN with MEP
WAN with MEP LAG with MEP
AlarmType
CommunicationAlarm
Severity
Major
ProbableCause LossOfFrame 5.133.1 Corrective Actions http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
121/219
14/08/2015
Alarm Descriptions
No corrective action is required.
5.134 Low BER Bit Error Ratio (BER) The threshold for Synchronous Digital Hierarchy (SDH) Low BER is passed (MMU2 E/F and MMU3 B only). Possible causes are the following: Fading (flat or selective). Bad antenna alignment. Link budget calculation not correct. Presence of interferers. SpecificProblem Low BER Source
RAU IF
AlarmType
CommunicationAlarm
Severity
Major
ProbableCause DegradedSignal 5.134.1 Consequences Degradation of the quality of the traffic signal line side. 5.134.2 Corrective Actions Perform the following actions: Note: If the alarm occurs in a 1+1 protected terminal, make sure that the Switch Mode is set to Manual on both the nearend and the farend terminal before troubleshooting. Perform all the actions on the active unit. Set Switch Mode to Auto once the troubleshooting is completed.
1. Verify that the RF input power on the receiving RAU is at least 5 dB above the threshold for BER 106 for the current configuration. See link budget calculation for the correct level. If the RF input power is not at least 5 dB above the threshold, go to Step 2. If the RF input power is at least 5 dB above the threshold, go to Step 12. 2. Perform an RF loop test on the nearend RAU. Turn off the RAU transmitter on the farend during the test. If the RF input power is not about 50 dBm (± 10 dB) during the test, replace the RAU on the nearend. Describe the fault on the Blue Tag and send it to the Repair Center together with the faulty RAU. If the RF input power is about 50 dBm (± 10 dB) during the test, go to Step 3. 3. Check fading conditions and weather circumstances. If link performance is not affected by propagation issues, go to Step 4. If link performance is affected by propagation issues, consult the transmission design department on how to address the link budget. http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
122/219
14/08/2015
Alarm Descriptions
4. Check the alarms and status of the farend terminal. If there are no alarms raised on the farend terminal, go to Step 5 in Section 5.74.2. If there are alarms raised on the farend terminal, find the root causes of these alarms first, and take corrective actions according to the alarm description. If the BER alarm is still raised on the nearend terminal after clearing the alarms on the farend terminal, go to Step 5. 5. Verify that the nearend terminal configuration matches the farend terminal configuration. If the configuration is not correct, reconfigure the nearend terminal and the farend terminal according to the Site Installation Documentation (SID). If the configuration is correct, go to Step 6. 6. Perform an RF loop test on the farend RAU. Turn off the RAU transmitter on the nearend during the test. If the RF input power is not about 50 dBm (± 10 dB) during the test, replace the RAU on the farend. Describe the fault on the Blue Tag and send it to the Repair Center together with the faulty RAU. If the RF input power is about 50 dBm (± 10 dB) during the test, go to Step 7. 7. Check for possible obstacles interfering with the line of sight and check that the antennas are mounted at the correct height according to the link budget. If there are obstacles or the antennas are not mounted at the correct height, consult the network design department to review the link budget planning. If there are no obstacles in the line of sight and the antennas are mounted at the correct height, go to Step 8. 8. Make sure the antennas are aligned correctly on the nearend and the farend to meet the link budget target. If the antennas are not aligned correctly, take corrective actions. If the antennas are aligned correctly, go to Step 9. 9. Verify that the RAUs are correctly mounted on the antennas, that any flexible waveguides are not damaged, and that correct polarization is set on both sides of the hop. If you find any problem, take corrective actions. If you do not find any problems, go to Step 10. 10. Replace the antenna on the nearend. If the BER alarm is not cleared after the replacement, reinstall the initial antenna, and go to Step 11. If the BER alarm is cleared after the replacement, describe the fault on the Blue Tag and send it to the Repair Center together with the faulty antenna. 11. Replace the antenna on the farend. Describe the fault on the Blue Tag and send it to the Repair Center together with the faulty antenna. 12. Verify that the nearend terminal configuration matches the farend terminal configuration. If the configuration is not correct, reconfigure the nearend terminal and the farend terminal according to the Site Installation Documentation (SID). If the configuration is correct, go to Step 13. 13. Perform a cold restart of the MMU and the RAU on the nearend. Restart MINILINK Craft.
Caution! A cold restart will disturb the traffic. http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
123/219
14/08/2015
Alarm Descriptions
If the BER alarm is not cleared after the restart, go to Step 14. If the BER alarm is cleared after the restart, monitor the hop for further BER alarms. If the alarm is raised again while the RF input level is higher than the threshold level for BER 106 for the current configuration, go to Step 14. 14. Perform an IF loop test on the nearend MMU. If the BER alarm is not cleared during the test, replace the MMU on the nearend. Describe the fault on the Blue Tag and send it to the Repair Center together with the faulty MMU. If the BER alarm is cleared during the test, go to Step 15. 15. Perform an RF loop test on the nearend RAU. Turn off the RAU transmitter on the farend during the test. If the BER alarm is not cleared during the test, go to Step 23. If the BER alarm is cleared during the test, go to Step 16. 16. Check the alarms and status of the farend terminal. If there are no alarms raised on the farend terminal, go to Step 17. If there are alarms raised on the farend terminal, find the root causes of these alarms first, and take corrective actions according to the alarm description. If the BER alarm is still raised on the nearend terminal after clearing the alarms on the farend terminal, go to Step 17. 17. Perform an RX loop test on the farend. If the BER alarm is not cleared during the test, go to Step 18. If the BER alarm is cleared, review the quality of the incoming traffic on the farend MMU line side. 18. Perform an interference test, see Verifying an Installation, Reference [24]. If there is no interference during the test, go to Step 19. If there is any interference during the test, consult the transmission design department to review network planning and link budget. 19. Replace the MMU on the farend. If the BER alarm is not cleared on the nearend after the replacement, reuse the initial MMU on the farend, and go to Step 20. If the BER alarm is cleared on the nearend after the replacement, describe the fault on the Blue Tag and send it to the Repair Center together with the faulty MMU. 20. Replace the RAU on the farend. If the BER alarm is not cleared on the nearend after the replacement, reuse the initial RAU on the farend, and go to Step 21. If the BER alarm is cleared on the nearend after the replacement, describe the fault on the Blue Tag and send it to the Repair Center together with the faulty RAU. 21. Check the radio cable for interference on the IF signal between the MMU and the RAU on the farend terminal with a SiteMaster or a Spectrum Analyzer. Make sure that there is no interference in the frequency range of 0–400 MHz. If there is no interference, go to Step 22. If there is any interference, check the cables for damages and replace the cables if needed. Monitor the interfering source and remove it if possible, or reroute the IF cables not to be disturbed by the interfering source. 22. Replace the radio cables and the connectors between the MMU and the RAU on the farend terminal. http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
124/219
14/08/2015
Alarm Descriptions
23. Replace the RAU on the nearend. If the BER alarm is not cleared on the nearend after the replacement, reuse the initial RAU, and go to Step 24. If the BER alarm is cleared on the nearend after the replacement, describe the fault on the Blue Tag and send it to the Repair Center together with the faulty RAU. 24. Check the radio cable for interference on the IF signal between the MMU and the RAU on the nearend terminal with a SiteMaster or a Spectrum Analyzer. Make sure that there is no interference in the frequency range of 0–400 MHz. If there is no interference, go to Step 25. If there is any interference, check the cables for damages and replace the cables if needed. Monitor the interfering source and remove it if possible, or reroute the IF cables not to be disturbed by the interfering source. 25. Replace the radio cables and the connectors between the MMU and the RAU on the farend terminal. For more information on how to replace the RAU, see Replacing a Radio Unit, Reference [16]. For more information on antenna alignment and antenna installation, see Installing Outdoor Equipment, Reference [5]. For more information on how to replace the MMU, see Replacing an MMU, Reference [13]. 5.134.3 Alarm Clearance The alarm is cleared when the BER estimation is below the threshold.
5.135 Low Input Voltage The input voltage is low. If it drops further, one or more plugin units can stop working. SpecificProblem Low Input Voltage Source
NE
AlarmType
EnvironmentalAlarm
Severity
Major
ProbableCause PowerProblem
5.136 Loss of Frames The alarm is raised if the frame Loss Ratio stays above a defined threshold for 2.5 seconds. SpecificProblem Loss of Frames Source
CES
AlarmType
QualityofServiceAlarm
Severity
Critical
ProbableCause LossOfFrame 5.136.1 Consequences An Alarm Indication Signal (AIS) is generated. http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
125/219
14/08/2015
Alarm Descriptions
5.136.2 Corrective Actions Check and improve the network performance. 5.136.3 Alarm Clearance The alarm is cleared when the Frame Loss Ratio stays below a defined threshold for 10 seconds.
5.137 Lower Layer Down No throughput on the interface. All Inverse Multiplexer (IM) interfaces are down. For TDM Link, Lower Layer Down (LLD) is reported for BER > 103. For Packet Link, LLD is reported for BER > 105. SpecificProblem Lower Layer Down Source
IM Group
AlarmType
CommunicationAlarm
Severity
Critical
ProbableCause Unavailable
5.138 Maintenance Unlock Reset Key Required (Warning) The number of available Maintenance Unlock tokens decreased to one, because the user entered Maintenance Unlock period. When entering Maintenance Unlock period again, the tokens run out and the severity of this alarm is changed to Major. SpecificProblem Maintenance Unlock Reset Key Required Source
License Handler
AlarmType
OperationalViolation
Severity
Warning
ProbableCause Unavailable 5.138.1 Corrective Actions Install Maintenance Unlock Refill licenses, see Installing and Managing Licenses, Reference [4]. 5.138.2 Alarm Clearance The alarm is cleared as soon as the user installs at least one Maintenance Refill license.
5.139 Maintenance Unlock Reset Key Required (Major) No Maintenance Unlock tokens available, because the user entered Maintenance Unlock period several times. When a Maintenance Unlock Refill license is installed, the severity of this alarm is changed to Warning. SpecificProblem Maintenance Unlock Reset Key Required Source
License Handler
AlarmType
OperationalViolation
Severity
Major
ProbableCause Unavailable http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
126/219
14/08/2015
Alarm Descriptions
5.139.1 Corrective Actions Install Maintenance Unlock Refill licenses, see Installing and Managing Licenses, Reference [4]. 5.139.2 Alarm Clearance The alarm is cleared as soon as the user installs at least one Maintenance Refill license.
5.140 Malformed Frames The alarm is raised if the percentage of malformed frames stays above a defined threshold for 2.5 seconds. SpecificProblem Malformed Frames Source
CES
AlarmType
CommunicationAlarm
Severity
Major
ProbableCause CommunicationsProtocolError 5.140.1 Consequences Malformed frames are replaced with filler data (0xFF). 5.140.2 Corrective Actions Check that the network is correctly configured and that there are no security threats in the network. 5.140.3 Alarm Clearance The alarm is cleared when the percentage of malformed frames stays below a defined threshold for 10 seconds.
5.141 Mismerge (Incorrect MA ID in CCM) A Maintenance End Point (MEP) has received a Continuity Check Message (CCM) frame with correct Maintenance Domain (MD) level, but with incorrect Maintenance Association (MA) ID. Note: This alarm is only available when using the ITUT Y.1731 standard for Connectivity Fault Management (CFM). SpecificProblem Mismerge (incorrect MA ID in CCM) Source
LAN with MEP
WAN with MEP LAG with MEP
AlarmType
CommunicationAlarm
Severity
Major
ProbableCause PathTraceMismatch http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
127/219
14/08/2015
Alarm Descriptions
5.141.1 Corrective Actions No corrective action is required.
5.142 Mod Index The modulation index of the MMU, controlled by the farend MMU, is out of the allowed range. SpecificProblem Mod Index Source
RAU IF
AlarmType
CommunicationAlarm
Severity
Major
ProbableCause DegradedSignal
5.143 Mode Mismatch: MS Multiplex Section Protection (MSP) mode mismatch. Farend configured as MSP 1:n and the received K2 byte does not indicate 1+1. SpecificProblem Mode Mismatch K2. Indicates faulty configuration in the farend unit. Source
Multiplex Section (MS)
AlarmType
EquipmentAlarm
Severity
Minor
ProbableCause ConfigurationOrCustomizationError 5.143.1 Corrective Actions Check and correct configuration mismatch. 5.143.2 Alarm Clearance The alarm is cleared when the K2 byte indicates 1+1.
5.144 Mode Mismatch: MSP Multiplex Section Protection (MSP) mode mismatch. Farend configured as MSP 1:n and the received K2 byte does not indicate 1+1. SpecificProblem Mode Mismatch Source
MSP
AlarmType
CommunicationAlarm
Severity
Minor
ProbableCause Indeterminate 5.144.1 Corrective Actions Check and correct configuration mismatch. http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
128/219
14/08/2015
Alarm Descriptions
5.144.2 Alarm Clearance The alarm is cleared when the K2 byte indicates 1+1.
5.145 No Holdover Protection SpecificProblem No holdover protection Source
NE
AlarmType
CommunicationAlarm
Severity
Minor
ProbableCause ClockSynchronisationProblem
5.146 No Traffic: LAG For all the ports allocated to the link aggregation group, the link is down. SpecificProblem No Traffic Source
LAG
AlarmType
CommunicationAlarm
Severity
Critical
ProbableCause Unavailable
5.147 No Traffic Possible No throughput on the interface. All Inverse Multiplexer (IM) interfaces are Down. SpecificProblem No Traffic Possible Source
HDLC
AlarmType
CommunicationAlarm
Severity
Critical
ProbableCause Unavailable
5.148 Node Installation The NE is in Node Installation mode. Enter the URL http://10.0.0.1 to reach the installation wizard. SpecificProblem Node Installation Source
NE
AlarmType
EquipmentAlarm
Severity
Minor
ProbableCause CommunicationsSubsystemFailure
5.149 NONLCAS A sink operating in Link Capacity Adjustment Scheme (LCAS) mode detected a NONLCAS source. http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
129/219
14/08/2015
Alarm Descriptions
SpecificProblem NONLCAS Source
VCG/LCAS NonStandard Alarms
AlarmType
CommunicationAlarm
Severity
Warning
ProbableCause ConfigurationOrCustomizationError 5.149.1 Corrective Actions Check the source.
5.150 NPU Installation The NE is in NPU Installation mode. Enter the URL http://10.0.0.1 to reach the installation wizard. SpecificProblem NPU Installation Source
NE
AlarmType
EquipmentAlarm
Severity
Major
ProbableCause CommunicationsSubsystemFailure
5.151 OAM Local Errored Frame , , The alarm is raised if the number of errored frames exceeds the threshold during the defined period of time. There are two variants of this alarm: OAM Local Errored Frame and OAM Remote Errored Frame. If Link OAM entity A has problems receiving traffic from peer Link OAM entity B, A raises a local alarm and sends an indication about traffic disturbance using the Link OAM protocol to B. B then raises a remote alarm. SpecificProblem OAM Local Errored Frame , , Source
LAN
AlarmType
CommunicationAlarm
Severity
Major
ProbableCause Unavailable
5.152 OAM Local Errored Frame Period , , The alarm is raised if the number of errored frames exceeds the threshold percentage during the defined number of frames. There are two variants of this alarm: OAM Local Errored Frame Period and OAM Remote Errored Frame Period. If Link OAM entity A has problems receiving traffic from peer Link OAM entity B, A raises a local alarm and sends an indication about traffic disturbance using the Link OAM protocol to B. B then raises a remote alarm. SpecificProblem OAM Local Errored Frame Period , , Source
LAN
AlarmType
CommunicationAlarm
http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
130/219
14/08/2015
Severity
Alarm Descriptions
Major
ProbableCause Unavailable
5.153 OAM Local Errored Secs Summary , , The alarm is raised if the number of errored frame seconds exceeds the threshold during the defined period of time. An errored frame second is a one second interval during which at least one frame error is detected. There are two variants of this alarm: OAM Local Errored Frame Secs Summary and OAM Remote Errored Frame Secs Summary. If Link OAM entity A has problems receiving traffic from peer Link OAM entity B, A raises a local alarm and sends an indication about traffic disturbance using the Link OAM protocol to B. B then raises a remote alarm. SpecificProblem OAM Local Errored Frame Secs Summary , , Source
LAN
AlarmType
CommunicationAlarm
Severity
Major
ProbableCause Unavailable
5.154 OAM Local Errored Symbol Period , , The alarm is raised if the number of errored symbols exceeds the threshold percentage during 1 second. There are two variants of this alarm: OAM Local Errored Symbol Period and OAM Remote Errored Symbol Period. If Link OAM entity A has problems receiving traffic from peer Link OAM entity B, A raises a local alarm and sends an indication about traffic disturbance using the Link OAM protocol to B. B then raises a remote alarm. SpecificProblem OAM Local Errored Symbol Period , , Source
LAN
AlarmType
CommunicationAlarm
Severity
Major
ProbableCause Unavailable
5.155 OAM Remote Errored Frame , , The alarm is raised if the number of errored frames exceeds the threshold during the defined period of time. There are two variants of this alarm: OAM Local Errored Frame and OAM Remote Errored Frame. If Link OAM entity A has problems receiving traffic from peer Link OAM entity B, A raises a local alarm and sends an indication about traffic disturbance using the Link OAM protocol to B. B then raises a remote alarm. SpecificProblem OAM Remote Errored Frame , , Source
LAN
AlarmType
CommunicationAlarm
Severity
Major
http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
131/219
14/08/2015
Alarm Descriptions
ProbableCause Unavailable
5.156 OAM Remote Errored Frame Period , , The alarm is raised if the number of errored frames exceeds the threshold percentage during the defined number of frames. There are two variants of this alarm: OAM Local Errored Frame Period and OAM Remote Errored Frame Period. If Link OAM entity A has problems receiving traffic from peer Link OAM entity B, A raises a local alarm and sends an indication about traffic disturbance using the Link OAM protocol to B. B then raises a remote alarm. SpecificProblem OAM Remote Errored Frame Period , , Source
LAN
AlarmType
CommunicationAlarm
Severity
Major
ProbableCause Unavailable
5.157 OAM Remote Errored Secs Summary , , The alarm is raised if the number of errored frame seconds exceeds the threshold during the defined period of time. An errored frame second is a one second interval during which at least one frame error is detected. There are two variants of this alarm: OAM Local Errored Frame Secs Summary and OAM Remote Errored Frame Secs Summary. If Link OAM entity A has problems receiving traffic from peer Link OAM entity B, A raises a local alarm and sends an indication about traffic disturbance using the Link OAM protocol to B. B then raises a remote alarm. SpecificProblem OAM Remote Errored Frame Secs Summary , , Source
LAN
AlarmType
CommunicationAlarm
Severity
Major
ProbableCause Unavailable
5.158 OAM Remote Errored Symbol Period , , The alarm is raised if the number of errored symbols exceeds the threshold percentage during 1 second. There are two variants of this alarm: OAM Local Errored Symbol Period and OAM Remote Errored Symbol Period. If Link OAM entity A has problems receiving traffic from peer Link OAM entity B, A raises a local alarm and sends an indication about traffic disturbance using the Link OAM protocol to B. B then raises a remote alarm. SpecificProblem OAM Remote Errored Symbol Period , , Source
LAN
AlarmType
CommunicationAlarm
Severity
Major
ProbableCause Unavailable http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
132/219
14/08/2015
Alarm Descriptions
5.159 OSPF LSA Database Overload The Open Shortest Path First (OSPF) routing database is full due to too many routers in the network. SpecificProblem OSPF LSA database overload Source
NE
AlarmType
CommunicationAlarm
Severity
Minor
ProbableCause StorageCapacityProblems
5.160 PFM Payload FCS Identifier Mismatch (PFM) The Payload FCS Identifier (PFI) field in the received frame does not match the configured value. SpecificProblem PFM Source
GFP
AlarmType
CommunicationAlarm
Severity
Major
ProbableCause PayloadTypeMismatch 5.160.1 Corrective Actions Repair the Virtual Container (VC) trail. 5.160.2 Alarm Clearance The Alarm is cleared when the PFI field in the received frame matches the configured value.
5.161 Phase Free Running Mode Entered The NE has lost traceability to the Grandmaster and runs in Phase Free Running Mode. SpecificProblem Phase Free Running Mode Entered Source
NE
AlarmType
CommunicationAlarm
Severity
Critical
ProbableCause Unavailable 5.161.1 Consequences Local clock accuracy is outside of the holdover specification. The clock cannot be used as a Master any more. 5.161.2 Corrective Actions No corrective action is required.
http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
133/219
14/08/2015
Alarm Descriptions
5.161.3 Alarm Clearance The alarm is cleared when the 1588v2 synchronization function enters locked status.
5.162 Phase Holdover Mode Entered The NE has lost traceability to the Grandmaster and runs in Phase Holdover Mode. SpecificProblem Phase Holdover Mode Entered Source
NE
AlarmType
CommunicationAlarm
Severity
Major
ProbableCause Unavailable 5.162.1 Consequences Local clock accuracy is still within the holdover specification and it can be used as a Master for a limited period. 5.162.2 Corrective Actions Check the reason why Grandmaster traceability is lost. 5.162.3 Alarm Clearance The alarm is cleared when the Grandmaster traceability is recovered or when the node enters into Free Running Mode after the holdover duration expires.
5.163 PLCR Partial Loss of Capacity Received (PLCR) Some of the Virtual Containers (VCs) belonging to a Virtual Concatenation Group (VCG) are temporarily removed in the receive direction. SpecificProblem PLCR Source
VCG/LCAS Standard Alarms
AlarmType
CommunicationAlarm
Severity
Major
ProbableCause BandwithReduced 5.163.1 Corrective Actions Repair the Virtual Container (VC) trail. 5.163.2 Alarm Clearance The Alarm is cleared when the temporarily removed VCs are restored.
5.164 PLCT http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
134/219
14/08/2015
Alarm Descriptions
Partial Loss of Capacity Transmit (PLCT) Some of the Virtual Containers (VCs) belonging to a Virtual Concatenation Group (VCG) are temporarily removed in the transmit direction. SpecificProblem PLCT Source
VCG/LCAS Standard Alarms
AlarmType
CommunicationAlarm
Severity
Major
ProbableCause BandwithReduced 5.164.1 Corrective Actions Repair the Virtual Container (VC) trail. 5.164.2 Alarm Clearance The Alarm is cleared when the temporarily removed VCs are restored.
5.165 PLM (Major) Payload Mismatch (PLM) The detection of PLM is based on a comparison between the expected Trail Signal Label (TSL), representing the selected/activated adaption function, and the accepted TSL. SpecificProblem PLM Source
VC3
VC4 VC412
AlarmType
CommunicationAlarm
Severity
Major
ProbableCause PayloadTypeMismatch 5.165.1 Consequences Service unavailable. 5.165.2 Corrective Actions Cease the particular transmission error. Check source.
5.166 PLM (Critical) Payload Mismatch (PLM) Nonconsistent configuration, so the received C2 byte is not equal to the expected C2 byte.
http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
135/219
14/08/2015
Alarm Descriptions
SpecificProblem PLM Source
VC12 VC4
AlarmType
CommunicationAlarm
Severity
Critical
ProbableCause SignalLabelMismatch 5.166.1 Consequences The service is unavailable. 5.166.2 Corrective Actions Check and correct configuration mismatch. 5.166.3 Alarm Clearance The alarm is cleared when the configuration mismatch is resolved.
5.167 Power Failure (Lower Input) SpecificProblem Power Failure (lower input) Source
NE
AlarmType
EquipmentAlarm
Severity
Major
ProbableCause PowerProblem
5.168 PPP Down Failure in the Data Communication Network (DCN) communication. Note: Valid for both IPv4 and IPv6. SpecificProblem PPP down Source
PPP
AlarmType
CommunicationAlarm
Severity
Minor
ProbableCause Unavailable
5.169 Protected Line Interface: EquipmentAlarm (Minor) The alarm is raised if one of the Application Plugin Units (APU) in an MSP configuration is faulty. SpecificProblem Unable to Protect Source
MSP
http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
136/219
14/08/2015
Alarm Descriptions
AlarmType
EquipmentAlarm
Severity
Minor
ProbableCause ProtectionPathFailure 5.169.1 Consequences Only one of the two APUs in the MSP configuration is operating correctly. If there is a failure in the second APU, there is a complete loss of traffic. 5.169.2 Corrective Actions Check and if necessary, replace the faulty APU. 5.169.3 Alarm Clearance The alarm is cleared when both APUs are operating correctly.
5.170 Protected Line Interface: EquipmentAlarm (Critical) The alarm is raised if both APUs (Application Plugin Units) in an MSP configuration are faulty. SpecificProblem Unable to Protect Source
MSP
AlarmType
EquipmentAlarm
Severity
Critical
ProbableCause ProtectionPathFailure 5.170.1 Consequences Both APUs in the MSP configuration are faulty. There is a complete loss of traffic. 5.170.2 Corrective Actions Check and if necessary, replace the APUs. 5.170.3 Alarm Clearance The alarm is cleared when both APUs are operating correctly.
5.171 Protected Line Interface: CommunicationAlarm (Minor) The alarm is raised if a Signal Fail (SF) is detected in one of the STM1 lines in an MSP configuration. SpecificProblem Unable to Protect Source
MSP
AlarmType
CommunicationAlarm
Severity
Minor
ProbableCause ProtectionPathFailure
http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
137/219
14/08/2015
Alarm Descriptions
5.171.1 Consequences Only one of the two STM1 lines in the MSP configuration is operating correctly. If the second STM1 line fails, there is a complete loss of traffic. 5.171.2 Corrective Actions Check the faulty STM1 line. 5.171.3 Alarm Clearance The alarm is cleared when both STM1 lines are operating correctly.
5.172 Protected Line Interface: CommunicationAlarm (Critical) The alarm is raised if both STM1 lines in an MSP configuration fails. SpecificProblem Unable to Protect Source
MSP
AlarmType
CommunicationAlarm
Severity
Critical
ProbableCause ProtectionPathFailure 5.172.1 Consequences A fail in both STM1 lines results in complete loss of traffic. 5.172.2 Corrective Actions Check the faulty STM1 lines. 5.172.3 Alarm Clearance The alarm is cleared when both STM1 lines are operating correctly.
5.173 Protected Port This alarm is only applicable for LTU2 155. The alarm is raised when both ports in an SFP port protection pair are detected as faulty. SpecificProblem Protected Port Source
SFP
AlarmType
EquipmentAlarm
Severity
Critical
ProbableCause ProtectionPathFailure 5.173.1 Consequences Traffic loss. 5.173.2 Corrective Actions http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
138/219
14/08/2015
Alarm Descriptions
If one of the SFPs appears to be working still, the following applies: If automatic switching is activated, which is the default behavior, no corrective action is needed. Otherwise perform a manual switch, see CLI User Guide, Reference [2]. If none of the SFPs appears to be working, try the following:
Danger! Never look directly into the end of a fiber optic cable, or other laser source. Equipment that transmits laser light can cause permanent eye damage. Switch off the laser before starting work on laser equipment. 1. Verify that both SFPs are still in place. 2. If the SFP LOS alarm or the RDI alarm is active, try the following: Verify that the Ycable used for SFP port protection is OK. Verify that the line is OK. Correct any relevant problems at the far end. 5.173.3 Alarm Clearance After an automatic switch, the NE monitors the active port. If the active port becomes free of faults within 30 minutes, the alarm is cleared. Otherwise, a new switching and recovery procedure is started. After a manual switch, the NE monitors the active port and clears the alarm if the active port is detected as free of faults. Otherwise, a new manual switch is required, see CLI User Guide, Reference [2].
5.174 PTM Payload Type Identifier Mismatch (PTM) The Payload Type Identifier (PTI) field in the received frame is different from 000b (client data frame), or 100b does not match one of the configured values. SpecificProblem PTM Source
GFP
AlarmType
CommunicationAlarm
Severity
Major
ProbableCause PayloadTypeMismatch 5.174.1 Corrective Actions Perform the following actions: 1. Check the local configuration. 2. Check the remote configuration.
5.175 Radio Frame (Major) The receiver failed to synchronize the frame of the received composite bit stream due to signal http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
139/219
14/08/2015
Alarm Descriptions
failure. Applicable for RAU IF (1+1). SpecificProblem Radio Frame Source
RAU IF
AlarmType
CommunicationAlarm
Severity
Major
ProbableCause LossOfFrame
5.176 Radio Frame (Critical) The receiver failed to synchronize the frame of the received composite bit stream due to signal failure. Applicable for RAU IF (1+0). SpecificProblem Radio Frame Source
RAU IF
AlarmType
CommunicationAlarm
Severity
Critical
ProbableCause LossOfFrame
5.177 Radio ID (Major) The received traffic comes from a terminal with an ID not matching the Far End ID. Possible causes are the following: Wrong Radio ID is set in either nearend or farend terminal. The antenna alignment is incorrect and the nearend radio receives a signal from another radio on the same frequency. Applicable for RAU IF (1+1). SpecificProblem Radio ID Source
RAU IF
AlarmType
CommunicationAlarm
Severity
Major
ProbableCause PathTraceMismatch 5.177.1 Consequences The protection is lost. 5.177.2 Corrective Actions Perform the following actions: 1. Check Radio ID on both nearend and farend terminal. 2. If Radio ID is correct on both nearend and farend, check antenna alignment. http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
140/219
14/08/2015
Alarm Descriptions
3. Perform an interference check by measuring input receive level when farend transmitter is turned off. 5.177.3 Alarm Clearance The alarm is cleared when correct Radio ID is set, or if Remote ID check is disabled.
5.178 Radio ID (Critical) The received traffic comes from a terminal with an ID not matching the Far End ID. Possible causes are the following: Wrong Radio ID is set in either nearend or farend terminal. The antenna alignment is incorrect and the nearend radio receives a signal from another radio. Applicable for RAU IF (1+0). SpecificProblem Radio ID Source
RAU IF
AlarmType
CommunicationAlarm
Severity
Critical
ProbableCause PathTraceMismatch 5.178.1 Consequences No connection with farend and traffic loss. 5.178.2 Corrective Actions Perform the following actions: 1. Check Radio ID on both nearend and farend terminal. 2. If Radio ID is correct on both nearend and farend, check antenna alignment. 3. Perform an interference check by measuring input receive level when farend transmitter is turned off. 5.178.3 Alarm Clearance The alarm is cleared when correct Radio ID is set, or if Remote ID check is disabled.
5.179 RAI Remote Alarm Indication (RAI) SpecificProblem RAI Source
E2/E3 Framed E1
AlarmType
CommunicationAlarm
Severity
Minor
http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
141/219
14/08/2015
Alarm Descriptions
ProbableCause RemoteAlarmIndication
5.180 RAU Power Supply Changed MINILINK TN can feed the RAU with a power supply of either +57 V DC or 48 V DC. The use of 48 V DC can support a higher power consumption of the RAU, but there are certain prerequisites. The alarm indicates that the selected RAU power supply is not available due to one of the following reasons: DC Bypass cannot be enabled because the prerequisites on the NE power supply are not fulfilled. There is incompatibility between the selected RAU power supply setting and the installed MMU/RAU. SpecificProblem RAU power supply changed Source
MMU
AlarmType
EquipmentAlarm
Severity
Minor
ProbableCause PowerProblem 5.180.1 Consequences A switch of RAU power supply may result in RAUs that are not supported by the new power supply range may be turned off. The switch can also result in changes in the power consumption. 5.180.2 Corrective Actions Verify that the correct prerequisites are fulfilled for the required power supply and that the NE is correctly configured. For more information on the prerequisites, see Troubleshooting, Reference [22]. 5.180.3 Alarm Clearance The alarm is cleared when all circumstances that prevents the NE from using the selected power supply is removed.
5.181 RCC (Major) Radio Communication Channel (RCC) Communication is lost on the RCC, between the MMU and the RAU. Applicable for the standby terminal in a 1+1 configuration. SpecificProblem RCC Source
All MMUs RAU
AlarmType
CommunicationAlarm
Severity
Major
ProbableCause Unavailable
http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
142/219
14/08/2015
Alarm Descriptions
5.181.1 Consequences Communication between the standby MMU and the RAU is lost, resulting in the transmitter on the RAU being switched off. 5.181.2 Corrective Actions
Figure 24 Workflow for RCC Alarm Corrective Actions Note: To clear the alarm, perform all the corrective actions below onsite.
To check the connection between the MMU and the RAU, do the following: 1. Check the IF cable with a SiteMaster (4.5 MHz to 350 MHz). http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
143/219
14/08/2015
Alarm Descriptions
2. Check the indoor radio connector for shortcircuit and bad or intermittent connections. 3. Check the radio interface panel connection and the station radio cable. 4. Check that the outdoor radio connector sealing is correct, that is, there is no water leakage in the cable. 5. Check that the sealing of the IF cable grounding is correct, that is, there is no water leakage in the cable. If none of the above steps clear the alarm, hardware replacement is required. To replace the faulty hardware, do the following: 6. Replace the MMU. If the RCC alarm is cleared, describe the fault on the Blue Tag and send it to the Repair Center together with the faulty MMU. If the RCC alarm is not cleared, reuse the initial MMU and go to Step 7. 7. Replace the RAU. Describe the fault on the Blue Tag and send it to the Repair Center together with the faulty RAU. For more information on how to replace the RAU, see Replacing a Radio Unit, Reference [16]. For more information on how to replace the MMU, see Replacing an MMU, Reference [13]. 5.181.3 Alarm Clearance The alarm is cleared when the RCC communication is restored.
5.182 RCC (Critical) Radio Communication Channel (RCC) Communication is lost on the RCC, between the MMU and the RAU. Applicable for 1+0 configuration and for the active terminal in a 1+1 configuration. SpecificProblem RCC Source
All MMUs RAU
AlarmType
CommunicationAlarm
Severity
Critical
ProbableCause Unavailable 5.182.1 Consequences Communication between the MMU and the RAU is lost, resulting in the transmitter on the RAU being switched off. 5.182.2 Corrective Actions
http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
144/219
14/08/2015
Alarm Descriptions
Figure 25 Workflow for RCC Alarm Corrective Actions Note: To clear the alarm, perform all the corrective actions below onsite.
To check the connection between the MMU and the RAU, do the following: 1. Check the IF cable with a SiteMaster (4.5 MHz to 350 MHz). 2. Check the indoor radio connector for shortcircuit and bad or intermittent connections. 3. Check the radio interface panel connection and the station radio cable. 4. Check that the outdoor radio connector sealing is correct, that is, there is no water leakage in the cable. 5. Check that the sealing of the IF cable grounding is correct, that is, there is no water leakage in the cable. http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
145/219
14/08/2015
Alarm Descriptions
If none of the above steps clear the alarm, hardware replacement is required. To replace the faulty hardware, do the following: 6. Replace the MMU. If the RCC alarm is cleared, describe the fault on the Blue Tag and send it to the Repair Center together with the faulty MMU. If the RCC alarm is not cleared, reuse the initial MMU and go to Step 7. 7. Replace the RAU. Describe the fault on the Blue Tag and send it to the Repair Center together with the faulty RAU. For more information on how to replace the RAU, see Replacing a Radio Unit, Reference [16]. For more information on how to replace the MMU, see Replacing an MMU, Reference [13]. 5.182.3 Alarm Clearance The alarm is cleared when the RCC communication is restored.
5.183 RDI (Minor) Remote Defect Indication (RDI) The RDI alarm indicates that the traffic signal transmitted from the near end line interface is received with errors on the far end line interface. SpecificProblem RDI Source
MS/RS
VC12 VC4
AlarmType
CommunicationAlarm
Severity
Minor
ProbableCause FarEndReceiverFailure 5.183.1 Consequences The service is unavailable at far end. 5.183.2 Corrective Actions
http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
146/219
14/08/2015
Alarm Descriptions
Figure 26 Workflow for RDI Alarm Corrective Actions, Part 1
http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
147/219
14/08/2015
Alarm Descriptions
Figure 27 Workflow for RDI Alarm Corrective Actions, Part 2 Perform the following steps: 1. Check if any alarm is raised on the farend receiving interface. If there is no alarm raised on the farend, go to Step 2. If there are one or more alarms raised on the farend, review the alarms and take corrective actions according to their alarm description. For basic and general fault finding instructions of RDI, go to Step 3 2. Perform a cold restart of the PlugIn Unit (PIU) that has received the RDI alarm, and restart MINILINK Craft.
Caution! http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
148/219
14/08/2015
Alarm Descriptions
A cold restart will disturb the traffic. Onsite action: If the RDI alarm is not cleared after the restart, replace the PIU on the nearend. Describe the fault on the Blue Tag and send it to the Repair Center together with the faulty PIU. Onsite action: If the RDI alarm is cleared, monitor the hop for further alarms. If further alarms are raised without any alarms occurring on the farend interface, replace the PIU on the nearend. Describe the fault on the Blue Tag and send it to the Repair Center together with the faulty PIU. 3. Make sure that the configuration is correctly set up on the nearend and the farend and is according to the Site Installation Documentation (SID). If the configuration of the nearend and the farend is not correctly set up and is not according to the SID, take corrective actions. If the RDI alarm is not cleared after the correction, go to Step 4. If the configuration of the nearend and the farend is correctly set up and is according to the SID, go to Step 4. 4. Perform a line loop test on the farend interface. Onsite action: If the alarm is not cleared on the farend during the test, replace the PIU on the farend. Describe the fault on the Blue Tag and send it to the Repair Center together with the faulty PIU. If the alarm is cleared on the farend during the test, go to Step 5. 5. Perform a line loop test on the nearend interface. If the alarm is not cleared on the farend during the test, go to Step 6. Onsite action: If the alarm is cleared on the farend during the test, replace the PIU on the nearend. Describe the fault on the Blue Tag and send it to the Repair Center together with the faulty PIU. 6. Onsite action: Check the transmission and the cables between the transmitting and receiving interfaces for faults. For more information on how to replace the faulty PIU, see applicable CPI under HW Management folder. 5.183.3 Alarm Clearance The alarm is cleared when the far end interface receives a valid traffic signal.
5.184 RDI (Major) Remote Defect Indication (RDI) The RDI alarm indicates that the traffic signal transmitted from the near end line interface is received with errors on the far end line interface. SpecificProblem RDI Source
AU4 MS TU3
TU12 VC3
http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
149/219
14/08/2015
Alarm Descriptions
VC4 VC12 AlarmType
CommunicationAlarm
Severity
Major
ProbableCause FarEndReceiverFailure 5.184.1 Consequences Service unavailable at far end. 5.184.2 Corrective Actions
Figure 28 Workflow for RDI Alarm Corrective Actions, Part 1
http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
150/219
14/08/2015
Alarm Descriptions
Figure 29 Workflow for RDI Alarm Corrective Actions, Part 2 Perform the following steps: 1. Check if any alarm is raised on the farend receiving interface. If there is no alarm raised on the farend, go to Step 2. If there are one or more alarms raised on the farend, review the alarms and take corrective actions according to their alarm description. For basic and general fault finding instructions of RDI, go to Step 3. 2. Perform a cold restart of the PlugIn Unit (PIU) that has received the RDI alarm, and restart MINILINK Craft.
Caution! http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
151/219
14/08/2015
Alarm Descriptions
A cold restart will disturb the traffic. Onsite action: If the RDI alarm is not cleared after the restart, replace the PIU on the nearend. Describe the fault on the Blue Tag and send it to the Repair Center together with the faulty PIU. Onsite action: If the RDI alarm is cleared, monitor the hop for further alarms. If further alarms are raised without any alarms occurring on the farend interface, replace the PIU on the nearend. Describe the fault on the Blue Tag and send it to the Repair Center together with the faulty PIU. 3. Make sure that the configuration is correctly set up on the nearend and the farend, and is according to the Site Installation Documentation (SID). If the configuration of the nearend and the farend is not correctly set up and is not according to the SID, take corrective actions. If the RDI alarm is not cleared after the correction, go to Step 4. If the configuration of the nearend and the farend is correctly set up and is according to the SID, go to Step 4. 4. Perform a line loop test on the farend interface. Onsite action: If the alarm is not cleared on the farend during the test, replace the PIU on the farend. Describe the fault on the Blue Tag and send it to the Repair Center together with the faulty PIU. If the alarm is cleared on the farend during the test, go to Step 5. 5. Perform a line loop test on the nearend interface, that has the RDI alarm raised. If the alarm is not cleared on the farend during the test, go to Step 6. Onsite action: If the alarm is cleared on the farend during the test, replace the PIU on the nearend. Describe the fault on the Blue Tag and send it to the Repair Center together with the faulty PIU. 6. Onsite action: Check the transmission and the cables between the transmitting and receiving interfaces for faults. For more information on how to replace the faulty PIU, see applicable CPI under HW Management folder. 5.184.3 Alarm Clearance The alarm is cleared when the farend interface receives a valid traffic signal.
5.185 RDI Bit Set in CCM A Maintenance End Point (MEP) has received a Continuity Check Message (CCM) frame with the Remote Defect Indication (RDI) field set. Note: This alarm is available with both the IEEE 802.1ag and the ITUT Y.1731 standards for Connectivity Fault Management (CFM). SpecificProblem RDI bit set in CCM Source
LAN with MEP
WAN with MEP LAG with MEP
http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
152/219
14/08/2015
Alarm Descriptions
AlarmType
CommunicationAlarm
Severity
Warning
ProbableCause FarEndReceiverFailure 5.185.1 Corrective Actions No corrective action is required.
5.186 Received Invalid CCM The Maintenance End Point (MEP) has received at least one invalid Continuity Check Message (CCM), the CCM interval of which has not yet timed out. Note: This alarm is only available when using the IEEE 802.1ag standard for Connectivity Fault Management (CFM). SpecificProblem Received Invalid CCM Source
LAN with MEP
WAN with MEP LAG with MEP
AlarmType
CommunicationAlarm
Severity
Major
ProbableCause SignalLabelMismatch 5.186.1 Corrective Actions No corrective action is required.
5.187 Remote Failure Indication Persistence of an RDIIMA defect at the nearend (more than 2.5 +/ 0.5 sec). An Rx failure is detected on the corresponding interface at the nearend IMA unit. SpecificProblem Remote Failure Indication Source
IMA Link
AlarmType
CommunicationAlarm
Severity
Critical
ProbableCause RemoteAlarmInterface 5.187.1 Consequences Since the farend detects a failure at the corresponding interface, the link is not active anymore. Related IMA groups can also be affected by the fault: in case the IMA group goes below the "minimum number of (active) links" no Asynchronous Transfer Mode (ATM) traffic can flow at all through the group. In this case the operational status of related ATMIMA (IMA group) and ATM goes to down. If the IMA group still have a minimum number of links it can still transmit the guaranteed bandwidth of traffic. http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
153/219
14/08/2015
Alarm Descriptions
5.187.2 Alarm Analysis The farend link should experience any fault from physical (Loss Of Signal (LOS)/Loss Of Frame (LOF)/Alarm Indication Signal (AIS)) or TC (LCD) layer. 5.187.3 Corrective Actions Check that the corresponding nearend link is properly connected and configured. 5.187.4 Alarm Clearance The alarm is cleared when the farend no longer detects any link failure.
5.188 Remote Loss of Frames The alarm is raised if a frame received at the nearend has the R bit set in the control word. A frame that is received with the Rbit set in the control word indicates failure of the connection in the opposite direction. SpecificProblem Remote Loss of Frames Source
CES
AlarmType
CommunicationAlarm
Severity
Minor
ProbableCause RemoteAlarmIndication 5.188.1 Consequences A remote loss of frames alarm is reported in MINILINK Craft. If structure aware mode is configured, a Remote Defect Indication (RDI) alarm is generated. 5.188.2 Corrective Actions Check the network performance in the nearend to farend direction. The alarm indicates that there is a problem with network traffic from the nearend to the farend. 5.188.3 Alarm Clearance The alarm is cleared when a frame received at the nearend does not have the R bit set in the control word.
5.189 Remote Tx Switch Over This alarm is raised when an active radio switch over is ordered from the farend side. It is only valid in Hot Standby (HSB). By default, raising of this alarm is disabled. It can be enabled in MINILINK Craft, see MINILINK Craft User Interface Descriptions, Reference [7], but it is only recommended to enable it in hops that have high fade margins and low probability for deep flat or multipath fading. SpecificProblem Remote Tx Switch Over Source
SWITCH
AlarmType
EquipmentAlarm
http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
154/219
14/08/2015
Severity
Alarm Descriptions
Major
ProbableCause ProtectionPathFailure 5.189.1 Consequences The protection switching function is locked until the alarm is reset manually. Even if the initial fault that triggered the switch over is corrected, the switching function does not work and the hop only functions as 1+0 until the alarm is reset manually. 5.189.2 Alarm Analysis The remote TX switch over function in HSB is used for protection of radio equipment after the output RF power detector; this includes branching, flexible waveguide, power splitter, and antenna. Faults in this equipment can be caused, for example, by high wind load or fading conditions (both rain and multipath). This kind of equipment fault is not possible to detect at the nearend side. If such a fault occurs on the active TX path, the farend side loses input signal on both receivers. It is likely that either the Radio Frame alarm or the RF Input Level alarm is raised. After 4 seconds, a command is sent to the nearend side to switch active TX and after completion the connection is up again. Because a remote TX switch over clears any alarms raised by the initial fault, the Remote TX Switch Over alarm must be raised to prevent a switch over back to the faulty path. For this reason, the Remote TX Switch Over alarm must be reset manually if full equipment protection in HSB is wanted. 5.189.3 Corrective Actions Correct the initial fault that triggered the switch over, for more information see Troubleshooting, Reference [22]. 5.189.4 Alarm Clearance The alarm is not cleared automatically. It must be reset manually in MINILINK Craft on the SWITCH Alarms and Status page for the applicable MMU. The reason for this is that the fault that triggered the remote TX switch over must be understood and corrected before a remote TX switch over can take place again. Always reset the Remote TX Switch Over alarm before taking a hop into service as installation work and testing can also trigger the function.
5.190 Reserved Position The alarm is raised if the unit in a certain position is of a different type than the type of unit the position is reserved for. SpecificProblem Reserved Position (Only applicable if source is Plugin Unit or RAU Source
Reserved Position at (Only applicable if source is SFP)
Plugin Unit
RAU SFP
AlarmType
EquipmentAlarm
Severity
Critical
ProbableCause ReplaceableUnitTypeMismatch
http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
155/219
14/08/2015
Alarm Descriptions
5.190.1 Consequences The unit is not operating correctly. 5.190.2 Corrective Actions Clear the slot reservation or install a correct unit. 5.190.3 Alarm Clearance The alarm is cleared when the slot reservation is cleared or a correct unit is installed.
5.191 RF Input Level (Critical) The received Radio Frequency (RF) input signal level drops below the threshold for the receiver. Applicable for RF (1+0). SpecificProblem RF Input Level Source
RF
AlarmType
CommunicationAlarm
Severity
Critical
ProbableCause ReceiverFailure 5.191.1 Corrective Actions
http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
156/219
14/08/2015
Alarm Descriptions
Figure 30 Workflow for RF Input Level Alarm Corrective Actions, Part 1
http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
157/219
14/08/2015
Alarm Descriptions
Figure 31 Workflow for RF Input Level Alarm Corrective Actions, Part 2
http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
158/219
14/08/2015
Alarm Descriptions
Figure 32 Workflow for RF Input Level Alarm Corrective Actions, Part 3 Perform the following steps: 1. Make sure that the configuration of the nearend and the farend is according to the Site Installation Documentation (SID). If the configuration of the nearend and the farend is not according to the SID, take corrective actions. If the RF Input Level alarm is not cleared after the correction, go to Step 2. If the configuration of the nearend and the farend is according to the SID, go to Step 2. 2. Check if the RF input level is below the threshold level for BER 106 for the current http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
159/219
14/08/2015
Alarm Descriptions
configuration. If the RF input level is not below the threshold level for BER 106 for the current configuration, go to step Step 3. If the RF input level is below the threshold level for BER 106 for the current configuration, go to Step 4. 3. Perform a cold restart of the RAU and restart MINILINK Craft.
Caution! A cold restart will disturb the traffic. Onsite action: If the RF Input Level alarm is not cleared after the restart, replace the RAU on the nearend. Describe the fault on the Blue Tag and send it to the Repair Center together with the faulty RAU. Onsite action: If the RF Input Level alarm is cleared, monitor the hop for further RF Input Level alarms. If the alarm is raised again while RF input level is higher than the threshold level for BER 106 for the current configuration, replace the RAU on the nearend. Describe the fault on the Blue Tag and send it to the Repair Center together with the faulty RAU. 4. Onsite action: Perform an RF loop test on the nearend RAU. Turn off the RAU transmitter on the farend during the test. If the RF input power is not about 50 dBm (± 10 dB) during the test, replace the RAU on the nearend. Describe the fault on the Blue Tag and send it to the Repair Center together with the faulty RAU. If the RF input power is about 50 dBm (± 10 dB) during the test, go to Step 5. 5. Check if the RF Output Level alarm is active on the farend RAU. If the RF Output Level alarm is not active, go to Step 6. Onsite action: If the RF Output Level alarm is active, replace the RAU on the farend. Describe the fault on the Blue Tag and send it to the Repair Center together with the faulty RAU. 6. Check if the RF output level on the farend is according to the link budget. If the RF output level is not according to the link budget, verify the correct value to be used with transmission design department and change the value. If the RF output level is according to the link budget, go to Step 7. 7. Onsite action: Perform an RF loop test on the farend RAU. Turn off the RAU transmitter on the nearend during the test. If the RF input power is not about 50 dBm (± 10 dB) on the farend RAU during the test, replace the RAU on the farend. Describe the fault on the Blue Tag and send it to the Repair Center together with the faulty RAU. If the RF input power is about 50 dBm (± 10 dB) on the farend RAU during the test, go to Step 8. 8. Onsite action: Check fading conditions and weather circumstances. If link performance is not affected by propagation issues, go to Step 9. If link performance is affected by propagation issues, consult the transmission design department on how to address the link budget. 9. Onsite action: Check for possible obstacles interfering with the line of sight. If there are no obstacles, go to Step 10. http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
160/219
14/08/2015
Alarm Descriptions
If there are obstacles, consult the transmission design department. 10. Onsite action: Make sure that the antennas are aligned correctly on the nearend and the far end to meet the link budget target. If the antennas are not aligned correctly, take corrective actions. If the antennas are aligned correctly, go to Step 11. 11. Onsite action: Check the status of the RF input level, that can be stable or can vary over time indicating multipath fading. If you are unsure, monitor the RF input level for 24 hours to find cyclic variations. If the RF input level is stable, go to Step 12. If the RF input level decrease is intermittent or periodic, consult the transmission design department to analyze the possible reflections and refractions. 12. Onsite action: Make sure that the polarization on the nearend and the farend is set according to the link budget planning. If the polarization on the nearend and the farend is not correctly set, take corrective actions. If the polarization on the nearend and the farend is correctly set, go to Step 13. 13. Onsite action: Replace the antenna on the nearend. If the RF Input Level alarm is not cleared after the replacement, reinstall the initial antenna, and go to Step 14. If the RF Input Level alarm is cleared after the replacement, describe the fault on the Blue Tag and send it to the Repair Center together with the faulty antenna. 14. Onsite action: Replace the antenna on the farend. Describe the fault on the Blue Tag and send it to the Repair Center together with the faulty antenna. For more information on how to replace the RAU, see Replacing a Radio Unit, Reference [16]. For more information on antenna alignment and antenna installation, see Installing Outdoor Equipment, Reference [5]. 5.191.2 Alarm Clearance The alarm is cleared when the received RF input signal is above the threshold for the receiver.
5.192 RF Input Level Div (Minor) The received Radio Frequency (RF) input signal level drops below the threshold for the Rx diversity channel of the TRX Space Diversity Combiner (SDC). RF Input Level and SDC Div Hardware Error alarms mask RF Input Level Div alarm because of higher severity in the receiver section. Applicable for 1+1 Space Diversity configuration. SpecificProblem RF Input Level Div Source
TRX SDC
AlarmType
CommunicationAlarm
Severity
Minor
ProbableCause ReceiverFailure 5.192.1 Corrective Actions Check that the cable is correctly connected between the TRX SDC unit and the RF branching filter. If http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
161/219
14/08/2015
Alarm Descriptions
the cable is broken, replace the cable. 5.192.2 Alarm Clearance The alarm is cleared when the cable is correctly connected between the TRX SDC unit and the RF branching filter.
5.193 RF Input Level Div (Major) The received Radio Frequency (RF) input signal level drops below the threshold for the Rx diversity channel of the TRX Space Diversity Combiner (SDC). RF Input Level and SDC Div Hardware Error alarms mask RF Input Level Div alarm because of higher severity in the receiver section. Applicable for 1+0 Space Diversity configuration. SpecificProblem RF Input Level Div Source
TRX SDC
AlarmType
CommunicationAlarm
Severity
Major
ProbableCause ReceiverFailure 5.193.1 Corrective Actions Check that the cable is correctly connected between the TRX SDC unit and the RF branching filter. If the cable is broken, replace the cable. 5.193.2 Alarm Clearance The alarm is cleared when the cable is correctly connected between the TRX SDC unit and the RF branching filter.
5.194 RF Input Level Main (Minor) The received Radio Frequency (RF) input signal level drops below the threshold for the Rx main channel of the TRX Space Diversity Combiner (SDC). RF Input Level and SDC Main Hardware Error alarms mask RF Input Level Main alarm because of higher severity in the receiver section. Applicable for 1+1 Space Diversity configuration. SpecificProblem RF Input Level Main Source
TRX SDC
AlarmType
CommunicationAlarm
Severity
Minor
ProbableCause ReceiverFailure 5.194.1 Corrective Actions Check that the cable is correctly connected between the TRX SDC unit and the RF branching filter. If the cable is broken, replace the cable. 5.194.2 Alarm Clearance http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
162/219
14/08/2015
Alarm Descriptions
The alarm is cleared when the cable is correctly connected between the TRX SDC unit and the RF branching filter.
5.195 RF Input Level Main (Major) The received Radio Frequency (RF) input signal level drops below the threshold for the Rx main channel of the TRX Space Diversity Combiner (SDC). RF Input Level and SDC Main Hardware Error alarms mask RF Input Level Main alarm because of higher severity in the receiver section. Applicable for 1+0 Space Diversity configuration. SpecificProblem RF Input Level Main Source
TRX SDC
AlarmType
CommunicationAlarm
Severity
Major
ProbableCause ReceiverFailure 5.195.1 Corrective Actions Check that the cable is correctly connected between the TRX SDC unit and the RF branching filter. If the cable is broken, replace the cable. 5.195.2 Alarm Clearance The alarm is cleared when the cable is correctly connected between the TRX SDC unit and the RF branching filter.
5.196 RF Input Threshold The Radio Frequency (RF) input level drops below the RF Input Alarm Threshold. SpecificProblem RF Input Threshold Source
RF SWITCH
AlarmType
CommunicationAlarm
Severity
Warning
ProbableCause DegradedSignal
5.197 RF Input Threshold Protection The Radio Frequency (RF) input level of both receivers in a protected terminal drops below their respective RF Input Alarm Threshold. SpecificProblem RF Input Threshold Protection Source
SWITCH
AlarmType
CommunicationAlarm
Severity
Warning
ProbableCause DegradedSignal http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
163/219
14/08/2015
Alarm Descriptions
5.198 RF Output Level (Major) The RF Output Level alarm is triggered if the transmitter is unable to achieve the configured RF output power. Applicable for RAU RF (1+1 working standby) standby transmitter. SpecificProblem RF Output Level Source
RF
AlarmType
CommunicationAlarm
Severity
Major
ProbableCause TransmitterFailure 5.198.1 Corrective Actions
Figure 33 Workflow for RF Output Level (Major) Alarm Corrective Actions http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
164/219
14/08/2015
Alarm Descriptions
Do the following: 1. Perform an RF loop test on the nearend RAU. Turn off both farend RAU transmitters during the test. Onsite action: If the input power is not about 50 dBm (± 10 dB), replace the RAU with the alarm raised on the nearend. Describe the fault on the Blue Tag and send it to the Repair Center together with the faulty RAU. If the input power is about 50 dBm (± 10 dB), go to Step 2. 2. Perform a cold restart of the RAU and restart MINILINK Craft.
Caution! A cold restart will disturb the traffic. Onsite action: If the RF Output Level alarm is not cleared after the restart, replace the RAU on the nearend. Describe the fault on the Blue Tag and send it to the Repair Center together with the faulty RAU. Onsite action: If the RF Output Level alarm is cleared, monitor the hop for further RF Output Level alarms. If the alarm is raised again, replace the RAU on the nearend. Describe the fault on the Blue Tag and send it to the Repair Center together with the faulty RAU. For more information on how to replace the RAU, see Replacing a Radio Unit, Reference [16]. 5.198.2 Alarm Clearance The alarm is cleared when the transmitter is able to achieve the configured RF output power.
5.199 RF Output Level (Critical) The RF Output Level alarm is triggered if the transmitter is unable to achieve the configured RF output power. Applicable for RAU RF (1+0) and RAU RF (1+1) active transmitter. SpecificProblem RF Output Level Source
RF
AlarmType
CommunicationAlarm
Severity
Critical
ProbableCause TransmitterFailure 5.199.1 Corrective Actions
http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
165/219
14/08/2015
Alarm Descriptions
Figure 34 Workflow for RF Output Level (Critical) Alarm Corrective Actions Do the following: 1. Perform an RF loop test on the nearend RAU. Turn off both farend RAU transmitters during the test. Onsite action: If the input power is not about 50 dBm (± 10 dB), replace the RAU on the nearend. Describe the fault on the Blue Tag and send it to the Repair Center together with the faulty RAU. If the input power is about 50 dBm (± 10 dB), go to Step 2. 2. Perform a cold restart of the RAU and restart MINILINK Craft.
Caution! A cold restart will disturb the traffic. http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
166/219
14/08/2015
Alarm Descriptions
Onsite action: If the RF Output Level alarm is not cleared after the restart, replace the RAU on the nearend. Describe the fault on the Blue Tag and send it to the Repair Center together with the faulty RAU. Onsite action: If the RF Output Level alarm is cleared, monitor the hop for further RF Output Level alarms. If the alarm is raised again, replace the RAU on the nearend. Describe the fault on the Blue Tag and send it to the Repair Center together with the faulty RAU. For more information on how to replace the RAU, see Replacing a Radio Unit, Reference [16]. 5.199.2 Alarm Clearance The alarm is cleared when the transmitter is able to achieve the configured RF output power.
5.200 RF Output Level ATPC Automatic Transmit Power Control (ATPC) This alarm indicates that the ATPC Fallback functionality is activated. The transmitter output power is continuously at Maximum ATPC Output Power too long. This can occur due to the following reasons: Maximum ATPC Output Power is set too low. The hop attenuation increases (steadystate). The transmitter Power Amplifier is deteriorating. The Low Noise Amplifier in Rx is deteriorating. SpecificProblem RF Output Level ATPC Source
RF
AlarmType
CommunicationAlarm
Severity
Major
ProbableCause TransmitterFailure 5.200.1 Consequences The hop might be down or it can have low availability. 5.200.2 Corrective Actions Try the following: 1. Increase the Maximum ATPC Output Power. 2. Check if obstacles are placed in the radio path between the two hops' antennas (at clear sky conditions). 3. If the RAU is faulty, replace it, see Replacing a Radio Unit, Reference [16]. To restore normal ATPC function again: 1. Disable ATPC (that is set Output Power Mode to RTPC). 2. Enable ATPC again. 5.200.3 Alarm Clearance http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
167/219
14/08/2015
Alarm Descriptions
The alarm is cleared when normal ATPC function is restored.
5.201 RLIME Oversubscription The total capacity of the packet links in the RLIME group exceeds the maximum capacity of the RL IME group. This can occur during RLIME configuration or radio link configuration. It can also occur if the Adaptive Modulation feature increases the link capacity. SpecificProblem RLIME Oversubscription Source
RLIME
AlarmType
CommunicationAlarm
Severity
Critical
ProbableCause Unavailable 5.201.1 Consequences Traffic can be lost. 5.201.2 Corrective Actions Reduce the number of packet links in the RLIME group or reduce the capacity of the packet links in the RLIME group. 5.201.3 Alarm Clearance The alarm is cleared when the total capacity of the packet links configured for the RLIME group is no longer higher than the maximum capacity of the RLIME group.
5.202 RLIME Resource Group1 Oversubscription The RLIME resource group uses more capacity than the maximum capacity allowed. SpecificProblem RLIME Resource Group1 Oversubscription Source
NE
AlarmType
CommunicationAlarm
Severity
Critical
ProbableCause Unavailable 5.202.1 Consequences Loss of traffic. 5.202.2 Corrective Actions Decrease the capacity used by the RLIME members of the resource group. 5.202.3 Alarm Clearance The alarm is cleared when the RLIME members of the resource group no longer use a capacity that is higher than the maximum capacity allowed. http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
168/219
14/08/2015
Alarm Descriptions
5.203 RLIME Degraded Service SpecificProblem Degraded Service Source
RLIME
AlarmType
CommunicationAlarm
Severity
Major
ProbableCause Unavailable
5.204 RLIME No Traffic SpecificProblem No Traffic Source
RLIME
AlarmType
CommunicationAlarm
Severity
Critical
ProbableCause Unavailable
5.205 RLIME Reassembly Failure SpecificProblem Reassembly failure Source
RLIME
AlarmType
QualityOfServiceAlarm
Severity
Major
ProbableCause DegradedSignal
5.206 Running Configuration Not Accepted The MMU/RAU/SFP could not accept the running configuration; the service LED is flashing. The unit could also be subject to a software upgrade. SpecificProblem Running configuration not accepted Source
All MMUs
All RAUs All SFPs
AlarmType
EquipmentAlarm
Severity
Major
ProbableCause ReplaceableUnitTypeMismatch 5.206.1 Corrective Actions The problem can occur if the inserted board is using an incompatible software version. See the compatibility document in the Planning folder of the CPI Library for instructions on how to verify and align plugin unit and software compatibility. If the alarm occurs even though the software version installed on the NE is compatible with the plug http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
169/219
14/08/2015
Alarm Descriptions
in unit; save configuration, remove the board, make clear reservation, and insert board again. Download configuration file.
5.207 Rx AFC The frequency of the received signal is outside the range of the Automatic Frequency Control (AFC) in the RAU receiver. The MMU has detected a deviation between the actual received second intermediate frequency and the theoretical frequency. The theoretical frequency requires a frequency change as it is at the boundary of the allowed range. SpecificProblem Rx AFC Source
RF
AlarmType
CommunicationAlarm
Severity
Major
ProbableCause ReceiverFailure 5.207.1 Corrective Actions
http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
170/219
14/08/2015
Alarm Descriptions
Figure 35 Workflow for Rx AFC Alarm Corrective Actions Perform the following steps: 1. Make sure that the Rx frequency on the nearend corresponds to the Tx frequency on the far end. 2. Onsite action: Perform an interference test, see Verifying an Installation, Reference [24]. Note: An undesired signal in the receiver can cause interference in microwave systems. As a result, the AFC cannot monitor the actually received frequency signal.
3. Onsite action: Perform a cold restart of the RAU and restart MINILINK Craft.
Caution! http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
171/219
14/08/2015
Alarm Descriptions
A cold restart will disturb the traffic. If the Rx AFC alarm is not cleared after the restart, replace the RAU. Describe the fault on the Blue Tag and send it to the Repair Center together with the faulty RAU. If the Rx AFC alarm is cleared, monitor the hop for further Rx AFC alarms. If the alarm is raised again, replace the RAU. Describe the fault on the Blue Tag and send it to the Repair Center together with the faulty RAU. For more information on how to replace the RAU, see Replacing a Radio Unit, Reference [16]. 5.207.2 Alarm Clearance The alarm is cleared when the incoming RF signal is within the range of the receiver.
5.208 RX Frequency (Major) The receiver frequency synthesizer loop is unlocked. Main reason for an RX Frequency alarm is a hardware fault in the RAU. SpecificProblem RX Frequency Source
RF (1+1)
AlarmType
CommunicationAlarm
Severity
Major
ProbableCause ReceiverFailure 5.208.1 Consequences The receiving path is switched. 5.208.2 Corrective Actions
http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
172/219
14/08/2015
Alarm Descriptions
Figure 36 Workflow for RX Frequency Alarm Corrective Actions Do the following: 1. Perform a cold restart of the RAU and restart MINILINK Craft.
Caution! A cold restart will disturb the traffic. Onsite action: If the RX Frequency alarm is not cleared after the restart, replace the RAU. Describe the fault on the Blue Tag and send it to the Repair Center together with the faulty RAU. Onsite action: If the RX Frequency alarm is cleared, monitor the hop for further RX Frequency alarms. If the alarm is raised again, replace the RAU. Describe the fault on the Blue Tag and send it to the Repair Center together with the faulty RAU. For more information on how to replace the RAU, see Replacing a Radio Unit, Reference [16].
5.209 RX Frequency (Critical) The receiver frequency synthesizer loop is unlocked. Main reason for an RX Frequency alarm is a http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
173/219
14/08/2015
Alarm Descriptions
hardware fault in the RAU. SpecificProblem RX Frequency Source
RF (1+0)
AlarmType
CommunicationAlarm
Severity
Critical
ProbableCause ReceiverFailure 5.209.1 Consequences Degradation in traffic capacity, or traffic is completely lost. 5.209.2 Corrective Actions
Figure 37 Workflow for RX Frequency Alarm Corrective Actions Do the following: 1. Perform a cold restart of the RAU and restart MINILINK Craft.
http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
174/219
14/08/2015
Alarm Descriptions
Caution! A cold restart will disturb the traffic. Onsite action: If the RX Frequency alarm is not cleared after the restart, replace the RAU. Describe the fault on the Blue Tag and send it to the Repair Center together with the faulty RAU. Onsite action: If the RX Frequency alarm is cleared, monitor the hop for further RX Frequency alarms. If the alarm is raised again, replace the RAU. Describe the fault on the Blue Tag and send it to the Repair Center together with the faulty RAU. For more information on how to replace the RAU, see Replacing a Radio Unit, Reference [16].
5.210 Rx IF Input Failure on the receiver Intermediate Frequency (IF) signal from the RAU to the MMU. SpecificProblem Rx IF Input Source
RAU IF
AlarmType
CommunicationAlarm
Severity
Major
ProbableCause ReceiverFailure
5.211 Rx Link Misconnected Rx link is not connected to the same farend Inverse Multiplexer over ATM (IMA) unit as the other Rx links in the group. SpecificProblem Rx Link Misconnected Source
IMA Group
AlarmType
CommunicationAlarm
Severity
Critical
ProbableCause ConfigurationOrCustomizationError 5.211.1 Consequences No Asynchronous Transfer Mode (ATM) traffic can be received from the specific IMA Link. Related IMA groups can also be affected by the fault: in case the IMA group goes below the "minimum number of (active) links" no ATM traffic can flow at all through the group. In this case the operational status of related ATMIMA (IMA group) and ATM goes to down. If the IMA group still have a minimum number of links it can still receive the guaranteed bandwidth of traffic. 5.211.2 Alarm Analysis Wrong connection of the Rx IMA link. 5.211.3 Corrective Actions Connect the Rx IMA link to the same farend IMA unit as the other Rx links in the group.
http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
175/219
14/08/2015
Alarm Descriptions
5.211.4 Alarm Clearance The alarm is cleared when the Rx IMA link is correctly connected to the farend IMA unit.
5.212 Rx Unusable (FarEnd) The alarm is reported when the farend Inverse Multiplexer over ATM (IMA) unit determines that its Rx link cannot be used for reception in the group. SpecificProblem Rx Unusable (FarEnd) Source
IMA Group
AlarmType
CommunicationAlarm
Severity
Major
ProbableCause RemoteAlarmInterface 5.212.1 Consequences No Asynchronous Transfer Mode (ATM) traffic can be transmitted over the specific IMA Link. Related IMA groups can also be affected by the fault: in case the IMA group goes below the "minimum number of (active) links" no ATM traffic can flow at all through the group. In this case the operational status of related ATMIMA (IMA group) and ATM goes to down. If the IMA group still have a minimum number of links it can still transmit the guaranteed bandwidth of traffic. 5.212.2 Alarm Analysis A fault in the farend link or protocol is detected by the IMA unit at Rx direction. 5.212.3 Corrective Actions Check the status of the farend Rx link. 5.212.4 Alarm Clearance The alarm is cleared when the farend Rx link failure is deleted or the cause at the corresponding nearend link.
5.213 SDC DADE Calibration Mismatch or Not Calibrated The alarm is raised in the following cases: Space Diversity Combiner (SDC) Delay Antenna Delay Equalization (DADE) calibration is not performed. TRX SDC is replaced, but no new DADE calibration is performed. SpecificProblem SDC DADE Calibration Mismatch or Not Calibrated Source
TRX SDC
AlarmType
EquipmentAlarm
Severity
Major
ProbableCause ReplaceableUnitProblem 5.213.1 Consequences http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
176/219
14/08/2015
Alarm Descriptions
The SDC function cannot be used. The path selection is not allowed and it is not possible to use the combining function until valid DADE calibration is performed. 5.213.2 Alarm Analysis After SDC is enabled, the default setting for path selector is the main channel. Without DADE calibration, SDC combiner mode cannot be activated. The main channel works without DADE calibration. When SDC is enabled, DADE calibration must be performed. The problem is that the DADE calibration is not performed after TRX SDC installation or when there is a TRX SDC replacement. 5.213.3 Corrective Actions Perform DADE calibration. 5.213.4 Alarm Clearance The alarm is cleared when DADE calibration is performed.
5.214 SDC Div Hardware Error The alarm is raised when there is a hardware error on the Rx diversity channel of the TRX Space Diversity Combiner (SDC). SpecificProblem SDC Div Hardware Error Source
TRX SDC
AlarmType
EquipmentAlarm
Severity
Major
ProbableCause ReplaceableUnitProblem 5.214.1 Consequences For 1+0 Space Diversity configuration, the SDC function is out of work because the receiver for the diversity channel is faulty. The system still works as a single receiver, without affecting the traffic. For 1+1 Space Diversity configuration, an Rx diversity switch is performed to the MMU and TRX SDC with no faults. The SDC is available with full functionality. 5.214.2 Alarm Analysis SDC Diversity Hardware Error indicates that the SDC function is not available because of a failure inside the Rx diversity receiver. The Rx main receiver still works, so no traffic is affected. In 1+1 Space Diversity configuration, SDC Main Hardware Error and SDC Div Hardware Error alarms are used as a trigger for Radio Protection Switch (RPS), that is, Rx diversity switch. The switch is performed to use the signal coming from the companion MMU connected to the TRX having full SDC functionality. The switch does not affect the traffic and the protection is an equipment and radio protection. 5.214.3 Corrective Actions Replace the faulty TRX SDC, see Replacing a TRX, Reference [19].
http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
177/219
14/08/2015
Alarm Descriptions
5.214.4 Alarm Clearance The alarm is cleared when the faulty TRX SDC is replaced.
5.215 SDC Main Hardware Error The alarm is raised when there is a hardware error on the Rx main channel of the TRX Space Diversity Combiner (SDC). SpecificProblem SDC Main Hardware Error Source
TRX SDC
AlarmType
EquipmentAlarm
Severity
Major
ProbableCause ReplaceableUnitProblem 5.215.1 Consequences For 1+0 Space Diversity configuration, the SDC function is out of work because the receiver for the main channel is faulty. The system still works as a single receiver, without affecting the traffic. For 1+1 Space Diversity configuration, an Rx diversity switch is performed to the MMU and TRX SDC with no faults. The SDC is available with full functionality. 5.215.2 Alarm Analysis SDC Main Hardware Error indicates that the SDC function is not available because of a failure inside the Rx main receiver. The Rx diversity receiver still works, so no traffic is affected. In 1+1 Space Diversity configuration, SDC Main Hardware Error and SDC Div Hardware Error alarms are used as a trigger for Radio Protection Switch (RPS), that is, Rx diversity switch. The switch is performed to use the signal coming from the companion MMU connected to the TRX having full SDC functionality. The switch does not affect the traffic and the protection is an equipment and radio protection. 5.215.3 Corrective Actions Replace the faulty TRX SDC, see Replacing a TRX, Reference [19]. 5.215.4 Alarm Clearance The alarm is cleared when the faulty TRX SDC is replaced.
5.216 SES 15 Min Threshold Crossing Severely Errored Seconds (SES) SES threshold crossing for 15 minutes composite performance monitoring. Applicable for RAU IF (1+0). Applicable for SWITCH (1+1). SpecificProblem SES 15 min threshold crossing Source
RAU IF
http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
178/219
14/08/2015
Alarm Descriptions
SWITCH AlarmType
QualityOfServiceAlarm
Severity
Major
ProbableCause ThresholdCrossed
5.217 SES 24 h Threshold Crossing Severely Errored Seconds (SES) SES threshold crossing for 24 hours composite performance monitoring. Applicable for RAU IF (1+0). Applicable for SWITCH (1+1). SpecificProblem SES 24 h threshold crossing Source
RAU IF SWITCH
AlarmType
QualityOfServiceAlarm
Severity
Major
ProbableCause ThresholdCrossed
5.218 SFP LOS (Major) SFP reports loss of signal. Applicable for the standby interface in a 1+1 configuration. SpecificProblem SFP LOS Source
LINE RS (1+1)
AlarmType
CommunicationAlarm
Severity
Major
ProbableCause LossOfSignal 5.218.1 Consequences The protection is lost. 5.218.2 Corrective Actions
http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
179/219
14/08/2015
Alarm Descriptions
Figure 38 Workflow for SFP LOS Alarm Corrective Actions Do the following: 1. Perform a line loop on the interface of the farend Plugin Unit (PIU). If the SFP LOS alarm is not cleared, go to Step 2. Onsite action: If the SFP LOS alarm is cleared, replace the PIU on the farend. Describe the fault on the Blue Tag and send it to the Repair Center together with the faulty PIU. 2. Onsite action: Replace the SFP. If the SFP LOS alarm is not cleared, reuse the initial SFP. Go to Step 3. If the SFP LOS alarm is cleared, describe the fault on the Blue Tag and send it to the Repair Center together with the faulty SFP. http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
180/219
14/08/2015
Alarm Descriptions
3. Onsite action: Check and replace the transmission media between the nearend MMU and the farend PIU. For more information on how to replace the SFP, see Replacing an SFP, Reference [18]. For more information on how to replace the faulty PIU, see applicable CPI under HW Management folder. 5.218.3 Alarm Clearance The alarm is cleared when a valid signal is detected in the SFP.
5.219 SFP LOS (Critical) SFP reports loss of signal. Applicable for 1+0 configuration or for the active interface in a 1+1 configuration. SpecificProblem SFP LOS Source
LINE RS (1+0 and active SI)
AlarmType
CommunicationAlarm
Severity
Critical
ProbableCause LossOfSignal 5.219.1 Consequences Loss of received signal: traffic is lost on the Plugin Unit (PIU) side. 5.219.2 Corrective Actions
http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
181/219
14/08/2015
Alarm Descriptions
Figure 39 Workflow for SFP LOS Alarm Corrective Actions Do the following: 1. Perform a line loop on the interface of the farend Plugin Unit (PIU). If the SFP LOS alarm is not cleared, go to Step 2. Onsite action: If the SFP LOS alarm is cleared, replace the PIU on the farend. Describe the fault on the Blue Tag and send it to the Repair Center together with the faulty PIU. 2. Onsite action: Replace the SFP. If the SFP LOS alarm is not cleared, reuse the initial SFP. Go to Step 3. If the SFP LOS alarm is cleared, describe the fault on the Blue Tag and send it to the Repair Center together with the faulty SFP. http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
182/219
14/08/2015
Alarm Descriptions
3. Onsite action: Check and replace the transmission media between the nearend MMU and the farend PIU. For more information on how to replace the SFP, see Replacing an SFP, Reference [18]. For more information on how to replace the faulty PIU, see applicable CPI under HW Management folder. 5.219.3 Alarm Clearance The alarm is cleared when a valid signal is detected in the SFP.
5.220 SFP Temperature High/Low (Critical) The alarm is raised if the measured temperature in the SFP exceeds the upper excessive threshold value or falls below the lower excessive threshold value. SpecificProblem SFP temperature high/low at Source
SFP
AlarmType
EquipmentAlarm
Severity
Critical
ProbableCause ReplaceableUnitProblem 5.220.1 Consequences The SFP is not operating correctly. 5.220.2 Corrective Actions Make sure that the environmental conditions are according to recommendations. Replace the SFP. 5.220.3 Alarm Clearance The alarm is cleared when the measured temperature in the SFP is below the upper excessive threshold value and above the lower excessive threshold value.
5.221 SFP Temperature High/Low (Warning) The alarm is raised if the measured temperature in the SFP exceeds the upper warning threshold value or falls below the lower warning threshold value. SpecificProblem SFP temperature high/low at Source
SFP
AlarmType
EquipmentAlarm
Severity
Warning
ProbableCause ReplaceableUnitProblem 5.221.1 Consequences The SFP is not operating correctly.
http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
183/219
14/08/2015
Alarm Descriptions
5.221.2 Corrective Actions Make sure that the environmental conditions are according to recommendations. Replace the SFP. 5.221.3 Alarm Clearance The alarm is cleared when the measured temperature in the SFP is below the upper warning threshold value and above the lower warning threshold value.
5.222 SFP Voltage High/Low (Critical) The alarm is raised if the measured supply voltage in the SFP exceeds the upper excessive threshold value or falls below the lower excessive threshold value. SpecificProblem SFP voltage high/low at Source
SFP
AlarmType
EquipmentAlarm
Severity
Critical
ProbableCause ReplaceableUnitProblem 5.222.1 Consequences The SFP is not operating correctly. 5.222.2 Corrective Actions Replace the SFP. 5.222.3 Alarm Clearance The alarm is cleared when the measured supply voltage is below the upper excessive threshold value and above the lower excessive threshold value.
5.223 SFP Voltage High/Low (Warning) The alarm is raised if the measured supply voltage in the SFP exceeds the upper warning threshold value or falls below the lower warning threshold value. SpecificProblem SFP voltage high/low at Source
SFP
AlarmType
EquipmentAlarm
Severity
Warning
ProbableCause ReplaceableUnitProblem 5.223.1 Consequences The SFP is not operating correctly. 5.223.2 Corrective Actions Replace the SFP. http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
184/219
14/08/2015
Alarm Descriptions
5.223.3 Alarm Clearance The alarm is cleared when the measured supply voltage is below the upper warning threshold value and above the lower warning threshold value.
5.224 SFP TX Bias High/Low (Critical) The alarm is raised if the measured TX laser bias current exceeds the upper excessive threshold value or falls below the lower excessive threshold value. SpecificProblem SFP TX bias high/low at Source
SFP
AlarmType
EquipmentAlarm
Severity
Critical
ProbableCause ReplaceableUnitProblem 5.224.1 Consequences The SFP is not operating correctly. 5.224.2 Corrective Actions Replace the SFP. 5.224.3 Alarm Clearance The alarm is cleared when the measured TX laser bias current is below the upper excessive threshold value and above the lower excessive threshold value.
5.225 SFP TX Bias High/Low (Warning) The alarm is raised if the measured TX laser bias current exceeds the upper warning threshold value or falls below the lower warning threshold value. SpecificProblem SFP TX bias high/low at Source
SFP
AlarmType
EquipmentAlarm
Severity
Warning
ProbableCause ReplaceableUnitProblem 5.225.1 Consequences The SFP is not operating correctly. 5.225.2 Corrective Actions Replace the SFP. 5.225.3 Alarm Clearance The alarm is cleared when the measured TX laser bias current is below the upper warning threshold http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
185/219
14/08/2015
Alarm Descriptions
value and above the lower warning threshold value.
5.226 SFP TX Power High/Low (Critical) The alarm is raised if the measured coupled SFP TX power exceeds the upper excessive threshold value or falls below the lower excessive threshold value. SpecificProblem SFP TX power high/low at Source
SFP
AlarmType
EquipmentAlarm
Severity
Critical
ProbableCause ReplaceableUnitProblem 5.226.1 Consequences The SFP is not operating correctly. 5.226.2 Corrective Actions Replace the SFP. 5.226.3 Alarm Clearance The alarm is cleared when the measured coupled SFP TX power is below the upper excessive threshold value and above the lower excessive threshold value.
5.227 SFP TX Power High/Low (Warning) The alarm is raised if the measured coupled SFP TX power exceeds the upper warning threshold value or falls below the lower warning threshold value. SpecificProblem SFP TX power high/low at Source
SFP
AlarmType
EquipmentAlarm
Severity
Warning
ProbableCause ReplaceableUnitProblem 5.227.1 Consequences The SFP is not operating correctly. 5.227.2 Corrective Actions Replace the SFP. 5.227.3 Alarm Clearance The alarm is cleared when the measured coupled SFP TX power is below the upper warning threshold value and above the lower warning threshold value.
http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
186/219
14/08/2015
Alarm Descriptions
5.228 SFP RX Power High/Low (Critical) The alarm is raised if the measured coupled SFP RX power exceeds the upper excessive threshold value or falls below the lower excessive threshold value. SpecificProblem SFP RX power high/low at Source
SFP
AlarmType
EquipmentAlarm
Severity
Critical
ProbableCause ReplaceableUnitProblem 5.228.1 Consequences The SFP is not operating correctly. 5.228.2 Corrective Actions Replace the SFP. 5.228.3 Alarm Clearance The alarm is cleared when the measured coupled SFP RX power is below the upper excessive threshold value and above the lower excessive threshold value.
5.229 SFP RX Power High/Low (Warning) The alarm is raised if the measured coupled SFP RX power exceeds the upper warning threshold value or falls below the lower warning threshold value. SpecificProblem SFP RX power high/low at Source
SFP
AlarmType
EquipmentAlarm
Severity
Warning
ProbableCause ReplaceableUnitProblem 5.229.1 Consequences The SFP is not operating correctly. 5.229.2 Corrective Actions Replace the SFP. 5.229.3 Alarm Clearance The alarm is cleared when the measured coupled SFP RX power is below the upper warning threshold value and above the lower warning threshold value.
5.230 SQM Sequence Indicator Mismatch (SQM) http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
187/219
14/08/2015
Alarm Descriptions
The received sequence number does not match the configured sequence number. It can be caused by Synchronous Digital Hierarchy (SDH) crossconnection misconfiguration. SpecificProblem SQM Source
VC12
VC3 VC4
AlarmType
CommunicationAlarm
Severity
Critical
ProbableCause CommunicationsProtocolError 5.230.1 Consequences Interface down. 5.230.2 Corrective Actions Perform the following actions: 1. Check the SDH crossconnection configuration. 2. Check the local configuration. 3. Check the remote configuration. 4. Check the Bit Error Ratio (BER), see Troubleshooting, Reference [22]. 5.230.3 Alarm Clearance The alarm is cleared when the received sequence number matches the configured sequence number. Communication recovers.
5.231 SQMULTIPLE Multiple sequence numbers received. There are two or more equal sequence numbers in different Virtual Containers (VCs). SpecificProblem SQMULTIPLE Source
VCG/LCAS Standard Alarms
AlarmType
CommunicationAlarm
Severity
Major
ProbableCause CommunicationsProtocolError 5.231.1 Corrective Actions Perform the following actions: 1. Check the remote configuration. 2. Check the Bit Error Ratio (BER), see Troubleshooting, Reference [22].
http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
188/219
14/08/2015
Alarm Descriptions
5.232 SQNC The received sequence numbers for this Virtual Concatenation Group (VCG) are not consistent (outof range or noncontinuous). SpecificProblem SQNC Source
VCG/LCAS Standard Alarms
AlarmType
CommunicationAlarm
Severity
Major
ProbableCause CommunicationsProtocolError 5.232.1 Corrective Actions Perform the following actions: 1. Check the remote configuration. 2. Check the Bit Error Ratio (BER), see Troubleshooting, Reference [22].
5.233 SQNONCONT Noncontinuous sequence numbers received (per Virtual Concatenation Group (VCG)). SpecificProblem SQNONCONT Source
VCG/LCAS Standard Alarms
AlarmType
CommunicationAlarm
Severity
Major
ProbableCause CommunicationsProtocolError 5.233.1 Corrective Actions Perform the following actions: 1. Check the remote configuration. 2. Check the Bit Error Ratio (BER), see Troubleshooting, Reference [22].
5.234 SQOR Sequence number outofrange received (per Virtual Concatenation Group (VCG)). SpecificProblem SQOR Source
VCG/LCAS Standard Alarms
AlarmType
CommunicationAlarm
Severity
Major
ProbableCause CommunicationsProtocolError 5.234.1 Corrective Actions Perform the following actions: http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
189/219
14/08/2015
Alarm Descriptions
1. Check the remote configuration. 2. Check the Bit Error Ratio (BER), see Troubleshooting, Reference [22].
5.235 Squelch Threshold Reached The quality level of the synchronization reference reaches the Squelch quality level. SpecificProblem Squelch threshold reached Source
NE
AlarmType
CommunicationAlarm
Severity
Critical
ProbableCause LossOfSynchronisation 5.235.1 Consequences The synchronization output signal is squelched or the appropriate Synchronization Status Message (SSM) value is propagated on interfaces supporting SSM. 5.235.2 Corrective Actions No action required. 5.235.3 Alarm Clearance The alarm is cleared when the synchronization reference reaches a quality level above the Squelch quality level.
5.236 Starting Up (FarEnd) The farend Inverse Multiplexer over ATM (IMA) unit is starting up (restarting). SpecificProblem Starting up (FarEnd) Source
IMA Group
AlarmType
CommunicationAlarm
Severity
Warning
ProbableCause Indeterminate 5.236.1 Consequences No ATM traffic can be transmitted over the specific IMA group before both the nearend and farend groups become operational. 5.236.2 Alarm Analysis The farend IMA group is restarted. 5.236.3 Corrective Actions Wait until the IMA group becomes operational. http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
190/219
14/08/2015
Alarm Descriptions
5.236.4 Alarm Clearance Usually this is a temporary alarm which is canceled as soon as the IMA group becomes operational again, or it presents another specific failure condition (for instance "Insufficient links").
5.237 Sync Problem This alarm is raised when one of three other synchronization alarms is raised. For severity warning, see Loss of network reference redundancy (Section 5.132). For severity major, see Holdover mode entered (Section 5.80). For severity critical, see Free running mode entered (Section 5.63).
5.238 TIM (Major) Trace Identified Mismatch (TIM) The detection of TIM is based on a comparison between the accepted Trail Trace Identifier (TTI) and the expected TTI, configured through the Network Management System (NMS). If TIM detection is disabled at the NMS, TIM is considered "false". SpecificProblem TIM Source
AU4 RS TU3
TU12 VC3 VC4 VC12
AlarmType
CommunicationAlarm
Severity
Major
ProbableCause PathTraceMismatch 5.238.1 Consequences Traffic towards the node is lost. Traffic from the node is not affected. 5.238.2 Corrective Actions Check configuration of TxTTI at source. Check configuration of expected TTI at sink. Check crossconnections.
5.239 TIM (Critical) Trace Identifier Mismatch (TIM) Configuration mismatch between the expected Trail Trace identifier (TTI) and the received TTI. http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
191/219
14/08/2015
Alarm Descriptions
SpecificProblem TIM Source
MS/RS
VC12 VC4
AlarmType
CommunicationAlarm
Severity
Critical
ProbableCause PathTraceMismatch 5.239.1 Consequences Traffic towards the node can be lost. Traffic from the node is not affected. 5.239.2 Corrective Actions Check configuration of TTI in source sink and crossconnections. 5.239.3 Alarm Clearance The alarm is cleared when the received TTI is equal to the expected TTI.
5.240 TIM Line Side Trace Identifier Mismatch (TIM) TIM at the Line side. SpecificProblem TIM Line Side Source
LINE RS
AlarmType
CommunicationAlarm
Severity
Major
ProbableCause PathTraceMismatch
5.241 TIM Radio Side Trace Identifier Mismatch (TIM) TIM at the Radio side. SpecificProblem TIM Radio Side Source
RADIO RS
AlarmType
CommunicationAlarm
Severity
Major
ProbableCause PathTraceMismatch
5.242 TLCR Total Loss of Capacity Receive (TLCR) http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
192/219
14/08/2015
Alarm Descriptions
Link Capacity Adjustment Scheme (LCAS) deletes all members. SpecificProblem TLCR Source
VCG/LCAS Standard Alarms
AlarmType
CommunicationAlarm
Severity
Critical
ProbableCause BandwithReduced 5.242.1 Consequences Interface down. 5.242.2 Corrective Actions Perform the following actions: 1. Repair the Virtual Container (VC) trail. 2. Check the Multiplex Section (MS), Regenerator Section (RS), and L1. 5.242.3 Alarm Clearance The alarm is cleared when communication is recovered.
5.243 TLCT Total Loss of Capacity Transmit (TLCT) Probable cause is Link Capacity Adjustment Scheme (LCAS) deletes all members. SpecificProblem TLCT Source
VCG/LCAS Standard Alarms
AlarmType
CommunicationAlarm
Severity
Critical
ProbableCause BandwithReduced 5.243.1 Consequences Interface down. 5.243.2 Corrective Actions Perform the following actions: 1. Repair the Virtual Container (VC) trail. 2. Check the Multiplex Section (MS), Regenerator Section (RS), and L1. 5.243.3 Alarm Clearance The alarm is cleared when communication is recovered.
http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
193/219
14/08/2015
Alarm Descriptions
5.244 Traffic System Failure (Major) SpecificProblem Traffic System Failure Source
NE
AlarmType
EquipmentAlarm
Severity
Major
ProbableCause CommunicationsSubsystemFailure
5.245 Traffic System Failure (Critical) SpecificProblem Traffic System Failure Source
NE
AlarmType
EquipmentAlarm
Severity
Critical
ProbableCause CommunicationsSubsystemFailure
5.246 TULOM Tributary Unit Loss of Multiframe (TULOM) SpecificProblem TULOM Source
VC4
AlarmType
CommunicationAlarm
Severity
Critical
ProbableCause LossOfMultiFrame
5.247 TX Frequency (Major) The receiver frequency synthesizer loop is unlocked. Main reason for a TX Frequency alarm is a hardware fault in the RAU. SpecificProblem TX Frequency Source
RF
AlarmType
CommunicationAlarm
Severity
Major
ProbableCause TransmitterFailure 5.247.1 Consequences In hot standby configuration, the active transmitter is switched off and the standby transmitter is automatically switched on. 5.247.2 Corrective Actions
http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
194/219
14/08/2015
Alarm Descriptions
Figure 40 Workflow for TX Frequency Alarm Corrective Actions Do the following: 1. Perform a cold restart of the RAU and restart MINILINK Craft.
Caution! A cold restart will disturb the traffic. Onsite action: If the TX Frequency alarm is not cleared after the restart, replace the RAU. Describe the fault on the Blue Tag and send it to the Repair Center together with the faulty RAU. Onsite action: If the TX Frequency alarm is cleared, monitor the hop for further TX Frequency alarms. If the alarm is raised again, replace the RAU. Describe the fault on the Blue Tag and send it to the Repair Center together with the faulty RAU. For more information on how to replace the RAU, see Replacing a Radio Unit, Reference [16].
5.248 TX Frequency (Critical) The receiver frequency synthesizer loop is unlocked. Main reason for a TX Frequency alarm is a http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
195/219
14/08/2015
Alarm Descriptions
hardware fault in the RAU. SpecificProblem TX Frequency Source
RF
AlarmType
CommunicationAlarm
Severity
Critical
ProbableCause TransmitterFailure 5.248.1 Consequences The transmitter is switched off that results in traffic loss. 5.248.2 Corrective Actions
Figure 41 Workflow for TX Frequency Alarm Corrective Actions Do the following: 1. Perform a cold restart of the RAU and restart MINILINK Craft.
http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
196/219
14/08/2015
Alarm Descriptions
Caution! A cold restart will disturb the traffic. Onsite action: If the TX Frequency alarm is not cleared after the restart, replace the RAU. Describe the fault on the Blue Tag and send it to the Repair Center together with the faulty RAU. Onsite action: If the TX Frequency alarm is cleared, monitor the hop for further TX Frequency alarms. If the alarm is raised again, replace the RAU. Describe the fault on the Blue Tag and send it to the Repair Center together with the faulty RAU. For more information on how to replace the RAU, see Replacing a Radio Unit, Reference [16].
5.249 Tx IF Input (Major) Failure on the received Intermediate Frequency (IF) signal from the MMU to the RAU. Applicable for RAU IF (1+1). SpecificProblem Tx IF Input Source
RAU IF
AlarmType
Communication
Severity
Major
ProbableCause TransmitterFailure
5.250 Tx IF Input (Critical) Failure on the received Intermediate Frequency (IF) signal from the MMU to the RAU. Applicable for RAU IF (1+0). SpecificProblem Tx IF Input Source
RAU IF
AlarmType
Communication
Severity
Critical
ProbableCause TransmitterFailure
5.251 Tx Link Misconnected The Tx link is not connected to the same farend Inverse Multiplexer over ATM (IMA) unit as the others Tx links in the group. SpecificProblem Tx Link Misconnected Source
IMA Group
AlarmType
CommunicationAlarm
Severity
Critical
ProbableCause ConfigurationOrCustomizationError
http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
197/219
14/08/2015
Alarm Descriptions
5.251.1 Consequences No Asynchronous Transfer Mode (ATM) traffic can be transmitted over the specific IMA Link. Related IMA groups can also be affected by the fault: in case the IMA group goes below the "minimum number of (active) links" no ATM traffic can flow at all through the group. In this case the operational status of related ATMIMA (IMA group) and ATM goes to down. If the IMA group still have a minimum number of links it can still transmit the guaranteed bandwidth of traffic. 5.251.2 Alarm Analysis Wrong connection of Tx IMA link. 5.251.3 Corrective Actions Connect the Tx IMA link to the same farend IMA unit as the other Tx links in the group. 5.251.4 Alarm Clearance The alarm is cleared when the Tx IMA link is correctly connected to the farend IMA unit.
5.252 TX Switch Over This alarm is raised when an active radio switch over is ordered by the nearend side. It is only valid in Hot Standby (HSB). By default, the functionality to order an active radio switch over on the farend side is disabled. It can be enabled in MINILINK Craft, see MINILINK Craft User Interface Descriptions, Reference [7], but it is only recommended to enable it in hops that have high fade margins and low probability for deep flat or multipath fading. SpecificProblem TX Switch Over Source
SWITCH
AlarmType
EquipmentAlarm
Severity
Major
ProbableCause ProtectionPathFailure 5.252.1 Consequences The protection switching function is locked until the alarm is reset manually. Even if the initial fault that triggered the switch over is corrected, the switching function does not work and the hop only functions as 1+0 until the alarm is reset manually. 5.252.2 Alarm Analysis The TX switch over occurs when the output power of the active radio is lost in HSB. The RF Output Level alarm is raised. The protection function switches off the output power on this radio and switches on the output power on the passive radio. The RF Output Level alarm on the faulty radio is then deactivated. Because a TX switch over clears any alarms raised by the initial fault, the TX Switch Over alarm must be raised to prevent a switch over back to the faulty path. For this reason, the TX Switch Over alarm must be reset manually if full equipment protection in HSB is wanted. 5.252.3 Corrective Actions http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
198/219
14/08/2015
Alarm Descriptions
Replace the RAU, see Replacing a Radio Unit, Reference [16]. 5.252.4 Alarm Clearance The alarm is not cleared automatically. It must be reset manually in MINILINK Craft on the SWITCH Alarms and Status page for the applicable MMU. The reason for this is that the fault that triggered the remote TX switch over must be understood and corrected before a remote TX switch over can take place again. Always reset the TX Switch Over alarm before taking a hop into service as installation work and testing can also trigger the function.
5.253 Tx Unusable (FarEnd) The alarm is reported when the farend Inverse Multiplexer over ATM (IMA) unit determines that its Tx link cannot be used for transmission in the group. SpecificProblem Tx Unusable (FarEnd) Source
IMA Group
AlarmType
CommunicationAlarm
Severity
Major
ProbableCause RemoteAlarmInterface 5.253.1 Consequences No Asynchronous Transfer Mode (ATM) traffic can be received from the specific IMA Link. Related IMA groups can also be affected by the fault: in case the IMA group goes below the "minimum number of (active) links" no ATM traffic can flow at all through the group. In this case the operational status of related ATMIMA (IMA group) and ATM goes to down. If the IMA group still have a minimum number of links it can still receive the guaranteed bandwidth of traffic. 5.253.2 Alarm Analysis A fault in the farend link or protocol is detected by the IMA unit at Tx direction. 5.253.3 Corrective Actions Check the status of the farend Tx link. 5.253.4 Alarm Clearance The alarm is cleared when the farend Tx link failure is removed.
5.254 Unable to Protect: NPU The alarm is raised when a protection switch is performed because of one of the following: BR button is pressed on the NPU in the secondary slot. The NPU in the secondary slot is removed without pressing the BR button. Failure of the NPU in the secondary slot. For more information about the primary and the secondary slot in the AMM, see Recommendations for Positioning of PlugIn Units, Reference [9]. SpecificProblem Unable to Protect http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
199/219
14/08/2015
Alarm Descriptions
Source
NPU
AlarmType
EquipmentAlarm
Severity
Major
ProbableCause
ReplaceableUnitProblem ReplaceableUnitMissing
5.254.1 Consequences The Ethernet switch is not protected. If the NPU in the primary slot that has the active Ethernet switch fails, traffic is lost. 5.254.2 Corrective Actions Repair or replace the faulty NPU. 5.254.3 Alarm Clearance This alarm is cleared when the NPU in the secondary slot is functioning correctly. Note that the NPU in the primary slot still can have the active Ethernet switch after replacement of the other NPU. To have a protected setup perform one of the following: If the revertive switch is manual, set the active switch to the NPU in the secondary slot. If the revertive switch is automatic, wait for the Wait To Restore Time.
5.255 Unable to Protect: E1 (Minor) SpecificProblem Unable to Protect Source
E1
AlarmType
CommunicationAlarm
Severity
Minor
ProbableCause ProtectionPathFailure
5.256 Unable to Protect: E1 (Critical) The protection fails. Both interfaces fail or the traffic is locked to a failing interface. SpecificProblem Unable to Protect Source
E1
AlarmType
CommunicationAlarm
Severity
Critical
ProbableCause ProtectionPathFailure
5.257 Unable to Protect: LPS (Major) The system is no longer able to provide protection of the line side. Loss Of Signal (LOS) or Loss Of Frame (LOF) on one path. http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
200/219
14/08/2015
Alarm Descriptions
SpecificProblem Unable to Protect Source
LPS
AlarmType
Communication
Severity
Major
ProbableCause ProtectionPathFailure
5.258 Unable to Protect: LPS (Critical) The system is no longer able to provide protection of the line side. SpecificProblem Unable to Protect Source
LPS
AlarmType
Communication
Severity
Critical
ProbableCause ProtectionPathFailure
5.259 Unable to Protect: MSP (Minor) The protection fails. Failure on one of the two lines involved in a Multiplex Section Protection (MSP) configuration. Probable causes are the following: The line has a fault condition (Loss Of Signal (LOS)). One LTU 155 board is faulty (Equipment fault). One LTU 155 board is in repair (not present). MSP is configured on only one of the two Synchronous Transport Module level 1 (STM1) boards. Manual switch mode is configured (traffic is locked to one of the two lines). SpecificProblem Unable to Protect Source
MSP
AlarmType
QualityOfServiceAlarm
Severity
Minor
ProbableCause Indeterminate 5.259.1 Consequences Only one of the two STM1 lines in the MSP configuration is operative. Failure of this line also leads to complete loss of traffic. 5.259.2 Corrective Actions Check the above mentioned probable causes. 5.259.3 Alarm Clearance The alarm is cleared when the STM1 lines are operative. http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
201/219
14/08/2015
Alarm Descriptions
5.260 Unable to Protect: MSP (Critical) The protection fails. Failure on both lines involved in a Multiplex Section Protection (MSP) configuration. Probable causes are the following: Both lines has a fault condition (Loss Of Signal (LOS)). Both LTU 155 boards are faulty (Equipment fault). Both LTU 155 boards are in repair (not present). Manual switch mode is configured (traffic is locked to one of the two lines) and this line is faulty. SpecificProblem Unable to Protect Source
MSP
AlarmType
QualityOfServiceAlarm
Severity
Critical
ProbableCause Indeterminate 5.260.1 Consequences Both Synchronous Transport Module level 1 (STM1) lines in the MSP configuration are faulty. The result is complete loss of traffic. 5.260.2 Corrective Actions Check the above mentioned probable causes. 5.260.3 Alarm Clearance The alarm is completely cleared when both STM1 lines are operative. If one of the two lines becomes operative, the alarm changes severity from Critical to Minor.
5.261 Unable to Protect: RLIME The alarm is raised when an Unable to Protect alarm is active on a radio link that is assigned to the RLIME group. SpecificProblem Unable to Protect Source
RLIME
AlarmType
EquipmentAlarm
Severity
Warning
ProbableCause ProtectionPathFailure 5.261.1 Corrective Actions Check and clear the Unable to Protect alarms of the radio links that are assigned to the RLIME group. 5.261.2 Alarm Clearance http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
202/219
14/08/2015
Alarm Descriptions
The alarm is cleared when no Unable to Protect alarms are active on the radio links that are assigned to the RLIME group.
5.262 Unable to Protect: SWITCH (Major) The system is no longer able to provide protection of the radio side. Probable causes for this are as follows: A Tx alarm or a common alarm on one path. An Rx alarm on one path and the duration is longer than 200 s (default value). SpecificProblem Unable to Protect Source
SWITCH
AlarmType
EquipmentAlarm
Severity
Major
ProbableCause ProtectionPathFailure
5.263 Unable to Protect: SWITCH (Critical) The system is no longer able to provide protection of the radio side because there are alarms on both paths. SpecificProblem Unable to Protect Source
SWITCH
AlarmType
EquipmentAlarm
Severity
Critical
ProbableCause ProtectionPathFailure
5.264 Unable to Protect Failure on Active Port: LAN This alarm is only applicable for ETU2 B and ETU3. The alarm is raised if the active port in an Ethernet port protection group does not operate with full functionality. The reasons of the failure on the active port can be the following: The operational status is Down for the LAN interface. The operational status is Out of Service for the active SFP. The operational status is Out of Service for the active ETU. Note: Only applicable if Ethernet port protection is configured on different ETUs.
SpecificProblem Unable to Protect Failure on Active Port Source
LAN
AlarmType
EquipmentAlarm
Severity
Minor
ProbableCause ProtectionPathFailure
http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
203/219
14/08/2015
Alarm Descriptions
5.264.1 Consequences The NE performs a port protection switch. Only one of the two Ethernet ports in the port protection group is operative. Failure of this port leads to complete loss of traffic. 5.264.2 Corrective Actions To correct the failure on the active port, do the following: 1. Check that the administrative status is set to Up for the LAN interface. 2. Check that the LAN connection is correctly configured with the far end. 3. Check that the administrative status is set to In Service for the SFP and the ETU. 4. Check that the SFP and the ETU are plugged correctly. 5. Replace the faulty SFP. For more information, see Replacing an SFP, Reference [18]. 6. Replace the faulty ETU. For more information, see Replacing an LTU, ETU, or SAU3, Reference [12].
Danger! Never look directly into the end of a fiber optic cable, or other laser source. Equipment that transmits laser light can cause permanent eye damage. Switch off the laser before starting work on laser equipment. 5.264.3 Alarm Clearance For faults detected on the active port, a switch is performed, and the former active port becomes passive. After the switch, the NE monitors the status of the new passive port. The alarm is cleared if the new passive port is detected as free of faults.
5.265 Unable to Protect Failure on Both Ports: LAN This alarm is only applicable for ETU2 B and ETU3. The alarm is raised if both the active port and the passive port in an Ethernet port protection group do not operate with full functionality. The reasons of the failure can be the following: The operational status is Out of Service for the ETU that has both the active and the passive port. Note: If Ethernet port protection is configured on different ETUs, the operational status can be Out of Service for both the active and the passive ETU.
The operational status is Out of Service for the active SFP and the passive SFP. SpecificProblem Unable to Protect Failure on Both Ports Source
LAN
AlarmType
EquipmentAlarm
Severity
Critical
ProbableCause ProtectionPathFailure 5.265.1 Consequences http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
204/219
14/08/2015
Alarm Descriptions
Both Ethernet ports in the port protection group are not operative. This leads to complete loss of traffic. 5.265.2 Corrective Actions To correct the failure on both ports, do the following: 1. Check that the administrative status is set to Up for the LAN interface. 2. Check that the LAN connection is correctly configured with the far end. 3. Check that the administrative status is set to In Service for the SFP and the ETU. 4. Check that the SFP and the ETU are plugged correctly. 5. Replace the faulty SFP. For more information, see Replacing an SFP, Reference [18]. 6. Replace the faulty ETU. For more information, see Replacing an LTU, ETU, or SAU3, Reference [12].
Danger! Never look directly into the end of a fiber optic cable, or other laser source. Equipment that transmits laser light can cause permanent eye damage. Switch off the laser before starting work on laser equipment. 5.265.3 Alarm Clearance For the active port, a switch is performed. After the switch, the NE monitors the status of the active port. If the needed recovery steps are taken on the active port within 30 minutes, the alarm is cleared. Otherwise, after 30 minutes, a new switch is performed, and the NE checks the status of the ports again. If one of the two ports is detected as free of faults, the alarm is cleared.
5.266 Unable to Protect Failure on Passive Port: LAN This alarm is only applicable for ETU2 B and ETU3. The alarm is raised if the passive port in an Ethernet port protection group does not operate with full functionality. The reasons of the failure on the passive port can be the following: The operational status is Out of Service for the passive SFP. The operational status is Out of Service for the passive ETU. Note: Only applicable if Ethernet port protection is configured on different ETUs.
SpecificProblem Unable to Protect Failure on Passive Port Source
LAN
AlarmType
EquipmentAlarm
Severity
Minor
ProbableCause ProtectionPathFailure 5.266.1 Consequences The active port is not protected anymore. Only one of the two Ethernet ports in the port protection group is operative. Failure of the active port leads to complete loss of traffic. http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
205/219
14/08/2015
Alarm Descriptions
5.266.2 Corrective Actions To correct the failure on the passive port, do the following: 1. Check that the administrative status is set to In Service for the SFP and the ETU. 2. Check that the SFP and the ETU are plugged correctly. 3. Replace the faulty SFP. For more information, see Replacing an SFP, Reference [18]. 4. Replace the faulty ETU. For more information, see Replacing an LTU, ETU, or SAU3, Reference [12].
Danger! Never look directly into the end of a fiber optic cable, or other laser source. Equipment that transmits laser light can cause permanent eye damage. Switch off the laser before starting work on laser equipment. 5.266.3 Alarm Clearance The alarm is cleared if the passive port is detected as free of faults.
5.267 Unable to Protect Manual Mode: LAN This alarm is only applicable for ETU2 B and ETU3. The alarm is raised if the Ethernet port protection switch mode is set to manual. SpecificProblem Unable to Protect Manual Mode Source
LAN
AlarmType
EquipmentAlarm
Severity
Minor
ProbableCause ProtectionPathFailure 5.267.1 Consequences The active port is not protected. Even if the NE detects a problem on the active port, the NE does not perform a switch to the passive port automatically. 5.267.2 Corrective Actions Set Ethernet port protection switch mode to automatic. 5.267.3 Alarm Clearance The alarm is cleared if the Ethernet port protection switch mode is set to automatic.
5.268 Unable to Protect Port Not Connected to Switch: LAN This alarm is only applicable for ETU2 B and ETU3. The alarm is raised if the Ethernet port protection has been created, but it has not been connected to a switch port. SpecificProblem Unable to Protect Port Not Connected to Switch Source
LAN
http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
206/219
14/08/2015
Alarm Descriptions
AlarmType
EquipmentAlarm
Severity
Warning
ProbableCause ProtectionPathFailure 5.268.1 Consequences The configuration of the Ethernet port protection is not complete. 5.268.2 Corrective Actions Connect the primary LAN interface, which is the active port, to one of the available switch ports. 5.268.3 Alarm Clearance The alarm is cleared if the primary LAN interface is connected to a switch port.
5.269 Unavailable Period The Plesiochronous Digital Hierarchy (PDH) Unavailable Period counter threshold is crossed, due to possible radio propagation problem. Applicable for RAU IF (1+0). Applicable for SWITCH (1+1). SpecificProblem Unavailable Period Source
RAU IF SWITCH
AlarmType
QualityOfServiceAlarm
Severity
Major
ProbableCause PerformanceDegraded
5.270 Unavailable State Unavailable State is activated after ten consecutive Severely Errored Seconds (SES). SpecificProblem Unavailable State Source
AU4 E1 E2/E3 Framed E1 MS/RS
MSP TU3 TU12 VC3
http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
207/219
14/08/2015
Alarm Descriptions
VC4 VC12 AlarmType
QualityOfServiceAlarm
Severity
Critical
ProbableCause Unavailable 5.270.1 Consequences Service unavailable. 5.270.2 Corrective Actions Eliminate defects that cause SES or Unavailable Seconds (UAS). 5.270.3 Alarm Clearance The alarm is cleared after ten consecutive nonSES.
5.271 Unavailable State Far End At the far end, Unavailable State is activated after ten consecutive Severely Errored Seconds (SES). SpecificProblem Unavailable State Far End Source
AU4 MS/RS MSP
TU3 TU12 VC3 VC4 VC12
AlarmType
QualityOfServiceAlarm
Severity
Critical
ProbableCause Unavailable 5.271.1 Consequences Service unavailable at far end. 5.271.2 Corrective Actions Eliminate defects that cause SES or Unavailable Seconds (UAS).
5.272 Unequipped (Major) http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
208/219
14/08/2015
Alarm Descriptions
The interface has no content, since the unit is not configured. SpecificProblem Unequipped Source
AU4 TU3
TU12 VC3 VC4 VC12
AlarmType
CommunicationAlarm
Severity
Major
ProbableCause Indeterminate 5.272.1 Consequences The service is unavailable. 5.272.2 Corrective Actions Check crossconnection of the alarmed path. 5.272.3 Alarm Clearance The alarm is cleared when the crossconnection is established.
5.273 Unequipped (Critical) Nonconsistent configuration, the unequipped defect is detected in the C2 byte. SpecificProblem Unequipped Source
VC12 VC4
AlarmType
CommunicationAlarm
Severity
Critical
ProbableCause PayloadTypeMismatch 5.273.1 Consequences The service is unavailable. 5.273.2 Corrective Actions Check and correct configuration. 5.273.3 Alarm Clearance http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
209/219
14/08/2015
Alarm Descriptions
The alarm is cleared when the configuration is corrected.
5.274 Unexpected MD Level in CCM A Maintenance End Point (MEP) has received a Continuity Check Message (CCM) frame with incorrect Maintenance Domain (MD) level. Note: This alarm is only available when using the ITUT Y.1731 standard for Connectivity Fault Management (CFM). SpecificProblem Unexpected MD Level in CCM Source
LAN with MEP
WAN with MEP LAG with MEP
AlarmType
CommunicationAlarm
Severity
Warning
ProbableCause PathTraceMismatch 5.274.1 Corrective Actions No corrective action is required.
5.275 Unexpected MEP Condition A Maintenance End Point (MEP) has received a Continuity Check Message (CCM) frame with correct Maintenance Domain (MD) level and correct Maintenance Association (MA) ID, but with unexpected MEP ID. Note: This alarm is only available when using the ITUT Y.1731 standard for Connectivity Fault Management (CFM). SpecificProblem Unexpected MEP Condition Source
LAN with MEP
WAN with MEP LAG with MEP
AlarmType
CommunicationAlarm
Severity
Major
ProbableCause SignalLabelMismatch 5.275.1 Corrective Actions No corrective action is required.
5.276 Unexpected Period in CCM http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
210/219
14/08/2015
Alarm Descriptions
A Maintenance End Point (MEP) has received a Continuity Check Message (CCM) frame with correct Maintenance Domain (MD) level, correct Maintenance Association (MA) ID, and correct MEP ID, but with a period field value different from its own CCM transmission period. Note: This alarm is only available when using the ITUT Y.1731 standard for Connectivity Fault Management (CFM). SpecificProblem Unexpected Period in CCM Source
LAN with MEP
WAN with MEP LAG with MEP
AlarmType
CommunicationAlarm
Severity
Warning
ProbableCause ResponseTimeExcessive 5.276.1 Corrective Actions No corrective action is required.
5.277 Unit Inaccessible: Plugin Unit The unit is not accessible. SpecificProblem Unit Inaccessible Source
Plugin Unit
AlarmType
EquipmentAlarm
Severity
Minor
ProbableCause ReplaceableUnitProblem
5.278 Unit Inaccessible: RMM The RMM is not accessible because of a fault or because no RMM is present. SpecificProblem Unit Inaccessible Source
RMM
AlarmType
EquipmentAlarm
Severity
Major
ProbableCause ReplaceableUnitProblem 5.278.1 Consequences Entering an unlocked period, during which all license controlled features that are connected to the licenses in the NE are possible to use. 5.278.2 Corrective Actions Check if the RMM is inserted correctly or replace the RMM, see Replacing an RMM, Reference [17]. http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
211/219
14/08/2015
Alarm Descriptions
5.278.3 Alarm Clearance The alarm is cleared when access to the RMM is restored.
5.279 Unit Removed (Minor) Either on the active side or on the passive side of the Ethernet port protection, the SFP or the ETU has been removed. SpecificProblem Unit Removed Source
Plugin Unit
AlarmType
EquipmentAlarm
Severity
Minor
ProbableCause ReplaceableUnitProblem 5.279.1 Consequences Missing SFP or ETU for the Ethernet port protection group. 5.279.2 Corrective Actions Insert the missing SFP or ETU to the NE.
5.280 Unit Removed (Critical) The unit is removed. SpecificProblem Unit Removed Source
Plugin Unit
AlarmType
EquipmentAlarm
Severity
Critical
ProbableCause ReplaceableUnitProblem
5.281 Unsupported Capability Profile The alarm is raised if the load module of ETU2 B or ETU3 does not support the configured capability profile. SpecificProblem Unsupported Capability Profile Source
ETU2 B ETU3
AlarmType
EquipmentAlarm
Severity
Minor
ProbableCause SoftwareEnvironmentProblem 5.281.1 Consequences http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
212/219
14/08/2015
Alarm Descriptions
The NE runs with reduced capabilities, that is, the configured capability is disabled on the plugin unit. 5.281.2 Corrective Actions Change the capability profile to a supported one or upgrade the load module of ETU2 B or ETU3. For more information, see Upgrading or Downgrading a SW Load Module, Reference [23]. For more information on feature and software compatibility regarding ETU capability profiles, see the Compatibility document in the Planning folder of the MINILINK TN CPI library. 5.281.3 Alarm Clearance The alarm is cleared when the capability profile is changed to a supported one or the load module of ETU2 B or ETU3 is upgraded.
5.282 Unsupported Unit Type The alarm is raised if the unit type is not supported by the software. SpecificProblem Unsupported Unit Type (Only applicable if source is Plugin Unit or RAU)
Unsupported Unit Type at (Only applicable if source is SFP)
Source
Plugin Unit
RAU SFP
AlarmType
EquipmentAlarm
Severity
Critical
ProbableCause ReplaceableUnitTypeMismatch 5.282.1 Consequences The unit is not operating. 5.282.2 Corrective Actions Remove and, if applicable, replace the unit. 5.282.3 Alarm Clearance The alarm is cleared when the unsupported unit is removed.
5.283 UPM User Payload Identifier Mismatch (UPM) The User Payload Identifier (UPI) field in the received Generic Framing Procedure (GFP) frame does not match the configured value. SpecificProblem UPM Source
GFP
http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
213/219
14/08/2015
Alarm Descriptions
AlarmType
CommunicationAlarm
Severity
Major
ProbableCause PayloadTypeMismatch 5.283.1 Consequences The service is not trusted and may be unavailable. 5.283.2 Corrective Actions Correct the user payload information and check configuration in both ends of the path. 5.283.3 Alarm Clearance The alarm is cleared when the UPI field in the received GFP frame matches the configured value.
5.284 User Input The Specific Problem and Severity are defined on the User Input Configuration page, see Reference [7]. SpecificProblem User input Source
User Input
AlarmType
EnvironmentalAlarm
Severity
User Defined
ProbableCause
5.285 Wrong NP Software The running NPU SW does not support the RMM due to incompatibility. SpecificProblem Wrong NP Software Source
RMM
AlarmType
EquipmentAlarm
Severity
Minor
ProbableCause ReplacableUnitProblem 5.285.1 Consequences The RMM is not accessible by the SW due to incompatibility. 5.285.2 Corrective Actions Perform a SW upgrade on the NPU. 5.285.3 Alarm Clearance Alarm is automatically cleared when the RMM is compatible with the NPU SW.
http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
214/219
14/08/2015
Alarm Descriptions
5.286 Wrong NPU Software The unit needs a later (updated) NPU software release. SpecificProblem Wrong NPU Software Source
Plugin unit
AlarmType
EquipmentAlarm
Severity
Critical
ProbableCause SoftwareEnvironmentProblem
5.287 Wrong Position The unit is in the wrong position in the AMM. SpecificProblem Wrong Position Source
Plugin Unit
AlarmType
EquipmentAlarm
Severity
Critical
ProbableCause ReplaceableUnitTypeMismatch
5.288 Wrong Software: Plugin Unit The software revision on the unit is not aligned with the Software Baseline (SBL). SpecificProblem Wrong Software Source
Plugin Unit
AlarmType
EquipmentAlarm
Severity
Critical
ProbableCause SoftwareEnvironmentProblem
5.289 WST LOS L2R (Major) Traffic failure in the transmitting direction of the Wayside Channel (only for MMU2 E/F). SpecificProblem WST LOS L2R Source
RAU IF (1+1)
AlarmType
CommunicationAlarm
Severity
Major
ProbableCause LossOfSignal
5.290 WST LOS L2R (Critical) Traffic failure in the transmitting direction of the Wayside Channel (only for MMU2 E/F). SpecificProblem WST LOS L2R Source
RAU IF (1+0)
http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
215/219
14/08/2015
Alarm Descriptions
AlarmType
CommunicationAlarm
Severity
Critical
ProbableCause LossOfSignal
5.291 WST LOS R2L (Major) The Wayside Channel Receiver on one of the MMU2 E/F in a 1+1 protection configuration detects loss of input signal. SpecificProblem WST LOS R2L Source
RAU IF (1+1)
AlarmType
CommunicationAlarm
Severity
Major
ProbableCause LossOfSignal 5.291.1 Consequences Protection lost on the Wayside Channel on MMU2 E/F. 5.291.2 Alarm Clearance The alarm is cleared when an input signal is received on the Wayside Channel on MMU2 E/F.
5.292 WST LOS R2L (Critical) The Wayside Channel Receiver on the MMU2 E/F detects loss of input signal. SpecificProblem WST LOS R2L Source
RAU IF (1+0)
AlarmType
CommunicationAlarm
Severity
Critical
ProbableCause LossOfSignal 5.292.1 Consequences Traffic is lost on the Wayside Channel on MMU2 E/F. 5.292.2 Alarm Clearance The alarm is cleared when an input signal is received on the Wayside Channel on MMU2 E/F.
5.293 XPIC Cable Disconnected Loss of the Cross Polarization Interference Canceller (XPIC) baseband crosssignal due to disconnected or broken XPIC crosscable between two MMU2 F/H/K, MMU3 A/B modems in XPIC mode. SpecificProblem XPIC Cable Disconnected Source http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
216/219
14/08/2015
Alarm Descriptions
MMU2 F MMU2 H
MMU2 K MMU3 A MMU3 B
AlarmType
EquipmentAlarm
Severity
Major
ProbableCause ReplaceableUnitMissing 5.293.1 Consequences Degraded receiving thresholds, performance (BER) or loss of traffic. 5.293.2 Corrective Actions Connect the XPIC crosscable or replace the faulty one. 5.293.3 Alarm Clearance The alarm is cleared when a non faulty XPIC crosscable is correctly connected between the two MMU2 F/H/K, MMU3 A/B modems in XPIC mode.
5.294 XPIC LOS The alarm is raised when the Cross Polarization Interference Canceller (XPIC) baseband crosssignal between two MMU2 F/H/K, MMU3 A/B modems in XPIC mode is lost, with the XPIC crosscable correctly connected. Loss of the XPIC baseband crosssignal due to MMU2 F/H/K, MMU3 A/B internal hardware or software fault. Not due to disconnected XPIC crosscable. SpecificProblem XPIC LOS Source
MMU2 F MMU2 H
MMU2 K MMU3 A MMU3 B
AlarmType
CommunicationAlarm
Severity
Major
ProbableCause LossOfSignal 5.294.1 Consequences Degraded receiving thresholds, performance (BER) or loss of traffic. 5.294.2 Corrective Actions
http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
217/219
14/08/2015
Alarm Descriptions
Figure 42 Workflow for XPIC LOS Alarm Corrective Actions Do the following: 1. Check if Rx IF Input alarm or RCC alarm is also raised. If Rx IF Input alarm or RCC alarm is raised, find the root causes of these alarms first, and take corrective actions according to their alarm description. If Rx IF Input alarm or RCC alarm is not raised, go to Step 2. 2. Onsite action: Replace one of the MMUs in the XPICpair. If the XPIC LOS alarm is not cleared, reuse the initial MMU and go to Step 3. If the XPIC LOS alarm is cleared, describe the fault on the Blue Tag and send it to the Repair Center together with the faulty MMU. 3. Onsite action: Replace the other MMU in the XPICpair. Describe the fault on the Blue Tag and send it to the Repair Center together with the faulty MMU. 5.294.3 Alarm Clearance http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
218/219
14/08/2015
Alarm Descriptions
The alarm is cleared when the XPIC baseband crosssignal is present again.
Reference List [1] Accessing a Network Element, 3/1543HRA 901 20 [2] CLI User Guide, 2/1553HRA 901 20 [3] Fault Management Operations, 4/1543HRA 901 20 [4] Installing and Managing Licenses, 9/1543HRA 901 20 [5] Installing Outdoor Equipment, 1/1531HRA 901 03/1 [6] LED Descriptions, 24/1543HRA 901 20 [7] MINILINK Craft User Interface Descriptions, 7/1551HRA 901 20 [8] Personal Health and Safety Information, 124 462885 [9] Recommendations for Positioning of PlugIn Units, 15/1551HRA 901 20 [10] Removing a PlugIn Unit, 20/1543HRA 901 20 [11] Replacing a Fan Unit, 42/1543HRA 901 20 [12] Replacing an LTU, ETU, or SAU3, 39/1543HRA 901 20 [13] Replacing an MMU, 37/1543HRA 901 20 [14] Replacing an MMU2 CS, 38/1543HRA 901 20 [15] Replacing an NPU, 35/1543HRA 901 20 [16] Replacing a Radio Unit, 41/1543HRA 901 20 [17] Replacing an RMM, 36/1543HRA 901 20 [18] Replacing an SFP, 55/1543HRA 901 20 [19] Replacing a TRX, 1/1543HRA 901 20 [20] Supplementary Safety Information for MINILINK, 124 46HSD 101 16/1 [21] System Safety Information, 124 462886 [22] Troubleshooting, 5/154 43HRA 901 20 [23] Upgrading or Downgrading a SW Load Module, 13/1543HRA 901 20 [24] Verifying an Installation, 1/1532HRA 901 20
Copyright
© Ericsson AB 2012–2014. All rights reserved. No part of this document may be reproduced in any form without the written permission of the copyright owner.
Disclaimer
The contents of this document are subject to revision without notice due to continued progress in methodology, design and manufacturing. Ericsson shall have no liability for any error or damage of any kind resulting from the use of this document.
Alarm Descriptions MINILINK TN ETSI
http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1
219/219
View more...
Comments
