RbsLocalCell_ConfiguredLimitExceedsLicensedLimitList of

Alarms seen with Rogers (RDC document)

The purpose of this document is gather information about the alarms seen during integration from
RDC members and to share the developed workarounds with other team members. If
you come across an alarm that isnt in this document and you think it should be added
then send an email to Michael Cerulli (lmcmcer).

A copy of this document is stored in the RDC Drive and in EKB in the
WRAN SW Deployment and Support Community
DOCUMENT LAST UPDATED ON:

January 11 2008

Alarms & Solutions

ALARM 1:Antenna alarms pointing to one sector
ALARM 2: Synchronization (RBS)
ALARM 3: Loss of Cell Delineation
ALARM 4: Carrier_RXDiversityLost
ALARM 5: AiDevice_AntennaSystemProblem or TmaDevice_AntennaSystemProblem
ALARM 6: Carrier_RejectSignalFromHardware
ALARM 7: RuDeviceGroup_GeneralHWError
ALARM 8: AiDevice_ExternalUnitFailure
ALARM 9: ExternalTma_LnaFailureBranchA
ALARM 10: Nbap (in RNC) OR Equipment for RUDeviceGroup (in RBS)
ALARM 11: Carrier_UL_GainProblem
ALARM 12: Carrier_UL_GainTruncated
ALARM 13: AuxPlugInUnit_PiuConnectionLost
ALARM 14: Tma_LnaFailure
ALARM 15: CLU_LossofMain
ALARM 16: FCU_DeviceGroup_NumberofHWEntitiesMismatch
ALARM 17: FCU_DeviceGroup_FanFailure
ALARM 18: RXDiversityLoss
ALARM 19: CarrierReject
ALARM 20: IMAGroupInsufficientLinks
ALARM 21: PSUDeviceGroup_GeneralSWError
ALARM 22: Carrier_SingalNotReceivedWithinTime
ALARM 23:Bfu_BatteryChargingFailure
ALARM 24: UtranCell_NbapMessageFailure (in RNC)
ALARM 25: UtranCell_NbapMessagefailure (RNC)
ALARM 26: RBS_LocalCellnotAdded (RNC) or NBapMessageFailure (RNC)
ALARM 27: UtranCell_InternalResourceUnavailable or UtranCell_NbapMessageFailure
ALARM 28: AiDevice_AntennaSystemProblem
ALARM 29: ExternalTMA_degraded/Failed
ALARM 30: Carrier Diversity Failed/Degraded
ALARM 31: IMA UNUSABLE
ALARM 32: Carrier_ULGainTruncated
ALARM 33: Loss of Tracking & Loss of Synch Reference Redundancy
ALARM 34: Switch Core Fault or PsDevice_LossOfMains

ALARM 35: Exceeded Maximum limit

ALARM 36: RfCable_Disconnected equipment_malfunction
ALARM 37: loss_of_signal
ALARM 38: loss_of_signal

ALARM 1:Antenna alarms pointing to one sector

To segregate whether the fault is in the feeder cable or the hardware, we need to swap the feeder cable on
FU from one sector to another and see if the fault moves too. If Yes, then its definitely a fault in the Feeder
cable. If not, then the fault should be in the FU board and it should be replaced

ALARM 2: Synchronization (RBS)

Mostly synchronization alarms are one of the following
Loss of Tracking
TU Synch Reference Loss of Signal
PDH Loss of Signal or PDH Loss of Frame or only Loss of Signal or Loss of Frame
In most cases, the node lost one of the synchronization references and the node needs
to be resynched
TU Synch Reference Loss of Signal: TUB or CBU doesnt get the signal
check the input port, cables, boards themselves
Loss of Tracking: Node is not in locked mode but in holdover mode
resetLossOfTracking on Sync MO (use LDN of pp1 and pp2 which are the
sync
references
PDH Loss of Signal/Frame or Loss of Signal/Frame: ET doesnt detect the signal
check port, cables, board (put cable between Tx and Rx on the ET), if
everything is ok, then remove this port from the sync reference

ALARM 3: Loss of Cell Delineation

This can happen for the IMA link or the separate T1
check status of T1s, their cross connection, configuration
check the link performance (ES and SES) on E1PhysPathTerm for that link, if
the numbers are increasing, then the network is not stable, if it is not
increasing, then there might be a HW issue (ET board)
ET port might be hanging, thus restart the port

ALARM 4: Carrier_RXDiversityLost
This alarm will cause a degraded carrier
check whether the RU or FU is locked
if connection is ok, try to restart the port for that sector lhsh 001200/xxx
restart
might be combined with antenna alarm (AiDevice_AntennaSystemProblem
or TmaDevice_AntennaSystemProblem), see below for more info

ALARM 5: AiDevice_AntennaSystemProblem or
TmaDevice_AntennaSystemProblem
Which alarm shows up depends on whether the antenna is connected to a TMA
check the antenna, jumper cables, cable connections visually and also by
swapping them among the sectors and see whether alarm moves
check FU

 check the value of the supervision parameter (should be 49, but if set to 0 no
alarm is reported)
restart the RU

ALARM 6: Carrier_RejectSignalFromHardware
This alarm is issued from several HW, mainly RU, TXboard and RRU
insert new HW
if this doesnt help reboot the RBS (there has been a CSR which requires
reboot)

ALARM 7: RuDeviceGroup_GeneralHWError
This alarm indicates problems with the component (written at beginning of alarm, in this
case RU)
restart RU port, restart whole RU board
if doesnt help, replace RU
Cable between RU and FU disconnected - Plug back in and restart boards with restartauxunit
command

ALARM 8: AiDevice_ExternalUnitFailure
This alarm appears if the feeder or jumper cable is connected incorrectly or damaged or
the TMA can be faulty
check the antenna, jumper cables, cable connections visually and also by
swapping them among the sectors and see whether alarm moves
check the TMA

ALARM 9: ExternalTma_LnaFailureBranchA
This alarm comes up when the two transistors amplifying the RF signals in the TMA fail.
The cell can still carry traffic as long as branch B is working, however, the RX might be
degraded.
=> run script to modify the TMA parameters
Make sure the currentHighLimA TMA parameter is set to 180 just like the currentHighLimB.

ALARM 10: Nbap (in RNC) OR Equipment for RUDeviceGroup

(in RBS)
Check in EMAS the equipment view for the RBS
Restart the specific RU/FU in RBSSubrack

ALARM 11: Carrier_UL_GainProblem

Check attenuation in BEMAS, RBS needs one of each, DPCL, TPA, TR

ALARM 12: Carrier_UL_GainTruncated

Check whether feeder loss is outside the acceptable range (max is 6db)
Check power
Are RU boards steady

ALARM 13: AuxPlugInUnit_PiuConnectionLost

Piu powered off? Cable problem?

FU/RU? => Check cabx
EC BUS disconnected
Power to FCU was cut

ALARM 14: Tma_LnaFailure

Check voltage (what TMA gives out),
if too low => check FU (bad or short circuit) => restart FU
if 0 => check if internalpower is set to yes (in ExternalTma MO)
check current (what antenna pulls out) => c heck if also AiDevice (antenna) alarm

ALARM 15: CLU_LossofMain

Lost power, node is in backup mode

ALARM 16: FCU_DeviceGroup_NumberofHWEntitiesMismatch

Was HW replaced? It then might have a different revision => restart PluginunitMO for that
piece

ALARM 17: FCU_DeviceGroup_FanFailure

1 FCU has fan, if enabled and unlocked, restart it

ALARM 18: RXDiversityLoss

Check if FU Is locked or the RX cable has been pulled out

ALARM 19: CarrierReject

If HSDPA is enabled, disable it, the alarm will then go away

ALARM 20: IMAGroupInsufficientLinks

IMAGroupInsufficientLinksatFarEnd
IMA is usually disabled, but IMA link is enabled
=> delete/recreate IMA, if that doesnt help,
=> or lock the active board (force it to go over to the redundant one), unlock after (so it
goes back)
=> or reset the processor on board

ALARM 21: PSUDeviceGroup_GeneralSWError

restart PSUDeviceGroup

ALARM 22: Carrier_SingalNotReceivedWithinTime

Carrier=1
=> is TXboard up?
=> disable HSDPA, txdevicegroup on slot 10

ALARM 23:Bfu_BatteryChargingFailure

i.e. Sector=1,

 check voltage on battery, should be around 50V, if not acc restartAuxUnit

AuxPlugInUnit (from PS1)

ALARM 24: UtranCell_NbapMessageFailure (in RNC)

AIDevice_ExternalUnitFailure + CarrierRejectSignalFromHW (in RBS)
Check if antenna feeder is too low in t&e
Check FU

ALARM 25: UtranCell_NbapMessagefailure (RNC)

Ai_Device_ExternalUnitFailure (RBS, equipment malfunction, FU aidevice=1)
Carrier_RejectSignalFromHardware (RBS)
In RBS t&e: antennafeeder low/high
turn off TMA power

ALARM 26: RBS_LocalCellnotAdded (RNC) or

NBapMessageFailure (RNC)
RBS has no alarms
cells are disabled, in RBS, txboard is down

ALARM 27: UtranCell_InternalResourceUnavailable or

UtranCell_NbapMessageFailure
workaround to reload the module where the RBS is
The module can be found in the properties of the RBS in EMAS under iub_links in the
Radio Network view.
Or it can be found using Moshell on the RNC
>pr iublink
Find the RBS in the list and do a get on it.
Read the module based on above info.

ALARM 28: AiDevice_AntennaSystemProblem

Use the following RBS command:
Moshell <rbs>
lt antennabranch
get antennabranch antennaSupervisionThreshold
lt tma
get tma power
In the RBS there is feature to measure the VSWR (Voltage Standing
Wave Ratio). In simple words, the VSWR is a measure of the
reflection in the RF path caused by faulty equipment between the
RBS and the Antenna. In case of non-TMA sites, the RBS has
another feature call DC resistance. See the following table to see
which features are used for the US market.

Table: Valid for FU12 19 and FU12 08, - = not supported

Configuration/Supervision

Feeder
Power
Supply
SV

DC
Antenna
SV

VSWR
Antenna
SV

TMA
SV

1. Only antenna

No

No

Yes

Yes

No

2. RET/RIU, no ASC/TMA

Yes,

No

Yes

Yes

No

branch A

3.TMA, external power supply

No

No

No

Yes

No

4. TMA, power supply by

FU/AIU

Yes

No

No

Yes

Yes

5. ASC

Yes

No

No

No

No

Note: Observe that when TMA is defined Branch B has NO

supervision.
If the antennasupervisionthreshold is not set correctly (general value
is 49) then we see this alarm. The formula for the different types of
supervision is in MOM and given below as well:
When DC resistance supervision is used the threshold maps to a
resistance (R),
R = (101-antennaSupervisionThreshold)*0.15 ohm
When VSWR supervision is used the threshold is mapped to a
return loss (RL),
when performed by ASC:
RL = 4 + 0.1*antennaSupervisionThreshold dB
when performed by FU:
RL = 3.3 + 0.22*antennaSupervisionThreshold dB
VSWR = (1+10^(-RL/20))/(1-10^(-RL/20))
The threshold value 0 means that the supervision is turned off.
In this case ask the ASP to put dummy loads on the RBS to
eliminate alarms with the Antenna.
Set the AntennaSupervision Threshold in Branch B to 0 for all the sectors to get rid of this alarm.

This is because the feeder cable is shared by the 1900 and the 850, and the 1900 powers the
TMA (15V) through the jumper cables thus interfering with the 850 branch B antenna supervision
readings (tests for DC resistance) triggering the alarm. Rogers is aware about this.

ALARM 29: ExternalTMA_degraded/Failed

Moshell <rbs>
cabx
# The cabx printout has PORT information at the end.
# For a 3 sector site there are 6 PORT information. One line for
# RU and FU devices (3 RU+3FU).
The printout shows the port, for example,
====================================
SMN APN PORT
BOARD
====================================
0 12 port_0_dev_8 RU22
0 12 port_0_dev_8 FU
0 12 port_4_dev_9 RU22
0 12 port_4_dev_9 FU
0 12 port_8_dev_10 RU22
0 12 port_8_dev_10 FU
------------------------------------

lhsh 001200/port_x_dev_yy fui get devstat

# get port information from cabx
Ensure that the devstat printout from above has ~16000mV for each
sector and the current is between 50mA-200mA, if and only if the
site has TMAs defined and is being powered by the UMTS RBS
(MO:externalTMA, Attribute:internalpower).
Each RBS in the US market, has threshold when this alarm is
generated. These thresholds are input into the RBS using scripts.
The thresholds vary for single band TMAs and dual band TMAs.
Make sure that the right threshold is set for the type of TMA. Below
is the threshold script for quick reference.
acc SystemConstants=1 writeConst
y
300
00001
acc SystemConstants=1 writeConst
y
301
135
acc SystemConstants=1 writeConst
y

302
270
acc SystemConstants=1 writeConst
y
303
135
acc SystemConstants=1 writeConst
y
304
270
For more information about the thresholds please see the following
document.

E:\Project_doc\
UMTS_docs\Reference_Info\RBS_Reference\AntennaSupervision_TMA\TMA threshold configuration.doc

ALARM 30: Carrier Diversity Failed/Degraded

In the RBS antenna branch A is TX/RX while branch B is RX only. Hence there are two RX paths
(RX diversity). The RBS monitors the two RX paths and compares the signal received from both
of these paths. If there is significant mismatch between these paths (like TMA failure on branch
B. Remember branch B has no supervision) then this alarm is generated.
This alarm is suppressed if there is a higher priority alarm such as the
AI_Device_antenna_system_problem. Give lgar command in moshell to see if this alarm was
raised and suppressed.

ALARM 31: IMA UNUSABLE

Alarms on RBS
Symptom:
Warn IMA Link Reception Unusable at Far End remote_node_transmission_error ImaGroup=1-1ima1,ImaLink=3
Warn IMA Link Reception Unusable at Far End remote_node_transmission_error ImaGroup=1-1ima1,ImaLink=4
Warn IMA Link Transmit Unusable at Far End remote_node_transmission_error ImaGroup=1-1ima1,ImaLink=3
Warn IMA Link Transmit Unusable at Far End remote_node_transmission_error ImaGroup=1-1ima1,ImaLink=4
Warn Remote Defect Indication on IMA Link remote_node_transmission_error ImaGroup=1-1ima1,ImaLink=3
Warn Remote Defect Indication on IMA Link remote_node_transmission_error ImaGroup=1-1ima1,ImaLink=4

Solution:
Make a cv on the RBS and cold restart RBS to clear alarms for imalink=3 and imalink=4.
cvms <cv name> <user> <comment>

acc 0 restart

ALARM 32: Carrier_ULGainTruncated

Symptoms
The RBS sectors which have long feed cables with feeder loss bigger than 6db get alarm
Carrier_ULGainTruncated, Bad Coverage on UE
The parameter ulfeederAtteunation should be set according to the actual feeder length,
even if the feeder attenuation is greater than 6db.The TRs HG19495 and HG67667
(WRNad12085) have been opened in PLM.
The problem occurs at sites with feeder losses bigger than 6dB and it is the entered feeder
loss value that triggers this alarm.
The alarm doesn't point out a real error (except in the case that the operator enters a value
that are bigger than 6dB by mistake), its more of an information that the feeder are large
and performance can get degraded with large feeder losses.
REMEDY:
This is a warning alarm issued when the UL amplification internally in the RBS cannot
compensate for the attenuation in the Antenna Feeder Cable. Optimal sensitivity is no
longer obtained.
Nothing in the RBS changes state because of this situation and trafic handling continues.
The external attenuation, that is the combination of the gain of the TMA and the UL
Attenuation of the Antenna Feeder (AntFeederCable), is larger than what the Low Noce
Amplifier (LNA) on the FU can compensate for. When that situation arise, the alarm
Carrier_ULGainTruncated is issued.
Accept the presence of the warning alarm. The ulAttenuation of AntennaFeederCable
shall not be changed to a false value, as that impacts the power measurements.
This alarm is planned to be removed in a later sw revision on the RBS.
The correction to this fault, WRNad12085, will be delivered by CR WRNad14794 in
RBS CXP 901 0809 R30A, included in RAN 4.0.12 which is planned to be released on
June 22. The P5ED package name is not known at the moment but will be released at the
same time as the P4 package.

ALARM 33: Loss of Tracking & Loss of Synch Reference

Redundancy
RBS> alt

1969-12-31 21:44:18 M Loss of Tracking replaceable_unit_problem Synchronization=1

1969-12-31 21:45:18 w Loss of Synch Reference Redundancy replaceable_unit_problem
Synchronization=1

RBS> lpr sync

060810-10:16:56 172.20.229.73
==================================================================================
Proxy MO
==================================================================================
102 Equipment=1,Subrack=1,Slot=1,PlugInUnit=1,Cbu=1,TimingUnit=1,TuSyncRef=1
1035 TransportNetwork=1,Synchronization=1
1102 NodeBFunction=1,RBSxxxSynchronization=1
1164 NodeBFunction=1,Iub=RBS,NodeSynchTp=1

RBS> get 1035

==============================================================
1035
TransportNetwork=1,Synchronization=1
==============================================================
SynchronizationId
1
degradationIsFault
0 (degrNotFault)
syncRefActivity
i[8] = 1 2 1 1 1 1 1 1
syncRefPriority
i[8] = 1 2 0 0 0 0 0 0
syncRefStatus
i[8] = 2 3 0 0 0 0 0 0
syncReference
[8] =
>>> syncReference =
Equipment=1,Subrack=1,Slot=1,PlugInUnit=1,Cbu=1,Etmc1=1,T1PhysPathTerm=pp1
>>> syncReference =
Equipment=1,Subrack=1,Slot=1,PlugInUnit=1,Cbu=1,Etmc1=1,T1PhysPathTerm=pp2
>>> syncReference =
>>> syncReference =
>>> syncReference =
>>> syncReference =
>>> syncReference =
>>> syncReference =
systemClockA
2 (lockedMode)
systemClockB
7 (notApplicable)
systemClockRedundancy
0 (SYSTEM_CLOCK_USERS_USE_PLANE_A)
userLabel
==================================================================================
Total: 1 MOs

RBS> acl 1035

==================================================================================
Proxy MO
Action
Nr of Params
==================================================================================
1035 Synchronization=1
addSyncRefResource
2
1035 Synchronization=1
changeSyncRefPriority
2
1035 Synchronization=1
removeSyncRefResource
1
1035 Synchronization=1
resetLossOfTracking
1
==================================================================================

RBS> acc 1035 resetLossOfTracking

==================================================================================
1035 TransportNetwork=1,Synchronization=1
==================================================================================
Are you Sure [y/n] ? y
==================================================================================
Proxy MO
Action
Nr of Params
==================================================================================
1035 Synchronization=1
resetLossOfTracking
1

Parameter 1 of 1, syncReference (moRef-ManagedObject):

Enter mo LDN: Equipment=1,Subrack=1,Slot=1,PlugInUnit=1,Cbu=1,Etmc1=1,T1PhysPathTerm=pp1
>>> Return value = null
==================================================================================
Total: 1 MOs attempted, 1 MOs actioned

RBS> acc 1035 resetLossOfTracking

==================================================================================
1035 TransportNetwork=1,Synchronization=1
==================================================================================
Are you Sure [y/n] ? y
==================================================================================
Proxy MO
Action
Nr of Params
==================================================================================
1035 Synchronization=1
resetLossOfTracking
1
Parameter 1 of 1, syncReference (moRef-ManagedObject):
Enter mo LDN: Equipment=1,Subrack=1,Slot=1,PlugInUnit=1,Cbu=1,Etmc1=1,T1PhysPathTerm=pp2
>>> Return value = null
==================================================================================
Total: 1 MOs attempted, 1 MOs actioned
RBS> alt
Alarm should be gone.

ALARM 34: Switch Core Fault or PsDevice_LossOfMains

Several ASPs lock sectors on their end. However, when they do so, some of them will block other
components by chance. This will throw alarms such as the ones mentions above.
1) Switch Core Fault: they blocked one of the redundancy slots.
2) PsDevice_LossOfMains: they tampered with the PCU.

ALARM 35:
RbsLocalCell_ConfiguredLimitExceedsLicensedLimit
unavailable
The cell range isnt set prorerly.
Block the cells on the RNC
On the RBS, set the cell range with command set cell cellrange 35000

ALARM 36: Node Status Analyzer doesnt open

If you get the following error when opening "NODE STATUS ANALYZER" to view cell activity
remotely:
"mismatch: struct IDL:Configuration/DataTypes/UndefinedValue:1.0 UndefinedValue{long
dummy} != string[0] vmcid: 0x0 minor code: 0 completed: No
Please run the Iub consistency report on the RNC.
How to open NODE STATUS ANALYZER:

In WCDMA RAN Explorer, Select the RBSRight click on itGo to ToolsSelect Node
Status Analyzer
How to run the Iub consistency report:
In WCDMA RAN Explorer, Select the RNC that RBS belongs toRight click on itGo to
ConsistencySelect IUB Consistency Report

ALARM 37: RfCable_Disconnected equipment_malfunction

Due to the TX plugin from FU board being disconnected.
Plug it back in.
A restart of the plugin unit may be required to eliminate the alarm.

ALARM 38: loss_of_signal

ET 1-2 connector pulled out

Alarm 39: TU Synch Reference Loss of Signal loss_of_signal

TU Synch Reference Loss of Signal loss_of_signal
Probable cause: TimingUnit=1,TuSyncRef=1 is unlocked but disabled.
Solution: Lock the TimingUnit=1,TuSyncRef=1 so that it is locked and disabled.
VN21DU> alt
070920-10:31:11 172.18.99.225 7.0e RBS_NODE_MODEL_J_5_5 stopfile=/tmp/21814
Trying file=/home/emc2ndl/moshell_logfiles/logs_moshell/tempfiles/20070920-101558_21784/ior21784
C601731_DEBUG: We are going to create the SSL Listener on port of 0
C601731_DEBUG: InetAddress is /172.21.54.44
C601731_DEBUG: going to create the listener socket using _serverSocket = new ServerSocket(_port, 50, inetAddr)
Resolving the alarm service in OMS...
Simple Alarm Client initialized...
Starting to retrieve active alarms
Nr of active alarms are: 1
============================================================================================
====
Date & Time (Local) S Specific Problem
Cause
Mo-Reference
============================================================================================
====
2007-09-20 01:33:03 M TU Synch Reference Loss of Signal loss_of_signal
Subrack=1,Slot=1,PlugInUnit=1,Cbu=1,TimingUnit=1,TuSyncRef=1
>>> Total: 1 Alarms (0 Critical, 1 Major)

When u see this alarm, do a lst on TimingUnit=1,TuSyncRef=1:

VN21DU> lst TimingUnit=1,TuSyncRef=1
070920-11:24:41 172.18.99.225 7.0e RBS_NODE_MODEL_J_5_5 stopfile=/tmp/21814
===================================================================================
Proxy Adm State Op. State MO
===================================================================================
136 1 (UNLOCKED) 0 (DISABLED) Equipment=1,Subrack=1,Slot=1,PlugInUnit=1,Cbu=1,TimingUnit=1,TuSyncRef=1
===================================================================================
Total: 1 MOs

If it is unlocked like in the above state, than that is the cause of the alarm, the reson
of the alarm is that the RBS are getting their synchronisation signal from the T1s and
not from the timing unit by gps. So if this mo is unlocked it is expecting a sync signal
that it is not getting so it thinks that the source of sync just droped and it lost the
signal, hence the alarm.

Lock that MO and the alarm should clear.

VN21DU> lbl 136
070920-11:24:41 172.18.99.225 7.0e RBS_NODE_MODEL_J_5_5 stopfile=/tmp/21814
===================================================================================
Proxy Adm State Op. State MO
===================================================================================
136 0 (LOCKED) 0 (DISABLED) Equipment=1,Subrack=1,Slot=1,PlugInUnit=1,Cbu=1,TimingUnit=1,TuSyncRef=1
===================================================================================
Total: 1 MOs

Ther should be no alarms left:

VN21DU> alt
070920-10:31:11 172.18.99.225 7.0e RBS_NODE_MODEL_J_5_5 stopfile=/tmp/21814
Trying file=/home/emc2ndl/moshell_logfiles/logs_moshell/tempfiles/20070920-101558_21784/ior21784
C601731_DEBUG: We are going to create the SSL Listener on port of 0
C601731_DEBUG: InetAddress is /172.21.54.44
C601731_DEBUG: going to create the listener socket using _serverSocket = new ServerSocket(_port, 50, inetAddr)
Resolving the alarm service in OMS...
Simple Alarm Client initialized...
Starting to retrieve active alarms
Nr of active alarms are: 0
============================================================================================
====
Date & Time (Local) S Specific Problem
Cause
Mo-Reference
============================================================================================
====
>>> Total: 0 Alarms (0 Critical, 0 Major)

TO finish, It is very important to create a cv and set it as startable.