Results 1 to 1 of 1

Thread: ALARM DESCRIPTIONS FOR ROGERS & CINGULAR

Thread Tools

o o
Display

Show Printable Version Subscribe to this Thread Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

o o o

1. 10-02-2011, 01:31 PM #1 mosesdam

o o o

View Profile View Forum Posts Private Message

Junior Member

Join Date Apr 2011 Posts 36 Credits 30 Rep Power 0

ALARM DESCRIPTIONS FOR ROGERS & CINGULAR

ALARM DESCRIPTIONS FOR ROGERS & CINGULAR The following alarms were seen during the Cingular Rollout on the RNC/RXI/RBS and are still being seen in the Rogers HSDPA Rollout. This document will be updated any time new alarms with workarounds come in. If you come across an alarm that hasnt been reported please send the details to Michael Cerulli (lmcmcer) so this document can be updated. ALARM: 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: 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: 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: 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: 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: 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 ALARM: 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: 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

ALARM: 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: Carrier_UL_GainProblem Check attenuation in BEMAS, RBS needs one of each, DPCL, TPA, TR ALARM: Carrier_UL_GainTruncated Check whether feeder loss is outside the acceptable range (max is 6db) Check power Are RU boards steady ALARM : AuxPlugInUnit_PiuConnectionLost

Piu powered off? Cable problem? FU/RU? => Check cabx ALARM: 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: CLU_LossofMain Lost power, node is in backup mode ALARM: FCU_DeviceGroup_NumberofHWEntitiesMismatch Was HW replaced? It then might have a different revision => restart PluginunitMO for that piece ALARM: FCU_DeviceGroup_FanFailure 1 FCU has fan, if enabled and unlocked, restart it ALARM: RXDiversityLoss Check if FU Is locked ALARM: CarrierReject If HSDPA is enabled, disable it, the alarm will then go away

ALARM: 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:PSUDeviceGroup_GeneralSWError ? restart PSUDeviceGroup ALARM:Carrier_SingalNotReceivedWithinTime i.e. Sector=1, Carrier=1 => is TXboard up? => disable HSDPA, txdevicegroup on slot 10 ALARM:Bfu_BatteryChargingFailure ? check voltage on battery, should be around 50V, if not acc restartAuxUnit AuxPlugInUnit (from PS1) ALARM: UtranCell_NbapMessageFailure (in RNC) AIDevice_ExternalUnitFailure + CarrierRejectSignalFromHW (in RBS) Check if antenna feeder is too low in t&e

Check FU

ALARM: 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: RBS_LocalCellnotAdded (RNC) or NBapMessageFailure (RNC) RBS has no alarms ? cells are disabled, in RBS, txboard is down

ALARM: 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: 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 ABAB 1. Only antenna No No Yes Yes - No 2. RET/RIU, no ASC/TMA Yes, branch A No Yes Yes - No 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.

ALARM: 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.

ALARM: 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: IMA UNUSABLE Alarms on RBS Symptom: Warn IMA Link Reception Unusable at Far End remote_node_transmission_error ImaGroup=1-1-ima1,ImaLink=3 Warn IMA Link Reception Unusable at Far End

remote_node_transmission_error ImaGroup=1-1-ima1,ImaLink=4 Warn IMA Link Transmit Unusable at Far End remote_node_transmission_error ImaGroup=1-1-ima1,ImaLink=3 Warn IMA Link Transmit Unusable at Far End remote_node_transmission_error ImaGroup=1-1-ima1,ImaLink=4 Warn Remote Defect Indication on IMA Link remote_node_transmission_error ImaGroup=1-1-ima1,ImaLink=3 Warn Remote Defect Indication on IMA Link remote_node_transmission_error ImaGroup=1-1-ima1,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: 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: 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,Ti mingUnit=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,Et mc1=1,T1PhysPathTerm=pp1 >>> syncReference = Equipment=1,Subrack=1,Slot=1,PlugInUnit=1,Cbu=1,Et mc1=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,Et mc1=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,Et mc1=1,T1PhysPathTerm=pp2 >>> Return value = null ================================================== ================================ Total: 1 MOs attempted, 1 MOs actioned RBS> alt Alarm should be gone. Similar Threads:
o o o o o

Ericsson LTE Advanced Feature descriptions Huawei LTE eNODB 3900 Reffrence Parameters Descriptions 3G ALARM ANALYSIS Cingular Radio Parameters Consistency Check (C3) Tool Wimax intro and brief descriptions

Reply With Quote

Quick Navigation Network Planning Top

Site Areas Settings Private Messages Subscriptions Who's Online Search Forums Forums Home Forums Forum Management 1. Announcement 2. Telecom News 3. Requests 4. Suggestions Experts Answer 1. Ericsson 1. GSM-EDGE 2. WCDMA-HSPA 3. LTE 2. NSN 1. GSM-EDGE 2. WCDMA-HSPA 3. LTE 3. ALU

1. GSM-EDGE 2. WCDMA-HSPA 3. LTE 4. CDMA 4. Huawei 1. GSM-EDGE 2. WCDMA-HSPA 3. LTE 4. CDMA 5. ZTE 1. GSM-EDGE 2. WCDMA-HSPA 3. LTE 4. CDMA 6. General VIP Exchange Hall 1. LTE Hall 2. WCDMA GSM Hall Telecom Library 1. NSN 1. GSM-EDGE 2. WCDMA-HSPA 3. LTE 2. Ericsson 1. GSM-EDGE 2. WCDMA-HSPA 3. LTE 3. Huawei 1. GSM-EDGE 2. WCDMA-HSPA 3. LTE 4. CDMA 4. Alcatel Lucent 1. GSM-EDGE 2. WCDMA-HSPA 3. LTE 4. CDMA 5. ZTE 1. GSM-EDGE 2. WCDMA-HSPA 3. LTE 4. CDMA 6. Telecom Videos and Photo 7. Telecom Dictionary Job World 1. Jobs-A New Start Telecom Reference Room 1. General 1. GSM-GPRS-EDGE 2. WCDMA

1. Interview Corner 3. HSPA 4. LTE 2. WiMax 3. CDMA 4. E Book 5. Miscellaneous Sources 6. IBS 7. Transmission Technology 1. NSN 2. Ericsson 3. ALU 4. Huawei 5. ZTE 8. Core and Switch Technology 1. NSN 2. Ericsson 3. ALU 4. Huawei 5. ZTE Software and Planning tools 1. Drive Test Tools 1. Nemo 2. TEMS 2. Network Planning 3. Post Processing 1. ACTIX 2. Nemo Analyze 3. Aexio & MCOM 4. Google Earth Tools 5. MapInfo Only Fun 1. Recreation-Charge your mind

Previous Thread | Next Thread Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests) Bookmarks
Bookmarks

Digg del.icio.us StumbleUpon Google

Posting Permissions

You may not post new threads You may not post replies You may not post attachments You may not edit your posts

BB code is On Smilies are On [IMG] code is On [VIDEO] code is Off HTML code is Off

Forum Rules

-- Blue Folio

Contact Us Telecom Funda Archive Web Hosting Top

All times are GMT. The time now is 10:10 AM. Powered by vBulletin Version 4.1.12 Copyright 2012 vBulletin Solutions, Inc. All rights reserved. (Morbid Suite vB4) Style design and Concept by DigitalvB.com vBCredits II Deluxe v2.0.0 Copyright 2010 DragonByte Technologies Advertising positioning by Digital Point 0 inShare Share