Professional Documents
Culture Documents
TN Alarm Description PDF
TN Alarm Description PDF
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 <Number> License Missing <KeyProductName> (Major)
5.57 FAL <Number> License Missing <KeyProductName> (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 <window>, <threshold>, <value>
5.152 OAM Local Errored Frame Period <window>, <threshold>, <value>
5.153 OAM Local Errored Secs Summary <window>, <threshold>, <value>
5.154 OAM Local Errored Symbol Period <window>, <threshold>, <value>
5.155 OAM Remote Errored Frame <window>, <threshold>, <value>
5.156 OAM Remote Errored Frame Period <window>, <threshold>, <value>
5.157 OAM Remote Errored Secs Summary <window>, <threshold>, <value>
5.158 OAM Remote Errored Symbol Period <window>, <threshold>, <value>
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 The source of the alarm.
AlarmType The alarm type. The alarm types are specified in Fault Management Operations,
Reference [3].
Severity 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 <Number> License Missing <KeyProductName> (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 <Number> License Missing <KeyProductName>
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 <Number> License Missing <KeyProductName> (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 <Number> License Missing <KeyProductName>
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 <Board Type>
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 <Board Type> (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 Alarm Descriptions
Severity 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 <window>, <threshold>, <value>
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 <window>, <threshold>, <value>
Source LAN
AlarmType CommunicationAlarm
Severity Major
ProbableCause Unavailable
5.152 OAM Local Errored Frame Period <window>, <threshold>, <value>
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 <window>, <threshold>, <value>
Source LAN
AlarmType CommunicationAlarm
http://localhost:43190/ETSI/MLTN/5_1543HRA90120V13Uen.J.html#CHAPTER4.1 130/219
14/08/2015 Alarm Descriptions
Severity Major
ProbableCause Unavailable
5.153 OAM Local Errored Secs Summary <window>, <threshold>, <value>
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 <window>, <threshold>, <value>
Source LAN
AlarmType CommunicationAlarm
Severity Major
ProbableCause Unavailable
5.154 OAM Local Errored Symbol Period <window>, <threshold>, <value>
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 <window>, <threshold>, <value>
Source LAN
AlarmType CommunicationAlarm
Severity Major
ProbableCause Unavailable
5.155 OAM Remote Errored Frame <window>, <threshold>, <value>
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 <window>, <threshold>, <value>
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 <window>, <threshold>, <value>
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 <window>, <threshold>, <value>
Source LAN
AlarmType CommunicationAlarm
Severity Major
ProbableCause Unavailable
5.157 OAM Remote Errored Secs Summary <window>, <threshold>, <value>
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 <window>, <threshold>, <value>
Source LAN
AlarmType CommunicationAlarm
Severity Major
ProbableCause Unavailable
5.158 OAM Remote Errored Symbol Period <window>, <threshold>, <value>
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 <window>, <threshold>, <value>
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 Alarm Descriptions
Severity 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
Reserved Position at <Board Type> (Only applicable if source is SFP)
Source
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 <Board Type>
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 <Board Type>
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 <Board Type>
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 <Board Type>
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 <Board Type>
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 <Board Type>
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 <Board Type>
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 <Board Type>
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 <Board Type>
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 <Board Type>
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 <Board Type> (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
© Ericsson AB 2012–2014. All rights reserved. No part of this document may be reproduced in any form
Copyright
without the written permission of the copyright owner.
The contents of this document are subject to revision without notice due to continued progress in
Disclaimer 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