No Debo Mlrc

UTRAN

Outputs

Node B (Radio Commander)

OML:Node B (RC)

A50016-G5000-F294-prelim3-7619ND-57469-703(E)-prelim03

2Siemens AG:A50016-G5000-F294-prelim3-7619NEC Corporation:ND-57469-703(E)-prelim03

OML:Node B (RC) OutputsNode B (Radio Commander)

f Important Notice on Product Safety

DANGER - RISK OF ELECTRICAL SHOCK OR DEATH - FOLLOW ALL INSTALLATION INSTRUCTIONS.

The system complies with the standard EN 60950 / IEC 60950. All equipment connected to the system mustcomply with the applicable safety standards.Hazardous voltages are present at the AC power supply lines in this electrical equipment. Some components mayalso have high operating temperatures.Failure to observe and follow all installation and safety instructions can result in serious personal injuryor property damage.Therefore, only trained and qualified personnel may install and maintain the system.

The same text in German:

Wichtiger Hinweis zur Produktsicherheit

LEBENSGEFAHR - BEACHTEN SIE ALLE INSTALLATIONSHINWEISE.

Das System entspricht den Anforderungen der EN 60950 / IEC 60950. Alle an das System angeschlossenenGeräte müssen die zutreffenden Sicherheitsbestimmungen erfüllen.In diesen Anlagen stehen die Netzversorgungsleitungen unter gefährlicher Spannung. Einige Komponentenkönnen auch eine hohe Betriebstemperatur aufweisen.Nichtbeachtung der Installations- und Sicherheitshinweise kann zu schweren Körperverletzungen oderSachschäden führen.Deshalb darf nur geschultes und qualifiziertes Personal das System installieren und warten.

Caution:This equipment has been tested and found to comply with EN 301489. Its class of conformity is defined in tableA30808-X3247-X910-*-7618, which is shipped with each product. This class also corresponds to the limits for aClass A digital device, pursuant to part 15 of the FCC Rules.These limits are designed to provide reasonable protection against harmful interference when the equipment isoperated in a commercial environment.This equipment generates, uses and can radiate radio frequency energy and, if not installed and used in accor-dance with the relevant standards referenced in the manual “Guide to Documentation”, may cause harmful inter-ference to radio communications.For system installations it is strictly required to choose all installation sites according to national and local require-ments concerning construction rules and static load capacities of buildings and roofs.For all sites, in particular in residential areas it is mandatory to observe all respectively applicable electromagneticfield / force (EMF) limits. Otherwise harmful personal interference is possible.

Trademarks:

All designations used in this document can be trademarks, the use of which by third parties for their own purposescould violate the rights of their owners.

Copyright (C) Siemens AG / NEC Corporation 2005.

Issued by:Siemens AG, Communications, Hofmannstraße 51, 81359 München, Germany andNEC Corporation, 7-1, Shiba 5-chome, Minato-ku, Tokyo, Japan

Technical modifications possible.Technical specifications and features are binding only insofar as they are specifically and expressly agreed upon in a written contract.

OutputsNode B (Radio Commander)

OML:Node B (RC)

Siemens AG:A50016-G5000-F294-prelim3-7619NEC Corporation: ND-57469-703(E)-prelim03 3

Reason for UpdateSummary:Addition of two new alarms (Error-IDs 200658 and 200659). Improved error descriptions

and troubleshootings.

Details:

Chapter/Section Reason for Update

200658 - Transmit bandwidth

limit for NBAP reached

200659 - Core Controller

overload protection activated

New

All Improved error descriptions and troubleshootings.

Editorial changes.

Issue HistoryIssue Date of issue Reason for Update

1 05/2005 First issue for new release.

2 07/2005 Addition of three new alarms (Error-IDs 201038,

201039, and 201040). Deletion of two alarms

(Error-IDs 200930 and 200978). Modification of the

error description for MEF alarms.

Generally, improved descriptions and editorial

changes.

prelim3 10/2005 Addition of two new alarms (Error-IDs 200658 and

200659). Improved error descriptions and trouble-

shootings.




OML:Node B (RC)


This document consists of 246 pages. All pages are issue prelim3.

Contents

Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11Title . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11Failure Event Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11Managed Object Class / Hardware Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11Event Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11Probable Cause . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12Severity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12Error Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Errors in Numerical Order (error-ID). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15200506 - Node B system start-up malfunction due to software/hardware problem . . 16200507 - System halt due to software watchdog detected problem. . . . . . . . . . . . . . 17200508 - System halt due to detected application process error . . . . . . . . . . . . . . . . 18200509 - System halt due to detected hardware exception . . . . . . . . . . . . . . . . . . . . 19200510 - System halt due to detected software loading malfunction . . . . . . . . . . . . . 20200656 - Iub link broke down . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21200657 - SSCOP sent overrun. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23200658 - Transmit bandwidth limit for NBAP reached . . . . . . . . . . . . . . . . . . . . . . . . 24200659 - Core Controller overload protection activated. . . . . . . . . . . . . . . . . . . . . . . 25200706 - An error occurred in the nbDatabase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26200707 - A warning occurred in the nbDatabase. . . . . . . . . . . . . . . . . . . . . . . . . . . . 27200756 - System call unsuccessful . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28200757 - Unexpected software error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29200758 - Not enough memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30200759 - A fatal error has occurred that may affect OAM command processing. . . . 31200905 - VSWR alarm Low . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32200906 - VSWR alarm High . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33200907 - RX alarm Low . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34200908 - RX alarm High. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35200909 - TMA switched off, but not defective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36200910 - TMA feeder alarm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37200911 - TMA DC alarm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39200914 - Fan unit failed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40200915 - Site input alarm detected . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41200916 - Rack Door open . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43200918 - PA combiner interface fault . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44200919 - Failure in the DC supply of PA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45200920 - High temperature of PA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46200921 - Over temperature of PA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47200922 - RF performance not being met due to bad linearisation . . . . . . . . . . . . . . . 48200923 - Internal failure of PA detected. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49200924 - Input power level of LPA too high but LPA can still hold its RF specification .

50200925 - Input power level of PA too high . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51



200926 - CPU failure of baseband card . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52200927 - Volatile memory failure of baseband card . . . . . . . . . . . . . . . . . . . . . . . . . . 53200928 - Non-volatile memory failure of baseband card. . . . . . . . . . . . . . . . . . . . . . . 54200929 - DSP failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55200931 - FPGA failure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56200932 - Control FPGA failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57200933 - External timing signal failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58200934 - Failure of the RF part of the TRX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59200935 - LVDS Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60200936 - Local bus failure around the CPU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61200937 - FTP connection failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62200938 - SWI CRC check failed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63200939 - Static configuration file CRC check failed . . . . . . . . . . . . . . . . . . . . . . . . . . 64200940 - SW activation failed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65200941 - Internal clock failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66200942 - Configuration file inconsistent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67200943 - IOR file inconsistent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68200944 - FTP put failed. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69200945 - FTP manage failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70200946 - Still alive supervision failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71200947 - Failure in the DC supply of DUAMCO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72200948 - CORBA communication failed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73200949 - Internal CORBA call failed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74200950 - Timeout for request or modification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75200951 - Status notification undefined . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76200952 - Maximum number of resets exceeded . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77200953 - CAN bus off . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78200954 - No message response on CAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79200955 - Mount supervision failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80200956 - Watch dog timer expired . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81200957 - Internal CAN processing failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83200958 - Timer for the reset supervision expired . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84200959 - Missing response from baseband card . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85200960 - Invalid response from baseband card . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86200961 - Firmware download failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87200980 - Invalid MO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88200981 - MO not mounted . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89200982 - Invalid command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90200983 - Invalid parameter in command. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91200984 - FW download access file error. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92200985 - CAN transaction error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93200986 - Temperature out of range in upper direction . . . . . . . . . . . . . . . . . . . . . . . . 94200987 - Hardware parameter invalid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95200988 - Response unknown . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96200989 - No CORBA proxy available for LRU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97200990 - No still alive response from LRU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98200991 - Duplex error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99


OML:Node B (RC)


200992 - Software Error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100200993 - Unexpected Alarm Status Bit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101200994 - HW Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102200995 - High Temperature Limit (Ht3) reached . . . . . . . . . . . . . . . . . . . . . . . . . . . 103200996 - Critical Temperature Limit (Ht4) reached . . . . . . . . . . . . . . . . . . . . . . . . . 104200997 - Lower Temperature Limit (Ht0) reached . . . . . . . . . . . . . . . . . . . . . . . . . . 105200998 - Temperature out of range in lower direction . . . . . . . . . . . . . . . . . . . . . . . 106200999 - Unexpected loss of unlocked card . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107201001 - RET power off . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108201002 - RET feeder alarm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109201003 - RET hardware alarm. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110201004 - RET communication error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111201005 - RET isn’t calibrated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112201006 - RET isn’t scaled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113201007 - RET lost position . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114201008 - RET received wrong configuration data . . . . . . . . . . . . . . . . . . . . . . . . . . 115201009 - A mounted card is not used to its full capacity . . . . . . . . . . . . . . . . . . . . . 116201010 - An incompatible card is mounted . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117201011 - Alignment of standby CC failed. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118201012 - Timeout for connection to standby CC . . . . . . . . . . . . . . . . . . . . . . . . . . . 119201013 - Connection failure to standby CC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120201014 - Standby CC forced to become active due to unreachable active CC . . . . 121201015 - Preparation of data to be aligned has failed . . . . . . . . . . . . . . . . . . . . . . . 122201016 - Non-fatal internal LVDS failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123201017 - Digital input power level too high, but gain reduced . . . . . . . . . . . . . . . . . 124201018 - The LRU could not process a message from CC . . . . . . . . . . . . . . . . . . . 125201019 - Gain below threshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126201020 - Loss of single DRIF interface detected . . . . . . . . . . . . . . . . . . . . . . . . . . . 127201022 - Alignment of file data has failed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128201023 - Bad signal quality of single DRIF interface detected. . . . . . . . . . . . . . . . . 129201024 - Bad signal quality of all DRIF interfaces detected. . . . . . . . . . . . . . . . . . . 130201025 - PID could not be read or is corrupted . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131201026 - LRU sent illegal parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132201027 - LRU could not process a message from CC containing data from DB . . . 133201028 - HW-failure clock processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134201029 - MEF blocked . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135201030 - Invalid hardware capacity licensing value . . . . . . . . . . . . . . . . . . . . . . . . . 136201031 - Wrong combination of licensed cards . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137201032 - Not all cells are licensed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138201033 - PID could not be read or is corrupted - non-fatal . . . . . . . . . . . . . . . . . . . 139201034 - Booster’s Fan unit failed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140201035 - MEF completely blocked. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141201036 - RRHs unable to establish communication links with the expected number of

PSRs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142201037 - RET unspecified error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143201038 - Resource conflict between CP and OAM . . . . . . . . . . . . . . . . . . . . . . . . . 144201039 - Inconsistency between hardware license and configuration . . . . . . . . . . . 145



201040 - Wrong cabling of LRU detected . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146201916 - Toggling condition detected for alarm “AIS”, SP ID 202059 . . . . . . . . . . . 147201917 - Toggling condition detected for alarm “RAI”, SP ID 202060 . . . . . . . . . . . 148201918 - Toggling condition detected for alarm “lineAIS”, SP ID 202062. . . . . . . . . 149201919 - Toggling condition detected for alarm “lineRDI”, SP ID 202063 . . . . . . . . 150201920 - Toggling condition detected for alarm “pathAIS”, SP ID 202065 . . . . . . . . 151201921 - Toggling condition detected for alarm “pathRDI”, SP ID 202066 . . . . . . . . 152201922 - Toggling condition detected for alarm “vcAIS”, SP ID 202072. . . . . . . . . . 153201923 - Toggling condition detected for alarm “vcRDI”, SP ID 202073 . . . . . . . . . 154201924 - Toggling condition detected for alarm “vpAIS”, SP ID 202075. . . . . . . . . . 155201925 - Toggling condition detected for alarm “vpRDI”, SP ID 202076 . . . . . . . . . 156201926 - Toggling condition detected for alarm “LOC”, SP ID 202097. . . . . . . . . . . 157202006 - A bbUsageRatio Quality of Service alarm has occurred . . . . . . . . . . . . . . 158202007 - A scanner could not be initialized. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159202008 - The temporary measurement results could not be stored . . . . . . . . . . . . . 160202009 - Unable to request measurement results . . . . . . . . . . . . . . . . . . . . . . . . . . 161202010 - The ScanCo could not be initialized. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162202011 - The final results files could not be generated. . . . . . . . . . . . . . . . . . . . . . . 163202012 - The first bbUsageRatio Quality of Service alarm has occurred . . . . . . . . . 164202013 - The second bbUsageRatio Quality of Service alarm has occurred . . . . . . 165202014 - The first sccpchUsageRatio Quality of Service alarm has occurred . . . . . 166202015 - The second sccpchUsageRatio Quality of Service alarm has occurred . . 167202016 - The first prachUsageRatio Quality of Service alarm has occurred . . . . . . 168202017 - The second prachUsageRatio Quality of Service alarm has occurred. . . . 169202018 - The first cpUsageRatio Quality of Service alarm has occurred . . . . . . . . . 170202019 - The second cpUsageRatio Quality of Service alarm has occurred . . . . . . 171202020 - The first prachCrciFailures Quality of Service alarm has occurred . . . . . . 172202021 - The second prachCrciFailures Quality of Service alarm has occurred . . . 173202056 - Loss Of Signal on Physical Link. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174202057 - Loss Of Frame on Physical Link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176202058 - Loss Of Cell Delineation on Physical Link . . . . . . . . . . . . . . . . . . . . . . . . . 178202059 - Alarm Indication Signal on Physical Link . . . . . . . . . . . . . . . . . . . . . . . . . . 179202060 - Remote Alarm Indication on Physical Link. . . . . . . . . . . . . . . . . . . . . . . . . 180202061 - Loss of Multi Frame Alarm Indication on E1 Physical Link . . . . . . . . . . . . 181202062 - Line Alarm Indication Signal Indication on STM1 Physical Link. . . . . . . . . 183202063 - Line Remote Defect Indication on STM1 Physical Link . . . . . . . . . . . . . . . 184202064 - Path Loss of Pointer Indication on STM1 Physical Link. . . . . . . . . . . . . . . 185202065 - Path Alarm Indication Signal on STM1 Physical Link . . . . . . . . . . . . . . . . 187202066 - Path Remote Defect Indication on STM1 Physical Link. . . . . . . . . . . . . . . 189202068 - Signal Label Mismatch Indication on STM1 Physical Link . . . . . . . . . . . . . 190202070 - Signal Degrade Indication on STM1 Physical Link . . . . . . . . . . . . . . . . . . 191202071 - Excessive Bit Error Rate Indication on STM1 Physical Link . . . . . . . . . . . 192202072 - Alarm Indication Signal on an ATM VC . . . . . . . . . . . . . . . . . . . . . . . . . . . 193202073 - Remote Defect Indication on an ATM VC . . . . . . . . . . . . . . . . . . . . . . . . . 194202074 - SSCOP Failure Indication on an ATM VC used by ALCAP or NBAP . . . . 195202075 - Alarm Indication Signal on an ATM VP . . . . . . . . . . . . . . . . . . . . . . . . . . . 196202076 - Remote Defect Indication on an ATM VP . . . . . . . . . . . . . . . . . . . . . . . . . 197


OML:Node B (RC)


202077 - ALCAP PVC Out Of Service Indication . . . . . . . . . . . . . . . . . . . . . . . . . . . 198202078 - Loss Of Delay Synchronisation on IMA Link . . . . . . . . . . . . . . . . . . . . . . . 199202079 - Loss Of IMA Frame on IMA Link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200202080 - Remote Failure Indicator on IMA Link. . . . . . . . . . . . . . . . . . . . . . . . . . . . 201202081 - IMA Tx link is detected as mis-connected. . . . . . . . . . . . . . . . . . . . . . . . . 202202082 - IMA Rx link is detected as mis-connected . . . . . . . . . . . . . . . . . . . . . . . . 203202083 - Tx fault declared at the NE on IMA Link . . . . . . . . . . . . . . . . . . . . . . . . . . 204202084 - Rx fault declared at the NE on IMA Link . . . . . . . . . . . . . . . . . . . . . . . . . . 205202085 - FE has reported Tx-Unusable on IMA Link . . . . . . . . . . . . . . . . . . . . . . . . 206202086 - FE has reported Rx-Unusable on IMA Link. . . . . . . . . . . . . . . . . . . . . . . . 207202087 - Startup FE reported on IMA Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208202088 - Config Abort reported on IMA Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209202089 - Config Abort FE reported on IMA Group. . . . . . . . . . . . . . . . . . . . . . . . . . 210202090 - Insufficient Links reported at NE on IMA Group . . . . . . . . . . . . . . . . . . . . 211202091 - Insufficient Links at FE reported on IMA Group . . . . . . . . . . . . . . . . . . . . 212202092 - Group Blocked at FE reported on IMA Group. . . . . . . . . . . . . . . . . . . . . . 213202093 - Timing Synch error reported on IMA Group . . . . . . . . . . . . . . . . . . . . . . . 214202095 - The Near End IMA has detected an invalid version set by the Far End . . 215202097 - Loss of Continuity detected on an ATM VP . . . . . . . . . . . . . . . . . . . . . . . 216202098 - CRC4 not used by FE reported on E1TTP . . . . . . . . . . . . . . . . . . . . . . . . 217202106 - Software activation failed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218202107 - Database activation failed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219202108 - Reliable software started without prior explicit activation . . . . . . . . . . . . . 220202109 - Reliable database started without prior explicit activation. . . . . . . . . . . . . 221202156 - Cannot acquire mutex for logging of FER. . . . . . . . . . . . . . . . . . . . . . . . . 222202157 - Cannot release mutex after logging of FER . . . . . . . . . . . . . . . . . . . . . . . 223202158 - Reset safe RAM for logging of FERs unavailable . . . . . . . . . . . . . . . . . . . 224202357 - CAN opcode not valid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225202358 - CAN received an unexpected message . . . . . . . . . . . . . . . . . . . . . . . . . . 226202359 - CAN received a message with an invalid parameter . . . . . . . . . . . . . . . . 227202360 - A necessary resource is missed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228202406 - ALCAP Protocol Error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229202431 - ITR initiated action from CPA to RNC timed out . . . . . . . . . . . . . . . . . . . . 230202432 - CPN initiated action from CPA to RNC timed out . . . . . . . . . . . . . . . . . . . 231202433 - Configuration misalignment between RNC and CPA . . . . . . . . . . . . . . . . 232202434 - RNC Establish Request message received which is invalid or cannot be han-

dled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233202435 - CPA to RNC communication (socket) problems . . . . . . . . . . . . . . . . . . . . 234202456 - CC Clock Warm Up Error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235202457 - CC Card HW Test Error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236202506 - Node B System Clock in Holdover Mode . . . . . . . . . . . . . . . . . . . . . . . . . 237202507 - Node B System Clock in Medium Accuracy . . . . . . . . . . . . . . . . . . . . . . . 238262041 - System call unsuccessful . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240262042 - Unexpected software error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241262043 - Error from Device Driver received. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242262044 - Not enough memory to initialize software . . . . . . . . . . . . . . . . . . . . . . . . . 243262045 - Memory allocation failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244



262046 - Unexpected exception handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245262047 - Uncaught exception handling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246


OML:Node B (RC)


Introduction

The aim of this manual is to describe all alarms and system information which can begenerated by the Node B. The OML:Node B (RC) provides information on handlingthese alarms via the RC.

A description of the general UTRAN maintenance concept and an example of how tosolve an alarm are provided in the Guide to Documentation.

The software attempts to provide a precise error description for each alarm containingall information for the operator and manufacturer for rapid localization, investigation andelimination of the fault. There is no relation between the number of described faults andtheir frequency of occurrence in the system.

Error ceased messages clear all alarms for a certain probable cause of one object. Ev-ery time that a diagnostic on a faulty object fails, the operator has to replace the faultymodule (specified in the Test Report) following the procedure described in the accordingmaintenance manual.

This manual is organized according to the error-IDs where each one forms a chapterwith:• Title• Failure Event Report• Error Description• Troubleshooting

TitleComposed of error-ID and error string

Failure Event ReportContains the following details:• Managed Object Class / Hardware Type• Event Type• Probable Cause• Severity

Managed Object Class / Hardware TypeThe managed object class / hardware type dentifies the managed object class of thefault or error.

In the OML:Node B (RC), an asterisk (’*’) symbol in the related field of the failure eventreport means that potentially any managed object class / hardware type can report thisalarm.

Event TypeThe event type may have these possible values:• communicationAlarm• environmentalAlarm

iThis document is prepared as a standard edition that may include descriptions not ap-plying to your system.



• equipmentAlarm• qualityOfServiceAlarm• processingErrorAlarm

Probable CauseIdentifies the probable cause of the fault or error. The probable cause is taken out of apredefined set of values defined for each alarm type.

SeverityAccording to the CCITT Rec. X.733 all alarm notifications produced in switching sys-tems have to be classified concerning the severity of their impact on the NE's (NetworkElement) functionality.

The severity assigned to a specific alarm has one of the following values:• critical• major• minor• warning

Fault Escalation Strategy

Some specific problems are handled according to the Fault Escalation Strategy. TheFault Escalation Strategy consists of the following rules:• If the object raises the corresponding alarm for the first time, the alarm’s severity is

WARNING.• Upon each occurrence of this alarm, a dedicated escalation counter is incremented

and a corresponding dedicated escalation timer is (re-)started.• If the object operates normally for a specific period of time (the expiration period of

the escalation timer), i.e. if the object does not raise the same alarm again until theescalation timer expires, the escalation counter is reset.If the object raises the same alarm after expiry of the escalation timer, the alarm’sseverity will be WARNING again.

• If the object raises the same alarm a predefined number of times without having op-erated normally for the escalation counter’s expiration period or longer, i.e. if the es-calation counter crosses a predefined threshold, the severity will change fromWARNING to a predefined final alarm severity.The alarm’s final severity is then set in the Failure Event Report. The OML:Node B(RC) describes the alarm’s final severity in the failure event report of the relevantalarm.

Configuration of alarm severities

The operator can configure the severities of some alarms to either minor , major , or crit-ical , thus achieving a satisfying adaptation to actual needs. To adapt the alarm severity,the Node B’s database (DB) has to be changed. The FaultMng MOC in the Node B’sDB contains the severities parameter which is a list of all modified alarm severities.Several instances within this list can be created at the LMT. Each instance provides thefollowing operator-configurable attributes:• Error ID of the alarm to be modified• ID of the MOC related to the alarm for which the severity is to be changed• Severity


OML:Node B (RC)


Each instance within the severities parameter is evaluated by the Node B’s software(SW). Instances with MOC IDs or error IDs incompatible to the current Node B SW loadare ignored.

To change the severity of an alarm, the following procedure has to be applied:

1. Upload the DB to the LMT.Use the TREE View window of the LMT or apply the uploadDataInitiate command tothe relevant OSU managed object.

2. Modify the DB with the help of an XML editor or using scripts.Proceed according to the OGL:Node B DB Editing Guide.The following possibilities exist at the LMT:– Adding or removing an instance to or from, respectively, the severities list.– Modifying an existing instance within the list.

3. Download the modified DB.Use the TREE View window of the LMT or apply the downloadDataInitiate commandto the relevant OSU managed object.

4. Activate the downloaded DB.Use the TREE View window or the activate nodeBDatabaseVersionType command.

For more information about DB parameters, refer to the OGL:Node B DB Description.

The severity assignment for a specific alarm is determined by the following sources,listed in descending priority:

1. Severity setting for a particular managed object class (MOC), such as ExtEquipIn orScanner.

2. Severity setting in the severities list of the Node B’s FaultMng MOI.3. Default built-in severity.

Error DescriptionConcise description of the probable cause of the error.

TroubleshootingDescribes the actions the operator must perform to attempt to solve the problem.

Collect Info for Assistance

In some cases it is necessary to get support from customer services in order to isolatethe fault. Prior to contacting the Technical Assistance Center (TAC) pay attention on thefollowing questions and tasks:• Description of malfunction.• What is the suspected origin of the error?• What are the functional and hardware states of the affected system?• What are the issues of the affected boards? Check HW and FW states.• Observed system activities?• External influences (power supply, environment)?• What has been done (customer, local service staff)?

i NOTEThe severities attribute will be considered only for alarms that represent a conditionfor which a corresponding clearance event exists. In contrast, alarms that represent onlyone single event, will always be sent with severity warning .



• Exact time of error: synchronize the time stamp of all log files, if possible.• Save the database of the affected NE.• Save the IDF of the affected NE.• Upload the log file of the affected NE.


OML:Node B (RC)


Errors in Numerical Order (error-ID)In this chapter all failure event reports related with the Node B 2nd platform are listed innumerical order. Each title is composed of the error ID concatenated with the error stringand followed by the failure event report.

An error description gives a general understanding of the alarm at systems level andpoints out what impacts could be expected. Hints of other symptoms or alarms thatmight be associated are also given.

Checks, detailed actions or data collection procedures for troubleshooting tasks are de-scribed subsequently.



200506 - Node B system start-up malfunction due to soft-ware/hardware problem

Failure Event Report

Error Description

The Node B system start-up is maintained by a dedicated software subsystem (Mas-terServiceTask: MST). Any error encountered during initialization of this subsystem willgenerate this fault report. The affected Node B Core Controller is not available. Probablereasons for these conditions are problems related either to hardware (e.g.: memoryproblem, input/output malfunction) or operating system environment. This conditionleads to a recovery reset of the whole Node B.

If the fault report relates to a HW problem, troubleshooting might require detailed knowl-edge of the Node B hardware structure (memory, boot system, ...). If the fault report re-lates to a SW problem, troubleshooting might require direct access to the Node B'soperating system console.

Troubleshooting

Due to the imponderable system behavior in case of hardware problems, there is nostatement about further system operations. Contact the technical assistance center(TAC) to get support in isolating the fault. For suitable preparation save the error symp-toms as described in "Collect Info for Assistance". Log files need to be analyzed andspecific measures must be taken which are out of the operator’s scope.

Managed Object Class / Hardware Type: OsuEvent Type: processingErrorAlarmProbable Cause: ApplicationSubsystemFailureSeverity: critical


OML:Node B (RC)


200507 - System halt due to software watchdog detectedproblem


Error Description

This problem reports a situation, where the software health observation system has de-tected a missing health indication from any Node B software subsystem. The affectedsubsystem malfunction might (dependent of subsystem and error cause) be already no-ticeable by generated fault reports from it's own scope. This condition leads to a recov-ery reset of the whole Node B. The affected Node B Core Controller is temporary notavailable. This information has to be analyzed to find the malfunction originator. Due tothe recovery reset, only the system log files could be used for 'post' analysis.

The probable reason for this alarm is a software problem.

Troubleshooting

Contact the technical assistance center (TAC) to get support in isolating the fault. Forsuitable preparation save the error symptoms as described in "Collect Info for Assis-tance". Log files need to be analyzed and specific measures must be taken which areout of the operator’s scope.

Managed Object Class / Hardware Type: OsuEvent Type: processingErrorAlarmProbable Cause: WatchDogTimerExpiredSeverity: critical



200508 - System halt due to detected application processerror


Error Description

This problem reports a situation, where the software health observation system has de-tected a 'dead' Node B software subsystem. The affected subsystem (generally) couldnot be indicated by generated fault reports from it's own scope, but this problem reportcontains information about the originator of the error. This condition leads to a recoveryreset of the whole Node B. The affected Node B Core Controller is temporarily not avail-able. Due to the recovery reset, only the system log files could be used for 'post' analy-sis.

The probable reason for this alarm is a software problem.

Troubleshooting


Managed Object Class / Hardware Type: OsuEvent Type: processingErrorAlarmProbable Cause: SoftwareProgramAbnormallyTermi-

natedSeverity: critical


OML:Node B (RC)


200509 - System halt due to detected hardware exception


Error Description

This problem reports a situation, where the software health observation system has de-tected an 'unexpected' signal by the Node B hardware. This will be just logged by theobservation system. This problem report contains information about the signal origina-tor. This condition leads to a recovery reset of the whole Node B. The affected Node BCore Controller is temporarily not available. Due to the recovery reset, only the systemlog files could be used for 'post' analysis.

Troubleshooting


Managed Object Class / Hardware Type: OsuEvent Type: communicationAlarmProbable Cause: VendorSpecificSeverity: critical



200510 - System halt due to detected software loadingmalfunction


Error Description

This problem reports a situation, where the system loader detects a failure during soft-ware loading. This problem report contains information about the name of the failed soft-ware component. If the malfunction relates to a HW problem, it might be necessary toreplace the addressed card. If the malfunction relates to a software problem, it might besolved by the recovery mechanisms of the software management subsystem (ISW).This condition leads to a recovery reset of the whole Node B. The affected Node BCore Controller is temporarily not available. Due to the recovery reset, only the systemlog files could be used for 'post' analysis.

Troubleshooting

1. Select the faulty Node B:– Left-click on the icon “Network Management” in the Application Launcher window.– Double left-click on the icon “Node B” , alternatively right-click on the icon

“Node B” and select “Navigate to panel”.– Select the faulty Node B in the list.

2. Lock the addressed module:– Right-click on the addressed module on GUI to open the context sensitive menu.– Select Configuration Management -> lock.

3. Reset the addressed module:– Right-click on the addressed module on GUI to open the context sensitive menu.– Select Configuration Management -> rst.

4. Unlock the addressed module:– Right-click on the addressed module on GUI to open the context sensitive menu.– Select Configuration Management -> unlock.

If the error message has not ceased yet, further repair actions will be necessary on site.Proceed according to the Output Manual OML:Node B.

Detailed information about the actions mentioned above is available in “Radio Com-mander‘s Online Help” and “Radio Commander Command Manual CML”.

Managed Object Class / Hardware Type: OsuEvent Type: communicationAlarmProbable Cause: VendorSpecificSeverity: critical


OML:Node B (RC)


200656 - Iub link broke down


Error Description

An existing ATM connection between CRNC (controlling RNC) and Node B (Iub link) isbroken because the CRNC is down, the cable has been plugged off or is broken. There-fore the Node B performs a reset.

The following subsequent alarms may also be initiated depending on the used interfacetype (E1/J1/T1, STM-1/OC-3):– 202056 - Loss Of Signal on Physical Link– 202057 - Loss Of Frame on Physical Link– 202058 - Loss Of Cell Delineation on Physical Link– 202059 - Alarm Indication Signal on Physical Link– 202060 - Remote Alarm Indication on Physical Link– 202061 - Loss of Multi Frame Alarm Indication on E1 Physical Link– 202062 - Line Alarm Indication Signal Indication on STM1 Physical Link– 202063 - Line Remote Defect Indication on STM1 Physical Link– 202064 - Path Loss of Pointer Indication on STM1 Physical Link– 202068 - Signal Label Mismatch Indication on STM1 Physical Link– 202070 - Signal Degrade Indication on STM1 Physical Link– 202071 - Excessive Bit Error Rate Indication on STM1 Physical Link– 202072 - Alarm Indication Signal on an ATM VC– 202073 - Remote Defect Indication on an ATM VC– 202074 - SSCOP Failure Indication on an ATM VC used by ALCAP or NBAP– 202075 - Alarm Indication Signal on an ATM VP– 202076 - Remote Defect Indication on an ATM VP– 202077 - ALCAP PVC Out Of Service Indication

The Iub link broke down alarm may be caused by one of the following:• A failure in the RNC. In this case alarms from the RNC are additionally active.• A failure of the link equipment or in the cable connection between Node B and link

equipment (LE). Usually the Node B is connected to the RNC or each other (Iub in-terface) via link equipment (LE) and in some rare cases by direct lines. If LE is in-volved the operation and maintenance system of this network has to be used forgetting information about the state and status of the relevant network element (NE).

• A failure within the OVPT or the IUBCON in case an E1/J1/T1 interface is used.• A failure in the CC (refer to 200994 - HW Failure). In this case, other CC initiated

alarms are additionally active.

The affected Node B is not working. All services will be interrupted. All cells will be lost.

Managed Object Class / Hardware Type: CcEvent Type: equipmentAlarmProbable Cause: LinkFailureSeverity: critical



Troubleshooting

If RNC alarms for the Iub link to the affected Node B are also reported concentrate thefault clearance actions on these alarms first. Fault clearance actions for RNC alarms atthe RC are described in the Output Manual OML:RNC (RC).

Otherwise, is an equipment alarm for the LE reported which is connected to the relevantport?• Use the appropriate operation and management system for further analysis• Try to fix this fault first which probably also eliminates the Iub link broke down alarm.

Otherwise, if only Node B alarms are reported:

1. Select the faulty Node B:– Left-click on the icon “Network Management” in the Application Launcher window.– Double left-click on the icon “Node B” or alternatively right-click on the icon


2. Reset the addressed module:– Right-click on the addressed CC on GUI to open the context sensitive menu.– Select Configuration Management -> rst.

3. If the error message has not ceased yet, further repair actions are necessary on site.Proceed according to the Output Manual OML:Node B.



OML:Node B (RC)


200657 - SSCOP sent overrun


Error Description

Node B’s SSCOP is not able to transmit messages to the CRNC (controlling RNC) usingthe requested data rate. Therefore, the Node B performs an automatic reset.

Troubleshooting


Managed Object Class / Hardware Type: CcEvent Type: equipmentAlarmProbable Cause: LinkFailureSeverity: critical



200658 - Transmit bandwidth limit for NBAP reached


Error Description

Under conditions with high traffic, the NBAP bandwidth set at the reporting Node B’s Iubinterface may not be sufficient. If the high-traffic condition persists, the Node B will startdropping messages.

This alarm therefore indicates a general lack of bandwidth to send messages at theNode B’s Iub interface. In other words, the Node B’s transmit bandwidth for NBAP con-nections toward the RNC has reached its limit and the message buffers are exhausted.

The Node B then started overload defence actions. This may affect service quality be-cause dedicated measurement reports will be dropped and RL setup or reconfigurationattempts will be rejected.

The reporting Node B continues operation. Service quality, however, is decreased. Theincreased traffic thus requires appropriate settings for the transmit bandwidth at theNode B’s Iub interface. In other words, the Node B’s database (DB) settings have to berevised and the transmit bandwith at the Iub interface has to be increased.

Troubleshooting

Take the following measures to clear this alarm and to prevent this overload conditionin the future:

1. Revise the reporting Node B’s DB settings in such a way that the NBAP transmitbandwidth is increased.Increase both the ingress and the egress peak cell rate to an identical value, usingthe following:– ’Node B Sum’ panel or Set N2TRFDESC:[...],pkcringress = ...

command– ’Node B Sum’ panel or Set N2TRFDESC:[...],pkcregress = ...

command2. If the first action did not clear the cause for this alarm, contact the technical assis-

tance center (TAC) to get support in isolating the fault. For suitable preparation savethe error symptoms as described in "Collect Info for Assistance". Log files need tobe analyzed and specific measures must be taken which are out of the operator’sscope.


Managed Object Class / Hardware Type: NodeBFddEEvent Type: qualityOfServiceAlarmProbable Cause: System ResourcesOverloadSeverity: minor


OML:Node B (RC)


200659 - Core Controller overload protection activated


Error Description

A situation with peak load has occurred in the reporting Node B. Due to this situation,the Node B may activate an overload protection. Overload protection is a defence actionof the Node B to maintain stable operation.

In fact, the reporting Node B’s core controller (CC) CPU capacity has reached its limit.As a consequence, RL setup or reconfiguration attempts will be rejected. Service qualityis decreased.

The causes for the Node B’s high CPU load needs to be investigated.

Troubleshooting

First, investigate the causes for the high CC load.


Managed Object Class / Hardware Type: NodeBFddEEvent Type: qualityOfServiceAlarmProbable Cause: System ResourcesOverloadSeverity: minor



200706 - An error occurred in the nbDatabase


Error Description

Node B startup failed because of an error in the nbDatabase.

This may be caused by the following:• A new database was installed but does not match release and version of the soft-

ware load.• A new database was installed but does not match the hardware configuration.• A new hardware equipment was installed but was not configured in the database.• A software error has occurred.

Troubleshooting

1. Check the Node B database:– Open the ’NodeB Sum’ panel.– Click the Network Management button in the Application Launcher to open the

’RC Region Sum’ panel– Double-click the Node B icon to open the Node B list.– In the ’NodeB Sum’ panel right-click the SW Admin icon– Select Software Management -> SeeSystemData– The window displays all information on the database version.

2. Check the Node B software version:– Open the ’NodeB Sum’ panel.– Click the Network Management button in the Application Launcher to open the

’RC Region Sum’ panel.– Double-click the Node B icon to open the Node B list.– In the Node B list select a Node B Sum# by double-clicking the corresponding row

of the list.– In the ’NodeB Sum’ panel right-click the SWM icon– Select Configuration Management -> Get Basics.– The parameters of the selected Node B are displayed.– Click Close to close the window.

3. Check the hardware configuration.4. If the error is not caused by an invalid database or an unsuitable hardware configu-

ration: Contact the technical assistance center (TAC) to get support in isolating thefault. For suitable preparation save the error symptoms as described in "Collect Infofor Assistance". Log files need to be analyzed and specific measures must be takenwhich are out of the operator’s scope.


Managed Object Class / Hardware Type: OsuEvent Type: processingErrorAlarmProbable Cause: SoftwareErrorSeverity: critical


OML:Node B (RC)


200707 - A warning occurred in the nbDatabase


Error Description

There may be an error in the nbDatabase. This warning only occurs during a version up-grade of the database.

This alarm may be caused by the following:• During version upgrade: There are missing attributes because of using a database

from an older version.• No version upgrade: The database is defective or a new database was installed but

does not match the software version.

Troubleshooting

If attributes are missing during a version upgrade of the databse, no action is necessarybecause default values will be used.

Otherwise, if no version upgrade has been performed, check the Node B database andadapt the database accordingly. To check the database, take the following measures:

1. Open the ’NodeB Sum’ panel.2. Click the Network Management button in the Application Launcher to open the ’RC

Region Sum’ panel3. Double-click the Node B icon to open the Node B list.4. In the ’NodeB Sum’ panel right-click the SW Admin icon5. Select Software Management -> SeeSystemData6. The window displays all information on the database version.

Software load and database must base on the same InfoModel which is also the basisfor the Command Manual CML:Node B.


Managed Object Class / Hardware Type: OsuEvent Type: processingErrorAlarmProbable Cause: SoftwareErrorSeverity: warning



200756 - System call unsuccessful


Error Description

A fatal software error has occurred. This is a recoverable error situation caused by a po-tentially serious software fault, which should be reported to customer services!

A call to the operating system or the operating system wrapper layer has failed. After anunsuccessful system call, the Node B resets automatically. Due to the reset, all serviceswill be interrupted.

This may cause the following:• All cells will be lost.• The connection between the Node B and the RNC will be lost.• Uplink or downlink errors will be reported by other Node Bs if they are connected to

the resetting Node B.

Once the reset is completed, normal operational service should be resumed i.e. the cellsare build up again, connection with the RNC will be re-established and any cross con-nections will be built up again.

This error is caused by a corrupted software image.

Troubleshooting






5. If the error message is not ceased now, use a previous, working version of the soft-ware.

6. Contact the technical assistance center (TAC) to get support in isolating the fault.For suitable preparation save the error symptoms as described in "Collect Info forAssistance". Log files need to be analyzed and specific measures must be takenwhich are out of the operator’s scope.


Managed Object Class / Hardware Type: *Event Type: processingErrorAlarmProbable Cause: SystemCallUnsuccesfulSeverity: critical


OML:Node B (RC)


200757 - Unexpected software error


Error Description

A fatal software error has occurred. This is a recoverable error situation caused by a po-tentially serious software fault, which should be reported to customer services!

A call to the operating system or the operating system wrapper layer has failed. After anunexpected software error, the Node B resets automatically. Due to the reset, all servic-es will be interrupted.



Once the reset is completed, normal operational service should be resumed i.e. the cellsare build up again, connection with the RNC will be re-established and any cross con-nections will be built up again.

This error is caused by a corrupted software image.

Troubleshooting




4. If the error message has not ceased yet, use a previous, working version of the soft-ware.



Managed Object Class / Hardware Type: *Event Type: processingErrorAlarmProbable Cause: SoftwareErrorSeverity: critical



200758 - Not enough memory


Error Description

A fatal software error has occurred. This is a recoverable error situation caused by a po-tentially serious software fault, which should be reported to customer services! The re-covery will result in a complete reset of the Node B. Due to the reset, all services will beinterrupted.



All connections to the management system will also be interrupted during this reset pe-riod. Once the reset is completed, normal operational service should be resumed i.e. thecells are built up again, connection with the RNC will be re-established and any crossconnections will be built up again. Any calls that were in operation before the reset arelost.

Troubleshooting


Managed Object Class / Hardware Type: *Event Type: processingErrorAlarmProbable Cause: OutOfMemorySeverity: critical


OML:Node B (RC)


200759 - A fatal error has occurred that may affect OAMcommand processing


Error Description

A fatal software error has occurred! This is a recoverable error situation caused by a po-tentially serious software fault, which should be reported to customer services. The re-covery will result in a complete reset of the Node B. Due to the reset, all services will beinterrupted.



All connections to the management systems will also be interrupted during this reset pe-riod. Once the reset is completed, normal operational service should be resumed i.e. thecells are built up again, connection with the RNC will be re-established and any crossconnections will be built up again. Any calls that were in operation before the reset arelost.

Troubleshooting


Managed Object Class / Hardware Type: *Event Type: processingErrorAlarmProbable Cause: SystemCallUnsuccessfulSeverity: critical



200905 - VSWR alarm Low


Error Description

Each antenna port of the DUAMCO/RRH is monitored for the Voltage Standing WaveRatio (VSWR) of the connected antenna system. Two levels for the antenna return losscan be defined for which an alarm of the appropriate severity will be generated as soonas the relevant threshold is exceeded. The “VSWR alarm Low” is the minor one - whichis under consideration here - related with the lower threshold and may be received be-fore alarm 200906 - VSWR alarm High. The most likely reason for the VSWR alarms isa defective antenna feeder cable or a damaged antenna.

Troubleshooting

For further investigation, a visit on site is necessary to find the cause for the VSWR lowalarm by inspecting the antenna system. Refer to the Output Manual OML:Node B.

Managed Object Class / Hardware Type: Duamco, RrhEvent Type: equipmentAlarmProbable Cause: TransmitterAntennaNotAdjustedSeverity: minor


OML:Node B (RC)


200906 - VSWR alarm High


Error Description

Each antenna port of the DUAMCO/RRH is monitored for the Voltage Standing WaveRatio (VSWR) of the connected antenna system. Two levels for the antenna return losscan be defined for which an alarm of the appropriate severity will be generated as soonas the relevant threshold is exceeded. The 200905 - VSWR alarm Low is the minor onerelated with the lower threshold and may be received before the “VSWR alarm High”which is under consideration here. The most likely reason for the VSWR alarms is a de-fective antenna feeder cable or a damaged antenna.

As a consequence, cells and/or calls could potenitally be lost. Furthermore, the statevalue of all affected managed objects is changed accordingly.

Troubleshooting

For further investigation, a visit on site is necessary to find the cause for the VSWR highalarm by inspecting the antenna system. Refer to the Output Manual OML:Node B.

Managed Object Class / Hardware Type: Duamco, RrhEvent Type: equipmentAlarmProbable Cause: TransmissionAntennaFailureSeverity: major



200907 - RX alarm Low


Error Description

This alarm occurred because one branch of an RX amplifier of the reporting LRU hasfailed. The RX amplifier is still working but degraded in its performance.

If both branches become out of order, the 200908 - RX alarm High will be sent.

Troubleshooting






5. If the error message has not ceased yet, further repair actions will be necessary onsite. Proceed according to the Output Manual OML:Node B.


Managed Object Class / Hardware Type: Duamco, Tma, RrhEvent Type: equipmentAlarmProbable Cause: ReceiverFailureSeverity: minor


OML:Node B (RC)


200908 - RX alarm High


Error Description

This alarm occurred because both branches of an RX amplifier of the reporting LRUhave failed.

If the alarm message is sent by the TMA, the MUCO mode in the DUAMCO will switchback to AMCO mode. After the reset, the DUAMCO will be in its original mode accordingto the DIP-switches on the front.

There might have been an alarm 200907 - RX alarm Low before.

As a consequence, cells or calls could potentially be lost. Furthermore, the states of allaffected managed objects change accordingly.

Troubleshooting








Managed Object Class / Hardware Type: Duamco, Tma, RrhEvent Type: equipmentAlarmProbable Cause: ReceiverFailureSeverity: major



200909 - TMA switched off, but not defective


Error Description

The TMA is switched off and the DUAMCO works in AMCO mode. This mode is indicat-ed by the TMA LED which is off. The receiver is degraded in its performance. The failureoccurs in one of the following situations:• Most likely this alarm is raised during normal Node B operation if the DIP switch 1

of the corresponding DIP switch group of the DUAMCO is set to OFF position (AM-CO mode/TMA off) by accident. The TMA is switched off, but not defective.

• In rare cases, the alarm can also be raised together with another more critical alarmlike 200908 - RX alarm High.

Troubleshooting

1. Check the power supply for the TMA at the associated DUAMCO. Furthermore, ver-ify that the TMA is connected to the DUAMCO and check if the DIP switch 1 of theDUAMCO (TMA ON/OFF) is switched ON.

2. If other critical alarms like 200908 - RX alarm High are also raised, please refer tothe corresponding alarm description.

3. A visit on site is probably necessary to switch the DUAMCO switch to the ON posi-tion. Refer to the Output Manual OML:Node B.

Managed Object Class / Hardware Type: TmaEvent Type: equipmentAlarmProbable Cause: PowerSupplyFailureSeverity: minor


OML:Node B (RC)


200910 - TMA feeder alarm


Error Description

The DUAMCO monitors the 2.176 MHz signaling carrier coming from the TMA. A break-down of this carrier initiates the TMA Feeder Alarm. The amplifier is degraded in its per-formance. The combination of OST/AVS for the addressed TMA and the related’localCellE’ managed object instance changes to disabled /failed and enabled /degrad-ed, respectively.

The TMA Feeder Alarm may be caused by:• A failure in the antenna feeder cable. In this case the 200905 - VSWR alarm Low /

200906 - VSWR alarm High and uplink/ downlink alarms may be additionally active.• A failure in the TMA.• A failure in the power supply. In this case, the 200911 - TMA DC alarm may be ad-

ditionally active.

If a RET module is installed in the current configuration, the alarm 201004 - RET com-munication error will be output as a consequence of this alarm.

For TMA recovery, a reset of the related DUAMCO is required in order to re-establishthe communication between the DUAMCO and the TMA. A reset of the TMA managedobject is not possible while this failure persists.

Troubleshooting

First, reset the related DUAMCO to re-establish the communication between the DUA-MCO and the TMA. Use the ’NodeB Sum’ panel or the rst command.

If the reset of the DUAMCO did not help to cease this alarm, take the following measuresin the order provided:






Managed Object Class / Hardware Type: TmaEvent Type: equipmentAlarmProbable Cause: ReceiverFailureSeverity: minor



5. If the error message has not ceased yet, further repair actions are necessary on site.Proceed according to the Output Manual OML:Node B.



OML:Node B (RC)


200911 - TMA DC alarm


Error Description

The power supply for the TMA is fed via the antenna feeder cable from the DUAMCO tothe TMA. If the supply voltage of a TMA at the antenna port of the DUAMCO is belowthe defined threshold (11,3 V), the TMA DC Alarm is initiated.

The TMA DC Alarm may be caused by:• A failure in the DC/DC converter of the DUAMCO.• A short circuit in the antenna feeder cable. In this case the alarms 200906 - VSWR

alarm High or 200905 - VSWR alarm Low and uplink/ downlink alarms are addition-ally active.

• The TMA is overcharged. The current consumption of the TMA is too high.

The amplifier is degraded in its performance.

Troubleshooting








Managed Object Class / Hardware Type: DuamcoEvent Type: equipmentAlarmProbable Cause: EquipmentFailureSeverity: minor



200914 - Fan unit failed


Error Description

One of the fan units in the Node B is defective. There might be a failure of componentssensitive to heat. Caused by the lack of air circulation, there might occur temperaturealarms, reported by the rack/ shelter or the cards.

This alarm message may occur in conjunction with temperature alarms:• 200920 - High temperature of PA• 200921 - Over temperature of PA• 200995 - High Temperature Limit (Ht3) reached• 200996 - Critical Temperature Limit (Ht4) reached

Troubleshooting

This repair action must be achieved on site. Proceed according to the Output ManualOML:Node B.

Managed Object Class / Hardware Type: FanEvent Type: environmentalAlarmProbable Cause: FanFailureSeverity: major

i NOTEIf the reporting Node B is of type NB-441/NB-881, the lack of air circulation may becaused by a polluted membrane filter (MEF). Therefore, if the Node B site is located inheavily air-polluted environments combined with special temperature conditions, amaintenance of the MEF filters in the outdoor NB-441/NB-881 might be necessary.If the MEFs are polluted, the 201029 - MEF blocked or 201035 - MEF completelyblocked alarm is output. Refer to the relevant alarm’s error description and follow thetroubleshooting.

i NOTETo avoid toggling of this alarm from the same managed object, i.e. the alarm is raisedand ceased alternately, the alarm will only be ceased if the following applies:After having cleared the cause of this fault, the addressed LRU has not reported thesame alarm again for at least 100 seconds.Otherwise, this alarm will not be ceased but remains active. Troubleshooting tasks mustbe taken.

i NOTEIf all fan units of the B-shelf are defective, self-disabling of B-shelf cards can occur as aconsequene. The Node B handles self-disabled cards as if a fatal board failure, such asan on-board power supply failure, has occurred. In other words, the combination ofOST/AVS changes to disabled /not installed and the LED of the self-disabled card isoff.

i NOTEThe defective fan unit(s) shall be exchanged within the next 24 hours!


OML:Node B (RC)


200915 - Site input alarm detected


Error Description

A site input alarm was detected.

This alarm is raised if one of the connected site input sensors is active, e.g. water de-tector, site door open switch, window broken, air condition system defect, etc.

The reported “Probable Cause” and “Severity” in the Failure Event Report depend onthe configuration of the related ’ExtEquipIn’ managed object in the nbDatabase.• For the severity the value of the attribute label “alarmSeverity” of each object class

’ExtEquipIn’ can be set to minor, major, or critical in the nbDatabase by an equivalentstring.

• The ’ExtEquipIn’ instances ExtEquipIn.4 to ExtEquipIn.12 at the RRH are reservedfor reporting alarms related to the power supply units for RRHs (PSRs). These ’Ex-tEquipIn’ instances have to exist in the database in configurations with RRHs.

• Whereas the value of the “probableCause” attribute label is represented by a num-ber which is related to a string defined in the Infomodel, e. g.:– 4 = Battery Breakdown– 22 = Power Supply Failure– 147 = Smoke Detected– 149 = Fuse Failure

• With the new AD panel HW, the alarm properties (Probable Cause: PowerSupply-Failure) listed in the following table may be displayed.

For explanations of customizing a nbDatabase please refer to the relevant chapter ofthe “OGL:Node B DB Description”.

Managed Object Class / Hardware Type: ExtEquipInEvent Type: environmentalAlarmProbable Cause: ExternalEquipmentFailureSeverity: minor

i NOTEChanging the ’ExtEquipIn’ managed object’s alarm severity, alarm value, associatedstring, and probable cause attributes does not affect an existing 200915 - Site inputalarm detected alarm. The modified attributes will take effect for the next occurrence ofthis alarm.When modifying the attributes mentioned above, however, only one attribute can bechanged simultaneously. In other words, when using the relevant command for settingthese attributes, only one single attribute of one single managed object can be set.

Source Additional Text

ExtEquipIn.7 AC/DC Converter - Mains Break Down Alarm

ExtEquipIn.8 AC/DC Converter - Battery Breakdown Alarm

ExtEquipIn.9 AC/DC Converter - Battery Charger Fault

ExtEquipIn10 AC/DC Converter - DC Output Voltage out of Tolerance



External equipment input identifier (extEquipInId) and pinning relations to the ACTM(Alarm Collection Terminal Master) can be found in the “HWMN:Node B Cards/Mod-ules”.

Troubleshooting

For further investigation, a visit on site is necessary to find the cause for the site inputalarm by inspecting the site and the supervision sensors used for the input. Refer to theOutput Manual OML:Node B.

Furthermore, contact the technical assistance center (TAC) to get support in isolatingthe fault. For suitable preparation save the error symptoms as described in "Collect Infofor Assistance". Log files need to be analyzed and specific measures must be takenwhich are out of the operator’s scope.


OML:Node B (RC)


200916 - Rack Door open


Error Description

The door condition is controlled by a reed switch together with a permanent magnet.This alarm occurs if one of the following doors is open:• The door of a rack• The door of a single shelter• One or both doors of a double shelter

A damaged or misaligned supervision contact (reed switch - magnet) or a door that isnot firmly closed (gap more than 10mm) should also be taken into consideration.

For outdoor shelters it has to be noted that the filter system (MEF = membrane filter)may be by-passed allowing dust to contaminate the equipment in the shelter, resultingin the malfunction.

Troubleshooting

For further investigation, a visit on site is necessary to find the cause of the rack dooropen alarm by inspecting the rack/shelter and possibly the door supervision contact. Re-fer to the Output Manual OML:Node B.

Managed Object Class / Hardware Type: BaseRack, ServiceRack, BoosterEvent Type: environmentalAlarmProbable Cause: EnclosureDoorOpenSeverity: minor



200918 - PA combiner interface fault


Error Description

An excessive level of Radio Frequency (RF) reflected power occurred. The cable be-tween the Power Amplifier (PA) and the DUAMCO may be damaged or not connected.As a consequence, the PA is switched off.

The PA was put out of service. This leads to a scenario in which cells or calls could po-tentially be lost. The states of all affected managed objects are then changed accord-ingly.

Troubleshooting

For further investigation, a visit on site is necessary to find the cause for the PA combin-er interface alarm by inspecting the PA, DUAMCO and the cabling. Refer to the OutputManual OML:Node B.

Managed Object Class / Hardware Type: Lpa, BoosterEvent Type: equipmentAlarmProbable Cause: TransmitterFailureSeverity: major


OML:Node B (RC)


200919 - Failure in the DC supply of PA


Error Description

A failure in the internal DC supply of the Power Amplifier (PA) occurred. As a conse-quence, the PA is switched off.

The PA was put out of service. This leads to a scenario in which cells or calls could po-tentially be lost. The states of all affected managed objects change accordingly.

Troubleshooting

For further investigation, a visit on site is necessary to find the cause for the failure inthe DC supply of PA by inspecting the PA. Refer to the Output Manual OML:Node B.

Managed Object Class / Hardware Type: Lpa, Booster, Cat, RrhEvent Type: equipmentAlarmProbable Cause: PowerSupplyFailureSeverity: major



200920 - High temperature of PA


Error Description

The temperature of the PA has exceeded the maximum operating temperature speci-fied. This could be caused by an internal problem of the PA or by insufficient cooling ofthe rack/shelter.

If this alarm is reported by a booster, the 201034 - Booster’s Fan unit failed alarm maybe the root cause for the failure reported by this alarm.

An additional rack/shelter temperature alarm (200995 or 200996) or fan alarms(200914) may indicate that the air circulation is decreased. A fan unit could be defectiveor especially for outdoor shelters obstructed air in- or outlets could also reduce the cool-ing capability.

As a consequence, the PA was put out of service. Cells and/or calls could potentially belost and the states of all affected managed objects change accordingly. The wholecell/sector or the second carrier in a two carrier cell/sector is unavailable. Traffic capa-bility for this cell/sector will be decreased or lost completely.

This alarm message may occur in connection with temperature alarms:• 200914 - Fan unit failed• 200995 - High Temperature Limit (Ht3) reached• 200996 - Critical Temperature Limit (Ht4) reached

Troubleshooting

In the event that the following preconditions are met, i.e.• The ’200920 - High temperature of PA’ alarm is reported by a booster and• The 201034 - Booster’s Fan unit failed alarm has been output before,

refer to the error description of the 201034 - Booster’s Fan unit failed alarm and followthe troubleshooting accordingly. The 201034 - Booster’s Fan unit failed alarm may indi-cate the root cause for the failure reported by this alarm.

For further investigation, a visit on site is necessary to find the cause for the high tem-perature of PA by inspecting the PA. Refer to the Output Manual OML:Node B.

Managed Object Class / Hardware Type: Lpa, Booster, Cat, RrhEvent Type: environmentalAlarmProbable Cause: HighTemperatureSeverity: minor



OML:Node B (RC)


200921 - Over temperature of PA


Error Description

The PA is overheated and a high temperature alarm (200920 - High temperature of PA)may be preceded. Because the temperature has reached a level that would cause dam-age, the PA is switched off. As a consequence the whole cell/sector or the second car-rier in a two carrier cell/sector is unavailable. Traffic capability for this cell/sector will bedecreased or lost completely.

If this alarm is reported by a booster, the 201034 - Booster’s Fan unit failed alarm maybe the root cause for the failure reported by this alarm.

This could be caused by an internal problem of the PA or by insufficient cooling capacityof the rack/shelter. An additional rack/shelter temperature alarm (200995 or 200996) orfan alarms (200914) may indicate that the air circulation is decreased. A fan unit couldbe defective or especially for outdoor shelters obstructed air in- or outlets could also re-duce the cooling capability.

As a consequence, the PA was put out of service. Cells and/or calls could potentially belost. The states of all affected managed objects change accordingly.

This alarm message may occur in connection with temperature alarms:• 200914 - Fan unit failed• 200995 - High Temperature Limit (Ht3) reached• 200996 - Critical Temperature Limit (Ht4) reached

Troubleshooting

In the event that the following preconditions are met, i.e.• The ’200921 - Over temperature of PA’ alarm is reported by a booster and• The 201034 - Booster’s Fan unit failed alarm has been output before,

refer to the error description of the 201034 - Booster’s Fan unit failed alarm and followthe troubleshooting accordingly. The 201034 - Booster’s Fan unit failed alarm may indi-cate the root cause for the failure reported by this alarm.

For further investigation, a visit on site is necessary to find the cause for the over tem-perature of PA by inspecting the PA. Refer to the Output Manual OML:Node B.

Managed Object Class / Hardware Type: Lpa, Booster, Cat, RrhEvent Type: equipmentAlarmProbable Cause: ExcessiveTransmitterTemperatureSeverity: major




200922 - RF performance not being met due to bad lineari-sation


Error Description

The PA linearization technics does not work correctly and could result in signal qualitynot being met. The PA is switched off. The PA was, furthermore, put out of service.

As a consequence, cells or calls could potentially be lost. The states of all affected man-aged objects change accordingly.

Troubleshooting

For further investigation, a visit on site is necessary to find the cause for the fault. Referto the Output Manual OML:Node B.

Managed Object Class / Hardware Type: Lpa, Booster, Cat, RrhEvent Type: equipmentAlarmProbable Cause: SignalQualityEvaluationFaultSeverity: major


OML:Node B (RC)


200923 - Internal failure of PA detected


Error Description

A fatal vendor specific hardware or software failure inside the PA was detected and thePA was switched off. Furthermore, the PA was put out of service.

The card should be replaced.

Cells or calls could potentially be lost. The states of all affected managed objectschange accordingly.

Troubleshooting

1. First try to reset the addressed card by the following procedures:– Lock the addressed card, using either the ’NodeB Sum’ panel or applying the

lock command to the addressed card.– Reset the addressed card. Use the ’NodeB Sum’ panel or the rst command.– Unlock the addressed card by means of the ’NodeB Sum’ panel or the unlock

command.2. For further investigation, a visit on site is necessary to find the cause for the internal

failure of PA by inspecting the PA. Refer to the Output Manual OML:Node B.


Managed Object Class / Hardware Type: Lpa, Booster, Cat, RrhEvent Type: equipmentAlarmProbable Cause: EquipmentFailureSeverity: major



200924 - Input power level of LPA too high but LPA can stillhold its RF specification


Error Description

The LPA detected an input power level from a TRX card that is above the nominal valuebut the specifications relating to the RF output are still met. There is no imminent dangerfor the LPA to be damaged.

A further power level increase will result in the error report 200925 - Input power level ofPA too high with the higher severity level “major” and a shutdown of the LPA is inevita-ble.

Troubleshooting


lock command to the addressed card.– Reset the addressed card. Use the ’NodeB Sum’ panel or the rst command.– Unlock the addressed card by means of the ’NodeB Sum’ panel or the unlock

command.2. For further investigation, a visit on site is necessary to find the cause for the fault.

Refer to the Output Manual OML:Node B.


Managed Object Class / Hardware Type: LpaEvent Type: equipmentAlarmProbable Cause: ExcessiveTransmitterOutputPowerSeverity: minor


OML:Node B (RC)


200925 - Input power level of PA too high


Error Description

The PA detected an input power level that would cause the PA to fail specifications re-lating to the RF output or damaging the PA. According to the following cases, the inputpower level may be eitehr analog or digital:• Case 1: This alarm occurred in an LPA, receiving its input power from a TRX card.

Thus, the analog input power level is too high.• Case 2: This alarm occurred in a CAT/RRH, receiving its input power from DRIC.

The following causes may be the root for this failure:– The digital input power level is too high for a certain period of time. In this case,

an autonomous gain correction was not possible.– Too rapid digital input signal variations could not be processed adequately.– The CAT/RRH itself produces too much power.

To avoid this the PA is switched off. As a consequence, cells or calls could potentiallybe lost. The states of all affected managed objects change accordingly.

It may be that the error reports 200924 - Input power level of LPA too high but LPA canstill hold its RF specification if LPA is concerned, or 201018 - The LRU could not processa message from CC if CAT/RRH is concerned were emitted before, being a sign of in-creasing power level input at the PA.

Troubleshooting

For further investigation, a visit on site is necessary to find the cause for the fault. Referto the Output Manual OML:Node B.

Managed Object Class / Hardware Type: Lpa, Booster, Cat, RrhEvent Type: equipmentAlarmProbable Cause: ExcessiveTransmitterOutputPowerSeverity: major



200926 - CPU failure of baseband card


Error Description

A fatal software or hardware error arose: a boot or watchdog error of a CPU occurred.The automatic recovery failed.

After an unsuccessful automatic recovery by means of a reset, thereporting BB card wasput out of service.


Troubleshooting







6. Furthermore, contact the technical assistance center (TAC) to get support in isolat-ing the fault. For suitable preparation save the error symptoms as described in"Collect Info for Assistance". Log files need to be analyzed and specific measures

must be taken which are out of the operator’s scope.


Managed Object Class / Hardware Type: Ch, Rep, Trx, DricEvent Type: equipmentAlarmProbable Cause: ProcessorProblemSeverity: major (final), handled according to the



OML:Node B (RC)


200927 - Volatile memory failure of baseband card


Error Description

A failure of an SDRAM (synchronous dynamic random access memory) was detected.

After an unsuccessful automatic recovery by means of a reset, the reporting BB cardwas put out of service.


Troubleshooting








Managed Object Class / Hardware Type: Ch, Rep, Trx, DricEvent Type: equipmentAlarmProbable Cause: EquipmentMalfunctionSeverity: major (final), handled according to the




200928 - Non-volatile memory failure of baseband card


Error Description

A checksum error was found for a ROM (read only memory). The automatic recoveryfailed.

After an unsuccessful automatic recovery by means of a reset, the reporting BB cardwas put of service.


Troubleshooting








Managed Object Class / Hardware Type: Ch, Rep, Trx, DricEvent Type: processingErrorAlarmProbable Cause: CorruptDataSeverity: major (final), handled according to the



OML:Node B (RC)


200929 - DSP failure


Error Description

A boot or watchdog error of a UTOPIA relevant DSP (digital signal processor) occurred.



Troubleshooting








Managed Object Class / Hardware Type: Ch, Rep, Trx, DricEvent Type: equipmentAlarmProbable Cause: ProcessorProblemSeverity: major (final), handled according to the




200931 - FPGA failure


Error Description

A configuration failure of an FPGA (field programmable gate array) was detected.



Troubleshooting











OML:Node B (RC)


200932 - Control FPGA failure


Error Description

A control FPGA (field programmable gate array) failure occurred.



Troubleshooting












200933 - External timing signal failure


Error Description

For synchronizing the baseband cards (CH, REP, TRX, DRIC) the Core Controller (CC)send timing signals via the UTOPIA bus and clock busses. These timing signals derivefrom the master clock generator of the Core Controller.• If only one baseband card sends the alarm message: There is a hardware failure in

the baseband card. The Node B is degraded in its performance.• If several baseband cards send the alarm message: There is a failure in the Core

Controller. The uplink and downlink connections of the Node B are affected. All af-fected cells are lost.



Troubleshooting












OML:Node B (RC)


200934 - Failure of the RF part of the TRX


Error Description

There is a hardware failure in the TRX card. Within the TRX card, the radio frequencyblock (RF) handles the downlink signals. If there is a failure in the RF part, the TRX carddoes not transmit downlink signals any longer.

After an unsuccessful automatic recovery by means of a reset, the reporting TRX cardwas put out of service.


Troubleshooting









Managed Object Class / Hardware Type: TrxEvent Type: equipmentAlarmProbable Cause: EquipmentMalfunctionSeverity: major (final), handled according to the




200935 - LVDS Failure


Error Description

The LVDS (low voltage differential signal) is an internal connection between the base-band cards. This alarm message occurs if the communication between the basebandcards is disconnected. The card which sends the alarm message is probably not the de-fective card.



This alarm message may occur in connection with the 200933 - External timing signalfailure.

Troubleshooting









Managed Object Class / Hardware Type: Ch, Rep, Trx, DricEvent Type: communicationAlarmProbable Cause: RemoteNodeTransmissionErrorSeverity: major (final), handled according to the



OML:Node B (RC)


200936 - Local bus failure around the CPU


Error Description

Local bus failure around the CPU.



Troubleshooting









Managed Object Class / Hardware Type: Ch, Rep, Trx, DricEvent Type: communicationAlarmProbable Cause: RemoteNodeTransmissionErrorSeverity: major (final), handled according to the




200937 - FTP connection failure


Error Description

FTP (file transfer protocol) connection between CC card (Core Controller) and BB card(baseband) or CAT (combined amplifier and transceiver) or RRH (remote radio head)could not be established.

After an unsuccessful automatic recovery by means of a reset, the reporting LRU wasput out of service.


The error should be reported to customer services. The root of the problem may be ahardware or software error.

Troubleshooting









Managed Object Class / Hardware Type: Ch, Rep, Trx, Dric, Cat, RrhEvent Type: communicationAlarmProbable Cause: TransmissionErrorSeverity: major (final), handled according to the



OML:Node B (RC)


200938 - SWI CRC check failed


Error Description

A CRC (cyclic redundancy check) error has been detected while checking the SWI (soft-ware image). This alarm message may occur if a new SW load is activated, which, how-ever, is defective. If no new SW load has been activated, there is an error in thesoftware.

After an unsuccessful automatic recovery by means of a reset, the reporting BB cardwas put out of service. As a consequence, cells or calls could potentially be lost. Thestates of all affected managed objects change accordingly.

Troubleshooting


Managed Object Class / Hardware Type: Ch, Rep, Trx, DricEvent Type: processingErrorAlarmProbable Cause: FileErrorSeverity: major (final), handled according to the




200939 - Static configuration file CRC check failed


Error Description

A CRC (cyclic redundancy check) error has been detected while checking the static con-figuration file. This alarm message may occur if a new SW load is activated, which, how-ever, is defective. If no new SW load has been activated, there is an error in thesoftware.

After an unsuccessful automatic recovery by means of a reset, the reporting BB cardwas put out of service. As a consequence, cells or calls could potentially be lost. Thestates of all affected managed objects change accordingly.

Troubleshooting


Managed Object Class / Hardware Type: Ch, Rep, Trx, DricEvent Type: processingErrorAlarmProbable Cause: FileErrorSeverity: major (final), handled according to the



OML:Node B (RC)


200940 - SW activation failed


Error Description

The SW version specified in the SW activation command could not be activated.



Troubleshooting

1. Report this error to the technical assistance center (TAC).2. Select the faulty Node B:

– Left-click on the icon “Network Management” in the Application Launcher window.– Double left-click on the icon “Node B” or alternatively right-click on the icon








Managed Object Class / Hardware Type: Ch, Rep, Trx, DricEvent Type: processingErrorAlarmProbable Cause: SoftwareProgramAbnormallyTermi-

natedSeverity: major (final), handled according to the




200941 - Internal clock failure


Error Description

A failure of the internal clock occurred.

After an unsuccesful automatic recovery by means of a reset, the reporting BB card wasput out of service.


Troubleshooting









Managed Object Class / Hardware Type: Ch, Rep, Trx, DricEvent Type: equipmentAlarmProbable Cause: TimingProblemSeverity: major (final), handled according to the



OML:Node B (RC)


200942 - Configuration file inconsistent


Error Description

The configuration file contains inconsistent data.



Troubleshooting

1. Report this error to the technical assistance center (TAC). Contact the technical as-sistance center (TAC) to get support in isolating the fault. For suitable preparationsave the error symptoms as described in "Collect Info for Assistance". Log filesneed to be analyzed and specific measures must be taken which are out of the op-erator’s scope.








Managed Object Class / Hardware Type: Ch, Rep, Trx, Dric, Cat, RrhEvent Type: processingErrorAlarmProbable Cause: FileErrorSeverity: major (final), handled according to the




200943 - IOR file inconsistent


Error Description

A fatal software error has occurred. The IOR (interoperable object reference) configura-tion file contains inconsistent data.



Troubleshooting







6. If this is not successful, further repair actions must be achieved on site. Proceedaccording to the Output Manual OML:Node B.


Managed Object Class / Hardware Type: Ch, Rep, Trx, Dric, Cat, RrhEvent Type: processingErrorAlarmProbable Cause: FileErrorSeverity: major (final), handled according to the



OML:Node B (RC)


200944 - FTP put failed


Error Description

A failure occurred while trying to put an FTP (file transfer protocol) file to the CC card(Core Controller). The addressed LRU is reset.

The error should be reported to customer services.

As a consequence of this failure, cells or calls could potentially be lost. The states of allaffected managed objects furthermore change accordingly.

Troubleshooting









Managed Object Class / Hardware Type: Ch, Rep, Trx, DricEvent Type: communicationAlarmProbable Cause: TransmissionErrorSeverity: warning (final), handled according to

the Fault Escalation Strategy



200945 - FTP manage failure


Error Description

A failure occurred in managing the RAM (random access memory) disc via FTP. Theaddressed LRU is reset.

The error should be reported to customer services.

As a consequence of this failure, cells or calls could potentially be lost. The states of allaffected managed objects change accordingly.

Troubleshooting









Managed Object Class / Hardware Type: Ch, Rep, Trx, DricEvent Type: processingErrorAlarmProbable Cause: CorruptDataSeverity: warning (final), handled according to

the Fault Escalation Strategy


OML:Node B (RC)


200946 - Still alive supervision failure


Error Description

Still alive supervision failure. It is possible that a hardware or software error is the rootof the problem.



Troubleshooting









Managed Object Class / Hardware Type: Ch, Rep, Trx, Dric, Cat, RrhEvent Type: equipmentAlarmProbable Cause: EquipmentMalfunctionSeverity: major (final), handled according to the




200947 - Failure in the DC supply of DUAMCO


Error Description

The DUAMCO is switched off. As a consequence, the DUAMCO was put out of service.

Furthermore, cells or calls could potentially be lost. The states of all affected managedobjects change accordingly.

Troubleshooting








Managed Object Class / Hardware Type: DuamcoEvent Type: equipmentAlarmProbable Cause: PowerSupplyFailureSeverity: major


OML:Node B (RC)


200948 - CORBA communication failed


Error Description

This alarm message is output due to the following fatal error: a CORBA (common objectrequest broker architecture) communication failure between CC and the reporting LRUoccurred. It is possible that a hardware or a software error is the root of the problem.



Troubleshooting









Managed Object Class / Hardware Type: Ch, Rep, Trx, Dric, Cat, RrhEvent Type: communicationAlarmProbable Cause: TransmissionErrorSeverity: major (final), handled according to the




200949 - Internal CORBA call failed


Error Description

A fatal software error has occurred! This is a recoverable error situation caused by a po-tentially serious software fault which should be reported to customer services! The re-covery will result in a completer reset of the Node B. Due to the reset, all services willbe interrupted.

This means:• All cells will be lost.• The connection between the Node B and the RNC will be lost.• Uplink or downlink errors will be reported by other Node Bs if they are connected to


All connections to the management systems will also be interrupted during this reset pe-riod. Once the reset is completed, normal operational service should be resumed i.e. thecells are built up again, connection with the RNC will be re-established, and any crossconnections will be built up again. Any calls that were in operation before the reset arelost.

Troubleshooting


Managed Object Class / Hardware Type: CcEvent Type: communicationAlarmProbable Cause: TransmissionErrorSeverity: warning


OML:Node B (RC)


200950 - Timeout for request or modification


Error Description

A fatal hardware error has occurred. The card did not send an expected response or no-tification.



Troubleshooting









Managed Object Class / Hardware Type: *Event Type: processingErrorAlarmProbable Cause: TimeoutExpiredSeverity: major (final), handled according to the




200951 - Status notification undefined


Error Description

A fatal hardware error has occurred. The card sends an unknown status notification.



Troubleshooting






5. If the error message is not ceased--> now, contact the technical assistance center(TAC) to get support in isolating the fault. For suitable preparation save the errorsymptoms as described in "Collect Info for Assistance". Log files need to be ana-lyzed and specific measures must be taken which are out of the operator’s scope.


Managed Object Class / Hardware Type: *Event Type: processingErrorAlarmProbable Cause: CorruptDataSeverity: major (final), handled according to the



OML:Node B (RC)


200952 - Maximum number of resets exceeded


Error Description

A fatal hardware error or software error occurred. The card was not able to start up com-pletely even after performing several numbers of resets.

The reporting LRU was put out of service.


Troubleshooting






5. If the reset is not successful, further repair actions must be achieved on site.Proceed according to the Output Manual OML:Node B.



Managed Object Class / Hardware Type: *Event Type: equipmentAlarmProbable Cause: EquipmentMalfunctionSeverity: major



200953 - CAN bus off


Error Description

There is an error detected in the physical CAN communication layer. Service may thusbe affected.

This alarm message may occur in connection with other CAN related alarms:• 200954 - No message response on CAN• 200955 - Mount supervision failure• 200956 - Watch dog timer expired• 200957 - Internal CAN processing failure

Troubleshooting









Managed Object Class / Hardware Type: *Event Type: equipmentAlarmProbable Cause: ProcessorProblemSeverity: warning


OML:Node B (RC)


200954 - No message response on CAN


Error Description

The watchdog timer on the CAN bus is expired. An object on the affected CAN bustherefore performed a reset.



This alarm message may occur in connection with other CAN related alarms:• 200953 - CAN bus off• 200955 - Mount supervision failure• 200956 - Watch dog timer expired• 200957 - Internal CAN processing failure

Troubleshooting













200955 - Mount supervision failure


Error Description

A CAN object performed reset caused by expiration of the mount supervision timer.



This alarm message may occur in connection with other CAN-related alarms:• 200953 - CAN bus off• 200954 - No message response on CAN• 200956 - Watch dog timer expired• 200957 - Internal CAN processing failure

Troubleshooting












OML:Node B (RC)


200956 - Watch dog timer expired


Error Description

The watch dog timer on CAN bus expired.

If the reporting managed object is a CAT (combined amplifier and transceiver) or a RRH(remote radio head), the following applies: The CAT’s/RRH’s CPU (central processingunit) watchdog detected a CPU failure.



This alarm message may occur in connection with other CAN related alarms:• 200953 - CAN bus off• 200954 - No message response on CAN• 200955 - Mount supervision failure• 200957 - Internal CAN processing failure

Troubleshooting







Managed Object Class / Hardware Type: *Event Type: processingErrorAlarmProbable Cause: WatchDogTimerExpiredSeverity: major (final), handled according to the







OML:Node B (RC)


200957 - Internal CAN processing failure


Error Description

A CAN object performed reset caused by an internal processing failure.



This alarm message may occur in connection with other CAN related alarms:• 200953 - CAN bus off• 200954 - No message response on CAN• 200955 - Mount supervision failure• 200956 - Watch dog timer expired

Troubleshooting








Managed Object Class / Hardware Type: *Event Type: equipmentAlarmProbable Cause: EquipmentMalfunctionSeverity: major (final), handled according to the




200958 - Timer for the reset supervision expired


Error Description

The timer for the reset supervision has been expired.



Troubleshooting








Managed Object Class / Hardware Type: *Event Type: equipmentAlarmProbable Cause: TimingProblemSeverity: major (final), handled according to the



OML:Node B (RC)


200959 - Missing response from baseband card


Error Description

The following fatal error has occurred: NBAP (Node B application part) has detected amissing response from a baseband card. It is possible that a hardware or software erroris the root of the problem.



The error should be reported to customer service.

Troubleshooting









Managed Object Class / Hardware Type: Ch, Rep, Trx, DricEvent Type: processingErrorAlarmProbable Cause: TimeoutExpiredSeverity: major (final), handled according to the




200960 - Invalid response from baseband card


Error Description

The following fatal software error has occurred: NBAP (Node B application part) has de-tected an invalid response from a baseband card. It is possible that a hardware or soft-ware error is the root of the problem.



The error should be reported to customer service.

Troubleshooting

1. First, reset the addressed card by the following procedures:– Lock the addressed card, using either the ’NodeB Sum’ panel or applying the

lock command to the addressed card.– Reset the addressed card by means of the ’NodeB Sum’ panel or the rst com-

mand.2. If this is not successful, further repair actions must be achieved on site. Proceed

according to the Output Manual OML:Node B.3. Contact the technical assistance center (TAC) to get support in isolating the fault.

For suitable preparation save the error symptoms as described in "Collect Info forAssistance". Log files need to be analyzed and specific measures must be takenwhich are out of the operator’s scope.


Managed Object Class / Hardware Type: Ch, Rep, Trx, DricEvent Type: communicationAlarmProbable Cause: InvalidMessageReceivedSeverity: major (final), handled according to the



OML:Node B (RC)


200961 - Firmware download failure


Error Description

A fatal hardware error was detected while downloading the FW (firmware) or no FW isavailable at all at the card.

The reporting LRU was put out of service.


Troubleshooting









Managed Object Class / Hardware Type: *Event Type: processingErrorAlarmProbable Cause: SoftwareDownloadFailureSeverity: major



200980 - Invalid MO


Error Description

An object was accessed at the CAN bus which does not exist or which is not mounted.

This may be caused by one of the following:• The Node B database is defective. A new database was installed but does not match

the hardware configuration.• The hardware configuration is invalid. A new hardware equipment was installed but

does not match the database.• A software error has occurred.

Troubleshooting

Perform the following tasks in the given order to solve this alarm:

1. Check if you are working with the newest version of the database.2. If necessary, change the running database.

– Open the ’NodeB Sum’ panel.– Click the Network Management button in the Application Launcher to open the


3. Otherwise, if the database was not defective, check the hardware configuration.Check the entry in the database and check the addressed MO on site. There mighthave been a change of the MO type on site or in the configuration, which was notedited in the database.

4. If the error is not caused by an invalid database or an unsuitable hardware configu-ration, contact the technical assistance center (TAC) to get support in isolating thefault. For suitable preparation save the error symptoms as described in "Collect Infofor Assistance". Log files need to be analyzed and specific measures must be takenwhich are out of the operator’s scope.


Managed Object Class / Hardware Type: *Event Type: processingErrorAlarmProbable Cause: DatabaseInconsistencyPerceived severity: warning


OML:Node B (RC)


200981 - MO not mounted


Error Description

The specified MO is not mounted.

Troubleshooting

Repair actions must be achieved on site. Proceed according to the Output ManualOML:Node B.

Managed Object Class / Hardware Type: *Event Type: communicationAlarmProbable Cause: UnavailableSeverity: warning



200982 - Invalid command


Error Description

A CAN command is invalid.

This alarm may be caused by one of the following:• The Node B database is defective. A new database was installed but does not match



Troubleshooting







3. If necessary, change the running database.4. Otherwise, if the database was not defective, check the hardware configuration.

Check the entry in the database and check the addressed MO on site. There mighthave been a change of the MO type on site or in the configuration, which was notedited in the database.

5. If the error is not caused by an invalid database or an unsuitable hardware configu-ration: Contact the technical assistance center (TAC) to get support in isolating thefault. For suitable preparation save the error symptoms as described in "Collect Infofor Assistance". Log files need to be analyzed and specific measures must be takenwhich are out of the operator’s scope.

Managed Object Class / Hardware Type: *Event Type: processingErrorAlarmProbable Cause: CorruptDataSeverity: warning


OML:Node B (RC)


200983 - Invalid parameter in command


Error Description

A CAN command contains an invalid parameter.

This alarm may be caused by one of the following:• The Node B database is defective. A new database was installed but does not match



Troubleshooting







3. If necessary, change the running database.4. Otherwise, if the database was not defective, check the hardware configuration.

Check the entry in the database and check the addressed MO on site. There mighthave been a change of the MO type on site or in the configuration, which was notedited in the database.

5. If the error is not caused by an invalid database or an unsuitable hardware configu-ration: Contact the technical assistance center (TAC) to get support in isolating thefault. For suitable preparation save the error symptoms as described in "Collect Infofor Assistance". Log files need to be analyzed and specific measures must be takenwhich are out of the operator’s scope.

Managed Object Class / Hardware Type: *Event Type: processingErrorAlarmProbable Cause: InvalidParameterSeverity: warning



200984 - FW download access file error


Error Description

FW (firmware) download access file error. The access to the card firmware is not possi-ble. Probably providing a wrong software causes the problem.

Troubleshooting


2. Choose the appropriate FW file for the selected card.3. Download FW to card. The download has to be done separately for each card. (At a

particular time, FW download is only possible to one card)

Managed Object Class / Hardware Type: *Event Type: processingErrorAlarmProbable Cause: SoftwareDownloadFailureSeverity: warning


OML:Node B (RC)


200985 - CAN transaction error


Error Description

A CAN transaction error. The card will be reset after inconsistency of data during com-munication over CAN, e.g. message timeouts, unexpected responses or errors whiledownload of the firmware.


Troubleshooting

1. First, reset the addressed card.2. If this is not successful, further repair actions must be achieved on site. Proceed

according to the Output Manual OML:Node B.3. Contact the technical assistance center (TAC) to get support in isolating the fault.


Managed Object Class / Hardware Type: *Event Type: equipmentAlarmProbable Cause: EquipmentMalfunctionSeverity: warning



200986 - Temperature out of range in upper direction


Error Description

The temperature at the temperature sensor wired to the ACTC board is out of range inupper direction. The temperature is above +87 ˚C (188.6 ˚F).

This error message occurs also, if the sensor is disconnected.

Troubleshooting


Managed Object Class / Hardware Type: BaseRack, ServiceRackEvent Type: environmentalAlarmProbable Cause: HighTemperatureSeverity: minor



OML:Node B (RC)


200987 - Hardware parameter invalid


Error Description

This alarm indicates that an unknown hardware parameter has been received. The re-porting card will be reset after it has delivered an unknown hardware parameter.

Normally, this alarm would have been caused by an incompatible hardware configura-tion, a defective database, etc.

In this case, however, the Node B software reports an invalid hardware parameter al-though neither the hardware configuration nor the Node B database are mismatched! Infact, this is an error in the software which should be reported to customers service.

Due to the reason that this is a software error rather than an incompatibility in the data-base or hardware configuration, checking or changing the Node B’s database and hard-ware configuration would not help to solve this alarm.

As a consequence of this failure, cells or calls could potentially be lost. The states of allaffected managed objects change accordingly.

Troubleshooting


Managed Object Class / Hardware Type: *Event Type: processingErrorAlarmProbable Cause: InvalidParameterSeverity: warning



200988 - Response unknown


Error Description

A non-fatal software error has occurred. An unknown response has been received.

Troubleshooting

1. Reset the addressed card.2. If the fault could not be cleared by the reset, further repair actions must be achieved

on site. Proceed according to the Output Manual OML:Node B.3. If the fault cannot be cleared by the reset, contact the technical assistance center

(TAC) to get support in isolating the fault. For suitable preparation save the errorsymptoms as described in "Collect Info for Assistance". Log files need to beanalyzed and specific measures must be taken which are out of the operator’sscope.

Managed Object Class / Hardware Type: *Event Type: processingErrorAlarmProbable Cause: MessageNotExpectedSeverity: warning


OML:Node B (RC)


200989 - No CORBA proxy available for LRU


Error Description

This alarm is output due to the following fatal software error: there is no CORBA (com-mon object request broker architecture) proxy available for the addressed LRU.



Troubleshooting

Perform the following tasks in the given order to solve this error:


lock command to the addressed card.– Reset the addressed card. Use the ’NodeB Sum’ panel or the rst command.








200990 - No still alive response from LRU


Error Description

This alarm message is output due to the following fatal software error: no still alive re-sponse from the addressed LRU has been received.


The error should be reported to the customers service.


Troubleshooting

Perform the following tasks in the given order:


lock command to the addressed card.– Reset the addressed card. Use the ’NodeB Sum’ panel or the rst command.







OML:Node B (RC)


200991 - Duplex error


Error Description

The duplex error occurs in the event of:• Receive logical channel FIFO overrun on duplex.• Loss of signal alarm on duplex.• Loss of cell delineation.• HCS-error on RXD interface on duplex.• Cell delineation state out of sync.• Transmit logical channel FIFO overrun on duplex.• Unable to lock input reference clock on duplex.• Invalid start of cell sequence on utopia input port on duplex.

As a consequence of this failure, service may be affected. Thus, cells or calls could po-tentially be lost. The states of all affected managed objects change accordingly.

Troubleshooting

Perform the following tasks in the given order:

1. First try to reset the addressed card. Either use the ’NodeB Sum’ panel or apply therst command to the relevant CC.




Managed Object Class / Hardware Type: CcEvent Type: equipmentAlarmProbable Cause: EquipmentMalfunctionSeverity: major (final), handled according to the




200992 - Software Error


Error Description

This error occurs in case of:• Flash error• CAN receive or transmit queue overflow• Interrupt queue overflow

As a consequence of this failure, service may be affected. Thus, cells or calls could po-tentially be lost. The states of all affected managed objects change accordingly.

Troubleshooting






Managed Object Class / Hardware Type: CcEvent Type: processingErrorAlarmProbable Cause: SoftwareErrorSeverity: critical


OML:Node B (RC)


200993 - Unexpected Alarm Status Bit


Error Description

Unexpected CAN status notification occurs in case of:• CRC-8 error for the whole received cell (RXD) on duplex.• Remote defect indication (RDI) received on LVDS (low voltage differential signal) on

duplex.• SRAM, duplex, EEPROM or CAN voltage error.

As a consequence of this failure, service may be affected: cells or calls could potentiallybe lost. The states of all affected managed objects change accordingly.

Troubleshooting






Managed Object Class / Hardware Type: CcEvent Type: processingErrorAlarmProbable Cause: CorruptDataSeverity: critical



200994 - HW Failure


Error Description

This error occurs in case of:• PLL of DC/DC-unit unlocked• Voltage or current out of range• Insufficient or excess temperature on DC/DC-unit

Troubleshooting

Perform the following tasks in the following order to solve this error:





Managed Object Class / Hardware Type: CcEvent Type: equipmentAlarmProbable Cause: EquipmentFailureSeverity: warning


OML:Node B (RC)


200995 - High Temperature Limit (Ht3) reached


Error Description

The Node B rack/shelter internal temperature has reached a high level (Ht3). If the tem-perature increases further (by 2 ˚C, which is equivalent to 3.6 ˚F) the critical level (Ht4)will be reached. See also 200996 - Critical Temperature Limit (Ht4) reached. The tem-perature level depends on the Node B type and is as follows:• NB-441/NB-881: Ht3 = 63 ˚C (125.6 ˚F)• NB-440/NB-880/NB-580: Ht3 = 59 ˚C (138.2 ˚F)• NB-420/NB-860: Ht3 = 61 ˚C (141.8 ˚F)• NB-341: Ht3 = 70 ˚C (158 ˚F)

This alarm message may occur in conjunction with 200920 - High temperature of PA and200921 - Over temperature of PA.

This alarm is cleared if the temperature decreases to the Ht2 level, which depends alsoon the Node B type:• NB-441/NB-881: Ht2 = 52 ˚C (125.6 ˚F)• NB-440/NB-880/NB-580: Ht2 = 47 ˚C (116.6 ˚F)• NB-420/NB-860: Ht2 = 47 ˚C (116.6 ˚F)• NB-341: Ht2 = 65 ˚C (149 ˚F)

Troubleshooting


Further repair actions must be achieved on site. Proceed according to the Output Man-ual OML:Node B.

Managed Object Class / Hardware Type: BaseRack, ServiceRackEvent Type: environmentalAlarmProbable Cause: HighTemperatureSeverity: major

i NOTEIf the reporting Node B is of type NB-441/NB-881, this alarm may be caused by a pol-luted membrane filter (MEF). Therefore, if the Node B site is located in heavily air-pol-luted environments combined with special temperature conditions, a maintenance of theMEF filters in the outdoor NB-441/NB-881 might be necessary.If the MEFs are polluted, the 201029 - MEF blocked or 201035 - MEF completelyblocked alarm is output. Refer to the relevant alarm’s error description and follow thetroubleshooting.



200996 - Critical Temperature Limit (Ht4) reached


Error Description

The Node B rack/shelter internal temperature has reached a critical level (Ht4). An im-mediate operator action is required: Switch off the Node B! Otherwise a severehardware damage can occur.

The temperature level depends on the Node B type and is as follows:• NB-441/NB-881: Ht4 = 65 ˚C (149 ˚F)• NB-440/NB-880/NB-580: Ht4 = 61 ˚C (141.8 ˚F)• NB-420/NB-860: Ht4 = 63 ˚C (145.4 ˚F)• NB-341: Ht4 = 72 ˚C (161.6 ˚F)

This alarm message may occur in conjunction with 200920 - High temperature of PA and200921 - Over temperature of PA.

This alarm is cleared if the temperature decreases to the Ht2 level, which depends alsoon the Node B type:• NB-441/NB-881: Ht2 = 52 ˚C (125.6 ˚F)• NB-440/NB-880/NB-580: Ht2 = 47 ˚C (116.6 ˚F)• NB-420/NB-860: Ht2 = 47 ˚C (116.6 ˚F)• NB-341: Ht2 = 65 ˚C (149 ˚F)

Troubleshooting

Switch off the Node B immediately! Otherwise, a severe hardware damage can occur.

Additional fan alarms like 200914 - Fan unit failed may indicate the basic cause.


Managed Object Class / Hardware Type: BaseRack, ServiceRackEvent Type: environmentalAlarmProbable Cause: HighTemperatureSeverity: major

i NOTEIf the reporting Node B is of type NB-441/NB-881, this alarm may be caused by a pol-luted membrane filter (MEF). Therefore, if the Node B site is located in heavily air-pol-luted environments combined with special temperature conditions, a maintenance of theMEF filters in the outdoor NB-441/NB-881 might be necessary.If the MEFs are polluted, the 201029 - MEF blocked or 201035 - MEF completelyblocked alarm is output. Refer to the relevant alarm’s error description and follow thetroubleshooting.

i NOTEAn overtemperature scenario in the Node B can lead to a self-disabling of B-shelf cards.The Node B handles self-disabled cards as if a fatal board failure, such as an on-boardpower supply failure, has occurred. In other words, the combination of OST/AVS thenchanges to disabled /not installed and the LED of the self-disabled card is off.


OML:Node B (RC)


200997 - Lower Temperature Limit (Ht0) reached


Error Description

The Node B rack/shelter internal temperature has reached the lower limit (Ht0). Belowthis temperature electronic equipment does not work reliably.

The temperature level for all Node B types is:• Ht0 = -5 ˚C (23 ˚F)

This alarm is cleared, if the temperature decreases to the Ht1 level, which is Node B de-pendent:• NB-441/NB-881: Ht1 = 5 ˚C (41 ˚F)• NB-440/NB-880/NB-580: Ht1 = 5 ˚C (41 ˚F)• NB-420/NB-860: Ht1 = 5 ˚C (41 ˚F)• NB-341: Ht1 = 0 ˚C (32 ˚F)

Troubleshooting


Managed Object Class / Hardware Type: BaseRack, ServiceRackEvent Type: environmentalAlarmProbable Cause: LowTemperatureSeverity: minor



200998 - Temperature out of range in lower direction


Error Description

The temperature at the temperature sensor wired to the ACT is out of range in lower di-rection.

The temperature is below:• NB-441/NB-881: -8 ˚C (17.6 ˚F)• NB-440/NB-880/NB-580: -8 ˚C (17.6 ˚F)• NB-420/NB-860: -8 ˚C (17.6 ˚F)• NB-341: -10 ˚C (14 ˚F)

This error message occurs also, if there is a short-circuit in the sensor or in the wiresbetween sensor and ACT.

Troubleshooting


Managed Object Class / Hardware Type: BaseRack, ServiceRackEvent Type: environmentalAlarmProbable Cause: LowTemperatureSeverity: minor


OML:Node B (RC)


200999 - Unexpected loss of unlocked card


Error Description

The mentioned card was unmounted without being locked before. Thunexpected loss ofan unlocked card can be caused by one of the following:• Extracting the card without setting the administrative state (AST) to locked before• Occurrance of a fatal board failure• Self-disabling of the reporting card due to an overtemperature scenario

As a consequence of this scenario, cells or calls could potentially be lost. The statesof all affected managed objects thus change accordingly.The Node B handles self-disabled cards as if a fatal board failure, such as an on-board power supply failure, has occurred. In other words, the combination ofOST/AVS changes to disabled /not installed and the LED of the self-disabled cardis off.

If this fatal board failure occurs even a CAN communication is not possible anymore.

Troubleshooting

Independent of the cause due to which this alarm occurred, repair actions must beachieved on site. Proceed according to the Output Manual OML:Node B.

Managed Object Class / Hardware Type: *Event Type: equipmentAlarmProbable Cause: EquipmentFailureSeverity: critical

i NOTEIf the reporting Node B is of type NB-441/NB-881, the self-disabling of the re-porting card may be caused by a polluted membrane filter (MEF). Therefore,if the Node B site is located in heavily air-polluted environments combinedwith special temperature conditions, a maintenance of the MEF filters in theoutdoor NB-441/NB-881 might be necessary.If the MEFs are polluted, the 201029 - MEF blocked or 201035 - MEF com-pletely blocked alarm is output. Refer to the relevant alarm’s error descriptionand follow the troubleshooting.

i NOTEIf this alarm occurs in combination with the 200914 - Fan unit failed alarm or the 200996- Critical Temperature Limit (Ht4) reached alarm, the probability is very high that the re-porting card disabled itself due to an overtemperature scenario.



201001 - RET power off


Error Description

The addressed RET module is switched off at the POWER ON/OFF switch, but not de-fective. This mode is indicated by the RET LED which is off. Most likely, this alarm israised during normal Node B operation if the DIP switch 6 of the corresponding DIPswitch group is set to OFF position by accident.

Please switch on the RET module.

This alarm will only be output if the power status of the RET module has changed fromON to OFF during operation. However, if the RET module is already switched off at boottime of the Node B, this alarm will not be raised.

For RET recovery, a reset of the related DUAMCO is required in order to re-establishthe communication between DUAMCO and RET. A reset of the RET managed object isnot possible while this failure exists.

Troubleshooting

1. Reset the relevant DUAMCO managed object by the following procedures:– Lock the DUAMCO, using either the ’NodeB Sum’ panel or the lock command.– Reset the relevant DUAMCO. Use either the ’NodeB Sum’ panel or, alternatively,

apply the rst command to it.2. If the fault could not be cleared by the reset of the DUAMCO, further repair actions

must be achieved on site. Proceed according to the Output Manual OML:Node B.

Managed Object Class / Hardware Type: RetEvent Type: environmentalAlarmProbable Cause: ExternalPowerSupplyFailureSeverity: minor


OML:Node B (RC)


201002 - RET feeder alarm


Error Description

RET operations of the reporting module are not possible because the 2.176 MHz carrierbetween the DUAMCO and DTMARET or the cable between DTMARET and RET is de-fective.

In the current configuration of Node B, this alarm should not occur at all. This alarm isdesigned for possible applications in the future when no TMA will be used. If the carrieris defective in the current configuration, the alarms 200910 - TMA feeder alarm and201004 - RET communication error are output.

For RET recovery a reset of the related DUAMCO is required in order to re-establish thecommunication between DUAMCO and RET. A reset of the RET managed object is notpossible while this failure exists.

Troubleshooting

1. Reset the relevant DUAMCO by the following procedures:– Lock the DUAMCO, using either the ’NodeB Sum’ panel or the lock command.– Reset the DUAMCO by means of the ’NodeB Sum’ panel or the rst command.

2. If the error has not ceased yet, further repair actions must be achieved on site.Proceed according to the Output Manual OML:Node B.


Managed Object Class / Hardware Type: RetEvent Type: equipmentAlarmProbable Cause: ReceiverFailureSeverity: minor



201003 - RET hardware alarm


Error Description

The addressed RET module reported a hardware error, such as a motor jam or anEPROM error.

Troubleshooting


Managed Object Class / Hardware Type: RetEvent Type: equipmentAlarmProbable Cause: EquipmentFailureSeverity: minor


OML:Node B (RC)


201004 - RET communication error


Error Description

The addressed RET module reported a communication error such as a signaling inter-rupt. This alarm may be caused by one of the following:• An error occurred on the serial communication line between TMA and RET (RS485).• This alarm is output as a consequence of 200910 - TMA feeder alarm, occurring

whenever the 2.176 MHz carrier between DUAMCO and DTMARET or the cable be-tween DTMARETand RET is defective.

For RET recovery, a reset of the related DUAMCO and the addressed RET is requiredin order to re-establish the communication between DUAMCO and RET. Only resettingthe RET managed object is not possible while this failure exists.

Troubleshooting

First, check whether alarm 200910 - TMA feeder alarm is output. If this alarm has oc-curred before, eliminate the cause of the fault. Proceed according to the troubleshootingof 200910 - TMA feeder alarm. This may clear the RET communication error, as well.

If either the TMA feeder alarm did not occur or the measures taken above did not clearthis fault, perform the following steps in the given order:

1. Reset the relevant DUAMCO managed object by the following procedures:– Lock the DUAMCO, using either the ’NodeB Sum’ panel or the lock command.– Reset the relevant DUAMCO. Use either the ’NodeB Sum’ panel or, alternatively,

apply the rst command to it.2. Reset the addressed RET managed object.

Use either the ’NodeB Sum’ panel or, alternatively, apply the rst command to it.3. If the error has not ceased yet, further repair actions must be achieved on site. Pro-

ceed according to the Output Manual OML:Node B.


Managed Object Class / Hardware Type: RetEvent Type: communicationAlarmProbable Cause: CommunicationProtocolErrorSeverity: minor



201005 - RET isn’t calibrated


Error Description

The reporting RET module is disabled because it is not calibrated. Both the RET moduleand the antenna have to be calibrated after installation. The stepper motor drives to theend position.

To solve this error, the addressed RET module has to be calibrated.

Troubleshooting

Perform the following tasks in the order described to solve this error:

1. First, calibrate the reporting RET module. Either use the ’NodeB Sum’ panel or applythe clb command to the relevant RET MOI.

2. Contact the technical assistance center (TAC) to get support in isolating the fault. Forsuitable preparation save the error symptoms as described in "Collect Info for As-sistance". Log files need to be analyzed and specific measures must be taken whichare out of the operator’s scope.


Managed Object Class / Hardware Type: RetEvent Type: equipmentAlarmProbable Cause: ExternalIFDeviceProblemSeverity: minor


OML:Node B (RC)


201006 - RET isn’t scaled


Error Description

The reporting RET module is disabled because it is not scaled. In other words, the trans-lation table has not been downloaded to the relevant RET module.

The spindle scale table of the relevant RET module must be re-programmed.

Troubleshooting

1. The relevant configuration data has to be uploaded.As a precondition, the relevant RET module must be accessible to connect theRS485 interface.To upload (and update) the configuration data, use the ’NodeB Sum’ panel or, alter-natively, apply the updTable command to the reporting RET object.

2. Contact the technical assistance center (TAC) to get support in isolating the fault. Forsuitable preparation save the error symptoms as described in "Collect Info for As-sistance". Log files need to be analyzed and specific measures must be taken whichare out of the operator’s scope.





201007 - RET lost position


Error Description

The reporting RET module lost position of the stepper motor and is therefore disabled.The relevant RET module must be calibrated again.

Furthermore, while adjusting the antenna tilt, the power supply was interrupted.

Troubleshooting

Perform the following tasks in the order described to solve this error:

1. First, calibrate the reporting RET module.Either use the ’NodeB Sum’ panel or apply the clb command to the relevant RETMOI.

2. Contact the technical assistance center (TAC) to get support in isolating the fault. Forsuitable preparation save the error symptoms as described in "Collect Info for Assis-tance". Log files need to be analyzed and specific measures must be taken whichare out of the operator’s scope.




OML:Node B (RC)


201008 - RET received wrong configuration data


Error Description

The addressed RET module received wrong configuration data and is therefore dis-abled.

Setting the appropriate configuration data may be required after installation of any RETmodule unless this task has already been performed by the vendor before delivery. Itloads vendor and antenna specific configuration data to establish the relationship be-tween the movement of the drive system and the beam position of the antenna.

Troubleshooting

1. Check whether the correct configuration data (antenna type and antenna OEM ven-dor) is used. Use the ’NodeB Sum’ panel or the getInfo command.– If the configuration data is OK, go to step (2).– Otherwise, if the configuration data is NG, the correct configuration data must be

uploaded and updated. Use the ’NodeB Sum’ panel or, alternatively, apply theupdTable command to the reporting RET module.

2. Further repair actions must be achieved on site. Proceed according to the OutputManual OML:Node B.


Managed Object Class / Hardware Type: RetEvent Type: communicationAlarmProbable Cause: CommunicationProtocolErrorSeverity: minor



201009 - A mounted card is not used to its full capacity


Error Description

The Node B's configuration does not use the mounted card's full capacity and/or fea-tures. This could be an unwanted waste of resources.

Troubleshooting


Managed Object Class / Hardware Type: *Event Type: processingErrorAlarmProbable Cause: ConfigurationOrCustomizationErrorSeverity: warning


OML:Node B (RC)


201010 - An incompatible card is mounted


Error Description

The mounted card does not fulfill the Node B's configuration requirements.

Troubleshooting


Managed Object Class / Hardware Type: *Event Type: processingErrorAlarmProbable Cause: ConfigurationOrCustomizationErrorSeverity: critical



201011 - Alignment of standby CC failed


Error Description

The alignment of the standby CC failed. The error should be reported to customer ser-vices. It is possible that a hardware or software error is the root of the problem.

Troubleshooting

Take the following steps to solve this error:

1. First, reset the relevant card. Use either the ’NodeB Sum’ panel or the rst com-mand.

2. If the manual reset did not clear the fault, contact the technical assistance center(TAC) to get support in isolating the fault. For suitable preparation save the errorsymptoms as described in "Collect Info for Assistance". Log files need to be ana-lyzed and specific measures must be taken which are out of the operator’s scope.


Managed Object Class / Hardware Type: CcEvent Type: processingErrorAlarmProbable Cause: FileErrorSeverity: major (final), handled according to the



OML:Node B (RC)


201012 - Timeout for connection to standby CC


Error Description

An expected message from the standby CC did not come in time. The error should bereported to customer services. It is possible that a hardware or software error is the rootof the problem.

Troubleshooting

In order to solve this error, perform the following steps in the given order:

1. Reset the relevant card. Use either the ’NodeB Sum’ panel or the rst command.2. If the manual reset did not clear the fault, contact the technical assistance center

(TAC) to get support in isolating the fault. For suitable preparation save the errorsymptoms as described in "Collect Info for Assistance". Log files need to be ana-lyzed and specific measures must be taken which are out of the operator’s scope.


Managed Object Class / Hardware Type: CcEvent Type: processingErrorAlarmProbable Cause: TimeoutExpiredSeverity: major



201013 - Connection failure to standby CC


Error Description

An attempt to connect to the standby CC failed. The error should be reported to custom-er services. It is possible that a hardware or software error is the root of the problem.

Troubleshooting


1. Reset the addressed standby CC, using either the ’NodeB Sum’ panel or the rstcommand.

2. If the manual reset did not clear the fault, contact the technical assistance center(TAC) to get support in isolating the fault. For suitable preparation save the errorsymptoms as described in "Collect Info for Assistance". Log files need to be ana-lyzed and specific measures must be taken which are out of the operator’s scope.Further repair actions must be achieved on site. Proceed according to the OutputManual OML:Node B.


Managed Object Class / Hardware Type: CcEvent Type: equipmentAlarmProbable Cause: LinkFailureSeverity: major


OML:Node B (RC)


201014 - Standby CC forced to become active due to un-reachable active CC


Error Description

The former standby CC was not able to connect with the expected active CC and nowbecame active. Please note that this CC became active due to a recovery action andmight not contain the expected configuration. The other CC was not able to become ac-tive, thus it should be replaced.

Troubleshooting


1. Repair actions must be achieved on site. Proceed according to the Output ManualOML:Node B.

2. If the measures taken on site did not clear the fault, contact the technical assistancecenter (TAC) to get support in isolating the fault. For suitable preparation save theerror symptoms as described in "Collect Info for Assistance". Log files need to be an-alyzed and specific measures must be taken which are out of the operator’s scope.

Managed Object Class / Hardware Type: CcEvent Type: processingErrorAlarmProbable Cause: CorruptDataSeverity: warning



201015 - Preparation of data to be aligned has failed


Error Description

Data which has to be aligned could not be prepared. As a consequence, the standby CCwill not be aligned correctly. The error should be reported to customer services. It is pos-sible that a hardware or software error is the root of the problem.

Troubleshooting


Managed Object Class / Hardware Type: CcEvent Type: processingErrorAlarmProbable Cause: FileErrorSeverity: warning


OML:Node B (RC)


201016 - Non-fatal internal LVDS failure


Error Description

A non-fatal hardware error has occurred (internal LVDS failure) in the reporting DRIC.The state of the card is changed accordingly (AVS is degraded ). If the card is providingservice (SBS is Providing Service ), parts of the service could be lost and some of thecells get disabled.

The card is still working partly but should be replaced. If a redundant card is installedwhich is enabled, an operator-triggered switchover can be initiated from OMC-B.

Troubleshooting

1. If a redundant card is installed, perform a switch-over to this card. Afterwards, thiscard will be active.To trigger a switch-over from the active to a redundant card installed, set the admin-istrative state of the reporting DRIC to shuttingDown . Use either the ’NodeB Sum’panel or, alternatively, apply the shutdown command to it.

2. If either no redundant card is installed or the measure taken above did not clear thefault, repair actions must be achieved on site. Proceed according to the Output Man-ual OML:Node B.


Managed Object Class / Hardware Type: DricEvent Type: equipmentAlarmProbable Cause: EquipmentMalfunctionSeverity: minor

i NOTEA switch-over to a redundant DRIC can only be triggered by setting the active DRIC’sAVS to shuttingDown . Setting the AVS to locked is not sufficient.Applying the shutdown command is furthermore only allowed if no cells would go downdue to this operation.



201017 - Digital input power level too high, but gainreduced


Error Description

The CAT/RRH detected a digital input power level from the DRIC that has continuouslybeen too high. In fact, the digital input power level has been more than 5 dB above themaximum output power of the CAT/RRH for more than 60 seconds.

A root cause for the occurrence of the ’201017 - Digital input power level too high, butgain reduced’ alarm may be the following: the congestion control parameters for the re-lated cell are not configured sufficiently in the RNC’s database.

Please refer to the• Radio Commander Command Manual CML:RNC for details about congestion con-

trol parameters• ’Cell Configuration’ of Radio Commander Online Help for details about setting up

congestion control in a specific cell

Troubleshooting


1. Repair actions must be achieved on site (confirm that cables are connectedproperly). Proceed according to the Output Manual OML:Node B.

2. Furthermore, check the setting of the following parameters related to congestioncontrol in the RNC database. The relevant parameters for the related cell of thisNode B must be set to the following values:– Downlink congestion threshold: dlCongT <= 0.9– Downlink congestion hysteresis: dlCongH >= 0.15– Number of bearers that are switched/dropped in each step: k >= 1– Enable bearer dropping: eBD= TRUEFor details about the parameters, refer to the CONGC managed object in the RadioCommander Command Manual CML:RNC.

Managed Object Class / Hardware Type: Cat, RrhEvent Type: equipmentAlarmProbable Cause: ExcessiveTransmitterOutputPowerSeverity: minor


OML:Node B (RC)


201018 - The LRU could not process a message from CC


Error Description

A fatal software error has occurred: the addressed LRU indicates a messaging failuretowards the CC.



Troubleshooting


1. Check the HW compatibility of the configuration.If card replacement is necessary, repair actions must be achieved on site. Proceedaccording to the Output Manual OML:Node B.

2. Reset the relevant card by the following procedures:– Lock the addressed card, using either the ’NodeB Sum’ panel or the lock com-

mand.– Reset the addressed card by means of either the ’NodeB Sum’ panel or the rst

command.3. Contact the technical assistance center (TAC) to get support in isolating the fault.



Managed Object Class / Hardware Type: Cc, Ch, Rep, Trx, Dric, Cat, Ret, RrhEvent Type: processingErrorAlarmProbable Cause: InvalidParameterSeverity: major (final), handled according to the




201019 - Gain below threshold


Error Description

The gain of the CAT/RRH falls below a certain threshold. The output power has been3dB below the expected output power calculated from the digital input signal for morethan a specified period of time.

As a consequence, the reporting CAT/RRH was put out of service. Cells or calls couldpotentially be lost. The states of all affected managed objects change accordingly.

Troubleshooting


Managed Object Class / Hardware Type: Cat, RrhEvent Type: equipmentAlarmProbable Cause: SignalQualityEvaluationFaultSeverity: major


OML:Node B (RC)


201020 - Loss of single DRIF interface detected


Error Description

The communiation to a specific CAT/RRH module over one CPRI-compliant DRIF inter-face was lost, whereas a second DRIF interface to this CAT/RRH exits and still is work-ing.

The single DRIF loss may be caused by a missing cable connection, by hardware prob-lems on the CAT/RRH DRIF interface side as well as on the DRIC side.

As a consequence, cells or calls could potentially be lost if the lost DRIF carried userplane data. Furthermore, the states of all affected managed objects change accordingly.

Troubleshooting


Managed Object Class / Hardware Type: DricEvent Type: equipmentAlarmProbable Cause: LinkFailureSeverity: minor



201022 - Alignment of file data has failed


Error Description

Alignment of file data from the active to the standby CC failed.

The data to be aligned is not indispensable for redundancy in general. For example log-ging-, or PM-data can be affected.

The error should be reported to customer services. It is possible that a hardware or soft-ware error is the root of the problem.

Troubleshooting


Managed Object Class / Hardware Type: CcEvent Type: processingErrorAlarmProbable Cause: FileErrorSeverity: minor (final), handled according to the



OML:Node B (RC)


201023 - Bad signal quality of single DRIF interfacedetected


Error Description

The addressed CAT/RRH module detected that the signal quality on one DRIF will notensure a reliable data transmission.

The following cases are possible:• Case 1: The DRIF to DRIC-N is affected and a second working DRIF connection to

DRIC-E exists. Therefore, CAT/RRH connects to DRIC-E. However, in this case cellsand calls could potentially be lost.

• Case 2: The DRIF to DRIC-E is affected. This case has no direct impact for cells andcalls until a switch over to DRIC-E occurs.

This alarm message may occur in conjunction with alarm 201020 - Loss of single DRIFinterface detected on DRIC-N.

The failure can be caused by one of the following:• Failure to receive an expected response to a CORBA request within specified time

limits• Indications of a connection failure from the communication stack, for example point-

to-point protocol (PPP), internet protocol (IP), high level data link control protocol(HDLC), etc.

Troubleshooting



Managed Object Class / Hardware Type: Cat, RrhEvent Type: equipmentAlarmProbable Cause: LinkFailureSeverity: minor



201024 - Bad signal quality of all DRIF interfaces detected


Error Description

The addressed CAT/RRH module detected that the signal quality on all DRIF will not en-sure a reliable data transmission. After an unsuccessful automatic recovery (card reset),the CAT/RRH was put out of service. The states of the CAT/RRH (operational state,availability status, and alarm status) changed accordingly.


The failure can be caused by one of the following:• Failure to receive an expected response to a CORBA request within specified time

limits• Indications of a connection failure from the communication stack, for example point-

to-point protocol (PPP), internet protocol (IP), high level data link control protocol(HDLC), etc.

Troubleshooting



Managed Object Class / Hardware Type: Cat, RrhEvent Type: equipmentAlarmProbable Cause: LinkFailureSeverity: major (final), handled according to the



OML:Node B (RC)


201025 - PID could not be read or is corrupted


Error Description

A hardware error has occurred! The PID of the addressed LRU could not be read or iscorrupted. Basic operation of the affected LRU is not possible.

The information contained in the PID is essential for the operation of the LRU. There-fore, the reporting LRU will fail.


Report this error to customer service. The PID of the failed LRU has to be updated.

Troubleshooting


Managed Object Class / Hardware Type: *Event Type: equipmentAlarmProbable Cause: EquipmentFailureSeverity: major (final), handled according to the




201026 - LRU sent illegal parameter


Error Description

The following fatal software error has occurred: the addressed LRU sent an illegal pa-rameter.

After an unsuccessful automatic recovery by means of a reset, the reporting LRU wasput of of service.

As a result of this failure, cells or calls could potentially be lost. Furthermore, the statesof all affected managed objects change accordingly.

As a matter of principle, this error should always be reported to customer service.

Manual recovery can be applied by an operator-triggered reset of the addressed cardfrom the RC.

Troubleshooting


1. Reset the addressed card.2. If the manual reset has not helped to cease the alarm, check the hardware compat-

ibility of the configuration.3. If the measures taken above have not been successful, contact the technical assis-

tance center (TAC) to get support in isolating the fault. For suitable preparation savethe error symptoms as described in "Collect Info for Assistance". Log files need tobe analyzed and specific measures must be taken which are out of the operator’sscope.

Managed Object Class / Hardware Type: *Event Type: processingErrorAlarmProbable Cause: InvalidParameterSeverity: major (final), handled according to the



OML:Node B (RC)


201027 - LRU could not process a message from CC con-taining data from DB


Error Description

A fatal error has occurred: the reporting LRU could not process a message from the corecontroller (CC) containing data from the Node B’s database (DB).

This alarm may be caused by one of the following:• Wrong database• A database attribute which has been changed via the Itf-B from the RC.

As a consequence of this failure, service may be affected.

The database should be verified. Manual recovery could be applied by an operator-trig-gered reset of the reporting card from the RC.

Troubleshooting

The following measures must be taken in the given order to solve this error:

1. Reset the reporting object by means of the following procedure:– Lock the object. Use the ’NodeB Sum’ panel or, alternatively, apply the lock com-

mand to the object.– Reset the object. Use the ’NodeB Sum’ panel or, alternatively, apply the rst com-

mand to the reporting MOI.2. Check the Node B’s database and adapt the database accordingly. Software load

and database must base on the same InfoModel which is also the basis for the Com-mand Manual CML:Node B.To check the database version installed, take the following steps:– Open the ’NodeB Sum’ panel.– Click the Network Management button in the Application Launcher to open the


3. If the manual reset has not helped to cease the alarm, further repair actions must beachieved on site. Proceed according to the Output Manual OML:Node B.


Managed Object Class / Hardware Type: Ch, Rep, Trx, Dric, Cat, RrhEvent Type: processingErrorAlarmProbable Cause: InvalidParameterSeverity: major



201028 - HW-failure clock processing


Error Description

A fatal hardware (HW) error has occurred. This error is caused by a fatal HW failure ofthe active core controller’s (CC) clock processing unit. This failure may lead to impactson the air interface’s synchronization.

If the clock processing failure occurs simultaneously with the 202506 - Node B SystemClock in Holdover Mode alarm, stable Node B operation may not be possible any longer.

As a consequence, cells or calls could be lost. The states (operational state and avail-ability status) of all affected managed objects change accordingly.

The card should be replaced. Furthermore, manual recovery could be applied by an op-erator-triggered reset of the CC from the RC. If a standby CC is installed, a switch overto this CC can be initiated, too.

Troubleshooting

Perform the following steps in the given order to solve this alarm:

1. Reset the defective core controller. Use the ’NodeB Sum’ panel or, alternatively, ap-ply the rst command to the reporting MOI.

2. If a standby CC is installed, perform a switch over from the defective active CC to thestandby CC. Use the ’NodeB Sum’ panel or, alternatively, apply the reduSwtchcommand to the active CC.

3. If the above measures could not solve this error, further repair actions must beachieved on site. Proceed according to the Output Manual OML:Node B.


Managed Object Class / Hardware Type: NodeBFddEEvent Type: equipmentAlarmProbable Cause: EquipmentMalfunctionSeverity: major


OML:Node B (RC)


201029 - MEF blocked


Error Description

The membrane filter (MEF) is polluted. Therefore, the MEF’s lifetime will run out.

The 200920 - High temperature of PA alarm has been output before. This alarm indi-cates a high temperature scenario in at least one PA installed in the Node B.

The MEF has to be exchanged within the next 2 weeks.

A further increase of the MEF’s pollution may lead to a severe defect. A heavily pollutedMEF can cause the following alarms:• 200921 - Over temperature of PA• 200986 - Temperature out of range in upper direction• 200995 - High Temperature Limit (Ht3) reached• 200996 - Critical Temperature Limit (Ht4) reached• 201035 - MEF completely blocked

Troubleshooting


Managed Object Class / Hardware Type: BaseRackEvent Type: equipmentAlarmProbable Cause: EquipmentMalfunctionSeverity: minor



201030 - Invalid hardware capacity licensing value


Error Description

The hardware capacity licensing value read from the reporting card is invalid.

Troubleshooting


Further repair actions must be achievd on site. Proceed according to the Output ManualOML:Node B.

Managed Object Class / Hardware Type: Cc, Ch, DricEvent Type: processingErrorAlarmProbable Cause: CorruptDataSeverity: warning


OML:Node B (RC)


201031 - Wrong combination of licensed cards


Error Description

The combination of hardware capacity licensing values is invalid. This error might becaused by using more cards that carry a restricted license than supported by the licens-ing terms and conditions.

Troubleshooting

Perform the following steps in the given order to solve this error:

1. Check the hardware compatibility of the configuration.2. If the first step could not clear the fault, contact the technical assistance center (TAC)

to get support in isolating the fault. For suitable preparation save the error symptomsas described in "Collect Info for Assistance". Log files need to be analyzed and spe-cific measures must be taken which are out of the operator’s scope.

Managed Object Class / Hardware Type: NodeBFddEEvent Type: processingErrorAlarmProbable Cause: ConfigurationOrCustomizationErrorSeverity: minor



201032 - Not all cells are licensed


Error Description

The contracted hardware capacity licenses for UTRAN cells do not cover all cells con-figured in the Node B’s database. Those cells which are not licensed remain disabledafter Node B’s start-up.

Troubleshooting

Carrying out the following steps in the given order will help to solve this alarm:

1. Check the compatibility of the current configuration.2. Check the Node B database.3. Change the Node B’s DB in such a way that only the licensed number of UTRAN

cells is configured.


Managed Object Class / Hardware Type: NodeBFddEEvent Type: processingErrorAlarmProbable Cause: ConfigurationOrCustomizationErrorSeverity: minor


OML:Node B (RC)


201033 - PID could not be read or is corrupted - non-fatal


Error Description

A hardware error has occurred! The PID of the addressed LRU could not be read or iscorrupted. Basic operation of the affected LRU is possible without the information con-tained in the PID.

Service is not affected.

Report this error to customer service. The PID of the failed LRU has to be updated.

Troubleshooting


Managed Object Class / Hardware Type: *Event Type: equipmentAlarmProbable Cause: EquipmentFailureSeverity: minor



201034 - Booster’s Fan unit failed


Error Description

The fan unit of the reporting booster is defective. This situation leads to a lack of air cir-culation in the affected Node B. A failure of components which are sensitive to heat mayexist.

Caused by the insufficient air circulation in the Node B, related temperature alarms maybe reported by the addressed booster. The following alarms may therefore occur in con-junction with the ’201034 - Booster’s Fan unit failed’ alarm:• 200920 - High temperature of PA• 200921 - Over temperature of PA

Troubleshooting


Managed Object Class / Hardware Type: BoosterEvent Type: environmentalAlarmProbable Cause: FanFailureSeverity: major


OML:Node B (RC)


201035 - MEF completely blocked


Error Description

The membrane filter (MEF) is heavily polluted. Therefore, the MEF’s lifetime has run out.

The 200921 - Over temperature of PA alarm has been output before. This alarm indi-cates an over temperature scenario in at least one PA installed in the Node B.

Exchange the defective MEF immediately. Otherwise a severe hardware damage canoccur.

A defective MEF can cause the following alarms:• 200986 - Temperature out of range in upper direction• 200995 - High Temperature Limit (Ht3) reached• 200996 - Critical Temperature Limit (Ht4) reached

Troubleshooting

Repair actions must be achieved on site immediately. Proceed according to the OutputManual OML:Node B.

Managed Object Class / Hardware Type: BaseRackEvent Type: equipmentAlarmProbable Cause: EquipmentMalfunctionSeverity: critical



201036 - RRHs unable to establish communication linkswith the expected number of PSRs.


Error Description

Remote radio heads (RRHs) of the reporting Node B cannot establish communicationlinks with the expected number of power supplies for the RRHs (PSRs).

The problem indicated by this alarm may occur in either of the following situations:• After Node B startup, not all configured PSRs managed to establish a communica-

tion link with a connected RRH within a specified period of time.Besides RRH and PSR hardware defects and wrong cable connections, this alarmcan occur when the number of PSRs configured in the system is wrong.

• After breakdown of a communication link, a PSR failed to reconnect itself to an RRHwithin a specified period of time.The breakdown of a communication link may be caused by the following:– RRH or PSR hardware defect– Broken cable connection– Preceding reset of the related RRH

If no communication link between RRH and PSR exists, no PSR alarms can be reportedby the Node B.

Troubleshooting


Managed Object Class / Hardware Type: NodeBFddEEvent Type: equipmentAlarmProbable Cause: EquipmentFailureSeverity: minor


OML:Node B (RC)


201037 - RET unspecified error


Error Description

An unspecified error occurred in the reporting RET module. Due to this error, the ad-dressed RET module is disabled.

Troubleshooting





201038 - Resource conflict between CP and OAM


Error Description

The CP rejected a request of the RNC, such as a radio link setup request, because thenecessary resources are currently allocated by OAM, for instance channels for orthog-onal channel noise simulator (OCNS). These resources may be channelization codes orcode trees occupied by DLLG or OCNS, issued by the staModSTx command.

The required resources have to be freed, releasing the OCNS channels, for example,before the RNC’s request can be processed.

This alarm is cleared as soon as all DLLG and OCNS channels are stopped on the af-fected cell.

Troubleshooting

To solve this problem, free the occupied resources of the reporting cell (LocalCellEMOI) by completely stopping the DLLG or OCNS channels. Use the ’NodeB Sum’ panelor apply the endModSTx command to the CHC the occupied resources are assigned to.

This will clear the alarm and free the resources allocated by OAM. RNC requests cannow be serviced again.

To avoid such collisions in the future, an adjustment of the channelization codes usedfor OCNS may be necessary.


Managed Object Class / Hardware Type: LocalCellEEvent Type: processingErrorAlarmProbable Cause: UnderlyingResourceUnavailableSeverity: minor


OML:Node B (RC)


201039 - Inconsistency between hardware license andconfiguration


Error Description

The hardware capacity license of the reporting LRU is not consistent with the currentconfiguration. This error may be caused by using an LRU equipped with an insufficientlicense.

As a result, the addressed LRU is put out of service. Additionally, all cells related to thisLRU remain disabled after startup.

Troubleshooting

To solve this error, perform the following steps in the order provided:

1. Check the hardware compatibility of the Node B.2. Update the addressed LRU’s hardware capacity to the required value.

Proceed according to the FD012258 - Activation of Hardware Functionality inNode B.

3. If the first steps could not clear the fault, contact the technical assistance center(TAC) to get support in isolating the fault. For suitable preparation save the errorsymptoms as described in "Collect Info for Assistance". Log files need to be ana-lyzed and specific measures must be taken which are out of the operator’s scope.

Managed Object Class / Hardware Type: CatEvent Type: processingErrorAlarmProbable Cause: ConfigurationOrCustomizationErrorSeverity: major



201040 - Wrong cabling of LRU detected


Error Description

The reporting LRU was not cabled correctly according to the installation manual of theNode B. As a result, the addressed LRU has been put out of service. All cells related tothis LRU remain disabled.

Troubleshooting


Managed Object Class / Hardware Type: CatEvent Type: processingErrorAlarmProbable Cause: ConfigurationOrCustomizationErrorSeverity: major


OML:Node B (RC)


201916 - Toggling condition detected for alarm “AIS”, SPID 202059


Error Description

An alarm toggling condition has been detected for the 202059 - Alarm Indication Signalon Physical Link alarm.

Troubleshooting

No action is required to cease this alarm.

Managed Object Class / Hardware Type: E1TTP, J1TTPEvent Type: communicationAlarmProbable Cause: VendorSpecificSeverity: minor



201917 - Toggling condition detected for alarm “RAI”, SPID 202060


Error Description

An alarm toggling condition has been detected for the 202060 - Remote Alarm Indicationon Physical Link alarm.

Troubleshooting


Managed Object Class / Hardware Type: E1TTP, J1TTPEvent Type: communicationAlarmProbable Cause: VendorSpecificSeverity: minor


OML:Node B (RC)


201918 - Toggling condition detected for alarm “lineAIS”,SP ID 202062


Error Description

An alarm toggling condition has been detected for the 202062 - Line Alarm IndicationSignal Indication on STM1 Physical Link alarm.

Troubleshooting


Managed Object Class / Hardware Type: Stm1TPEvent Type: communicationAlarmProbable Cause: VendorSpecificSeverity: minor



201919 - Toggling condition detected for alarm “lineRDI”,SP ID 202063


Error Description

An alarm toggling condition has been detected for the 202063 - Line Remote Defect In-dication on STM1 Physical Link alarm.

Troubleshooting




OML:Node B (RC)


201920 - Toggling condition detected for alarm “pathAIS”,SP ID 202065


Error Description

An alarm toggling condition has been detected for the 202065 - Path Alarm IndicationSignal on STM1 Physical Link alarm.

Troubleshooting





201921 - Toggling condition detected for alarm “pathRDI”,SP ID 202066


Error Description

An alarm toggling condition has been detected for the 202066 - Path Remote Defect In-dication on STM1 Physical Link alarm.

Troubleshooting




OML:Node B (RC)


201922 - Toggling condition detected for alarm “vcAIS”,SP ID 202072


Error Description

An alarm toggling condition has been detected for the 202072 - Alarm Indication Signalon an ATM VC alarm.

Troubleshooting


Managed Object Class / Hardware Type: VcTTPEvent Type: communicationAlarmProbable Cause: VendorSpecificSeverity: minor



201923 - Toggling condition detected for alarm “vcRDI”,SP ID 202073


Error Description

An alarm toggling condition has been detected for the 202073 - Remote Defect Indica-tion on an ATM VC alarm.

Troubleshooting


Managed Object Class / Hardware Type: VcTTPEvent Type: communicationAlarmProbable Cause: VendorSpecificSeverity: minor


OML:Node B (RC)


201924 - Toggling condition detected for alarm “vpAIS”,SP ID 202075


Error Description

An alarm toggling condition has been detected for the 202075 - Alarm Indication Signalon an ATM VP alarm.

Troubleshooting


Managed Object Class / Hardware Type: VpTTPEvent Type: communicationAlarmProbable Cause: VendorSpecificSeverity: minor



201925 - Toggling condition detected for alarm “vpRDI”,SP ID 202076


Error Description

An alarm toggling condition has been detected for the 202076 - Remote Defect Indica-tion on an ATM VP alarm.

Troubleshooting


Managed Object Class / Hardware Type: VpTTPEvent Type: communicationAlarmProbable Cause: VendorSpecificSeverity: minor


OML:Node B (RC)


201926 - Toggling condition detected for alarm “LOC”, SPID 202097


Error Description

An alarm toggling condition has been detected for the 202097 - Loss of Continuity de-tected on an ATM VP alarm.

Troubleshooting


Managed Object Class / Hardware Type: ContinuityMonitorEvent Type: communicationAlarmProbable Cause: VendorSpecificSeverity: minor



202006 - A bbUsageRatio Quality of Service alarm has oc-curred


Error Description

A bbUsageRatio threshold crossing alarm has been raised. (only used in UMR2.0Drop 1)

Troubleshooting


Managed Object Class / Hardware Type: NodeBFddEEvent Type: qualityOfServiceAlarmProbable Cause: ThresholdCrossedSeverity: indeterminate


OML:Node B (RC)


202007 - A scanner could not be initialized


Error Description

The addressed scanner could not be initialized. The additional text will give the reason(e.g. too many scanners, invalid parameters). If the problem is a misconfiguration, thescanner will be created but will be disabled. Lock the scanner, fix the configuration, thenunlock to clear the error.

Troubleshooting

1. Lock the relevant scanner. Use the lock command in order to set the administrativestate of the relevant scanner to locked.

2. Fix the configuration.3. Set the administrative state of the addressed scanner to unlocked in order to clear

the error. Use the unlock command.


Managed Object Class / Hardware Type: Scanner, ScannerHsdpaEvent Type: processingErrorAlarmProbable Cause: ConfigurationOrCustomizationErrorSeverity: minor



202008 - The temporary measurement results could not bestored


Error Description

The internal temporary measurement results could not be stored. The reporting scannerwill no longer perform any measurements and will be set to disabled . The Node B mayneed to be reset before measurements can be restarted correctly.

Troubleshooting








Managed Object Class / Hardware Type: Scanner, ScannerHsdpaEvent Type: processingErrorAlarmProbable Cause: FileErrorSeverity: minor


OML:Node B (RC)


202009 - Unable to request measurement results


Error Description

One or more of the measurement results for the addressed scanner could not be re-quested. These measurements will be marked as suspect for the current granularity pe-riod. The scanner will try to request these measurements again at the end of the nextgranularity period. If the next request for reports is successful, the fault will automaticallybe cleared.

Troubleshooting


Managed Object Class / Hardware Type: Scanner, ScannerHsdpaEvent Type: processingErrorAlarmProbable Cause: SystemCallUnsuccessfulSeverity: minor



202010 - The ScanCo could not be initialized


Error Description

A ScanCo could not be created. The additional text will give the reason for the failure.As a consequence, performance measurements will not be started on the relevantNode B.

Troubleshooting


Managed Object Class / Hardware Type: ScanCoEvent Type: processingErrorAlarmProbable Cause: ConfigurationOrCustomizationErrorSeverity: minor


OML:Node B (RC)


202011 - The final results files could not be generated


Error Description

The temporary measurement results of the reporting ScanCo could not be convertedinto a final results files.

This failure will have the following impacts:• The upload in progress will be aborted.• Some measurement files will be lost.• A Node B reset may be required before further upload attempts will be successful.

Troubleshooting

Reset the associated Node B. Use the ’NodeB Sum’ panel or, alternatively, apply therst command to the relevant N2NBFDDE managed object.


Managed Object Class / Hardware Type: ScanCoEvent Type: processingErrorAlarmProbable Cause: FileErrorSeverity: minor



202012 - The first bbUsageRatio Quality of Service alarmhas occurred


Error Description

The first bbUsageRatio threshold-crossing alarm was raised (used from UMR2.0 Drop 2onwards). This is a QoS alarm which was not generated by any HW or SW error.

The operator can set four thresholds of any percentage for bbUsageRatio: notifyhigh 1/2 and notify low 1/2 which raise and clear the related alarms (202012 - The firstbbUsageRatio Quality of Service alarm has occurred / 202013 - The second bbUsageR-atio Quality of Service alarm has occurred), respectively, when crossed. Furthermore,the operator can determine an alarm severity for each of the relevant QoS alarms. Allvalues are related to call-processing resources of the Node B.

If many subscribers within one UTRAN cell use their UEs at the same time, a shortageof hardware resources in this cell may occur as a consequence and this alarm will beoutput.

Troubleshooting

Re-consider the current network design. If possible, modify the configuration of the ad-jacent cells so that the same area of this cell is covered by several Node Bs. This mayhelp to solve the lack of resources without a system crash.


As soon as this QoS alarm is ceased, relevant threshold information will be displayed.



OML:Node B (RC)


202013 - The second bbUsageRatio Quality of Servicealarm has occurred


Error Description

The second bbUsageRatio threshold-crossing alarm was raised (used from UMR 2.0Drop 2 onwards). This is a QoS alarm which was not generated by any HW or SW error.

The operator can set four thresholds of any percentage for bbUsageRatio: notifyhigh 1/2 and notify low 1/2 which raise and clear the related alarms (202012 - The firstbbUsageRatio Quality of Service alarm has occurred / 202013 - The second bbUsageR-atio Quality of Service alarm has occurred), respectively, when crossed. Furthermore,the operator can determine an alarm severity for each of the relevant QoS alarms. Allvalues are related to call-processing resources of the Node B.


Troubleshooting

Re-consider the current network design. If possible, modify the configuration of the ad-jacent adjacent cells so that the same area of this cell is covered by several Node Bs.This may help to solve the lack of resources without a system crash.






202014 - The first sccpchUsageRatio Quality of Servicealarm has occurred


Error Description

The first sccpchUsageRatio threshold-crossing alarm was raised. This is a QoS alarmwhich was not generated by any HW or SW error.

The operator can set four thresholds of any percentage for sccpchUsageRatio: notifyhigh 1/2 and notify low 1/2 which raise and clear the related alarms (202014 - The firstsccpchUsageRatio Quality of Service alarm has occurred / 202015 - The second sccp-chUsageRatio Quality of Service alarm has occurred), respectively, when crossed.Fur-thermore, the operator can determine an alarm severity for each of the relevant QoSalarms. All values are related to call-processing resources of the Node B.


Troubleshooting




Managed Object Class / Hardware Type: LocalCellEEvent Type: qualityOfServiceAlarmProbable Cause: ThresholdCrossedSeverity: indeterminate


OML:Node B (RC)


202015 - The second sccpchUsageRatio Quality of Servicealarm has occurred


Error Description

The second sccpchUsageRatio threshold-crossing alarm was raised. This is a QoSalarm which was not generated by any HW or SW error.

The operator can set four thresholds of any percentage for sccpchUsageRatio: notifyhigh 1/2 and notify low 1/2 which raise and clear the related alarms (202014 - The firstsccpchUsageRatio Quality of Service alarm has occurred / 202015 - The second sccp-chUsageRatio Quality of Service alarm has occurred), respectively, when crossed.Fur-thermore, the operator can determine an alarm severity for each of the relevant QoSalarms. All values are related to call-processing resources of the Node B.

If many subscribers within one UTRAN cell use their UEs at the same time, a shortageof hardware resources in this cell may be the consequence and this alarm will be output.

Troubleshooting







202016 - The first prachUsageRatio Quality of Servicealarm has occurred


Error Description

The first prachUsageRatio threshold-crossing alarm was raised. This is a QoS alarmwhich was not generated by any HW or SW error.

The operator can set four thresholds of any percentage for prachUsageRatio: notifyhigh 1/2 and notify low 1/2 which raise and clear the related alarms (202016 - The firstprachUsageRatio Quality of Service alarm has occurred / 202017 - The second pra-chUsageRatio Quality of Service alarm has occurred), respectively, when crossed. Fur-thermore, the operator can determine an alarm severity for each of the relevant QoSalarms. All values are related to call-processing resources of the Node B.


Troubleshooting






OML:Node B (RC)


202017 - The second prachUsageRatio Quality of Servicealarm has occurred


Error Description

The second prachUsageRatio threshold-crossing alarm was raised. This is a QoS alarmwhich was not generated by any HW or SW error.

The operator can set four thresholds of any percentage for prachUsageRatio: notifyhigh 1/2 and notify low 1/2 which raise and clear the related alarms (202016 - The firstprachUsageRatio Quality of Service alarm has occurred / 202017 - The second pra-chUsageRatio Quality of Service alarm has occurred), respectively, when crossed. Fur-thermore, the operator can determine an alarm severity for each of the relevant QoSalarms. All values are related to call-processing resources of the Node B.


Troubleshooting

Re-consider the current networ design. If possible, modify the configuration of the adja-cent cells so that the same area of this cell is covered by several Node Bs. This mayhelp to solve the lack of resources without a system crash.






202018 - The first cpUsageRatio Quality of Service alarmhas occurred


Error Description

The first cpUsageRatio threshold-crossing alarm was raised. This is a QoS alarm whichwas not generated by any HW or SW error.

The operator can set four thresholds of any percentage for cpUsageRatio: notifyhigh 1/2 and notify low 1/2 which raise and clear the related alarms (202018 - The firstcpUsageRatio Quality of Service alarm has occurred / 202019 - The second cpUsageR-atio Quality of Service alarm has occurred), respectively, when crossed. Furthermore,the operator can determine an alarm severity for each of the relevant QoS alarms. Allvalues are related to call-processing resources of the Node B.


Troubleshooting

Re-consider the current networkdesign. If possible, modify the configuration of the ad-jacent cells so that the same area of this cell is covered by several Node Bs. This mayhelp to solve the lack of resources without a system crash.





OML:Node B (RC)


202019 - The second cpUsageRatio Quality of Servicealarm has occurred


Error Description

The second cpUsageRatio threshold-crossing alarm was raised. This is a QoS alarmwhich was not generated by any HW or SW error.

The operator can set four thresholds of any percentage for cpUsageRatio: notifyhigh 1/2 and notify low 1/2 which raise and clear the related alarms (202018 - The firstcpUsageRatio Quality of Service alarm has occurred / 202019 - The second cpUsageR-atio Quality of Service alarm has occurred), respectively, when crossed. Furthermore,the operator can determine an alarm severity for each of the relevant QoS alarms. Allvalues are related to call-processing resources of the Node B.


Troubleshooting







202020 - The first prachCrciFailures Quality of Servicealarm has occurred


Error Description

The first prachCrciFailures threshold-crossing alarm was raised. This is a QoS alarmwhich was not generated by any HW or SW error.

The operator can set four thresholds of any percentage for cpUsageRatio: notifyhigh 1/2 and notify low 1/2 which raise and clear the related alarms (202020 - The firstprachCrciFailures Quality of Service alarm has occurred / 202021 - The second prach-CrciFailures Quality of Service alarm has occurred), respectively, when crossed. Fur-thermore, the operator can determine an alarm severity for each of the relevant QoSalarms. All values are related to call-processing resources of the Node B.

If many subscribers within one UTRAN cell use their UEs at the same time, a shortageof HW resources in this cell may occur as a consequence and this alarm will be output.

Troubleshooting






OML:Node B (RC)


202021 - The second prachCrciFailures Quality of Servicealarm has occurred


Error Description

The second prachCrciFailures threshold-crossing alarm was raised. This is a QoS alarmwhich was not generated by any HW or SW error.

The operator can set four thresholds of any percentage for cpUsageRatio: notifyhigh 1/2 and notify low 1/2 which raise and clear the related alarms (202020 - The firstprachCrciFailures Quality of Service alarm has occurred / 202021 - The second prach-CrciFailures Quality of Service alarm has occurred), respectively, when crossed. Fur-thermore, the operator can determine an alarm severity for each of the relevant QoSalarms. All values are related to call-processing resources of the Node B.

If many subscribers within one UTRAN cell use their UEs at the same time, a shortageof HW resources in this cell may occur as a consequence and this alarm will be output.

Troubleshooting

Re-consider the current network design. If possible, modify the configuration of the ad-jacent cells so that the same area of this cell is covered by several Node Bs. This mayhelp to solve the lack of resources without any system crash.






202056 - Loss Of Signal on Physical Link


Error Description

Loss of signal (LOS) indication has been received on a physical link E1, J1, T1 or STM-1(according to reported MOC in the failure event report). This indicates that the signalfrom the next device upstream is not present. This may be due to misconfiguration ofthe hardware at either end, faulty hardware at either end or due to a break in the trans-mission medium between the two ends.

The following subsequent alarms may also be initiated:• 202057 - Loss Of Frame on Physical Link• 202058 - Loss Of Cell Delineation on Physical Link• 202059 - Alarm Indication Signal on Physical Link• 202060 - Remote Alarm Indication on Physical Link• 202062 - Line Alarm Indication Signal Indication on STM1 Physical Link• 202063 - Line Remote Defect Indication on STM1 Physical Link• 202065 - Path Alarm Indication Signal on STM1 Physical Link• 202072 - Alarm Indication Signal on an ATM VC• 202075 - Alarm Indication Signal on an ATM VP

Troubleshooting

Usually the Node B is connected to the RNC or each other (Iub interface) via Link Equip-ment (LE) and in some rare cases by direct lines. Having a direct line the other end isalso in the scope of the RC and can be analyzed for fault location. If LE is involved theoperation and management system of this network has to be used for getting informa-tion about the state and status of the relevant network element (NE).

Depending on the applied configuration of the Node Bs like star, hub, cascade or loopnot only the reported Node B of this error message is affected but also subordinatedNode Bs.• Star configuration

Only the reported Node B• Hub configuration

If the hub Node B is the reporting one for a connection to the RNC:– For E1/J1/T1: the supplied Node B of the relevant E1/J1/T1 link will report AIS– For STM-1/OC-3: all supplied Node Bs will report AIS

• Cascade configurationAll Node Bs in the chain downstream the LOS reporting Node B will initial an AIS er-ror message for the relevant E1/J1/T1 link respectively all if the first Node B is re-porting and connected to the RNC via STM-1/OC-3.

• Loop configurationThe redundant path in the loop configuration will take over the traffic

Managed Object Class / Hardware Type: E1TTP, J1TTP, Stm1TPEvent Type: communicationAlarmProbable Cause: LossOfSignalSeverity: major


OML:Node B (RC)


To isolate the fault check for other error messages in the following order:

1. Is there also an equipment alarm of the Core Controller (CC) in the reporting Node Bpresent?

Using the Network Management Application:– Choose the icon “Network Management” in the Application Launcher window

(left-click).– Choose the icon “Node B” (right-click -> Navigate To Panel).– Choose the Node B in question from the list (right-click -> Navigate To Panel).– Right-click on the addressed CC on GUI to open the context sensitive menu.– Select Fault Management -> seeActiveAlarms.

Using the Alarm Monitoring Application:– Choose the icon “Alarm Monitoring” in the Application Launcher window (left-

click).– Look for an alarm of the CC in the reporting Node BIf an equipment alarm of the CC is present try to fix this fault first which probably alsoeliminates the LOS alarm.

2. Is there an equipment alarm for the upstream NE (RNC, Node B or LE) reportedwhich is connected to the relevant port?– For RNC and Node B proceed as described above accordingly– For LE the appropriate operation and management system has to be usedIf an equipment alarm is present try to fix this fault first which probably also elimi-nates the LOS alarm.

3. What communication alarm shows the upstream NE?– For AIS indication it can be assumed that the line in downstream direction is bro-

ken but in upstream direction OK– LOS indication means a break in the transmission medium in both directionsFor further investigation, a visit on site is necessary to find the cause for the inter-ruption by inspecting lines and termination equipment. Refer to the Output ManualOML:Node B.

Configuration mismatch?

Is the configuration of the relevant ports at either end in accordance with each other?• For RNC and Node B use the Network Management Application of the RC• For LE the appropriate operation and management system has to be used

If the misconfiguration can be identified as probable cause for the error report the align-ment of the settings should clear the fault.




202057 - Loss Of Frame on Physical Link


Error Description

Loss of frame (LOF) indication has been received on a physical link E1, J1, T1 or STM-1/OC-3 (according to reported MOC in the failure event report).

Independent of the mode of CRC operation, this alarm indicates one of the following:• Basic frame synchronization has been lost on the transport interface between the

Node B and the next device upstream.This may be due to misconfiguration of the hardware at either end, faulty hardwareat either end or problems on the transmission medium between the two ends.

• Although both frame alignment is active and the reporting line is running, a greatnumber of CRC-4 errors occurred.

The following subsequent alarms may also be initiated:• 202058 - Loss Of Cell Delineation on Physical Link• 202059 - Alarm Indication Signal on Physical Link• 202060 - Remote Alarm Indication on Physical Link• 202062 - Line Alarm Indication Signal Indication on STM1 Physical Link• 202063 - Line Remote Defect Indication on STM1 Physical Link• 202065 - Path Alarm Indication Signal on STM1 Physical Link• 202072 - Alarm Indication Signal on an ATM VC• 202075 - Alarm Indication Signal on an ATM VP

Troubleshooting

Usually the Node B is connected to the RNC or each other (Iub interface) via Link Equip-ment (LE) and in some rare cases by direct lines. Having a direct line the other end isalso in the scope of the RC and can be analyzed for fault location. If LE is involved theoperation and management system of this network has to be used for getting informa-tion about the state and status of the relevant network element (NE).

Depending on the applied configuration of the Node Bs like star, hub, cascade or loopnot only the reported Node B of this error message is affected but also subordinatedNode Bs.• Star configuration

Only the reported Node B• Hub configuration

If the hub Node B is the reporting one for a connection to the RNC:– For E1/J1/T1: the supplied Node B of the relevant E1/J1/T1 link will report AIS– For STM-1/OC-3: all supplied Node Bs will report AIS

• Cascade configurationAll Node Bs in the chain downstream the LOF reporting Node B will initial an AIS er-ror message for the relevant E1/J1/T1 link respectively all if the first Node B is re-porting and connected to the RNC via STM-1/OC-3.

• Loop configurationThe redundant path in the loop configuration will take over the traffic

Managed Object Class / Hardware Type: E1TTP, J1TTP, Stm1TPEvent Type: communicationAlarmProbable Cause: LossOfFrameSeverity: major


OML:Node B (RC)


To isolate the fault check for other error messages in the following order:





click).– Look for an alarm of the CC in the reporting Node BIf an equipment alarm of the CC is present try to fix this fault first which probably alsoeliminates the LOF alarm.

2. Is there an equipment alarm for the upstream NE (RNC, Node B or LE) reportedwhich is connected to the relevant port?– For RNC and Node B proceed as described above accordingly– For LE the appropriate operation and management system has to be usedIf an equipment alarm is present try to fix this fault first which probably also elimi-nates the LOF alarm.

Configuration mismatch:



On site inspection:

For further investigation, a visit on site is necessary to find the cause for the problem onthe transmission medium by inspecting lines and termination equipment. Refer to theOutput Manual OML:Node B.




202058 - Loss Of Cell Delineation on Physical Link


Error Description

Loss of cell delineation (LCD) indication has been received on a physical link E1, J1, T1or STM-1/OC-3 (according to reported MOC in the failure event report). This indicatesthat ATM cells are not being delineated correctly and so cannot be extracted from thereceived signal. This may be due to faulty hardware at either end or problems on thetransmission medium between the two ends.

The following subsequent alarms may also be initiated:• 202072 - Alarm Indication Signal on an ATM VC• 202075 - Alarm Indication Signal on an ATM VP

Troubleshooting





click).– Look for an alarm of the CC in the reporting Node BIf an equipment alarm of the CC is present try to fix this fault first which probably alsoeliminates the LCD alarm.

2. Is there an equipment alarm for the upstream NE (RNC, Node B or LE) reportedwhich is connected to the relevant port?– For RNC and Node B proceed as described above accordingly– For LE the appropriate operation and management system has to be usedIf an equipment alarm is present try to fix this fault first which probably also elimi-nates the LCD alarm.

3. On site inspection:For further investigation, a visit on site is necessary to find the cause for the problemon the transmission medium by inspecting lines and termination equipment. Referto the Output Manual OML:Node B.


Managed Object Class / Hardware Type: E1TTP, J1TTP, Stm1TPEvent Type: communicationAlarmProbable Cause: LossOfCellDelineationSeverity: major


OML:Node B (RC)


202059 - Alarm Indication Signal on Physical Link


Error Description

Alarm indication signal (AIS) indication has been received on a physical link E1, J1, orT1 (according to reported MOC in the failure event report). Indicates that a problem hasbeen detected upstream from the Node B on the physical link reporting the alarm andtransmission to the Node B from that direction has probably been interrupted on this link.

This alarm is triggered by one of the following preceded alarms from an upstream NE inthe supervision of the RC:• 202056 - Loss Of Signal on Physical Link• 202057 - Loss Of Frame on Physical Link

or from Link Equipment (LE) in upstream direction:• Loss Of Signal (LOS)• Loss Of Frame (LOF)

The following subsequent alarms may also be initiated:• 202060 - Remote Alarm Indication on Physical Link• 202072 - Alarm Indication Signal on an ATM VC• 202075 - Alarm Indication Signal on an ATM VP

Troubleshooting

Because this error message is a consequence of a preceded alarm from an upstreamNE the troubleshooting has to start with investigation of the trigger alarm. Find the rele-vant alarm in the list of the Alarm Monitoring Application:

1. Choose the icon “Alarm Monitoring” in the Application Launcher window (left-click)2. Look for one of the alarms in the list below reported from an upstream NE

For troubleshooting instructions refer to:• 202056 - Loss Of Signal on Physical Link• 202057 - Loss Of Frame on Physical Link

LE caused alarms are handled accordingly.

After solving the problem which initiated the trigger alarm this error message will also becleared.

Managed Object Class / Hardware Type: E1TTP, J1TTPEvent Type: communicationAlarmProbable Cause: AlarmIndicationSignalSeverity: major



202060 - Remote Alarm Indication on Physical Link


Error Description

Remote alarm indication (RAI) indication has been received on a physical link E1, J1, orT1 (according to reported MOC in the failure event report). Indicates that a problem hasbeen detected downstream from the Node B on the physical link reporting the alarm andreception from the Node B in that direction has been probably interrupted on this link.This may be due to faulty hardware at either end or problems on the transmission me-dium between the two ends.

This alarm is triggered by one of the following preceded alarms from an downstream NEin the supervision of the RC:• 202056 - Loss Of Signal on Physical Link• 202057 - Loss Of Frame on Physical Link

or from Link Equipment (LE) in downstream direction:• Loss Of Signal (LOS)• Loss Of Frame (LOF)

The following subsequent alarms may also be initiated:• 202059 - Alarm Indication Signal on Physical Link• 202072 - Alarm Indication Signal on an ATM VC• 202075 - Alarm Indication Signal on an ATM VP

Troubleshooting

Because this error message is a consequence of a preceded alarm from an downstreamNE the troubleshooting has to start with investigation of the trigger alarm. Find the rele-vant alarm in the list of the Alarm Monitoring Application:

1. Choose the icon “Alarm Monitoring” in the Application Launcher window (left-click)2. Look for one of the alarms in the list below reported from an downstream NE

For troubleshooting instructions refer to:• 202056 - Loss Of Signal on Physical Link• 202057 - Loss Of Frame on Physical Link

LE-caused alarms are handled accordingly.


Managed Object Class / Hardware Type: E1TTP, J1TTPEvent Type: communicationAlarmProbable Cause: RemoteAlarmIndicationSeverity: major


OML:Node B (RC)


202061 - Loss of Multi Frame Alarm Indication on E1Physical Link


Error Description

Loss of multi frame alarm (LOMF) indication has been received on an E1 physical link.This indicates that multiframe synchronization has been lost on the E1 transport inter-face between the Node B and the next device upstream. This may be due to misconfig-uration of the hardware at either end, faulty hardware at either end or problems on thetransmission medium between the two ends.

The “202061 - Loss of Multi Frame Alarm Indication on E1 Physical Link” alarm may becaused by the following:

The Node B’s E1TTP managed object’s attribute “crcOperationMode“, which indicatesthe mode of CRC operation, is set to its default value crcForced whereas the frame for-mat for the RNC is set to “0” meaning that the CRC is disabled. Therefore, the E1TTP’sOST/AVS combination changes to disabled /failed .

If the “crcOperationMode“ is set to crcAutomatic , refer to the description of the 202098- CRC4 not used by FE reported on E1TTP alarm and follow the alarm’s troubleshooting.

Troubleshooting

Other error messages:





click).– Look for an alarm of the CC in the reporting Node BIf an equipment alarm of the CC is present try to fix this fault first which probably alsoeliminates the LOMF alarm.

2. Is there an equipment alarm for the upstream NE (RNC, Node B or LE) reportedwhich is connected to the relevant port?– For RNC and Node B proceed as described above accordingly– For LE the appropriate operation and management system has to be usedIf an equipment alarm is present try to fix this fault first which probably also elimi-nates the LOMF alarm.

Managed Object Class / Hardware Type: E1TTPEvent Type: communicationAlarmProbable Cause: LossOfMultiFrameSeverity: major



Configuration mismatch:



On site inspection:




OML:Node B (RC)


202062 - Line Alarm Indication Signal Indication on STM1Physical Link


Error Description

Line alarm indication signal (L-AIS) indication has been received on an STM-1/OC-3physical link. Indicates that a problem (e.g. LOS, LOF, LOP) has been detected up-stream from the Node B on the STM-1/OC-3 link reporting the alarm and transmissionto the Node B from that direction has probably been interrupted on this link.

This alarm is triggered by one of the following preceded alarms from an upstream NE inthe supervision of the RC:• 202056 - Loss Of Signal on Physical Link• 202057 - Loss Of Frame on Physical Link• 202064 - Path Loss of Pointer Indication on STM1 Physical Link

or from Link Equipment (LE) in upstream direction:• Loss Of Signal (LOS)• Loss Of Frame (LOF)• Loss Of Pointer (LOP)

The following subsequent alarms may also be initiated:• 202063 - Line Remote Defect Indication on STM1 Physical Link• 202065 - Path Alarm Indication Signal on STM1 Physical Link• 202072 - Alarm Indication Signal on an ATM VC• 202075 - Alarm Indication Signal on an ATM VP

Troubleshooting



For troubleshooting instructions refer to:• 202056 - Loss Of Signal on Physical Link• 202057 - Loss Of Frame on Physical Link• 202064 - Path Loss of Pointer Indication on STM1 Physical Link



Managed Object Class / Hardware Type: Stm1TPEvent Type: communicationAlarmProbable Cause: AlarmIndicationSignalSeverity: major



202063 - Line Remote Defect Indication on STM1 PhysicalLink


Error Description

Line remote defect indication (L-RDI) indication has been received on an STM-1/OC-3physical link. Indicates that a problem has been detected downstream from the Node Bon the STM-1/OC-3 link reporting the alarm and reception from the Node B in that direc-tion has been probably interrupted on this link. This may be due to faulty hardware ateither end or problems on the transmission medium between the two ends.

This alarm is triggered by one of the following preceded alarms from an downstream NEin the supervision of the RC:• 202056 - Loss Of Signal on Physical Link• 202057 - Loss Of Frame on Physical Link• 202064 - Path Loss of Pointer Indication on STM1 Physical Link• 202065 - Path Alarm Indication Signal on STM1 Physical Link

or from Link Equipment (LE) in downstream direction:• Loss Of Signal (LOS)• Loss Of Frame (LOF)• Loss Of Pointer (LOP)

The following subsequent alarms may also be initiated:• 202062 - Line Alarm Indication Signal Indication on STM1 Physical Link• 202072 - Alarm Indication Signal on an ATM VC• 202075 - Alarm Indication Signal on an ATM VP

Troubleshooting



For troubleshooting instructions refer to:• 202056 - Loss Of Signal on Physical Link• 202057 - Loss Of Frame on Physical Link• 202064 - Path Loss of Pointer Indication on STM1 Physical Link• 202065 - Path Alarm Indication Signal on STM1 Physical Link



Managed Object Class / Hardware Type: Stm1TPEvent Type: communicationAlarmProbable Cause: RemoteAlarmIndicatorSeverity: major


OML:Node B (RC)


202064 - Path Loss of Pointer Indication on STM1 PhysicalLink


Error Description

Path loss of pointer (P-LOP) indication has been received on an STM-1/OC-3 physicallink. The pointer enables the STM-1/OC-3 device on the Node B to locate the payloadwithin the signal. If the Node B STM-1/OC-3 interface has received an invalid path point-er, it will declare a loss of pointer condition. Because the STM-1/OC-3 interface cannotdetermine where the payload starts, all downstream traffic will be lost as long as the con-dition persists. This may be due to faulty hardware at either end or problems on thetransmission medium between the two ends.

This alarm may trigger the following subsequent alarms:• 202065 - Path Alarm Indication Signal on STM1 Physical Link• 202066 - Path Remote Defect Indication on STM1 Physical Link

Troubleshooting






click).– Look for an alarm of the CC in the reporting Node BIf an equipment alarm of the CC is present try to fix this fault first which probably alsoeliminates the P-LOP alarm.

2. Is there an equipment alarm for the upstream NE (RNC, Node B or LE) reportedwhich is connected to the relevant port?– For RNC and Node B proceed as described above accordingly– For LE the appropriate operation and management system has to be usedIf an equipment alarm is present try to fix this fault first which probably also elimi-nates the P-LOP alarm.

On site inspection:

Managed Object Class / Hardware Type: Stm1TPEvent Type: communicationAlarmProbable Cause: LossOfPointerSeverity: major





OML:Node B (RC)


202065 - Path Alarm Indication Signal on STM1 PhysicalLink


Error Description

A Path Alarm Indication Signal (P-AIS) has been received on an STM-1/OC-3 physicallink.

The P-AIS indicates the following:• At least one of the following problems has been detected upstream from the Node B

on the STM-1/OC-3 link reporting this alarm:– Loss of Signal (LOS)– Loss of Frame (LOF)– Path Loss of Pointer (P-LOP)– Line Alarm Indication Signal (L-AIS)

• Transmission from upstream direction to the Node B has probably been interruptedon the reporting link.

The ’202065 - Path Alarm Indication Signal on STM1 Physical Link’ alarm is triggeredby one of the following preceded alarms reported by an upstream NE:• 202056 - Loss Of Signal on Physical Link• 202057 - Loss Of Frame on Physical Link• 202062 - Line Alarm Indication Signal Indication on STM1 Physical Link• 202064 - Path Loss of Pointer Indication on STM1 Physical Link• Or by LOS, LOF, P-LOP, or L-AIS from link equipment (LE) in upstream direction.

Furthermore, as a consequence of this alarm, the following alarms may be triggered:• 202063 - Line Remote Defect Indication on STM1 Physical Link• 202066 - Path Remote Defect Indication on STM1 Physical Link• 202072 - Alarm Indication Signal on an ATM VC• 202075 - Alarm Indication Signal on an ATM VP

Troubleshooting

Due to the fact that this error message is a consequence of a preceded alarm from anupstream NE, troubleshooting has to start with investigation of the trigger alarm(s). Findthe relevant trigger alarm in the Alarm Monitoring window of the RC:

1. Open the Alarm Monitoring window.2. Use the filter and sort function to concentrate on the following relevant alarms:

– 202056 - Loss Of Signal on Physical Link– 202057 - Loss Of Frame on Physical Link– 202062 - Line Alarm Indication Signal Indication on STM1 Physical Link– 202064 - Path Loss of Pointer Indication on STM1 Physical Link

3. Proceed according to the troubleshooting of the trigger alarm.

Alarms caused by LE are handled accordingly.

Managed Object Class / Hardware Type: Stm1TPEvent Type: communicationAlarmProbable Cause: AlarmIndicationSignalSeverity: major



After having solved the problem which initiated the trigger alarm, this error message willalso be cleared.

Contact the technical assistance center (TAC) to get support in isolating the fault if theprevious actions was not successful. For suitable preparation save the error symptomsas described in "Collect Info for Assistance". Log files need to be analyzed and specificmeasures must be taken which are out of the operator’s scope.


OML:Node B (RC)


202066 - Path Remote Defect Indication on STM1 PhysicalLink


Error Description

A Path Remote Defect Indication (P-RDI) indication has been received on an STM-1/OC-3 physical link.

The P-RDI indicates the following:• At least one of the following problems has been detected upstream from the Node B

on the STM-1/OC-3 link reporting this alarm:– Path Loss of Pointer (P-LOP)– Path Alarm Indication Signal (P-AIS)

• Transmission from upstream direction to the Node B has probably been interruptedon the reporting link.

The ’202066 - Path Remote Defect Indication on STM1 Physical Link’ alarm is triggeredby one of the following preceded alarms reported by an upstream NE:• 202064 - Path Loss of Pointer Indication on STM1 Physical Link• 202065 - Path Alarm Indication Signal on STM1 Physical Link• Or by P-LOP or P-AIS from link equipment (LE) in upstream direction.

Furthermore, as a consequence of this alarm, the following alarms may be triggered:• 202072 - Alarm Indication Signal on an ATM VC• 202075 - Alarm Indication Signal on an ATM VP

Troubleshooting

Due to the fact that this error message is a consequence of a preceded alarm from anupstream NE, troubleshooting has to start with investigation of the trigger alarm(s). Findthe relevant trigger alarm in the Alarm Monitoring window of the RC:

1. Open the Alarm Monitoring window.2. Use the filter and sort function to concentrate on the following relevant alarms:

– 202064 - Path Loss of Pointer Indication on STM1 Physical Link^– 202065 - Path Alarm Indication Signal on STM1 Physical Link

3. Proceed according to the troubleshooting of the trigger alarm.

Alarms caused by LE are handled accordingly.

After having solved the problem which initiated the trigger alarm, this error message willalso be cleared.


Managed Object Class / Hardware Type: Stm1TPEvent Type: communicationAlarmProbable Cause: RemoteAlarmIndicationSeverity: major



202068 - Signal Label Mismatch Indication on STM1 Phys-ical Link


Error Description

Signal label mismatch (SLM) indication has been received on an STM-1/OC-3 physicallink. This may be because of corruptions on the STM-1/OC-3 line or incorrect configu-ration at the transmitting end.

Troubleshooting




Managed Object Class / Hardware Type: Stm1TPEvent Type: communicationAlarmProbable Cause: SignalLabelMismatchSeverity: minor


OML:Node B (RC)


202070 - Signal Degrade Indication on STM1 Physical Link


Error Description

Signal degrade (SD) indication has been received on an STM-1/OC-3 physical link. Thisindicates that the bit error rate on the received STM-1/OC-3 signal has exceeded thethreshold set in the signalDegradeThreshold configuration attribute. This may be due tofaulty hardware at either end or problems on the transmission medium between the twoends.

Troubleshooting






click).– Look for an alarm of the CC in the reporting Node BIf an equipment alarm of the CC is present try to fix this fault first which probably alsoeliminates the SD alarm.

2. Is there an equipment alarm for the upstream NE (RNC, Node B or LE) reportedwhich is connected to the relevant port?– For RNC and Node B proceed as described above accordingly– For LE the appropriate operation and management system has to be usedIf an equipment alarm is present try to fix this fault first which probably also elimi-nates the SD alarm.

On site inspection:



Managed Object Class / Hardware Type: Stm1TPEvent Type: communicationAlarmProbable Cause: DegradedSignalSeverity: minor



202071 - Excessive Bit Error Rate Indication on STM1Physical Link


Error Description

Excessive bit error rate (EBER) indication has been received on an STM-1/OC-3 phys-ical link. This indicates that the bit error rate on the received STM-1/OC-3 signal has ex-ceeded the threshold set in the signalFailThreshold configuration attribute. This may bedue to faulty hardware at either end or problems on the transmission medium betweenthe two ends.

Troubleshooting






click).– Look for an alarm of the CC in the reporting Node BIf an equipment alarm of the CC is present try to fix this fault first which probably alsoeliminates the EBER alarm.

2. Is there an equipment alarm for the upstream NE (RNC, Node B or LE) reportedwhich is connected to the relevant port?– For RNC and Node B proceed as described above accordingly– For LE the appropriate operation and management system has to be usedIf an equipment alarm is present try to fix this fault first which probably also elimi-nates the EBER alarm.

On site inspection:



Managed Object Class / Hardware Type: Stm1TPEvent Type: communicationAlarmProbable Cause: ExcessiveBERSeverity: major


OML:Node B (RC)


202072 - Alarm Indication Signal on an ATM VC


Error Description

An alarm indication signal (AIS) indication has been received on an ATM VC. This indi-cates that an alarm condition has been detected upstream from the Node B and theequipment that has detected it is indicating a problem to equipment downstream of it.The ATM cell stream on the affected VC will probably have been interrupted.

This alarm is triggered by one of the following preceded alarms from an upstream NE inthe supervision of the RC:• 202056 - Loss Of Signal on Physical Link• 202057 - Loss Of Frame on Physical Link• 202058 - Loss Of Cell Delineation on Physical Link• 202065 - Path Alarm Indication Signal on STM1 Physical Link• 202066 - Path Remote Defect Indication on STM1 Physical Link


The following subsequent alarms may also be initiated:• 202073 - Remote Defect Indication on an ATM VC• 202075 - Alarm Indication Signal on an ATM VP• 202076 - Remote Defect Indication on an ATM VP

Troubleshooting



For troubleshooting instructions refer to:• 202056 - Loss Of Signal on Physical Link• 202057 - Loss Of Frame on Physical Link• 202058 - Loss Of Cell Delineation on Physical Link• 202065 - Path Alarm Indication Signal on STM1 Physical Link• 202066 - Path Remote Defect Indication on STM1 Physical Link



Managed Object Class / Hardware Type: VcTTPEvent Type: communicationAlarmProbable Cause: AlarmIndicationSignalSeverity: minor



202073 - Remote Defect Indication on an ATM VC


Error Description

A remote defect indication (RDI) indication has been received on an ATM VC. This indi-cates that an alarm condition has been detected downstream from the Node B and theequipment that has detected it is indicating a problem to equipment upstream of it. TheATM cell stream on the affected VC will probably have been interrupted.

This alarm is triggered by one of the following preceded alarms from an downstream NEin the supervision of the RC:• 202056 - Loss Of Signal on Physical Link• 202057 - Loss Of Frame on Physical Link• 202058 - Loss Of Cell Delineation on Physical Link


The following subsequent alarms may also be initiated:• 202072 - Alarm Indication Signal on an ATM VC• 202075 - Alarm Indication Signal on an ATM VP• 202076 - Remote Defect Indication on an ATM VP

Troubleshooting



For troubleshooting instructions refer to:• 202056 - Loss Of Signal on Physical Link• 202057 - Loss Of Frame on Physical Link• 202058 - Loss Of Cell Delineation on Physical Link



Managed Object Class / Hardware Type: VcTTPEvent Type: communicationAlarmProbable Cause: RemoteAlarmIndicationSeverity: minor


OML:Node B (RC)


202074 - SSCOP Failure Indication on an ATM VC used byALCAP or NBAP


Error Description

A SAAL failure has been received on an ATM VC used for ALCAP or NBAP signaling.This may be only a temporary failure from which the link will have recovered by itself(e.g. by automatic retransmission). Persistent reports of this kind may be due to hard-ware or software failure at either end or problems on the transmission medium betweenthe two ends.

Troubleshooting






click).– Look for an alarm of the CC in the reporting Node BIf an equipment alarm of the CC is present try to fix this fault first which probably alsoeliminates this alarm.

2. Is there an equipment alarm for the upstream NE (RNC, Node B or LE) reportedwhich is connected to the relevant port?– For RNC and Node B proceed as described above accordingly– For LE the appropriate operation and management system has to be usedIf an equipment alarm is present try to fix this fault first which probably also elimi-nates this alarm.

On site inspection:



Managed Object Class / Hardware Type: VcTTPEvent Type: communicationAlarmProbable Cause: SscopFailureSeverity: warning



202075 - Alarm Indication Signal on an ATM VP


Error Description

An alarm indication signal (AIS) indication has been received on an ATM VP. This indi-cates that an alarm condition has been detected upstream from the Node B and theequipment that has detected it is indicating a problem to equipment downstream of it.The ATM cell stream on the affected VP will probably have been interrupted.

This alarm is triggered by one of the following preceded alarms from an upstream NE inthe supervision of the RC:• 202056 - Loss Of Signal on Physical Link• 202057 - Loss Of Frame on Physical Link• 202058 - Loss Of Cell Delineation on Physical Link• 202065 - Path Alarm Indication Signal on STM1 Physical Link• 202066 - Path Remote Defect Indication on STM1 Physical Link


The following subsequent alarms may also be initiated:• 202072 - Alarm Indication Signal on an ATM VC• 202073 - Remote Defect Indication on an ATM VC• 202076 - Remote Defect Indication on an ATM VP

Troubleshooting



For troubleshooting instructions refer to:• 202056 - Loss Of Signal on Physical Link• 202057 - Loss Of Frame on Physical Link• 202058 - Loss Of Cell Delineation on Physical Link• 202065 - Path Alarm Indication Signal on STM1 Physical Link• 202066 - Path Remote Defect Indication on STM1 Physical Link



Managed Object Class / Hardware Type: VpTTPEvent Type: communicationAlarmProbable Cause: AlarmIndicationSignalSeverity: minor


OML:Node B (RC)


202076 - Remote Defect Indication on an ATM VP


Error Description

A remote defect indication (RDI) indication has been received on an ATM VP. This indi-cates that an alarm condition has been detected downstream from the Node B and theequipment that has detected it is indicating a problem to equipment upstream of it. TheATM cell stream on the affected VP will probably have been interrupted.

This alarm is triggered by one of the following preceded alarms from an downstream NEin the supervision of the RC:• 202056 - Loss Of Signal on Physical Link• 202057 - Loss Of Frame on Physical Link• 202058 - Loss Of Cell Delineation on Physical Link


The following subsequent alarms may also be initiated:• 202072 - Alarm Indication Signal on an ATM VC• 202073 - Remote Defect Indication on an ATM VC• 202075 - Alarm Indication Signal on an ATM VP

Troubleshooting



For troubleshooting instructions refer to:• 202056 - Loss Of Signal on Physical Link• 202057 - Loss Of Frame on Physical Link• 202058 - Loss Of Cell Delineation on Physical Link



Managed Object Class / Hardware Type: VpTTPEvent Type: communicationAlarmProbable Cause: RemoteAlarmIndicationSeverity: minor



202077 - ALCAP PVC Out Of Service Indication


Error Description

The signaling protocol (STC) used by ALCAP has indicated that the connection is out ofservice. This may be due to traffic congestion or a failure in the network or because thefar end is not configured. STC will repeatedly attempt to reconnect and will indicatewhen the connection is in service.

Troubleshooting


Managed Object Class / Hardware Type: VcTTPEvent Type: equipmentAlarmProbable Cause: LinkFailureSeverity: major


OML:Node B (RC)


202078 - Loss Of Delay Synchronisation on IMA Link


Error Description

A loss of delay synchronization (LODS) defect is reported when the link differential delaybetween the link and the other links in the group is over the tolerable link differential de-lay (as defined by the configuration attribute imaGroupDiffDelayMax). If this alarm oc-curs then the ImaGroup will automatically cease transmitting on the link and (assumingthat there are sufficient good links for the Group to remain Operational) continue to op-erate using the remaining good links.

Troubleshooting


Managed Object Class / Hardware Type: ImaLinkEvent Type: communicationAlarmProbable Cause: VendorSpecificSeverity: minor

i NOTEIf an IMA group has been configured, however, not being operational during start-up,the Node B possibly restarts some minutes after start-up.



202079 - Loss Of IMA Frame on IMA Link


Error Description

The LIF (loss of IMA frame) defect is the occurrence of persistent OIF (out of IMA frame)anomalies for at least 2 IMA frames. This indicates that the IMA frame synchronizationhas been lost. If this alarm occurs then the ImaGroup will automatically cease transmit-ting on the link and (assuming that there are sufficient good links for the Group to remainOperational) continue to operate using the remaining good links.

Troubleshooting





OML:Node B (RC)


202080 - Remote Failure Indicator on IMA Link


Error Description

Persistence of an RDI-IMA defect at the NE. An RDI-IMA is when one of the availableremote defect indicators (including IMA link specific defect) is indicated in the link relatedLink Information field. This indicates that the IMA Link at the far end has detected a de-fect and has reported it to the near end. If this alarm occurs then the ImaGroup will au-tomatically cease transmitting on the link and (assuming that there are sufficient goodlinks for the Group to remain Operational) continue to operate using the remaining goodlinks.

Troubleshooting





202081 - IMA Tx link is detected as mis-connected


Error Description

TX link is detected as mis-connected. This is reported when the IMA unit has determinedthat the Tx link is not connected to the same FE IMA unit as the other Tx links in thegroup. This condition will be detected by the Test Pattern Procedure.

Troubleshooting




OML:Node B (RC)


202082 - IMA Rx link is detected as mis-connected


Error Description

RX link is detected as mis-connected. This is reported when the IMA unit has deter-mined that the Rx link is not connected to the same FE IMA unit as the other Rx links inthe group. This condition will be detected by the Test Pattern Procedure.

Troubleshooting





202083 - Tx fault declared at the NE on IMA Link


Error Description

Implementation specific TX fault declared at the NE. This alarm indication that a hard-ware specific defect has been detected in the Tx direction on one link of the IMAGroup.If this alarm occurs then the ImaGroup will automatically cease transmitting on the linkand (assuming that there are sufficient good links for the group to remain operational)continue to operate using the remaining good links. This alarm is likely to be due to faultyhardware at the near end.

Troubleshooting




OML:Node B (RC)


202084 - Rx fault declared at the NE on IMA Link


Error Description

Implementation specific RX fault declared at the NE. This alarm indication that a hard-ware specific defect has been detected in the Rx direction on one link of the IMAGroup.If this alarm occurs then the ImaGroup will automatically cease transmitting on the linkand (assuming that there are sufficient good links for the Group to remain operation)continue to operate using the remaining good links. This alarm is likely to be due to faultyhardware at either end.

Troubleshooting





202085 - FE has reported Tx-Unusable on IMA Link


Error Description

The far end has reported that the link is unusable in the TX direction. When the Ima-Group is starting up this is an indication that would be expected before the link gets toits normal operating state and so does not necessarily indicate a problem. Thereafterthis alarm indication means that the link is no longer active for some reason that may beindicated by other alarms. If this alarm occurs then the ImaGroup will automaticallycease transmitting on the link and (assuming that there are sufficient good links for theGroup to remain Operational) continue to operate using the remaining good links.

Troubleshooting




OML:Node B (RC)


202086 - FE has reported Rx-Unusable on IMA Link


Error Description

The far end has reported that the link is unusable in the RX direction. When the Ima-Group is starting up this is an indication that would be expected before the link gets toits normal operating state and so does not necessarily indicate a problem. Thereafterthis alarm indication means that the link is no longer active for some reason that may beindicated by other alarms. If this alarm occurs then the ImaGroup will automaticallycease transmitting on the link and (assuming that there are sufficient good links for theGroup to remain Operational) continue to operate using the remaining good links.

Troubleshooting





202087 - Startup FE reported on IMA Group


Error Description

The far end IMA Group is in the Startup state. This alarm indication should be seen aspart of the normal startup procedure of the Group and does not necessarily indicate aproblem. Thereafter it indicates that the Group has reset to its startup state for some rea-son that may be explained by other alarms.

Troubleshooting


Managed Object Class / Hardware Type: ImaGroupEvent Type: communicationAlarmProbable Cause: VendorSpecificSeverity: major


OML:Node B (RC)


202088 - Config Abort reported on IMA Group


Error Description

This indication means that the IMA Group has aborted its attempted startup for somereason. This may be because the IMA Group at the far end has been configured withincompatible attributes to those that have been used at the near end. Possible incom-patible attributes are: Frame Length, Group Symmetry or the IMA Version. These maybe fixable by modification to the configuration at one or both ends.

Troubleshooting








202089 - Config Abort FE reported on IMA Group


Error Description

This indication is the same as the imaGroupConfigAbort (see: 202088 - Config Abort re-ported on IMA Group) but has been reported by the far end IMA to the near end. Thecauses and possible fixes are the same as for the imaGroupConfigAbort.

Troubleshooting







OML:Node B (RC)


202090 - Insufficient Links reported at NE on IMA Group


Error Description

The NE has reported that the number of active links (operational state = enabled) is lessthan is required for the Group to be operational.

This may be caused by one of the following:• The configuration of the group requires more links than have been configured.• One or more links are non-operational for other reasons, such as fault conditions.• One or more links have not yet completed their startup procedure.

If enough links have been configured, the status of these links must be examined to de-termine why not sufficiently enough of these links are in the operational state enabled .

At startup of the group this alarm indication would normally be expected to be seen asthe group performs its startup procedure.

Troubleshooting

Perform the following tasks to solve this error:

1. Check Node B database.The number of links required for the group to be operational is configured by the at-tribute “imaGroupMinNumLinks”

2. Change Node B database.






202091 - Insufficient Links at FE reported on IMA Group


Error Description

The FE has reported that the number of active links (operational state = enabled ) is lessthan is required for the group to be operational.

The reasons and actions for this alarm are similar to those described for the InsufficientLinks indication at the near end (see: 202090 - Insufficient Links reported at NE on IMAGroup).

Troubleshooting








OML:Node B (RC)


202092 - Group Blocked at FE reported on IMA Group


Error Description

The FE IMA group has been blocked (i.e. its adminstrative state has been set to lockedby the operator at the FE). As a consequence, the FE IMA group is not operating.

Troubleshooting


1. Check the administrative state of the IMA group at the FE.2. Change the administrative state to unlocked at the FE.




202093 - Timing Synch error reported on IMA Group


Error Description

FE transmit clock mode is different from the NE transmit clock mode due to different con-figuration of the group. The imaGroupNeTxClkMode at both ends should be set to CTC(Common Transmit Clock).

Troubleshooting








OML:Node B (RC)


202095 - The Near End IMA has detected an invalid versionset by the Far End


Error Description

The Node B does only support IMA version 1.1. The far end IMA group, however, is us-ing a different IMA version. This indicates that the far end hardware configuration is in-compatible with the near end hardware.

Troubleshooting

Check the hardware compatibility of the configuration.




202097 - Loss of Continuity detected on an ATM VP


Error Description

The VpCTP or the VpTTP which contains the continuity monitor does not receive the ex-pected continuity check cells from the source.

Troubleshooting

Troubleshooting has to start with investigation on other alarms: Check whether alarmsat upstream NEs are present in the Alarm Monitoring window of the RC:

1. Open the Alarm Monitoring window.2. Proceed according to the troubleshooting of the trigger alarm.

If either no such alarm is present or if the actions taken above did not clear the conditionfor this alarm, repair actions must be achieved on site. Proceed according to the OutputManual OML:Node B.


Managed Object Class / Hardware Type: ContinuityMonitorEvent Type: communicationAlarmProbable Cause: VendorSpecificSeverity: minor


OML:Node B (RC)


202098 - CRC4 not used by FE reported on E1TTP


Error Description

The following indication has been received on the reporting E1 physical link: ’CRC4 notused by FE’.

The ’202098 - CRC4 not used by FE reported on E1TTP’ alarm indicates that no multi-frame synchronization could be found. This may be due to the follwing:• Misconfiguration of the hardware at either end• Faulty hardware at either end• Problems on the transmission medium between the two ends

The "202098 - CRC4 not used by FE Indication on E1 Physical Link" alarm may becaused by the following:

The Node B's E1TTP managed object's attribute crcOperationMode , which indicatesthe mode of CRC operation, is set to crcAutomatic whereas the frame format for theRNC is set to 0 meaning that the CRC is disabled.

The "202098 - CRC4 not used by FE Indication on E1 Physical Link" does not cause anychange of the reporting E1TTP's OST/AVS.

Troubleshooting


Managed Object Class / Hardware Type: E1TTPEvent Type: communicationAlarmProbable Cause: VendorSpecificSeverity: warning



202106 - Software activation failed


Error Description

The activation of a software load failed in the previous run.

As a consequence, the Node B now automatically switched back to the previously run-ning software load.

Troubleshooting




OML:Node B (RC)


202107 - Database activation failed


Error Description

The activation of a database failed in the previous run.

As a consequence, the Node B now automatically switched back to the previously run-ning database.

Troubleshooting


Managed Object Class / Hardware Type: OsuEvent Type: processingErrorAlarmProbable Cause: ConfigurationOrCustomizationErrorSeverity: warning



202108 - Reliable software started without prior explicitactivation


Error Description

The reliable software was started without a prior explicit activation procedure (automaticfallback).

This case occurs due to one of the following situations:• No activation is running and the start-up with the running software failed three times

in a row.• An error occurred in a very early boot phase.

Troubleshooting




OML:Node B (RC)


202109 - Reliable database started without prior explicitactivation


Error Description

The reliable database was started without a prior explicit activation procedure (automat-ic fallback).

This case occurs due to one of the following situations:• No activation is running and the start-up with the reliable database failed three times

in a row.• An error occurred in a very early boot phase.

Troubleshooting





202156 - Cannot acquire mutex for logging of FER


Error Description

FER cannot be logged, because mutex to access reset safe RAM could not be acquired.

Troubleshooting




OML:Node B (RC)


202157 - Cannot release mutex after logging of FER


Error Description

Next FER can not be logged, because mutex for access to reset safe RAM could not bereleased.

Troubleshooting





202158 - Reset safe RAM for logging of FERs unavailable


Error Description

Logging failure, because the reset safe RAM was not accessible. Logging of FERs is notpossible without accessing reset safe RAM.

Troubleshooting




OML:Node B (RC)


202357 - CAN opcode not valid


Error Description

The Node B CAN communicates with various devices via CAN bus. The Core Controllersoftware verifies messages from CAN participants for valid types. This fault report willbe generated, if the Core Controller software detects an invalid message type. The af-fected Node B may continue to operate in a degraded mode.

The probable cause for that condition could either be a hardware failure or a softwarefailure.

Troubleshooting

1. Any CAN bus participant may cause the problem. Check all CAN bus participants inorder to isolate the fault



Managed Object Class / Hardware Type: CcEvent Type: communicationAlarmProbable Cause: InvalidMessageReceivedSeverity: warning



202358 - CAN received an unexpected message


Error Description

The Node B CAN communicates with various devices via CAN bus. The Core Controllersoftware verifies the communication scenarios. This fault report will be generated, if theCore Controller software detects an unexpected message in the actual message sce-nario. The affected Node B may continue to operate in a degraded mode.


Troubleshooting






OML:Node B (RC)


202359 - CAN received a message with an invalid parame-ter


Error Description

The Node B CAN communicates with various devices via CAN bus. The Core Controllersoftware verifies some parameter values supplied by CAN participants. This fault reportwill be generated, if the Core Controller software detects an invalid parameter from aCAN participant. The affected Node B may continue to operate in a degraded mode.


Troubleshooting







202360 - A necessary resource is missed


Error Description

The Node B communicates with various devices via a CAN bus. This fault report will begenerated, if the Core Controller cannot initialize its local resources. This condition leadsto a recovery reset. The affected Node B is therefore temporarily not operational.


Troubleshooting




Managed Object Class / Hardware Type: CcEvent Type: processingErrorAlarmProbable Cause: UnderlyingRessourceUnavailableSeverity: warning


OML:Node B (RC)


202406 - ALCAP Protocol Error


Error Description

ALCAP (access link control application part) protocol errors are an indication of one ofthe following conditions:• Messages are being corrupted over the Iub interface.• Software implementation problems between RNC and Node B.• ALCAP protocol in the RNC has been upgraded to a later version of the specification

(ITU-T Q.2630.1).

Troubleshooting


Managed Object Class / Hardware Type: CcEvent Type: communicationAlarmProbable Cause: CommunicationProtocolErrorSeverity: warning



202431 - ITR initiated action from CPA to RNC timed out


Error Description

An ITR (transport management subsystem) initiated Iub request on ALCAP (access linkcontrol application part) has timed out. This means that block request, unblock requestor reset request has been requested by ITR and has timed out before a reply has beenreceived from the RNC.

This condition is fairly serious as it can lead to a configuration misalignment betweenRNC and Node B. This error could either be caused by congestion or a failure in the AL-CAP socket between RNC and Node B.

Troubleshooting


Managed Object Class / Hardware Type: CcEvent Type: qualityOfServiceAlarmProbable Cause: CongestionSeverity: warning


OML:Node B (RC)


202432 - CPN initiated action from CPA to RNC timed out


Error Description

A CPN (call processing NBAP) initiated Iub request on ALCAP has timed out. Thismeans that reset request or release request has been requested by CPN and has timedout before a reply has been received from the RNC.

This condition is fairly serious as it can lead to a configuration misalignment betweenRNC and Node B. This error could either be caused by congestion or a failure in the AL-CAP socket between RNC and Node B.

Troubleshooting

Contact the technical assistance center (TAC) to get support in isolating the fault. Forsuitable preparation save the error symptoms as described in "Collect Info forAssistance". Log files need to be analyzed and specific measures must be taken whichare out of the operator’s scope.

Managed Object Class / Hardware Type: CcEvent Type: qualityOfServiceAlarmProbable Cause: CongestionSeverity: warning



202433 - Configuration misalignment between RNC andCPA


Error Description

This error occurs when RNC sends a message to CPA (call processing ALCAP) to per-form an action which is not valid. Such actions include:• RNC attempts to block a path which is already blocked or does not exist.• RNC attempts to unblock a path which is already unblocked or does not exist.• RNC attempts to reset a path which does not exist.• RNC attempts to release a non-existent connection.

While not a serious problem in itself, these unexpected actions could point to either asoftware error or a configuration misalignment between RNC and CPA which is serious.

Troubleshooting


Managed Object Class / Hardware Type: CcEvent Type: communicationAlarmProbable Cause: SscopFailureSeverity: warning


OML:Node B (RC)


202434 - RNC Establish Request message received whichis invalid or cannot be handled


Error Description

This error indicates that an ALCAP (access link control application part) establish re-quest message has been received from the RNC which is either invalid or can not behandled.

Possible errors include:• Establish request for a connection which is destined to be routed to a BB (baseband)

card that is not in service (this is an NBAP/BB card problem).• Establish request which contains an invalid binding ID.• Establish request with an invalid NSEA (NSAP service endpoint address) address

for the Node B.• Establish request which contains unexpected parameters for this implementation.• Establish request for a path which does not exist• Establish request for a channel that is already in use.• Establish request with no TCI (test connection indication) for a path which is locally

blocked.

These either indicate a problem with the RNC or internal subsystems.

Troubleshooting


Managed Object Class / Hardware Type: CcEvent Type: communicationAlarmProbable Cause: CommunicationProtocolErrorSeverity: warning



202435 - CPA to RNC communication (socket) problems


Error Description

This error occurs if data that is about to be sent is lost due to the TNP (transport networkprotocol) socket between Node B and RNC either being out-of-service or returning error.

This is a serious problem as, if there is no retry mechanism (e.g. for release requests),then configuration misalingment could result between RNC and Node B.

The following subsequent alarm may also be initiated:• 200656 - Iub link broke down

Troubleshooting


Managed Object Class / Hardware Type: CcEvent Type: communicationAlarmProbable Cause: SscopFailureSeverity: warning


OML:Node B (RC)


202456 - CC Clock Warm Up Error


Error Description

CC (Core Controller) clock warm up error. BHS (basic hardware service) monitors thewarming up of the clock. It waits 4 minutes for the message from the LIU (line interfaceunit) board, where the oven quartz clock is located, confirming the stable work of theclock. In case of any error the CC must be reset.

Troubleshooting


1. First, reset the addressed card. Either use the ’NodeB Sum’ panel or apply the rstcommand to the relevant CC.

2. If this is not successful, further repair actions must be achieved on site. Refer to theOutput Manual OML:Node B.


Managed Object Class / Hardware Type: CcEvent Type: environmentalAlarmProbable Cause: CoolingSystemFailureSeverity: critical



202457 - CC Card HW Test Error


Error Description

In the reporting CC (Core Controller) card, a hardware test error occurred.

BHS (basic hardware service) initiates and monitors the boards' device tests. In case ofany error board tests SW returns the short error description message (no more than 256letters) which is forwarded to IFA (fault and alarm management). In fact, BHS tests theCPU, LIU, ATM, and STM-1/OC-3 boards.

Troubleshooting



2. If this is not successful, further repair actions must be achieved on site. Refer to theOutput Manual OML:Node B.


Managed Object Class / Hardware Type: CcEvent Type: equipmentAlarmProbable Cause: EquipmentFailureSeverity: critical


OML:Node B (RC)


202506 - Node B System Clock in Holdover Mode


Error Description

The reference input for the Node B system clock is not available or not stable enoughfor synchronization. System clock oscillator is running without external synchronization(holdover mode). This may be due to incorrect configuration of the clock managementin the Node B database, or due to insufficient signal quality of the reference clocksource.

Troubleshooting

All clock signals in the Node B are derived from an internal high accuracy master clock(OC-VCXO) which is synchronized to a reference clock signal by PLL. This referenceclock can be derived from the Iub interface (E1/J1/T1 or STM-1/OC-3) or from an exter-nal source connected to the external synchronization input.

With the MO “clmng” in the nbDatabase not only the source for the reference clock canbe defined but also the priority order of up to 4 possible sources can be selected. If thereference clock is lost or is not of sufficient quality the internal clock (OC-VCXO) will stillwork within 3GPP frequency stability limit of 0,05 ppm for at least 2 days. The workingstate is “hold over mode - high accuracy”.

1. Reference clock lostIf the reference clock is derived from an E1/J1/T1 or STM-1/OC-3 line and the rele-vant incoming Iub signal is lost or degraded concentrate on fixing the Iub interfacealarm first as they are:– 202056 - Loss Of Signal on Physical Link– 202057 - Loss Of Frame on Physical Link– 202070 - Signal Degrade Indication on STM1 Physical Link– 202071 - Excessive Bit Error Rate Indication on STM1 Physical LinkIf an external clock is chosen as reference on site inspection is necessary to find thecause for the lost or degraded reference signal. Refer to the Output ManualOML:Node B

2. Clock management configuration incorrectThe MO “clmng” in the nbDatabase defines the reference clock sources and theirpriority. The attributes “prio0Port” and “prio0LineType” show the interface with thehighest priority whereas “prio3Port” and “prio3LineType” are assigned to the inter-face with the lowest priority.– Upload the nbDatabase– Check for right configuration of ports and line types of MO “clmng” as well as

“stm1Port” and “lineCircuitAddress” of the transport related MOCs “stm1TP” or“e1TTP/j1TTP” respectively. Refer to the OGL:Node B DB Description

3. Reference signal quality insufficientFor further investigation, a visit on site is necessary to find the cause for the problemon the lost or degraded clock reference by inspecting lines and termination equip-ment. Refer to the Output Manual OML:Node B.

Managed Object Class / Hardware Type: ClMngEvent Type: equipmentAlarmProbable Cause: TimingProblemSeverity: minor



202507 - Node B System Clock in Medium Accuracy


Error Description

The accuracy of the Node B system clock is in medium accuracy range. This may bedue to insufficient signal quality of the reference clock source.

The following preceded alarm should have been reported:– 202506 - Node B System Clock in Holdover Mode

Troubleshooting

All clock signals in the Node B are derived from an internal high accuracy master clock(OC-VCXO) which is synchronized to a reference clock signal by PLL. This referenceclock can be derived from the Iub interface (E1/J1/T1 or STM-1/OC-3) or from an exter-nal source connected to the external synchronisation input.

With the MO “clmng” in the nbDatabase not only the source for the reference clock canbe defined but also the priority order of up to 4 possible sources can be selected. If thereference clock is lost or is not of sufficient quality the internal clock (OC-VCXO) will firstchange to the working state “hold over mode - high accuracy”. But if the bad synchroni-sation remains for up to 2 days the Node B will go from “hold over mode - high accuracy”to “hold over mode - medium accuracy”. In this case the frequency stability can only beguaranteed for a few days and after this period there is a possibility that the Node B willtransmit outside 0,05 ppm.

1. Reference clock lostIf the reference clock is derived from an E1/J1/T1 or STM-1/OC-3 line and the rele-vant incoming Iub signal is lost or degraded concentrate on fixing the Iub interfacealarm first as they are:– 202056 - Loss Of Signal on Physical Link– 202057 - Loss Of Frame on Physical Link– 202070 - Signal Degrade Indication on STM1 Physical Link– 202071 - Excessive Bit Error Rate Indication on STM1 Physical LinkIf an external clock is chosen as reference on site inspection is necessary to find thecause for the lost or degraded reference signal. Refer to the Output ManualOML:Node B

2. Clock management configuration incorrectThe MO “clmng” in the nbDatabase defines the reference clock sources and theirpriority. The attributes “prio0Port” and “prio0LineType” show the interface with thehighest priority whereas “prio3Port” and “prio3LineType” are assigned to the inter-face with the lowest priority.– Upload the nbDatabase– Check for right configuration of ports and line types of MO “clmng” as well as

“stm1Port” and “lineCircuitAddress” of the transport related MOCs “stm1TP” or“e1TTP/j1TTP” respectively. Refer to the OGL:Node B DB Description

Managed Object Class / Hardware Type: ClMngEvent Type: equipmentAlarmProbable Cause: TimingProblemSeverity: minor


OML:Node B (RC)


3. Reference signal quality insufficientFor further investigation, a visit on site is necessary to find the cause for the problemon the lost or degraded clock reference by inspecting lines and termination equip-ment. Refer to the Output Manual OML:Node B.



262041 - System call unsuccessful


Error Description

A system call was not successful. As a consequence, the CC (Core Controller) will bereset, because the software is not capable of working stable any longer. The problemhas to be analyzed by the customer service.

Troubleshooting


Managed Object Class / Hardware Type: *Event Type: processingErrorAlarmProbable Cause: SystemCallInsuccessfulSeverity: critical


OML:Node B (RC)


262042 - Unexpected software error


Error Description

An unexpected software error occurred. As a consequence, the CC (Core Controller)will be reset, because the software is not capable of working stable any longer. Theproblem has to be analyzed by the customer service.

Troubleshooting





262043 - Error from Device Driver received


Error Description

A function call to a device driver returned an error. In most of the cases the CC (CoreController) will be reset as a consequence. The problem has to be analyzed by the cus-tomer service.

Troubleshooting




OML:Node B (RC)


262044 - Not enough memory to initialize software


Error Description

At start-up time the OS (operating system) could not allocate enough memory for taskstacks, message buffers and dynamic memory management etc. The problem has to beanalyzed by the customer service.

Troubleshooting


Managed Object Class / Hardware Type: CcEvent Type: processingErrorAlarmProbable Cause: OutOfMemorySeverity: critical



262045 - Memory allocation failure


Error Description

The system did not have enough free memory to satisfy a memory allocation request.As a consequence, the CC (Core Controller) will be reset. The problem has to be ana-lyzed by the customer service.

Troubleshooting


Managed Object Class / Hardware Type: *Event Type: processingErrorAlarmProbable Cause: OutOfMemorySeverity: critical


OML:Node B (RC)


262046 - Unexpected exception handling


Error Description

An unexpected exception was thrown. As a consequence, the CC (Core Controller) willbe reset, because the software is not capable of working stable any longer. The problemhas to be analyzed by the customer service.

Troubleshooting





262047 - Uncaught exception handling


Error Description

A thrown exception was not caught. As a consequence, the CC (Core Controller) will bereset, because the software is not capable of working stable any longer. The problemhas to be analyzed by the customer service.

Troubleshooting



Documents

No Debo Mlrc