nsn administering alarms in mcrnc and flexi direct rnc

60
Multicontroller RNC, Rel. 3.0, Operating Documentation, Pre- release, Issue 01 Administering Alarms in mcRNC and Flexi Direct RNC DN09123463 Issue 02 DRAFT Approval Date 2013-05-14 Confidential Nokia Siemens Networks is continually striving to reduce the adverse environmental effects of its products and services. We would like to encourage you as our customers and users to join us in working towards a cleaner, safer environment. Please recycle product packaging and follow the recommendations for power use and proper disposal of our products and their compo- nents. If you should have questions regarding our Environmental Policy or any of the environmental services we offer, please contact us at Nokia Siemens Networks for any additional information.

Upload: lhgoul

Post on 13-Dec-2015

161 views

Category:

Documents


24 download

DESCRIPTION

NSN Administering Alarms in McRNC and Flexi Direct RNC

TRANSCRIPT

Multicontroller RNC, Rel. 3.0, Operating Documentation, Pre-release, Issue 01

Administering Alarms in mcRNC and Flexi Direct RNC

DN09123463

Issue 02 DRAFTApproval Date 2013-05-14

Confidential

Nokia Siemens Networks is continually striving to reduce the adverse environmental effects of its products and services. We would like to encourage you as our customers and users to join us in working towards a cleaner, safer environment. Please recycle product packaging and follow the recommendations for power use and proper disposal of our products and their compo-nents.

If you should have questions regarding our Environmental Policy or any of the environmental services we offer, please contact us at Nokia Siemens Networks for any additional information.

2 DN09123463

Administering Alarms in mcRNC and Flexi Direct RNC

Id:0900d805809a71a5Confidential

The information in this document is subject to change without notice and describes only the product defined in the introduction of this documentation. This documentation is intended for the use of Nokia Siemens Networks customers only for the purposes of the agreement under which the document is submitted, and no part of it may be used, reproduced, modified or transmitted in any form or means without the prior written permission of Nokia Siemens Networks. The documentation has been prepared to be used by professional and properly trained personnel, and the customer assumes full responsibility when using it. Nokia Siemens Networks welcomes customer comments as part of the process of continuous development and improvement of the documentation.

The information or statements given in this documentation concerning the suitability, capacity, or performance of the mentioned hardware or software products are given "as is" and all liability arising in connection with such hardware or software products shall be defined conclusively and finally in a separate agreement between Nokia Siemens Networks and the customer. However, Nokia Siemens Networks has made all reasonable efforts to ensure that the instructions contained in the document are adequate and free of material errors and omissions. Nokia Siemens Networks will, if deemed necessary by Nokia Siemens Networks, explain issues which may not be covered by the document.

Nokia Siemens Networks will correct errors in this documentation as soon as possible. IN NO EVENT WILL Nokia Siemens Networks BE LIABLE FOR ERRORS IN THIS DOCUMENTA-TION OR FOR ANY DAMAGES, INCLUDING BUT NOT LIMITED TO SPECIAL, DIRECT, INDI-RECT, INCIDENTAL OR CONSEQUENTIAL OR ANY LOSSES, SUCH AS BUT NOT LIMITED TO LOSS OF PROFIT, REVENUE, BUSINESS INTERRUPTION, BUSINESS OPPORTUNITY OR DATA,THAT MAY ARISE FROM THE USE OF THIS DOCUMENT OR THE INFORMATION IN IT.

This documentation and the product it describes are considered protected by copyrights and other intellectual property rights according to the applicable laws.

The wave logo is a trademark of Nokia Siemens Networks Oy. Nokia is a registered trademark of Nokia Corporation. Siemens is a registered trademark of Siemens AG.

Other product names mentioned in this document may be trademarks of their respective owners, and they are mentioned for identification purposes only.

Copyright © Nokia Siemens Networks 2013. All rights reserved

f Important Notice on Product SafetyThis product may present safety risks due to laser, electricity, heat, and other sources of danger.

Only trained and qualified personnel may install, operate, maintain or otherwise handle this product and only after having carefully read the safety information applicable to this product.

The safety information is provided in the Safety Information section in the “Legal, Safety and Environmental Information” part of this document or documentation set.

The same text in German:

f Wichtiger Hinweis zur Produktsicherheit Von diesem Produkt können Gefahren durch Laser, Elektrizität, Hitzeentwicklung oder andere Gefahrenquellen ausgehen.

Installation, Betrieb, Wartung und sonstige Handhabung des Produktes darf nur durch geschultes und qualifiziertes Personal unter Beachtung der anwendbaren Sicherheits-anforderungen erfolgen.

Die Sicherheitsanforderungen finden Sie unter „Sicherheitshinweise“ im Teil „Legal, Safety and Environmental Information“ dieses Dokuments oder dieses Dokumentations-satzes.

DN09123463 3

Administering Alarms in mcRNC and Flexi Direct RNC

Id:0900d805809a71a5Confidential

Table of contentsThis document has 60 pages.

Summary of changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1 Overview of alarm administration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.1 Alarm system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.2 Alarm repository. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.3 Severity levels of the alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.4 Alarm data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.4.1 Type-specific alarm data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.4.2 Instance-specific alarm data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141.5 Alarm flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201.6 Alarm blocking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221.7 Alarm filtering with identifying fields. . . . . . . . . . . . . . . . . . . . . . . . . . . . 231.8 Radio network alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241.9 Alarm correlation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261.9.1 Alarm correlation for 70168 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2 Alarm monitoring with SCLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282.1 Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282.1.1 Permissions for SCLI commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282.2 Acknowledging and unacknowledging alarms . . . . . . . . . . . . . . . . . . . . 292.3 Adding alarm types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302.4 Changing the alarm type definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312.5 Clearing automatic alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332.6 Clearing manual alarms. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352.7 Configuring number of alarms processed per second . . . . . . . . . . . . . . 372.8 Configuring the alarm blocking rules . . . . . . . . . . . . . . . . . . . . . . . . . . . 392.9 Raising a test alarm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412.10 Viewing active alarm data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432.11 Viewing alarm history. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 482.12 Viewing alarm manual and test instructions. . . . . . . . . . . . . . . . . . . . . . 512.13 Viewing alarm recovery history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 522.14 Viewing notification ID of an alarm. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 552.15 Viewing probable causes and specific problems . . . . . . . . . . . . . . . . . . 562.16 Viewing the alarm type definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

3 Alarm handling in OMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

4 DN09123463

Administering Alarms in mcRNC and Flexi Direct RNC

Id:0900d805809a71a5Confidential

List of figuresFigure 1 A fault is detected and an alarm raised. . . . . . . . . . . . . . . . . . . . . . . . . . 20Figure 2 User clears the alarm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21Figure 3 mcRNC fault management functional environment . . . . . . . . . . . . . . . . 25

DN09123463 5

Administering Alarms in mcRNC and Flexi Direct RNC

Id:0900d805809a71a5Confidential

List of tablesTable 1 Type-specific alarm parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13Table 2 Instance-specific alarm parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . 16Table 3 Alarm additional information for RNW alarms . . . . . . . . . . . . . . . . . . . . 18Table 4 Permissions to execute the SCLI commands . . . . . . . . . . . . . . . . . . . . 28Table 5 Alarm type parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31Table 6 Forced values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33Table 7 Alarm filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34Table 8 Alarm filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35Table 9 Parameters for configuring number of alarm events . . . . . . . . . . . . . . . 37Table 10 Mandatory parameters for raising test alarm . . . . . . . . . . . . . . . . . . . . 41Table 11 Optional parameters for raising a test alarm . . . . . . . . . . . . . . . . . . . . . 41Table 12 Parameters for viewing active alarm data . . . . . . . . . . . . . . . . . . . . . . . 45Table 13 Alarm filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45Table 14 Numeric value for the Alarm severity . . . . . . . . . . . . . . . . . . . . . . . . . . 45Table 15 Alarm parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46Table 16 Parameters for viewing alarm history . . . . . . . . . . . . . . . . . . . . . . . . . . 48Table 17 Alarm filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49Table 18 Alarm filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53Table 19 Parameters for viewing notification IDs of an alarm . . . . . . . . . . . . . . . 55Table 20 Parameters for viewing probable causes used in the alarm system . . . 56Table 21 Parameters for viewing specific problems used in the alarm system . . 56Table 22 Parameters for viewing all alarm type definitions used in the alarm system

57

6 DN09123463

Administering Alarms in mcRNC and Flexi Direct RNC

Id:0900d805809a71a5Confidential

DN09123463 7

Administering Alarms in mcRNC and Flexi Direct RNC Summary of changes

Id:0900d805809a70ecConfidential

Summary of changesChanges between document issues are cumulative. Therefore, the latest document issue contains all changes made to previous issues.

Changes between issues 01 (2012-10-15, RU30) and 02 DRAFT (2013-05-14, RU40)

• Document title has been modified from Administering Alarms in mcRNC and I-HSPA Adapter to Administering Alarms in mcRNC and Flexi Direct RNC.

• Term I-HSPA Adapter has been replaced with Flexi Direct RNC throughout the doc-ument.

• Section Overview of alarm administration has been re-structured. • The following sections have been modified:

– Alarm system– Alarm blocking– Changing the alarm type definition– Viewing alarm history– Viewing the alarm type definition

• The following sections have been added:– Alarm correlation– Permissions for SCLI commands

• The following tables have been modified:– Alarm filters– Alarm parameters

• Section Adding alarm types has been removed.

Changes between issues 01 DRAFT (2012-07-03, RU30) and 01 (2012-10-15, RU30)

• Document title has been modified from Alarm Administration in mcRNC and I-HSPA Adapter to Administering Alarms in mcRNC and I-HSPA Adapter.

• Step 2 in section 2.10 Viewing active alarm data has been updated. • Parameters have been added to Table 13, Table 15, and Table 20.

8 DN09123463

Administering Alarms in mcRNC and Flexi Direct RNC

Id:0900d805809a717bConfidential

Overview of alarm administration

1 Overview of alarm administration

1.1 Alarm systemThe alarm system indicates potential faults in the system as well as faults that require corrective actions. After an alarm is raised, the fault causing the alarm must be solved. The solution can be an automatic recovery or a manual corrective action.

Alarms are typically used in situations where it is possible to give instructions for correc-tive actions in the alarm description, such as replacing a hardware unit.

The alarms can also be raised through the alarm system to indicate that the system is not working normally, for example, when the hard disk is full and the system cannot write to it. Such alarms are cleared automatically when the system returns to its normal state. You cannot clear these alarms manually.

The alarm system consists of an alarm processor, convenience libraries, alarm manage-ment interfaces, and an alarm repository. The components share data with each other using the alarm repository.

Convenience librariesConvenience libraries provide an interface for applications to send requests for raising and clearing alarms. The alarm applications write their alarm records to a syslog file through a convenience library. Convenience libraries perform initial validation for the syntax of the alarm records. After successful validation, the libraries write the alarm records to the syslog file.

Alarm processorThe alarm processor reads alarm notifications from syslog, processes them and decides whether they will be turned into alarm events. Alarm events are further processed by the alarm processor and are stored in alarm history, which is maintained by the alarm system. As a result, the alarm system can create new active alarms, modify the state or remove some of the existing active alarms. The processing of alarms is done according to various processing rules such as filtering rules, correlation rules and suppression rules.

Syslog fileThe alarm processor reads log records from a dedicated syslog file and parses them. Each syslog record contains alarm notification information encoded in a predefined format. The syslog parser validates and extracts this information and further pro-cesses it.

g Syslog is only used as an internal communication channel between the convenience library and alarm processor. It must not be used for checking the state of alarms because it only contains incomplete information about the state of the alarms in the system. To get full information, one should use the alarm system's management inter-face.

Alarm management interfacesAlarm management interfaces provide access to the alarm data in the alarm system. Using the Alarmlightlib, interested applications can poll the list of active alarms and the alarm history.

DN09123463 9

Administering Alarms in mcRNC and Flexi Direct RNC Overview of alarm administration

Id:0900d805809a717bConfidential

Alarm repositoryThe repository is the file-system based central storage for the alarm management system. All alarm data is stored in the alarm repository, and the components use it to share data. After the alarm processor has read the alarm records from the syslog file, the alarm repository is the only link between the alarm system components.

The following data is stored in the alarm repository:

• Active alarms list • Alarm history • Alarm type parameters.

Alarm system capacity or performance requirements The capacity or performance requirements of the alarm system are:

• Maximum number of active alarms is configurable by NSN personel and is limited only by the size of internal memory, as every active alarm takes about 2KB.

• Maximum number of Alarm history events is configurable by NSN personel and can be as big as the available disk space. One alarm event occupies around 2KB of disk space.

• Around 100 alarm notifications per second with low CPU utilization for the steady alarm flow.

• Unlimited amount of alarm notifications per second during alarm bursts, depending on the capacity of syslog files used as communication channels.

g Even with a huge number of notifications written to syslog, the alarm system is pro-cessing them at a normal rate (around 100 per second). This means that it will take around 10 seconds to process all notifications if the burst has suddenly generated 1000 notifications.

Alarm system capacity or performance requirements The capacity or performance requirements of the alarm system are:

• Maximum number of active alarms is 10000. • Maximum number of Alarm history events is 25000. • 8-10 alarm notifications per second for the steady alarm flow. • 50 alarm notifications per second during alarm bursts (30 seconds burst once a

day).

Managing alarmsAlarms can be monitored and managed using SCLI and through some other manage-ment applications running on NetAct or OMS.

10 DN09123463

Administering Alarms in mcRNC and Flexi Direct RNC

Id:0900d805809a70eeConfidential

1.2 Alarm repositoryThe Alarm Repository is partly based on memory lists and partly based on binary files. The Active Alarms are stored in structured lists, while the Alarm History is stored in binary files. In addition to this, a snapshot of Active Alarms is backed up in what are referred as snapshot files to aid recovery of active alarm list in case of Alarm System restart. All these files are stored in a dedicated partition and available across nodes.

DN09123463 11

Administering Alarms in mcRNC and Flexi Direct RNC

Id:0900d805809a70efConfidential

1.3 Severity levels of the alarmsThe severity levels of the alarms indicate the default and perceived severity of the alarms. The following severity levels are used in the system:

• CriticalThe Critical severity level indicates that a service-affecting condition has occurred and an immediate corrective action is required. This severity level can be reported, for example, when a managed object becomes totally out of service and its capabil-ity must be restored.

• MajorThe Major severity level indicates that a service-affecting condition has developed and an urgent corrective action is required. This severity level can be reported, for example, when there is a severe degradation in the capability of the managed object and its full capability must be restored.

• MinorThe Minor severity level indicates that there is a condition that does not affect ser-vices. Corrective action should be taken to prevent a more serious fault, for example, a fault that affects a service. Such a severity can be reported, for example, when the detected alarm condition is not currently degrading the capacity of the managed object.

• WarningThe Warning severity level indicates the detection of a potential or impending service-affecting fault, before any significant effects have been detected. Action should be taken to further diagnose and, if necessary, correct the problem to prevent it from becoming a more serious service affecting fault.

The following severity levels apply only to the perceived severity of the alarms:

• IndeterminateThe Indeterminate severity level indicates that the severity level of the alarm cannot be determined, that is, the application is not able to set the concrete level of severity for the detected fault.It is not recommended to use this value.

• ClearedThe Cleared severity level indicates that one or more previously reported alarms have been cleared.

12 DN09123463

Administering Alarms in mcRNC and Flexi Direct RNC

Id:0900d805809a70f0Confidential

1.4 Alarm data

1.4.1 Type-specific alarm dataThe alarms occurring in the system are based on 3GPP 32.111 series Release 4 spec-ifications. Most of the 3GPP requirements are based on ITU-T recommendation X.733.

The alarm type defines a class of alarms. The parameters, or attributes, specific to an alarm type, are defined in the following table.

Type-specific alarm parameters are either dynamic or static. You can only modify the dynamic parameters that are:

• Default severity • Autoacknowledged • Clearing delay • Informing delay • Time to live • Switchover update.

The following are examples of an alarm output including type-specific data:

Specific problem : 70011 - NODE NOT RESPONDINGProbable cause : 315 - Equipment malfunctionDefault severity : 3 (major)Clearing : automaticAuto acknowledged : yesSwitch over update : noEvent type : x5 (equipment)Clearing delay : 0Informing delay : 0Time to live : 0Operation instructions : Not defined

Specific problem : 70012 - SERVICE LEVEL DEGRADED BELOW THRESHOLD

Probable cause : 315 - Equipment malfunctionDefault severity : 4 (minor)Clearing : automaticAuto acknowledged : yesSwitch over update : noEvent type : x5 (equipment)Clearing delay : 0Informing delay : 30000Time to live : 0Operation instructions : Not defined

The type-specific parameters and their values are listed in Table 1 Type-specific alarm parameters.

DN09123463 13

Administering Alarms in mcRNC and Flexi Direct RNC

Id:0900d805809a70f0Confidential

Alarm parameter Description Value range

Specific problem

Identifies the specific problem causing the alarm; an alarm number. Static field that cannot be modified. The specific problems selected in the Alarm Parameter List dialog. For example, 70006.

Integer

Probable cause Categorizes the alarm into probable causes listed in 3GPP TS 32.111-2 annex B, Probable causes. Each Probable cause is mapped to a Specific problem. For example, Protection path failure.

String

Default severity

Indicates the default severity of the alarm, based on ITU-T rec. X733.

Critical

Major

Minor

Warning

Clearing Indicates whether the alarm is cleared automatically by the system or manually by the user. Static field that cannot be modified.

Manual

Automatic

Auto acknowledged

Defines whether the alarm is acknowledged automatically when cleared.

YesNo

Switchover update

(Changeover update)

Defines whether the active alarm is to be updated into the new active unit by the alarm system. If a unit switchover takes place, alarms with No as Switchover update value are cleared.

YesNo

Event type Categorizes the alarm based on the nature of the failure, as listed in ITU-T rec. X.733. Each Default event type is mapped to a set of probable causes.

Communications

Processing error

Quality of Service

Equipment

Environmental

Clearing delay Defines the clearing delay period, in milliseconds. Clearing delay is the period of time that the clearing of the alarm is delayed to filter the unnecessary cancellation if the alarm is raised again during the clearing delay.

Integer

If Clearing delay is not used, the value is zero (0).

Table 1 Type-specific alarm parameters

14 DN09123463

Administering Alarms in mcRNC and Flexi Direct RNC

Id:0900d805809a70f0Confidential

1.4.2 Instance-specific alarm dataEach alarm contains instance-specific data that is visible in the Alarm management application. The instance-specific alarm data refers to a specific alarm raised by an application.

The following are examples of an alarm output including instance-specific data.

Alarm ID : 114Specific problem : 70360 - UNSAVED CONFIGURATION IN USEManaged object : fsClusterId=ClusterRoot Severity : 5 (warning)Cleared : yesClearing : automaticAcknowledged : noAck. user ID : N/AAck. time : N/AAlarm time : 2011-08-10 18:00:02:143 EESTEvent type : x2 (processing error)Application : fsClusterId=ClusterRootIAppl Addl. info : Appl. Addl. info : Notification ID : 362 Extended event type : x1 (raise) Control indicator : 7 (full visible)

Informing delay

Defines the informing delay, in milli-seconds. Informing delay is the waiting period before the informa-tion concerning the raising of a new alarm in forwarded. Informing delay should be set to an alarm that has a tendency to be cleared almost immediately after it has been raised. If the alarm is cleared during the informing delay, both raising and clearing of the alarm is filtered as a false alarm.

Integer

If Informing delay is not used, the value is zero (0).

Time to live Defines the live time, in millisec-onds.Time to live is defined only if the alarm is to be cleared by the alarm system after the given time has passed.

Integer

If Time to live is not used, the value is zero (0). If the value is positive, then it must be greater than the Informing delay value.

Operation instructions

Possible instructions for handling the alarm.

String

Maximum length is 254 characters.

Alarm parameter Description Value range

Table 1 Type-specific alarm parameters (Cont.)

DN09123463 15

Administering Alarms in mcRNC and Flexi Direct RNC

Id:0900d805809a70f0Confidential

Alarm ID : 214452Specific problem : 7740 - BEATING WCDMA BTS ALARMManaged object : moid=WBTS-

325,fsLogicalNetworkElemId=NE-RNC-156,fsFragmentId=external,fsClusterId=ClusterRoot

Severity : 6 (cleared)Cleared : yesClearing : automaticAcknowledged : yesAck. user ID : Alarm LightAck. time : 2012-06-28 02:42:20:810 EESTAlarm time : 2012-06-28 02:42:20:810 EESTEvent type : x2 (processing error)Application : appid=fshaProcessInstanceName$E$QNOBHER

O$C$fshaRecoveryUnitName$E$QNOMUServer-0$C$fsipHostName$E$CFPU-0$C$fsFragmentId$E$Nodes$C$fsFragmentId$E$HA$C$fsClusterId$E$ClusterRoot,fsLogicalNetworkElemId=NE-RNC-156,fsFragmentId=external,fsClusterId=ClusterRoot

IAppl Addl. info : si=7750Appl. Addl. info : afamily=rnw

ai=1$S$0$S$0$S$0$S$0$S$0$S$0$S$0$S$0$S$0$S$0$S$0$S$0$S$0 atime=1340840538000 et=x2 modesc=WBTS-325 rawinfo=5077010000000000000000000000000000000000000000000000000000000000 utc=180

Alarm ID : 693Specific problem : 7661 - BASE STATION LICENCE

NOTIFICATIONManaged object : moid=WBTS-19,fsLogicalNetworkElemId=NE-

RNC-89,fsFragmentId=external,fsClusterId=ClusterRoot

Severity : 4 (minor)Cleared : noClearing : automaticAcknowledged : noAck. user ID : N/AAck. time : N/AAlarm time : 2012-06-29 10:32:56:002 EESTEvent type : x5 (equipment)Application : appid=fshaProcessInstanceName$E$QNOBHER

O$C$fshaRecoveryUnitName$E$QNOMUServer-0$C$fsipHostName$E$CFPU-

16 DN09123463

Administering Alarms in mcRNC and Flexi Direct RNC

Id:0900d805809a70f0Confidential

0$C$fsFragmentId$E$Nodes$C$fsFragmentId$E$HA$C$fsClusterId$E$ClusterRoot,fsLogicalNetworkElemId=NE-RNC-89,fsFragmentId=external,fsClusterId=ClusterRoot

IAppl Addl. info : si=64$S$1$S$64$S$4056FSMD$S$1$S$10Appl. Addl. info : afamily=rnw atime=1340955163960 et=x5

rawinfo=6401643430353646534D44202020011000000000000000000000000000000000 st=Verification$S$of$S$target$S$ID$S$failed$S$3$S$times. utc=180

The instance-specific alarm parameters and their values are listed in Table 2 Instance-specific alarm parameters.

Parameter Description Value range

Alarm ID Unique alarm identifier. For example, 1007.

Integer

Managed object

Identifier of the managed object that is the target of the alarm.

String

Severity Indicates the perceived severity of the alarm, based on ITU-T recommendation X733.

Critical

Major

Minor

Warning

Indeterminate

Cleared

Cleared Shows whether the alarm has been cleared or not.

YesNo

Clearing Indicates whether the alarm is cleared automatically by the system or manually by the user. Static field that cannot be modi-fied.

Manual

Automatic

Acknowledged The acknowledgement status of the alarm.

Yes

No

Ack. user ID ID of the user who has acknowl-edged/unacknowledged the alarm. By default not applicable if the alarm has not been acknowledged/unacknowl-edged.

String

Table 2 Instance-specific alarm parameters

DN09123463 17

Administering Alarms in mcRNC and Flexi Direct RNC

Id:0900d805809a70f0Confidential

Ack. time Date and time when the alarm was acknowledged/unacknowl-edged.

The default value is null.

Alarm time Date and time when the alarm was raised, cleared, or its severity was changed.

For example, Fri Jan 09 18:47:34 EET 2005.

Event type Categorizes the alarm based on the nature of the failure, as listed in ITU-T rec. X.733. Each Event type is mapped to a set of probable causes.

Communications

Processing error

Quality of Service

Equipment

Environmental

Application Identifier for the instance of the application that has raised the alarm.

String

IAppl Addl. info

Identifying additional informa-tion on the alarm.

String

Appl. Addl Info

Non-identifying additional infor-mation on the alarm.

String

Notification ID

Unique identifier created to every alarm event (raise/can-cel/change/acknowledgement) assigned by the alarm system. Alarm ID identifies every active alarm instance (set+can-cel pairs), whereas Notification ID identifies every single alarm notification that the system can generate.

Integer

Extended event type

Type of the alarm event itself. x1 = alarm raise

x2 = alarm data change (for an active alarm)

x3 = alarm acknowledgement

x4 = alarm canceling

Parameter Description Value range

Table 2 Instance-specific alarm parameters (Cont.)

18 DN09123463

Administering Alarms in mcRNC and Flexi Direct RNC

Id:0900d805809a70f0Confidential

Details on additional information for RNW alarms are described in Table 3 Alarm addi-tional information for RNW alarms

Control indicator

Bitmask value that indicates vis-ibility of the alarm.

0 = full invisible

1 = alarm is reported to NetAct

2 = alarm is visible in local UI (for example, OMS FM GUI)

4 = alarm is sent to OMS

7 = full visible

Additional information parameter Description

si Identifying supplementary information fields of the alarm. There can be more than one si fields, in which situation $S$ fillers are used to separate individual fields. Compare: alarms 7740 and 7661 in 1.4.2 Instance-specific alarm data. A missing si tag means that there are no identifying information fields for the given RNW alarm.

afamily Internal value for the alarm system. It indi-cates that a given alarm is an RNW alarm.

ai Rest of the supplementary information fields (non-identifying ones).

atime Actual time of the alarm event. In case of BTS-originated alarm, it means the time-stamp sent by the BTS in alarms.

et Event type that originates from application SW or BTS. It might or might not be the same as Event type.

modesc Managed object description. It is the name of the WBTS object that the user has defined in RNW DB.

rawinfo Information specific to alarm system only. It contains the original supplementary byte buffer that the RNW alarm system needs if it has to read alarms from Flexi-Platform alarm system.

Table 3 Alarm additional information for RNW alarms

Parameter Description Value range

Table 2 Instance-specific alarm parameters (Cont.)

DN09123463 19

Administering Alarms in mcRNC and Flexi Direct RNC

Id:0900d805809a70f0Confidential

st Supplementary text for the alarm. A missing st tag means that the alarm does not have any supplementary text included.

utc Alarm timestamp difference from the UTC time.

Additional information parameter Description

Table 3 Alarm additional information for RNW alarms (Cont.)

20 DN09123463

Administering Alarms in mcRNC and Flexi Direct RNC

Id:0900d805809a70f1Confidential

1.5 Alarm flowAlarms inform users about the faults in the system. The solution to a fault can be an automatic recovery administered by the system or a manual corrective action by the operator. Furthermore, the system can raise informative alarms about events that do not necessarily require any corrective actions.

The information of an alarm event that requires corrective actions by the operator proceeds from the detection of a fault in a system to the clearing of the alarm as described below.

1. The system detects a fault.2. The alarm application sends an alarm notification to the alarm processor through the

convenience libraries.3. The alarm processor reads the notification and processes it.4. The alarm processor updates the list of active alarms with the processed data. 5. The alarm management application, polls the alarm system for the list of active

alarms using the Alarmlightlib.6. The Alarmlightlib reads the list of active alarms and sends it to the alarm manage-

ment application for displaying it to the user.

Figure 1 A fault is detected and an alarm raised

g Step 7 is needed only if the alarm requires manual canceling.

7. Once the problem is solved, a request to clear the alarm comes from the OMS. Application SW is also involved; it sends the alarm cancel request to the RNW alarm system to check if it has to cancel the alarm.

8. The Alarmlightlib writes the request to clear the alarm to the alarm system database.9. The alarm processor reads the request in the alarm repository. If the alarm proces-

sor accepts the request, it removes the cleared alarm from the list of active alarms.

DN09123463 21

Administering Alarms in mcRNC and Flexi Direct RNC

Id:0900d805809a70f1Confidential

Figure 2 User clears the alarm

8 7

9

22 DN09123463

Administering Alarms in mcRNC and Flexi Direct RNC

Id:0900d805809a7179Confidential

1.6 Alarm blockingThe alarm blocking filters incoming alarm notifications, and it does not allow incoming alarm notifications to be processed further. The alarm blocking manages the alarm numbers and optionally, the managed objects linked with the alarm, for which the blocking rule is applied. If the blocking rule is activated, the next raise / clear alarm noti-fications are blocked and the existing alarms in the list, matching the blocking rule are automatically cleared by the alarm system. The blocked alarms with auto acknowledge-ment are acknowledged by the alarm system, the moment they are cleared. The blocked alarms without auto acknowledgement are manually acknowledged.

The blocking rule can be applied for the internal alarms and does not work for the external alarms. Notification ID is used to differentiate between the alarms, as it is always defined.

The alarm agent provides Java and the C++ application programming interface (API) to manage the alarm blocking. The API has a set of blocking rules defined and enables the following operations:

• Adding the blocking rule to the list • Removing the blocking rule from the list • Activating or deactivating the blocking rule • Searching for an available blocking rule in the list • Providing a list of available blocking rules

The blocking rule includes alarm number as a mandatory parameter and managed object as an optional one. The MOID provided must be a full managed object name or part of the managed object ID (MOID) flanked by the wildcard %--%MOID%, for example %NE3sAgent%. Blocking rule can be in the active (blocking is enabled) and non-active (blocking is disabled) state. The activating, deactivating, deleting and querying opera-tions can be performed to change the state of the blocking rule.

The blocking rule can be added into the system either as active or non-active. After adding into the system, the blocking rule gets a rule-id, which is an unique-id, required for further operations like activating or deactivating the rules. The alarm processor filters the corresponding alarm notifications based on the list of active blocking rules. The alarm processor logs the filtered alarm notifications into the syslog.

g It is not necessary to restart the alarm processor to enable the existing active or non-active blocking rules. A new record is added to the alarm system database that contains a list of blocking rules. If the added record is enabled, then a new record is not added. The old record's status is changed to active. The permissions applicable for the fsalarmagent must be provided to the users linked with the applications using the alarm agent library.

DN09123463 23

Administering Alarms in mcRNC and Flexi Direct RNC

Id:0900d805809a717aConfidential

1.7 Alarm filtering with identifying fieldsA single alarm can be identified by the identifying fields. The identifying fields are:

• Managed Object ID • Specific Problem • Identifying Additional Information • Application ID

The descriptions and possible values of these fields are listed in the alarm parameter tables.

When two alarm instances have the same values for all the identifying fields, the alarm instances are interpreted to be the same alarm. If the same alarm is raised when it is already active, the new alarm is filtered out.

The alarm system offers filtering properties to reduce the number of published alarm reports and to give the user only a useful amount of fault indication information. Repeated alarms that have the same information content are filtered out, and a new alarm is raised only when the value in one or more of the identifying fields has changed in comparison to the currently active alarms.

However, if an alarm is repeated with the same identifying fields but with a different per-ceived severity, the alarm is considered changed and is updated in the alarm repository.

g If an alarm with non-zero Time to Live is repeated with the same identifying fields and same or different severity, its Time to Live is extended up to the expiration time defined for the last repetitive raise.

24 DN09123463

Administering Alarms in mcRNC and Flexi Direct RNC

Id:0900d805809a7178Confidential

1.8 Radio network alarmsRadio Network alarm handling is provided by a specific application alarm handler in the RNC, the RNW Alarm System. RNW Alarm System handles all the alarms that are set by RNC application layer processes and are targeted to Radio Network objects (RNW alarms). The Radio Network objects appearing in RNW alarms are WBTS and WCEL. RNW Alarm System is also responsible for keeping track of underlying Radio Network alarm situation, that is alarm from BTSs.

The RNW Alarm System collects alarms reported by BTSes over the BTS O&M inter-face. The alarm situation between the RNC and individual base stations is synchronized automatically when needed, which ensures that alarm situation is up-to-date in the RNC. RNW Alarm System provides basic filtering tasks intended for application level alarm handlers. For more information, see General overview of RNC fault management.

The RNW Alarm System provides a configurable suspend mode for the alarms that are set by RNC applications for RNW objects. This functionality prevents RNC alarm system and also alarm monitoring tools from exhaustion if a large scale RNW outage occurs that causes, for example, a large number of WCEL alarms at once. RNW Alarm System limits the number of active alarms belonging to predefined fault categories to a defined level when it is apparent that there is a common reason for a large number of alarms. One such a reason can be, for example, a failure in a common resource that is shared by all the faulty RNW objects. During suspend mode RNW Alarm System buffers inter-nally all the alarms and when the number of active alarms belonging to a suspended fault category decreases, the buffered alarms can get activated.

The suspend mode activation for a certain fault type is notified with a separate alarm (2881, RNW ALARM SYSTEM SUSPEND MODE ACTIVATED) that contains informa-tion on the fault type that was observed in large quantities. The corresponding alarm manual page contains instructions on how to analyze the fault situation. The alarm is cleared automatically after there are no more buffered alarms in the system for the given fault type.

The BTS-level failures, detected in the RNC, are indicated by the BTS-level alarms. The cell-level alarms are not reported separately. The RNC detects failures that affect all the working cells under the BTS. A WBTS-object specific alarm, 7786 WCDMA BASE STATION OUT OF USE, is used when the whole BTS is affected because of the failure. This reduces the alarms generated by the system and improves the reliability and per-formance of the system. If the cell-level alarms are desired instead, it can be configured in the RNC.

Special handling for FTM alarms in RNCThe RNC implements some special handling for certain alarms from BTS sites. Basic BTS alarms targeted to WBTS and WCEL objects are handled in a straightforward fashion, but FTM module alarms in the Flexi WCDMA BTS are handled in encapsulated format. This means that the data of each individual FTM alarm instance is encapsulated by BTS into a specific BTS alarm (targeted to a WBTS object) and it is stored in this format into the RNC alarm system. In the Element Manager and NWI3 reporting inter-faces the encapsulation is removed so that the original FTM alarm data is displayed to the user in EM and in NetAct. This encapsulation is implemented because FTM alarm data content is not compatible with RNC alarm system as such. The encapsulated FTM alarms are shown as 7665 BASE STATION TRANSMISSION ALARM alarm instances in RNC printouts. If there are multiple FTM alarms active for the same BTS site, then there are multiple instances of alarm number 7665 active for the same WBTS object.

DN09123463 25

Administering Alarms in mcRNC and Flexi Direct RNC

Id:0900d805809a7178Confidential

See the alarm manual page for alarm 7665 BASE STATION TRANSMISSION ALARM in Multicontroller RNC and IPA-RNC Base Station Alarms (7000-7900) for details on how FTM alarm is encapsulated in this alarm.

The Flexi Direct RNC alarm system is based on FlexiPlatform. The functional environ-ment is similar to the one presented in Figure 3.

Figure 3 mcRNC fault management functional environment

26 DN09123463

Administering Alarms in mcRNC and Flexi Direct RNC

Id:0900d805809c23ebConfidential

1.9 Alarm correlationWhen a managed object (MO) is switched over, the alarms raised against the MO becomes obsolete and needs to be cleared or updated. Similar situations arise when a cluster is restarted. All the alarms raised before the restart are obsolete and has to be cleared.

The alarm processor makes the alarm correlation by using the information provided by high availability services (HAS) in the form of alarms.

The following alarms from HAS trigger the alarm correlation:

• 70159 MANAGED OBJECT FAILED • 70166 MANAGED OBJECT LOCKED • 70168 CLUSTER STARTED (RESTARTED) • 70186 CLUSTER OPERATION INITIATED BY OPERATOR • 70188 MANAGED OBJECT SHUTDOWN BY OPERATOR • 70194 RECOVERY GROUP SWITCHOVER

g For alarm 70168, all active alarms are subjected to correlation.

The following rules apply to alarm correlation:

• To reduce manual actions required for the user, the alarm system automatically clears or updates obsolete alarms.

• The alarm system updates alarms that were raised by switched over application (HAS informs the alarm system about the switchover by sending the 70194 alarm) if the alarms supports switchover, updates are not cleared and does not require manual clearing. If the alarms do not support switchover, updates (but the other mentioned conditions are valid) are cleared.

1.9.1 Alarm correlation for 70168Alarm 70168 is an informative alarm indicating that the whole cluster has been (re)started. It acts as a trigger to the Light Alarm System to clear alarms that were raised before the restart and have now become obsolete. However this behavior in Light Alarm System is configurable.To clear alarms on a cluster restart, Light Alarm System has added two new attributes to the Configuration Directory.

• fsLightClearAlarmsOnNEResetThis parameter implies what type of alarms (manual or automatic) need to be cleared.The permissible values for this parameter are as follows: • all: This value implies that all alarms (both manual and automatic) are cleared

on a cluster restart. • none: This value implies that none of the alarms raised before the cluster restart

are cleared. This is the default value set in the Configuration Directory. • automatic-only: This implies that only automatically cleared alarms in active

alarm list are cleared on cluster restart. • fsLightExcludeRangeFromNEResetRule

This parameter implies that alarms within a range of specific problems (SP) should

DN09123463 27

Administering Alarms in mcRNC and Flexi Direct RNC

Id:0900d805809c23ebConfidential

not be cleared on a cluster restart. This is a multivalued parameter and multiple ranges can be specified using this parameter.The possible values for this parameter are as follows: • SPlow-SPhigh: This implies that the alarms from SPlow through SPhigh

should not be cleared. The valid range is 0 < SPlow < SPhigh.

g The hyphen between the two values is mandatory.

• none: This implies that no SPs need to be excluded during clearing of alarms. This is the default value set in the Configuration Directory.

g The command show alarm active gives a different output in “structured mode” and “pretty mode”. The example above is in structured mode.

28 DN09123463

Administering Alarms in mcRNC and Flexi Direct RNC

Id:0900d805809a7199Confidential

Alarm monitoring with SCLI

2 Alarm monitoring with SCLI

2.1 Permissions

2.1.1 Permissions for SCLI commandsUser must have correct permissions for executing SCLI commands. To execute the fol-lowing SCLI commands the corresponding permissions are required:

For more detailed description on the various permissions supported, see Security guide.

For more information on managing user accounts, see Administration Guide.

Commands Permissions

add or delete fsASManageConfig

modify (set) fsASTest, fsASClearAlarm, fsASManageAcknowledgement, and/or fsASManageConfig

show fsASView

Table 4 Permissions to execute the SCLI commands

DN09123463 29

Administering Alarms in mcRNC and Flexi Direct RNC

Id:0900d805809a717cConfidential

2.2 Acknowledging and unacknowledging alarmsPurposeAcknowledge alarms to indicate to other users of alarm system that you are handling the alarms. Unacknowledge an alarm to release it for others to process.

Steps

1 Log into the SCLI shell.

2 Acknowledge an alarm.In the command line interface, enter:

set alarm acknowledge alarm-id <alarm-id>

3 Unacknowledge an alarm.In the command line interface, enter:

set alarm unacknowledge alarm-id <alarm-id>

g The acknowledgment status is visible only in SCLI.

30 DN09123463

Administering Alarms in mcRNC and Flexi Direct RNC

Id:0900d805809a717dConfidential

2.3 Adding alarm typesPurposeTo add a new alarm type(s).

Steps

1 Log into the SCLI shell.

2 Add alarm type from file.In the command line interface, enter:

add alarm type from-file file-path <file-path>

In the command, <file-path> is the argument specifying the absolute file path to the alarm type xml file under your home directory path.

g If you are logged in as root, place the file under /home (as the user root does not have a home directory) and provide the absolute path.

Example: To add an alarm type file located in the home directory, enter:

add alarm type from-file file-path /home/ \alarmxmls/testspexists.xml

The following output is displayed:

AlarmType Added successfully

3 Add alarm type from directory.In the command line interface, enter:

add alarm type from-directory dir-path <dir-path>

In the command, <dir-path> is the argument specifying the absolute file path to the directory where the file is placed.

g If you are logged in as root, place the file under /home (as the user root does not have a home directory) and provide the absolute path.

Example: To add an alarm type file located in the home directory, enter:

add alarm type from-directory dir-path /home/alarmxmls/

The following output is displayed:

AlarmType Added successfully: /home/testalarmxml//test1.xml

DN09123463 31

Administering Alarms in mcRNC and Flexi Direct RNC

Id:0900d805809a717eConfidential

2.4 Changing the alarm type definitionPurposeTo update the information of existing alarm type definition with values provided by the user. The alarm type definition is updated for a given specific problem.

Steps

1 Log into the SCLI shell.

2 Change the alarm type definition for specific problem.In the command line interface, enter:

set alarm type specific-problem <specific-problem> \ [auto-acknowledged <auto-acknowledged-value>] \ [clearing-delay <clearing-delay-value>] \ [default-severity <default-severity-value>] \ [informing-delay <informing-delay-value>] [switchover-update <switchover-update>] [time-to-live <time-to-live>]

The parameters and their values are described in the following table:

Note that after you have modified any of the alarm type parameters, descriptions of the existing alarms will still show the original reference values. It is only the newly generated alarms that will show the modified alarm type parameters. The original values are saved in the alarm system and can be restored using the alarm management application.

Alarm type parameter

Description Value Range

auto-acknowledged

Shows if the alarm is autoacknowledged or not. When the parameter value for Autoacknowl-edged is On, it means that when an alarm is cleared, it is acknowledged automatically.

The accepted values are on or off.

clearing-delay

Shows the clearing delay period of the alarms in milliseconds.

The accepted value is a number.

default-severity

Alarm-type-specific parameter; defines the severity level of the alarm.

The accepted value is a number.

informing-delay

Shows the informing delay period of the alarms in milliseconds.

The accepted value is a number.

switchover-update

Shows if the active alarm is to be updated into the new active unit by the alarm system when a unit switchover takes place. Alarms with empty switchover update value are cleared then.

The accepted values are on or off

time-to-live Shows the lifetime of the alarms in millisec-onds. If the Time To Live value is not specified, the alarm stays active until it is explicitly cleared either by the application that raised it or by the user.

The accepted value is a number.

Table 5 Alarm type parameters

32 DN09123463

Administering Alarms in mcRNC and Flexi Direct RNC

Id:0900d805809a717eConfidential

3 Restore the default alarm type definition for specific problem.In the command line interface, enter:

set alarm type-restore-defaults specific-problem <specific-problem>

DN09123463 33

Administering Alarms in mcRNC and Flexi Direct RNC

Id:0900d805809a717fConfidential

2.5 Clearing automatic alarmsPurposeTo manually clear automatic alarms.

SummaryThe system automatically clears some alarms after the fault has been corrected. In this case you cannot clear the alarm manually. To manually clear automatic alarms you must use forced option while clearing.

Steps

1 Log into the SCLI shell.

2 Clear specific alarm.In the command line interface, enter:

set alarm clear forced yes alarm-id <alarm-id>

This command clears one alarm with a specified alarm ID.

The possible values for forced are as follows:

g By default, fsLightManualAlarmClearingEnabled is set to false in LDAP. If fsLightManualAlarmClearingEnabled is set to true, it allows clearing of automat-ically cleared alarms through the management interface using the set alarm clear command without the force keyword. This parameter does not affect manually cleared alarms set by alarm-type definition.

3 Restart the alarm system.To restart the alarm system, enter the following command:

set has restart managed-object /AlarmSystemLight

4 Clear specific alarm.In the command line interface, enter:

set alarm clear alarm-id <alarm-id>

This command clears one alarm with a specified alarm ID.

Option Value Description

forced yes Both manual and auto-matic alarms will be cleared.

no Only manual alarms will be cleared.

Table 6 Forced values

34 DN09123463

Administering Alarms in mcRNC and Flexi Direct RNC

Id:0900d805809a717fConfidential

5 Clear alarms by the given criteria.

g If you press Enter without specifying any filter name after filter-by option in the command, then all alarms will be cleared by default.

It is possible to clear more than one alarm at once by using the given criteria. In the command line interface, enter:

set alarm clear-matching-alarms forced yes filter-by [<filter-name> <filtervalue>

The option filter-by <filter-name> <filter-value> provides the possibility to clear the alarms by using the given criteria. The possible options for filter and their values are shown in the following table:

Filter name Description Value Range

application-id This option filters alarms with specified Application-ID.

The accepted value is a string of characters.

identifying-application-additional-info

This option filters alarms with specified Identifying Application Additional Info.

The accepted value is a string of characters.

managed-object This option filters alarms with specified Managed Object pattern.

The accepted value is a string of characters.

managed-object-full-name

This option filters alarms with specified Managed Object pattern in DN format.

The accepted value is a string of characters.

severity This option filters alarms with specified Severity.

The accepted value is number of severity.

specific-problem This option filters alarms with specified Specific Problem.

The accepted value is a number of the specific problem.

Table 7 Alarm filters

DN09123463 35

Administering Alarms in mcRNC and Flexi Direct RNC

Id:0900d805809a7180Confidential

2.6 Clearing manual alarmsPurposeWhen the fault that has caused the alarm has been corrected, the alarm is cleared. This is done either manually or automatically.

SummaryThe system automatically clears some alarms after the fault has been corrected. In this case the user cannot clear the alarm manually. This is indicated by the Clearing Info parameter value (Automatic/Manual). However, restrictions for manual clearing of the alarm can be removed, so that the manual clearing of the alarm after it was cleared auto-matically is possible.

Steps

1 Log into the SCLI shell.

2 Clear a specific alarm.In the command line interface, enter:

set alarm clear alarm-id <alarm-id>

This command clears one alarm with a specified alarm ID.

3 Clear alarms by the given criteria.

g If you press Enter without specifying any filter name after filter-by option in the command, then all alarms will be cleared by default.

It is possible to clear more alarms at once by using the given criteria. In the command line interface, enter:

set alarm clear-matching-alarms filter-by [<filter-name> <filter-value>]

The option filter-by <filter-name> <filter-value> gives the possibility to clear the alarms by using the given criteria. The possible options for filter and their values are shown in the following table:

Filter name Description Value Range

application-id This option filters alarms with specified Application-ID.

The accepted value is a string of characters.

identifying-application-additional-info

This option filters alarms with specified Identifying Application Additional Info.

The accepted value is a string of characters.

managed-object This option filters alarms with specified Managed Object pattern.

The accepted value is a string of characters.

managed-object-full-name

This option filters alarms with specified Managed Object pattern in DN format.

The accepted value is a string of characters.

Table 8 Alarm filters

36 DN09123463

Administering Alarms in mcRNC and Flexi Direct RNC

Id:0900d805809a7180Confidential

g Canceling RNW alarms with SCLI is not possible. An attempt to do so will result in the output as follows: Clear Operation failed: Alarm does not Exist or Alarm cannot be cleared manually. This concerns alarms within the range of 7400-7799. For canceling RNW alarms, OMS tools should be used instead.

severity This option filters alarms with specified Severity.

The accepted value is number of severity.

specific-problem This option filters alarms with specified Specific Problem.

The accepted value is a number of the specific problem.

Filter name Description Value Range

Table 8 Alarm filters (Cont.)

DN09123463 37

Administering Alarms in mcRNC and Flexi Direct RNC

Id:0900d805809a7181Confidential

2.7 Configuring number of alarms processed per secondPurposeTo configure the number of alarms processed per second through SCLI commands.

SummaryIn order to restrict central processing unit (CPU) usage of Alarm System, when it is bom-barded with alarm events (150-200 events/seconds continuously for 10 seconds or more) while the system has other critical tasks to perform, three attributes fsLightEventsProcessed, fsLightProcessingInterval, and fsLightProcessorSleepInterval have been added to Configuration Directory.

The number of alarms processed per second is dependant on the hardware used.

g Modifying of the parameters is not recommended without consulting a Nokia Siemens Networks representative.

Steps

1 Log into the SCLI shell by executing the fsclish command.

2 Configure the number of alarm events.To configure the number of alarm events, execute the following command:

set config attribute fsClusterId=ClusterRoot fsFragmentId=AlarmMgmt fsFragmentId=AlarmProcessors fsAlarmProcessorId=AlarmProcessor1 fsAlarmProcessorConfigurationId=Default attribute-list fsLightEventsProcessed <value>

Example: To configure the number of alarm events, execute the following command:

set config attribute fsClusterId=ClusterRoot fsFragmentId=AlarmMgmt fsFragmentId=AlarmProcessors fsAlarmProcessorId=AlarmProcessor1

Parameter Description

fsLightEventsProcessed

Number of events that the Alarm System is allowed to process under normal conditions in fsLightProcessingInterval milliseconds.

fsLightProcessingInterval

Time interval in milliseconds during which the ALarm System processes alarm events.

fsLightProcessorSleepInterval

Sleeping time of the alarm processor. Sleeping time is the duration left in a second after processing the alarm events (fsLightProcessingInterval) in milliseconds.(1000-fsLightProcessingInterval) milliseconds

Table 9 Parameters for configuring number of alarm events

38 DN09123463

Administering Alarms in mcRNC and Flexi Direct RNC

Id:0900d805809a7181Confidential

fsAlarmProcessorConfigurationId=Default attribute-list fsLightEventsProcessed 20

g To disable this feature, set any of the above three parameters to zero value.

3 Restart the alarm system.To restart the alarm system execute the following command:

set has restart managed-object /AlarmSystemLight

4 Verifying the set configuration.To verify if the values have taken effect, execute the following command:

show config fsClusterId=ClusterRoot fsFragmentId=AlarmMgmt fsFragmentId=AlarmProcessors fsAlarmProcessorId=AlarmProcessor1 fsAlarmProcessorConfigurationId=Default

The output displays the entire configuration of the Alarm System.You may verify the values of the set parameters.

DN09123463 39

Administering Alarms in mcRNC and Flexi Direct RNC

Id:0900d805809a7190Confidential

2.8 Configuring the alarm blocking rulesPurposeTo configure the alarm blocking rules for the alarm system.

SummaryAlarms can be blocked from being processed based on a specific problem (or a range of specific problems) and optionally a Managed Object Id. This combination of a range of specific problems and a managed object id is termed as a blocking rule. You can add, activate, deactivate, retrieve and remove blocking rules.

Multi-sp Blocking Rules are rules based on a range of specific problems.

Steps

1 Enable the Multi-sp Blocking Rules.To enable the Multi-sp Blocking Rules, based on a range of specific problems, to the Configuration Directory, parameter fsMultiSpBlockingRuleEnabled is set to true.

g By default fsMultiSpBlockingRuleEnabled is set to false.

To set the parameter for fsMultiSpBlockingRuleEnabled to true, enter the follow-ing command:

set config timeout 10000 attribute fsClusterId=ClusterRoot fsFragmentId=AlarmMgmt fsFragmentId=AlarmProcessors fsAlarmProcessorId=AlarmProcessor1 fsAlarmProcessorConfigurationId=Default attribute-list fsMultiSpBlockingRuleEnabled true attribute-list fsMultiSpBlockingRuleEnabled true

Restart the Alarm System for the configuration to be effective, by using the following command.

set has restart managed-object /AlarmSystemLight

g If Multi-sp rules are disabled, you can add rules based on a single sp, i.e, from specific problem and to specific problem remain same.

2 Add alarm blocking rule.To add the alarm blocking rule, enter the following command:

add alarm blocking-rule from-specific-problem <problem name> to-specific-problem < problem name> [managed-object-id <MO name>

Where, <problem name> is a number, for example 70001or 70002.

3 Show alarm blocking rule.To list the blocking rules in the alarm system, enter the following command:

show alarm blocking-rules all

To list the blocking rules specified by the unique rule id, enter the following command:

show alarm blocking-rules rule-id <rule-id>

40 DN09123463

Administering Alarms in mcRNC and Flexi Direct RNC

Id:0900d805809a7190Confidential

Where, rule-id is a unique-id assigned for each rule, by the alarm system.

4 Activate the alarm blocking rule.By default the rule is deactivated. To activate the rule for a specific rule-id, enter the fol-lowing command:

set alarm blocking-rule activate rule-id <rule-id>

Where, rule-id is a unique-id assigned for each rule, by the alarm system.

g Once a rule is activated, all alarms in the active list matching to the given rule are cleared and removed from the active list; and any matching alarm raised from thereon will not be processed.

g if there are two rules having the same range of Specific Problems and one has a MOID, and the other doesn't specify a MOID (meaning all alarms within the specific problem range are blocked). Though both rules can exists at the same time, only one can be acti-vated. The rules can have overlapping range of specific problems incase their MOID filters are different and none of these rules have an empty MOID as a filter.

5 Deactivate the alarm blocking rule.To deactivate the rule for a specific rule-id, enter the following command:

set alarm blocking-rule deactivate rule-id <rule-id>

Where, rule-id is a unique-id assigned for each rule, by the alarm system.

6 Delete alarm blocking rule.To delete the alarm blocking rule for a specific rule-id, enter the following command:

delete alarm blocking-rule rule-id <rule-id>

Where, rule-id is a unique-id assigned for each rule, by the alarm system.

DN09123463 41

Administering Alarms in mcRNC and Flexi Direct RNC

Id:0900d805809a7191Confidential

2.9 Raising a test alarmPurposeTo raise a test alarm.

Steps

1 Log into the SCLI shell.

2 Raise a test alarm.In the command line interface, enter:

set alarm raise application-id <application-id-value> \ managed-object <managed-object-value> specific-problem <specific-problem-value> \ managed-object <managed-object-value> specific-problem <specific-problem-value> event time <event-time-value>] [identifying-application-additional-info \ <identifying-application-additional-info-value>] [severity <severity-value>]

The mandatory parameters are in the following table:

The list of possible parameters and their values are shown in the following table:

Parameter Description Value Range

application-id The alarm will be created with this specific Application-ID.

application-id indicates the managed object ID of the application that raised or cleared the alarm.

The accepted value is a string of characters.

managed-object The alarm will be created with this specific Managed Object pattern.

managed-object indicates the ID of the faulty managed object.

The accepted value is a string of characters.

managed-object-full-name

This is the name of the managed object in HAS format.

The list of HAS names of RG and RU on the machine.

specific-problem The alarm will be created with this Specific Problem.

The specific problem value must be known by the alarm system.

The accepted value is a number of the specific problem.

Table 10 Mandatory parameters for raising test alarm

Parameter Parameter value

application-additional-info

The accepted value is a string of characters.

Table 11 Optional parameters for raising a test alarm

42 DN09123463

Administering Alarms in mcRNC and Flexi Direct RNC

Id:0900d805809a7191Confidential

Example: To raise a test alarm, enter the following command:

set alarm raise specific-problem 70002 application-id\ fshaProcessInstanceName=Ap_Test,fshaRecoveryUnitName=Ap_Test,\ fsipHostName=CLA-0,fsFragmentId=Nodes,fsFragmentId=HA,\ fsClusterId=ClusterRoot managed-object\ fshaProcessInstanceName=Mo_Test,fshaRecoveryUnitName=Mo_Test,\ fsipHostName=CLA-0,fsFragmentId=Nodes,fsFragmentId=HA,\ fsClusterId=ClusterRoot

The sample output is:

*** The ‘Alarm Notification’ to RAISE an Alarm was sent successfully. ***

event-time The accepted value is date in format DDMMYYYYHHMMSSsss.

identifying-application-additional-info

The accepted value is a string of characters. If one character should not be specified, use _ which represents it. If one or more characters should not be specified, use % which represents it.

severity The accepted value is number of severity.

Parameter Parameter value

Table 11 Optional parameters for raising a test alarm (Cont.)

DN09123463 43

Administering Alarms in mcRNC and Flexi Direct RNC

Id:0900d805809a7192Confidential

2.10 Viewing active alarm dataSummaryActive alarm data can be displayed according to chosen options from the command show alarm active. It is possible to select which alarm parameter will be shown and filter the output by giving the filtering criteria.

Steps

1 Log into the SCLI shell.

2 View active alarm data.To view the active alarm data in the system, enter:

show alarm active

The following are sample outputs:

Alarm ID : 114Specific problem : 70360 - UNSAVED CONFIGURATION IN USEManaged object : fsClusterId=ClusterRootSeverity : 5 (warning)Cleared : yesClearing : automaticAcknowledged : noAck. user ID : N/AAck. time : N/AAlarm time : 2011-08-10 18:00:02:143 EESTEvent type : x2 (processing error)Application : fsClusterId=ClusterRootIAppl Addl. info :Appl. Addl. info :

Alarm ID : 179554Specific problem : 7771 - WCDMA CELL OUT OF USEManaged object : moid=WBTS-3/WCEL-

4,fsLogicalNetworkElemId=NE-RNC-425,fsFragmentId=external,fsClusterId=ClusterRoot

Severity : 3(major)Cleared : noClearing : automaticAcknowledged : noAck. user ID : N/AAck. time : N/AAlarm time : 2012-06-28 15:41:59:054 HKTEvent type : x4 (quality of service)Application : appid=fshaProcessInstanceName$E$QNOBH

ERO$C$fshaRecoveryUnitName$E$QNOMUServer-0$C$fsipHostName$E$CFPU-0$C$fsFragmentId$E$Nodes$C$fsFragment

44 DN09123463

Administering Alarms in mcRNC and Flexi Direct RNC

Id:0900d805809a7192Confidential

Id$E$HA$C$fsClusterId$E$ClusterRoot,fsLogicalNetworkElemId=NE-RNC-425,fsFragmentId=external,fsClusterId=ClusterRoot

IAppl Addl. info :Appl. Addl. info : afamily=rnw ai=400$S$0d

atime=1340869267000 et=x4 rawinfo=0004000000000000000000000000000000000000000000000000000000000000 utc=480

Alarm ID : 179462Specific problem : 7750 - FAILURE IN WCDMA WBTS O&M

CONNECTIONManaged object : moid=WBTS-

2,fsLogicalNetworkElemId=NE-RNC-425,fsFragmentId=external,fsClusterId=ClusterRoot

Severity : 3(minor)Cleared : noClearing : automaticAcknowledged : noAck. user ID : N/AAck. time : N/AAlarm time : 2012-06-28 15:08:52:477 HKTEvent type : x1 (communications)Application : appid=fshaProcessInstanceName$E$QNOBH

ERO$C$fshaRecoveryUnitName$E$QNOMUServer-0$C$fsipHostName$E$CFPU-0$C$fsFragmentId$E$Nodes$C$fsFragmentId$E$HA$C$fsClusterId$E$ClusterRoot,fsLogicalNetworkElemId=NE-RNC-425,fsFragmentId=external,fsClusterId=ClusterRoot

IAppl Addl. info : si=1Appl. Addl. info : afamily=rnw ai=14608d

atime=1340867320000 et=x1 rawinfo=0110390000000000000000000000000000000000000000000000000000000000 utc=480

In case of many active alarm data records, the parameters from-index and how-many can be used for specifying displayed output.

DN09123463 45

Administering Alarms in mcRNC and Flexi Direct RNC

Id:0900d805809a7192Confidential

The option filter-by <filter-name> <filter-value> gives the possibility to filter the output by the given criteria. More than one filter option can by applied at the same time. The possible options for filters and their values are shown in the following-table:

Parameter Description

from-index <number>

This parameter will choose which row of alarm records the output starts from, which means the parameter specifies the starting index for retrieving the records. The from-index value of 1 specifies the latest alarm.

how-many <number>

This parameter will choose the number of rows of alarm records to be displayed, which equals the number of records to be retrieved.

Table 12 Parameters for viewing active alarm data

Filter name Filter description and value Value Range

acknowledged This option filters all alarms that are in Acknowledged state.

The accepted values are true or false.

application-id This option filters alarms with specified Application-ID.

The accepted value is a string of characters.

cleared This option filters alarms that are in Cleared state.

The accepted values are true or false.

identifying-application-additional-info

This option filters alarms with specified Identifying Application Additional Info.

g Information in the Additional infor-mation field is the correct one to be used if there is a discrepancy between content in MO field and Additional info field.

The accepted value is a string of characters.

managed-object This option filters alarms with specified Managed Object pattern.

The accepted value is a string of characters.

severity This option filters alarms with specified Severity.

The accepted value is the numeric value of severity.

specific-problem This option filters alarms with specified Specific Problem.

The accepted value is a number of the specific problem.

Table 13 Alarm filters

Numeric value Alarm severity

1 Indeterminate

2 Critical

3 Major

Table 14 Numeric value for the Alarm severity

46 DN09123463

Administering Alarms in mcRNC and Flexi Direct RNC

Id:0900d805809a7192Confidential

OrWhen viewing active alarm data, you might be interested only in one parameter of active alarms. There are several parameters of active alarms that can be viewed by SCLI commands. Only one parameter can be viewed and specified in the command. In the command line interface, enter:show alarm active [from-index < number>] [how-many < number>] \[application-ids[from-index<number>][how-many<number>]][filter-by<filter-by-value>] [managed-object-ids[from-index<number>][how-many<number>]] \ [probable-cause [from-index<number>][how-many<number>]][severities <severities - value>]\ [specific-problem[from-index<number>][how-many<number>]]

The option <parameter> <parameter-value> gives the possibility to choose which parameter of an active alarm will be displayed. The list of alarm parameters that can be specified for displayed output is shown in the following table:

Example: To view five acknowledged alarms with severity two, starting from eight record in the alarm repository, enter:

show alarm active from-index 8 how-many 5 filter-by acknowledged true severity 2

To view all severities of currently active alarms, enter:

show alarm active severities

4 Minor

5 Warning

6 Cleared

Parameter Parameter description and values Value Range

application-ids Shows all the Application IDs of active alarms.

The accepted value is a string of characters.

managed-object-ids

Shows all the Managed Object IDs of active alarms.

The accepted value is a string of characters

probable-causes Shows all the Probable Causes of active alarms.

The accepted value is a string of characters

severities Shows all the Severities of active alarms.

The accepted value is the numeric value of the severity level

specific-problem Shows all the Specific Problems of active alarms.

The accepted value is a number of the specific problem.

Table 15 Alarm parameters

Numeric value Alarm severity

Table 14 Numeric value for the Alarm severity (Cont.)

DN09123463 47

Administering Alarms in mcRNC and Flexi Direct RNC

Id:0900d805809a7192Confidential

3 View number of active alarms.In the SCLI, enter:

show alarm alarm-count [filter-by <filter-name> <filter-value>]

The possible options for filter and its values are shown in the Alarm Filters table.

Example: To view how many active alarms are in the system, enter:

show alarm alarm-count

The sample output is:

Number of Alarms : 47

Example: To view the number of uncleared and unacknowleged alarms with severity one present in the system, enter:

show alarm alarm-count filter-by cleared false severity 1 acknowledged false

The sample output is:

Number of Alarms : 47

48 DN09123463

Administering Alarms in mcRNC and Flexi Direct RNC

Id:0900d805809a7193Confidential

2.11 Viewing alarm historySummaryAlarm history data can be displayed according to chosen options from the command show alarm history. It is possible to select which alarm parameters will be shown and filter the output by the given filtering criteria.

Steps

1 Log into the SCLI shell.

2 View alarm history.To view the alarm history, enter the following command:

show alarm history

The sample output is:

Alarm ID : 114Specific problem : 70360 - UNSAVED CONFIGURATION IN USEManaged object : fsClusterId=ClusterRootSeverity : 5 (warning)Cleared : yesClearing : automaticAcknowledged : noAck. user ID : N/AAck. time : N/AAlarm time : 2011-08-10 18:00:02:143 EESTEvent type : x2 (processing error)Application : fsClusterId=ClusterRootIAppl Addl. info :Appl. Addl. info :Notification ID : 362Extended event type : x1 (raise)Control indicator : 7 (full visible)

The following is the command with various parameters specified:

show alarm history [from-index <number>] [how-many <number>] \ [filter-by <filter-name> <filter-value>]

In case of many alarm history records, the parameters from-index and how-many can be used for specifying displayed output.

Parameter Description

from-index <number> This parameter will choose which row of alarm records the output starts from, which means the parameter specifies the starting index for retrieving the records.

how-many <number> This parameter will choose the number of rows of alarm records to be displayed, which equals the number of records to be retrieved.

Table 16 Parameters for viewing alarm history

DN09123463 49

Administering Alarms in mcRNC and Flexi Direct RNC

Id:0900d805809a7193Confidential

The option filter-by <filter-name> <filter-value> gives the possibility to filter the output by the given criteria. More than one filter option can by applied at the same time. The possible options for filter and their values are shown in the following table:

Example: To view first five records of cleared alarms that were cleared between 01:00, 20th Nov 2011 and 23:00, 29th Nov 2011, enter:

show alarm history from-index 0 how-many 4 filter-by cleared true from-event-time 20-11-2011.01:00:00 to-event-time 29-11-2011.23:00:00

The output is:

Alarm ID : 621Specific problem : 70186 - CLUSTER OPERATION INITIATED BY OPERATOR

include-heartbeat-alarms

States if hearbeat alarms should be displayed in the list of events/alarms fetched.

Filter name Filter description and value Value Range

acknowledged This option filters all history records that are in Acknowl-edged state.

The accepted values are true or false.

application-id This option filters all history records with specified Applica-tion-ID.

The accepted value is a string of characters.

cleared This option filters all history records that are in Cleared state.

The accepted values are true or false.

from-event-time This option filters all history records that contain this speci-fied date and time.

The accepted value is date in format DDMMYYYYHHMMSSSSS.

managed-object This option filters all history records with specified Managed Object pattern.

The accepted value is a string of characters.

managed-object-full-name

This option filters all history records with specified Managed Object pattern in DN format.

The accepted value is a string of characters.

specific-problem This option filters all history records with specified Specific Problem.

The accepted value is a number of the specific problem.

to-event-time This option filters all history records that contain this speci-fied date and time.

The accepted value is date in format DDMMYYYYHHMMSSSSS.

Table 17 Alarm filters

Parameter Description

Table 16 Parameters for viewing alarm history (Cont.)

50 DN09123463

Administering Alarms in mcRNC and Flexi Direct RNC

Id:0900d805809a7193Confidential

Managed object : fshaRecoveryUnitName=FSFT_HAS_TEST_HIServer,fsipHostName=CLA-0,fsFragmentId=Nodes,fsFragmentId=HA,fsClusterId=ClusterRootSeverity : 6 (cleared)Cleared : yesClearing : automaticAcknowledged : noAck. user ID : N/AAck. time : N/AAlarm time : 201Event type : x4 (quality of service)Application : fshaProcessInstanceName=HASClusterManager,fshaRecover,fsipHostName=CLA-0,fsFragmentId=Nodes,fsFragmentId=HIAppl Addl. Info :Appl. Addl. Info : Recovery unit restarted by operator.Notification ID : 2703Extended event type : x4 (clear)Control indicator : 7 (full visible)

3 View number of alarm events.In the command line interface, enter:

show alarm history-count [filter-by <filter-name> <filter-value>]

The possible options for filter and its values are shown in the Alarm Filters table above.

Example: To view how alarm events are in the history, enter:

show alarm history-count

The output is:

Alarm Events count is: 1822

Example: To view how many uncleared alarm events with specific problem 71096 are in history, enter:

show alarm history-count filter-by cleared false specific-problem 71096

The output is:

Alarm Events count is: 82

DN09123463 51

Administering Alarms in mcRNC and Flexi Direct RNC

Id:0900d805809a7194Confidential

2.12 Viewing alarm manual and test instructionsPurposeTo view the alarm manual and the test instructions for the alarm type identified by a specific problem. The test instructions are the steps required to raise an alarm.

Steps

1 Log into the SCLI shell.

2 View the manual for an alarm.In the command line interface, enter:

show alarm manual specific-problem <specific-problem>

The parameter specific-problem <specific-problem> has a numeric value. It determines the specific problem for which the alarm manual is retrieved.

Further informationThe parameter specific-problem <specific-problem> or more precisely all specific problems defined in the system, can be checked by executing the command:

show alarm specific-problems

3 View test instructions for an alarm.In the command line interface, enter:

show alarm test-instructions specific-problem <specific-problem>

The parameter specific-problem <specific-problem> has a numeric value. It determines the specific problem for which the alarm test instructions information is retrieved.

g Test instructions should not be used in live NEs due to possible disturbances to the traffic.

52 DN09123463

Administering Alarms in mcRNC and Flexi Direct RNC

Id:0900d805809a7195Confidential

2.13 Viewing alarm recovery historyPurposeTo view the alarm recovery history.

SummaryAlarm recovery history data can be displayed according to the options chosen from the following command show alarm recovery-history. It is possible to filter the output displayed, based on the filtering criteria specified.

Steps

1 Log into the SCLI shell.

2 View alarm history.To view the alarm recovery history, enter the following command:

show alarm recovery-history

The sample output, for example could be as follows:

Alarm ID | Specific Problem | Alarm Text | Clearing Info | Event Type Name | Alarm Time | Perceived Severity | Acked | Ack Time | AckUser ID | Cleared | ManagedObject ID | Application ID | IAppl Additional Info | Appl Additional Info | Notification ID | Extended Event Type Name | Control Indicator

107948 70159 MANAGED OBJECT FAILED 1 x2 2010-10-20 11:33:04:992 IST 6 1 2010-10- 20 11:33:05:007 IST Alarm Light 1 fshaRecoveryUnitName=FSFTPServer,fsipHostName= CLA-1,fsFragmentId=Nodes,fsFragmentId=HA,fsClusterId=ClusterRoot fshaProcessInstanceName=HASNodeAgent,fshaRecoveryUnitName=FSNodeHAServer,fsipHostName=CLA-1,fsFragmentId=Nodes,fsFragmentId=HA,fsClusterId=ClusterRoot Cold active/standby RU failure: Important process FtpdIPv4Process has failed. 666198 x3 0

107952 70159 MANAGED OBJECT FAILED 1 x2 2010-10-20 11:33:05:069 IST 6 0 0 1 fshaRecoveryGroupName=FTP,fsFragmentId=RecoveryGroups,fsFragmentId=HA,fsClusterId=ClusterRoot fshaProcessInstanceName=HASClusterManager,fshaRecoveryUnitName=FSClusterHAServer,fsipHostName=CLA-1,fsFragmentId=Nodes,fsFragmentId=HA,fsClusterId=Cl usterRoot Double failure: Both RU"s in cold active standby RG are faulty. 66619 9 x4 0

You can choose to specify the filters based on the output desired. The same command can be executed as follows:

DN09123463 53

Administering Alarms in mcRNC and Flexi Direct RNC

Id:0900d805809a7195Confidential

show alarm recovery-history [filter-by <filter-name> <filter-value>]

The option filter-by <filter-name> <filter-value> gives the possibility to filter the output by the given criteria. More than one filter option can by applied at the same time. The possible options for filter and their values are shown in the following table:

Example: To view the recovery history for all nodes, specify the <filter name> as mo-type and <filter value> as node:

show alarm recovery-history filter-by mo-type node

The output is as follows:

Alarm ID | Specific Problem | Alarm Text | Clearing Info | Event Type Name | Alarm Time | Perceived Severity | Acked | Ack Time | AckUser ID | Cleared | ManagedObject ID | Application ID | IAppl

Filter name Filter description and value

Value Range

from-event-time This option filters all history records that contain this specified date and time.

The value-range is a date in format DD-MM-YYYY.HH:MM:SS.

managed-object This option filters all history records with specified Managed Object pattern.

The accepted value is a string of characters.

managed-object-full-name

This is the name of the managed object in HAS format.

The list of HAS names of RG and RU on the machine.

mo-type This option filters all history records with specified Managed Object typepat-tern

The value-range for mo-type is one of the following keywords:

cluster | node | rg | ru | process | other

action-type output can be filtered by HAS action type. Multiple action types may be chosen.

g The action type set is limited by the actions that can be extracted from HAS alarm mes-sages.

The value-range could be the following action types: lock | unlock | start | poweroff | shutdown | switchover.

to-event-time This option filters all history records that contain this specified date and time.

The value-range is a date in format DD-MM-YYYY.HH:MM:SS.

Table 18 Alarm filters

54 DN09123463

Administering Alarms in mcRNC and Flexi Direct RNC

Id:0900d805809a7195Confidential

Additional Info | Appl Additional Info | Notification ID | Extended Event Type Name | Control Indicator

35 70189 MANAGED OBJECT UNLOCKED BY OPERATOR 1 x4 2010-09-15 19:22:56:295 EEST 5 0 0 0 fsipHostName=CLA-0,fsFragmentId=Nodes,fsFragmentId=HA,fsClusterId=ClusterRoot fshaProcessInstanceName=HASClusterManager,fshaRecoveryUnitName=FSClusterHAServer,fsipHostName=CLA-0,fsFragmentId=Nodes,fsFragmentId=HA,fsClusterId=ClusterRoot Node unlocked by operator. 41 x1 0

36 70189 MANAGED OBJECT UNLOCKED BY OPERATOR 1 x4 2010-09-15 19:22:56:300 EEST 5 0 0 0 fsipHostName=AS-0,fsFragmentId=Nodes,fsFragmentId=HA,fsClusterId=ClusterRoot fshaProcessInstanceName=HASClusterManager,fshaRecoveryUnitName=FSClusterHAServer,fsipHostName=CLA-0,fsFragmentId=Nodes,fsFragmentId=HA,fsClusterId=ClusterRoot Node unlocked by operator. 42 x1 0

35 70189 MANAGED OBJECT UNLOCKED BY OPERATOR 1 x4 2010-09-15 19:22:56:989 EEST 6 0 0 1 fsipHostName=CLA-0,fsFragmentId=Nodes,fsFragmentId=HA,fsClusterId=ClusterRoot fshaProcessInstanceName=HASClusterManager,fshaRecoveryUnitName=FSClusterHAServer,fsipHostName=CLA-0,fsFragmentId=Nodes,fsFragmentId=HA,fsClusterId=ClusterRoot Node unlocked by operator. 45 x4 0

DN09123463 55

Administering Alarms in mcRNC and Flexi Direct RNC

Id:0900d805809a7196Confidential

2.14 Viewing notification ID of an alarmPurposeTo view all notification IDs of a specific alarm.

SummaryThe notification ID is a unique identifier (for the entire network element) assigned by the alarm system to every published alarm event (raise / clear / change / acknowledged /unacknowledged). Each alarm ID (the alarm unique identifier) can be associated with multiple notification IDs, but each notification ID is only linked to one alarm ID.

Steps

1 Log into the SCLI shell.

2 View notification IDs of an alarm.In the command line interface, enter:

show alarm notification-id alarm-id <alarm-id-value> [from-index <number>] \ [how-many <number>]

The parameter alarm-id <alarm-id-value> specifies the alarm for which the noti-fication IDs must be displayed. The accepted value for parameter alarm-id is a number.

Parameter Description

from-index <number> This parameter specifies the starting index for retrieving the records.

how-many <number> This parameter selects the number of rows of alarm records to be displayed, which is equal to the number of records to be retrieved.

Table 19 Parameters for viewing notification IDs of an alarm

56 DN09123463

Administering Alarms in mcRNC and Flexi Direct RNC

Id:0900d805809a7197Confidential

2.15 Viewing probable causes and specific problemsPurposeTo view all probable causes and specific problems used in the alarm system.

Steps

1 Log into the SCLI shell.

2 View probable causes used in the alarm system.Enter the following command:

show alarm probable-causes [from-index <number>] [how-many <number>]

3 View specific problems used in the alarm system.Enter the following command:

show alarm specific-problem [from-index <number>] [how-many <number>]

Parameter Description

from-index <number> This parameter allows you to specify the starting index number for retrieving the alarm records. Alarm records are displayed from the particular row number that you specify in the from-index <number> parameter.

how-many <number> This parameter allows you to choose the number of rows of alarm records to be displayed. The total number of records displayed is equal to the number that you specify in the how-many <number> parameter.

Table 20 Parameters for viewing probable causes used in the alarm system

Parameter Description

from-index <number> This parameter allows you to specify the starting index number for retrieving the alarm records. Alarm records are displayed from the particular row number which you specify in the from-index <number> parameter.

how-many <number> This parameter allows you to choose the number of rows of alarm records to be displayed. The total number of records displayed is equal to the number that you specify in how-many <number> parameter.

Table 21 Parameters for viewing specific problems used in the alarm system

DN09123463 57

Administering Alarms in mcRNC and Flexi Direct RNC

Id:0900d805809a7198Confidential

2.16 Viewing the alarm type definitionPurposeTo view the alarm type definition for the given specific problem.

Steps

1 Log into the SCLI shell.

2 View the alarm type definition for specific problem.In the command line interface, enter:

show alarm type specific-problem <specific-problem>

The parameter specific-problem <specific-problem> has a numeric value. It determines the specific problem for which the alarm type definition is retrieved.

3 View all alarm type definitions used in the alarm system.In the command line interface, enter:

show alarm type-all [from-index <number>] [how-many <number>]

Example: To view the alarm type definition for a specific problem, enter the following command:

show alarm type specific-problem 70002

The output is:

Specific problem : 70002 - INVALID SNMP TRAP COMMUNITY STRINGProbable cause : 153 - Corrupt dataDefault severity : 4 (minor)Clearing : manualAuto acknowledged : yesSwitch over update : yesEvent type : x2 (processing error)Clearing delay : 0

Parameter Description

from-index <number> This parameter allows the user to specify the starting index number for retrieving the alarm records. Alarm records are displayed from the particular row number which is specified in the from-index <number> param-eter.

how-many <number> This parameter allows the user to choose the number of rows of alarm records to be displayed. The total number of records displayed is equal to the number which is speci-fied in the how-many <number> parameter.

Table 22 Parameters for viewing all alarm type definitions used in the alarm system

58 DN09123463

Administering Alarms in mcRNC and Flexi Direct RNC

Id:0900d805809a7198Confidential

Informing delay : 0Time to live : 0Operation instructions : Not defined

Example: To view all the alarm type definitions used in the alarm system, enter the following command:

show alarm type-all from-index 10 how-many 5

The output is:

Specific problem : 70011 - NODE NOT RESPONDINGProbable cause : 315 - Equipment malfunctionDefault severity : 3 (major)Clearing : automaticAuto acknowledged : yesSwitch over update : noEvent type : x5 (equipment)Clearing delay : 0Informing delay : 0Time to live : 0Operation instructions : Not defined

Specific problem : 70012 - SERVICE LEVEL DEGRADED BELOW THRESHOLDProbable cause : 315 - Equipment malfunctionDefault severity : 4 (minor)Clearing : automaticAuto acknowledged : yesSwitch over update : noEvent type : x5 (equipment)Clearing delay : 0Informing delay : 30000Time to live : 0Operation instructions : Not defined

Specific problem : 70013 - IN-MEMORY DATABASE PARTITION GETTING FULLProbable cause : 351 - Threshold crossedDefault severity : 3 (major)Clearing : automaticAuto acknowledged : yesSwitch over update : noEvent type : x4 (quality of service)Clearing delay : 0Informing delay : 0Time to live : 0Operation instructions : Not defined

Specific problem : 70025 - POSSIBLE SECURITY THREAT IN NETWORK ELEMENTProbable cause : 351 - Threshold crossed

DN09123463 59

Administering Alarms in mcRNC and Flexi Direct RNC

Id:0900d805809a7198Confidential

Default severity : 4 (minor)Clearing : manualAuto acknowledged : yesSwitch over update : yesEvent type : x4 (quality of service)Clearing delay : 0Informing delay : 0Time to live : 0Operation instructions : Not defined

Specific problem : 70030 - DISK DATABASE IS GETTING FULLProbable cause : 151 - Storage capacity problemDefault severity : 3 (major)Clearing : automaticAuto acknowledged : yesSwitch over update : noEvent type : x2 (processing error)Clearing delay : 0Informing delay : 0Time to live : 0Operation instructions : Not defined

60 DN09123463

Administering Alarms in mcRNC and Flexi Direct RNC

Id:0900d805809a71a4Confidential

Alarm handling in OMS

3 Alarm handling in OMSOMS functionsOperation and Management Server (OMS) provides the NWI3 interface towards NetAct for alarm reporting and Element Management Interface (EMI) for RNC local manage-ment via OMS element manager. OMS application layer functionality collects alarms from FP AS and stores the alarms to OMS alarm system. OMS applications can also set alarms that are handled by OMS alarm system.

OMS interface to RNCOMS is connected to RNC with the BTS O&M interface which allows OMS to communi-cate using BTS O&M protocol messages. The counterpart for OMS alarm system in mcRNC/Flexi Direct RNC is the FP AS that sends the changes in alarm situation to OMS. OMS can also synchronize the alarm situation between itself and FP AS whenever needed, for example after connection break situations. OMS can also ask alarm cancellation from FP AS if the user has performed manual alarm cancelling task using the OMS EM. The changes in alarm situation are reflected in real-time to NetAct and OMS element manager.

OMS alarm systemOMS is implemented on top of FlexiPlatform that provides the alarm system functionality for OMS. FlexiPlatform alarm database is used to store the RNC alarm situation in OMS and it also functions as alarm history storage for the whole network element. FlexiPlat-form alarm system provides also an interface for OMS applications to set and clear alarms. OMS own alarms are visible locally via the Fault Management application in the OMS element manager.

For more information on alarm system in OMS, see Managing Faults with OMS.

OMS element manager (EM) supportOMS element manager provides Fault Management application for viewing and managing the alarm situation in the RNC, and also for controlling the RNC and OMS alarm system functionality.

NWI3 interface supportOMS works as a mediator between the RNC and NetAct and it provides NWI3 interface support for reporting and synchronizing alarms between these elements. Alarm syn-chronization is done on the basis of alarm situation in OMS, which means that RNC and BTS sites are not part of alarm synchronization scenario that is performed over NWI3.