NOKIA NMS/2000

Document number/Issue Copyright © Nokia Telecommunications Oy

NTC TAN 0704/1.1 en

1

NOKIA NMS/2000FOR MANAGING CELLULAR NETWORKS

FAULT MANAGEMENT

BASIC OPERATING PRINCIPLES AND PROCEDURES

User's Guide


NTC TAN 0704/1.1 en2

The information in this document is subject to change without notice and describes only the product definedin the introduction of this documentation. This document is intended for the use of NokiaTelecommunications' customers only for the purposes of the agreement under which the document issubmitted, and no part of it may be reproduced or transmitted in any form or means without the prior writtenpermission of Nokia Telecommunications. The document has been prepared to be used by professional andproperly trained personnel, and the customer assumes full responsibility when using it. NokiaTelecommunications welcomes customer comments as part of the process of continuous development andimprovement of the documentation.

The information or statements given in this document concerning the suitability, capacity, or performance ofthe mentioned hardware or software products cannot be considered binding but shall be defined in theagreement made between Nokia Telecommunicat ions and the customer. However, NokiaTelecommunications has made all reasonable efforts to ensure that the instructions contained in thedocument are adequate and free of material errors and omissions. Nokia Telecommunications will, ifnecessary, explain issues which may not be covered by the document.

Nokia Telecommunications' liability for any errors in the document is limited to the documentary correction oferrors. Nokia Telecommunications WILL NOT BE RESPONSIBLE IN ANY EVENT FOR ERRORS IN THISDOCUMENT OR FOR ANY DAMAGES, INCIDENTAL OR CONSEQUENTIAL (INCLUDING MONETARYLOSSES), that might arise from the use of this document or the information in it.

This document and the product it describes are considered protected by copyright according to theapplicable laws.

NOKIA logo is a registered trademark of Nokia Corporation.

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

Copyright © Nokia Telecommunications Oy 1998. All rights reserved.

No. of Edited by Author Approved by Previous issuepages (1) approved

E Hartikainen M Nurminen J Pulkkinen77/EIH 20 May 1998 22 Jan 1998 20 May 1998

Copyright © Nokia Telecommunications Oy 1997. All rights reserved.



TABLE OF CONTENTS

1 ABOUT THIS MANUAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.1 Contents of this Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.2 Where to Find Information on Fault Management . . . . . . . . . . . . . . . . . . . 61.3 Typographic Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2 FAULT MANAGEMENT PRINCIPLES. . . . . . . . . . . . . . . . . . . . . . . 112.1 Fault Management Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.2 Network Management Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3 INTRODUCTION TO NOKIA’S FAULT MANAGEMENT . . . . . . 163.1 Nokia FM Tools Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.1.1 Top-level User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.1.2 Alarm Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.1.3 Alarm Viewer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.1.4 Alarm Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.1.5 Alarm History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.1.6 Alarm Forwarder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.1.7 Alarm Filtering and Reclassification . . . . . . . . . . . . . . . . . . . . . . 233.1.8 Alarm Correlation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.1.8.1 Correlation Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.1.9 Alarm Statistics in PC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.1.10 Tools for Collecting Alarms from Third-party Elements . . . . . . 26

3.2 Life Cycle of an Alarm in the NMS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.3 Alarm Number Ranges. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.3.1 DX Equipment Alarms 0-5999 . . . . . . . . . . . . . . . . . . . . . . . . . . 293.3.2 BTS Alarms 7000-8999 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.3.3 Workstation Alarms 9000-9999. . . . . . . . . . . . . . . . . . . . . . . . . . 30

4 STRATEGIES FOR REDUCING THE ALARM FLOW . . . . . . . . . 314.1 Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314.2 Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.2.1 Why Filter Alarms? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334.2.2 What to Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344.2.3 Filtering Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344.2.4 Implementation of Alarm Filtering . . . . . . . . . . . . . . . . . . . . . . . 36

4.3 Correlation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.3.1 Correlation Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.3.1.1 Suppression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384.3.1.2 Count . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.3.1.3 Compression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.3.2 Relation Checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444.3.2.1 The Basic Rule. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454.3.2.2 Example of Situation in which Correlation Does Not Take

Place. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47



4.3.2.3 Example of Situation in which Correlation Does TakePlace. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

4.3.3 Implementation of Alarm Correlation . . . . . . . . . . . . . . . . . . . . . 554.4 Informing Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564.5 Reclassification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

4.5.1 Implementation of Alarm Reclassification . . . . . . . . . . . . . . . . . 57

5 OFFLINE ANALYSIS OF ALARMS. . . . . . . . . . . . . . . . . . . . . . . . . . 585.1 Alarm Statistics in PC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585.2 Working with Templates in Alarm Statistics in PC. . . . . . . . . . . . . . . . . . 595.3 Generating Reports with Alarm Statistics in PC . . . . . . . . . . . . . . . . . . . . 60

5.3.1 Using ready-made templates for routine reports . . . . . . . . . . . . . 605.3.2 Using ReportWizard for ad hoc reports . . . . . . . . . . . . . . . . . . . . 615.3.3 Automatic reports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

5.4 Example of Report Generation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

6 ALARM COLLECTION FROM THIRD-PARTY NETWORKELEMENTS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 646.1 SNMP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 656.2 ASCII . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 666.3 RPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

APPENDIX A. MAPPING OF DIFFERENT ALARM FORMATS . . . 68

INDEX. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

About this Manual



1 ABOUT THIS MANUAL

This manual gives an overall picture of the Nokia NMS tools which are used forFault Management in your network. It describes each of the tools, gives you allthe background information you may need when using the tools, and gives somepointers on using the NMS applications to achieve maximum efficiency innetwork monitoring.

This manual does not give you basic instructions in using the software userinterfaces. Those instructions are given in the individual Helps of the differentapplications.

1.1 Contents of this Manual

The information given in this manual includes chapters on:

• Chapter 2, Fault Management Principles, contains backgroundinformation on alarms and the Nokia NMS solution for working withnetwork alarms.

• Chapter 3,Introduction to Nokia’s Fault Management, briefly introduceseach of the NMS graphical applications used in fault monitoring.

• Chapter 4,Strategies for Reducing the Alarm Flow, gives a thoroughexplanation of the principles governing alarm filtering, auto-acknowledgement, reclassification, and correlation techniques, as well asin-depth information on Nokia’s filtering and correlation applications.

• Chapter 5,Offline Analysis of Alarms, contains a description of the NMSapplication Alarm Statistics in PC. The chapter introduces the basicfunctions of the application along with an example of usage.

• Chapter 6,Alarm Collection from Third-party Network Elements, brieflyoutlines Nokia’s solutions for multivendor environments.

• Appendix A,Mapping of Different Alarm Formats, contains informationon the differences between the alarm formats of DX and BTS elements andthe Nokia NMS alarm format. This is useful if you use both MMLs andNMS applications to view alarms.

About this Manual



1.2 Where to Find Information on Fault Management

The information you need for network monitoring, making filtering andcorrelation rules, and analysing alarm situations is contained in the alarmhandling applications’ Helps and in this manual. The Helps concentrate oninstructions for using the alarm handling applications, while this manual coversall other information necessary for developing an effective fault managementstrategy.

The Helps and this manual are both important and should be usedtogether if youwant to achieve the best results. In addition there are other library referencemanuals which contain information on FM applications and processes.

Information on Troubleticketing, FM databases, and FM processes andconfiguration files can be found in other user guides and reference guides in theNMS Library.

Information on the NMS alarm pipe, the alarms database, and cleaning thedatabase, are contained in system administrator’s guides.

For more information on integration third-party network elements to the NMS tocollect alarms from them, see your Nokia representative.

The following pictures give a map of FM information in Nokia NMSdocumentation.

About this Manual



Figure 1. Information in Helps about Using FM Software

F M I n f o i n O n l i n e H e l p s

A l a r m M o n i t o r- D e f i n i n g m o n i t o r i n g c r i t e r i a- U s i n g A l a r m M o n i t o r w i t h A l a r m C o r r e l a t i o n- A c k n o w l e d g i n g a n d c a n c e l l i n g a l a r m s

A l a r m H i s t o r y

- S e a r c h i n g t h e d a t a b a s e f o r a l a r m s- G e t t i n g i n f o r m a t i o n o n a l l a c t i v e a l a r m s i n t h e d a t a b a s e- G e t t i n g a l i s t o f t h e t o p 1 0 a l a r m i n g o b j e c t s i n n e t w o r k

A l a r m C o r r e l a t i o n R u l e E d i t o r

- C r e a t i n g / m o d i f y i n g c o r r e l a t i o n r u l e s- T a k i n g r u l e s i n t o u s e- D e l e t i n g r u l e s

- M a k i n g a f o r w a r d i n g c r i t e r i a s e t- T e s t i n g t h e f o r w a r d i n g

A l a r m F o r w a r d e r

A l a r m V i e w e r

- V i e w i n g a n d p r i n t i n g a l a r m s- S a v i n g a l a r m s t o a U N I X f i l e

- U p l o a d i n g a l a r m s f r o m a n e t w o r k e l e m e n t

A l a r m D a t a b a s e U p l o a d

- O p e n i n g t h e m a n u a l p a g e f o r a n a l a r m- H o w t o a d d c o m m e n t s t o a n a l a r m p a g e

A l a r m M a n u a l

- D i s p l a y i n g a n d p r i n t i n g t h e d a t a b a s e u s a g e s t a t u s- T a k i n g a b a c k u p o f t h e d a t a b a s e

D a t a b a s e F u n c t i o n s

F M R u l e E d i t o r

- M a k i n g f i l t e r i n g , a u t o - a c k , i n f o r m i n g d e l a y , a c k w i t h c a n c e l a n d r e c l a s s i f i c a t i o n r u l e s- S e a r c h i n g f o r a c t i v e r u l e s

T o p - l e v e l U s e r I n t e r f a c e

- U s i n g t h e a l a r m s m o d e- W o r k i n g w i t h i n t e r n a l a l a r m s

About this Manual



Figure 2.FM Information in NMS Online Library

F M B a s i c O p e r a t i n gP r i n c i p l e s & P r o c e d u r e s- U s e r ' s G u i d e s -

A b o u t a l a r m s

- A l a r m l i f e c y c l e- A l a r m n u m b e r r a n g e s- H o w D X & B T S a l a r m s m a p t o N M S a l a r m f o r m a t

F o c u s e d m o n i t o r i n g

- F i l t e r i n g a n d c o r r e l a t i o n- F i l t e r i n g i n t h e n e w F M R u l e E d i t o r- C o r r e l a t i o n t y p e s - s u p p r e s s i o n - c o u n t - c o m p r e s s i o n- R e l a t i o n c h e c k i n g- I n f o r m i n g d e l a y- A l a r m r e c l a s s i f i c a t i o n- A l a r m T r i g g e r

O f f l i n e a n a l y s i s o f a l a r m s

- A l a r m S t a t i s t i c s i n P C- W o r k i n g w i t h t e m p l a t e s- G e n e r a t i n g r e p o r t s

- S N M P - A S C I I- R P C

A l a r m c o l l e c t i o n f r o m t h i r d - p a r t yn e t w o r k e l e m e n t s

F M I n f o i n N M S O n l i n e L i b r a r y

F a u l t M a n a g e m e n t D a t a b a s e D e s c r i p t i o n- R e f e r e n c e G u i d e s -

- D e s c r i p t i o n o f a l l d a t a b a s e t a b l e s u s e d b y N o k i a ' s F M

T e c h n i c a l R e f e r e n c e G u i d e- R e f e r e n c e G u i d e s -

- F M u s e r i n t e r f a c e a p p l i c a t i o n s - h o w t o o p e n f r o m T o p - l e v e l U s e r I n t e r f a c e a n d f r o m t h e c o m m a n d l i n e- F M b a c k g r o u n d p r o c e s s e s- F M c o n f i g u r a t i o n f i l e s

T r o u b l e t i c k e t i n g B a s i cO p e r a t i n g P r i n c i p l e s a n d P r o c e d u r e s - U s e r ' s G u i d e s -

- U s i n g t h e T r o u b l e T i c k e t A p p l i c a t i o n- T r o u b l e t i c k e t i n g w o r k f l o w

About this Manual



Figure 3.FM Information in System Administrator’s Guides

F M I n f o i n S y s t e m A d m i n i s t r a t o r ' s G u i d e s

D a t a b a s e M a i n t e n a n c e

- C h e c k i n g t h a t a l a r m s a r e s t o r e d i n t h e d a t a b a s e- C l e a n i n g u p t h e a l a r m d a t a b a s e- C o n f i g u r i n g t h e a u t o m a t i c a l a r m d a t a b a s e c l e a n u p- E n a b l i n g o r d i s a b l i n g a l a r m s f o r a d a t a b a s e t a b l e- E n a b l i n g o r d i s a b l i n g s u p e r v i s i o n b y D a t a b a s e F u n c t i o n s- A l a r m p o i n t s a n d a l a r m l i m i t s- E s t i m a t e d m a x i m u m s i z e o f a d a t a b a s e t a b l e- U s a g e s t a t u s o f a d a t a b a s e t a b l e

W o r k s t a t i o n N e t w o r k M a i n t e n a n c e

- M o d i f y i n g a l a r m l i f t i n g r u l e s- A d d i n g a n d d e l e t i n g a l a r m p i p e s- V e r i f y i n g t h a t t h e m o n i t o r e d N E i s o n l i n e- V e r i f y i n g t h a t t h e N M S i s s h o w i n g t h e t r u e s t a t e o f t h e n e t w o r k- V e r i f y i n g t h a t a l a r m s a r e n o t b u f f e r e d i n t h e B S C- D i s a b l i n g a n d e n a b l i n g n e t w o r k a l a r m s- B l o c k i n g a l a r m s i n N E s- B l o c k i n g B T S a l a r m s i n t h e B S C- S e t t i n g u p p r i n t e r s i n A l a r m V i e w e r- I n s t a l l i n g c u s t o m i s e d s o u n d s f o r A l a r m V i e w e r

S y s t e m M a n a g e m e n t B a s i c O p e r a t i n g P r i n c i p l e s & P r o c e d u r e s

- A l a r m f l o w s u p e r v i s i o n- N M S a l a r m s y s t e m- A l a r m l i f t i n g- A l a r m p i p e s- I n f o r m i n g d e l a y

About this Manual


NTC TAN 0704/1.1 en10

1.3 Typographic Conventions

The Nokia NMS manuals use the following typographic conventions.

Table 1.Text styles in this document

Style Explanation

Initial Upper-CaseLettering

• Application names

• Hardware components

• Names of windows and dialogs

Italicised text • Emphasis

• State, status or mode

Courier • File and directory names

• Names of database tables

• Parameters

• User names

• System output

• User input

UPPER-CASELETTERING

• Keys on the keyboard (ALT, TAB, CTRL etc.)

Bold text • Graphical user interface components

Initial Upper-CaseLettering in Italics

• Referenced documents

• Referenced sections and chapters within adocument

<bracketed text> • Variable user input

Shaded box • Further information about command lineparameters

Fault Management Principles


NTC TAN 0704/1.1 en11

2 FAULT MANAGEMENT PRINCIPLES

There are a number of terms used throughout this document and in network faultmonitoring in general. The list which follows gives the definitions of severalbasic terms as they are used in this manual.

2.1 Fault Management Concepts

Alarm

A message which notifies the management system of an abnormal condition inthe managed system. The message carries quite a bit of information on theorigins, time, and possible reasons for the abnormal condition. In the NMS, thisinformation is broken down into different fields. The fields are put together tomake the alarms which are shown in the alarm handling applications.

All alarms have an alarm number which identifies the possible reason for thealarm. For example, alarm 9224, entitled SUPERVISION PROGRAM FAILED,indicates that one of the programs used to supervise the NMS system failed forsome reason.

Alarms are placed into a class which indicates their severity. There are threeclasses of alarms, plus the warning class, used in the NMS: critical, major, minor,and warning. Each operator has their own requirements for handling each class.Nokia recommends the following:

Cancel

A message which clears an alarm when a fault is over. In managing atelecommunications network, it is extremely important that the end of an alarmsituation is very clearly indicated in the NMS alarm handling applications. Ifalarms are not cancelled, then it is impossible to have a clear picture of the realsituation in the network.

Alarm Number (or Probable Cause)

Every alarm has an alarm number which identifies it. The values of alarmnumber may range between 1 and 99 999. For more information on alarmnumber ranges and which equipment they are assigned to, seeAlarm NumberRanges in Chapter 3 of this manual.

Alarm class Required actions

Critical (***) This type of alarm is likely to cause disturbances intraffic. Action must be taken on alarm within one hour

Major (**) Action must be taken within working hours

Minor (*) Does not require attention unless it occurs repeatedly

Warning (W) No actions required



NTC TAN 0704/1.1 en12

Alarm Text

The alarm text gives a brief description of the alarm.

Alarm Class

The alarm class represents the severity of the alarm. The alarm classes used inthe Nokia NMS are critical, major, minor, and warning.

Notification Identifier (or Notification ID)

The Notification ID is a running number which is assigned to each and everyincoming alarm as its unique identifier. This is necessary so that alarms andcancels can be matched together correctly. An alarm is identified by itsnotification ID, alarm number, and distinguished name. Because alarms can havethe same alarm number and distinguished name, the notification ID is needed toidentify each instance.

Only one active alarm with the same notification identifier, alarm number anddistinguished name is stored into the Nokia NMS database. In case twooccurrences of the same alarm (with the same alarm number and distinguishedname) are sent to the NMS, the latter one is considered a duplicate and causes anerror log entry.

Correlated Notification

The correlated notification is used in cancels. If the alarm is cancelled, the valueof the correlated notification is the same as the notification ID of the alarm to becancelled.

Event Type

The event type gives you more information on what kind of problem caused thealarm. There are five different event types used in the NMS:

communication An alarm that is associated with the procedures and/or processes required to convey information from onepoint to another (e.g. loss of frame, call establishmenterror).

environmental An alarm principally associated with a conditionrelating to an enclosure in which the equipmentresides (e.g. door open, electricity failure).

equipment An alarm concerning an equipment fault (e.g. powerproblem, receiver failure, I/O device error).

event processing Alarm type principally associated with a software ordata processing fault (e.g. storage capacity problem,version mismatch, corrupt data, file error, out ofmemory).



NTC TAN 0704/1.1 en13

quality of service An alarm that is associated with a certain degradationin the quality of service (e.g. response time too long,resource limits near, congestion).

Alarm Lifting

Alarm Lifting is a feature that re-targets the alarms of one object class - thesource object - to another object class - the target object. The alarms of theoriginal object class are shown as alarms of the new object class. The originalobject’s name is, however, given in the alarm information attached to the re-targeted alarm.

For more information on this, talk to your system administrator or seeSystemManagement Basic Operating Principles and Procedures.

Alarm Upload

With the alarm upload the current alarm status in the external system istransmitted to the Nokia NMS. After that the alarm database in the Nokia NMSis synchronised with that of the external system. This is necessary in thefollowing cases:

• After a network element is connected to the NMS for the first time

• After the connection between the NMS and the NE has been broken forsome reason (and alarms and cancels are not buffered), and then restored

• On a regular basis at certain intervals

NE Reset

When a network element is reset, it sends a specific alarm to the NMS, whichcauses certain active alarms in that managed object and in its child objects to becancelled. These alarms are defined in theFX_RULE database. After these arecancelled, the element sends a report on its current alarm situation to the NMS.

2.2 Network Management Concepts

Managed Object

A managed object represents a physical or logical network element or a piece ofequipment belonging to the network. This element is in some way connected tothe NMS, so that the NMS can be used to manage it by gathering information,such as information on alarms, from it.

Maintenance Region

A maintenance region is a logical managed object in the NMS object model. Itis a collection of managed objects which are grouped together, normally torepresent some geographical part of the network. Maintenance regions aredefined by the system administrator.



NTC TAN 0704/1.1 en14

Site Object

A site is a place where one or more of the elements of the network are situated.One site could contain more than one managed object. If there are multipleelements on one site, then the site object represents the element which is highestin the hierarchy on that site. For example, a site may contain an OMC as well asone of its workstations. In this case, the OMC is the site object.

Managed Object Class

All managed objects of the same type are grouped together to form a class. Thismakes it easier for the NMS to represent the elements in the network in a sensibleway.

In NMS software, each class is represented by its own symbol. These symbolscan be used in the Top-level User Interface to make graphical views of thenetwork. These views are very effective in helping NMS users visualise thenetwork as a whole.

Managed Object Instance

As a managed object class represents a type of network element, a managedobject instance represents one unique element. For example, Workstation is anobject class. One workstation sitting on the table is an instance of the class ofworkstations.

In practice, the termmanaged object or justobject is often used to refer to amanaged object instance.

Parent and Child Objects

Managed objects are often hierarchical, with certain objects controlling and/orcontaining others. This hierarchy is shown in the NMS object model as well. Theparent object controls or contains achild object.

Relative Distinguished Name

This name is used to help identify an object instance. It contains the managedobject class + a string which identifies the instance of that class, for example,WS-1. The relative distinguished name must be unique within the parent object.

Distinguished Name

This is an even more effective identifier of a particular managed object instance.It contains the relative distinguished name of the object instance in question, plusthe relative distinguished names of all of its parent objects. These are shown asa path of elements arranged in hierarchical order and separated by a slash (/). Forexample:

ClassName-InstanceValue/ClassName-InstanceValue/ClassName-InstanceValue



NTC TAN 0704/1.1 en15

or:

PLMN-1/OMC-2/WS-4

ClassName is an abbreviation for a managed object class name and consists ofnumbers or capital letters. Its maximum length is four characters. The maximumlength ofInstanceValue is ten characters, and the value should contain printablecharacters. These are often numbers, but do not have to be.

Topology

The topology of a network is the picture of the actual physical elements of thenetwork, where they are situated, and how they are related to each other.

It is important that this picture of the network is kept as consistent as possiblewith the actual physical network. It will then be an accurate representation of thatnetwork.

View

The Top-level User Interface uses views to picture a network or a part of it. Themanaged objects of the network are shown using symbols, and their relationshipsto each other are shown in the view using connecting lines. These views are veryeffective in helping NMS users visualise the network as a whole.

Introduction to Nokia’s Fault Management


NTC TAN 0704/1.1 en16

3 INTRODUCTION TO NOKIA’S FAULTMANAGEMENT

3.1 Nokia FM Tools Overview

The Nokia NMS offers you a comprehensive set of tools for collecting andmanaging network alarms. The function of the tools can be broken down into thefollowing areas:

The following sections give you a more thorough explanation of each of thesetools.

Area of Fault Monitoring NMS Tools

Online monitoring andinvestigating alarms

• Top-level User Interface

• Alarm Monitor

• Alarm Viewer

• Alarm Manual

• Alarm History

• Alarm Forwarder

• Alarm Database Upload

Alarm reduction • Alarm Filtering and Reclassification

• Alarm Correlation

Offline analysis of alarms • Alarm Statistics in PC

Alarm collection from third-party elements

• SNMP Integration Toolkit

• ASCII Integration Toolkit

• RPC Integration Toolkit

• Alarm Collection from SNMP, ASCII, andRPC



NTC TAN 0704/1.1 en17

3.1.1 Top-level User Interface

Figure 4.Top-level User Interface

The Top-level User Interface contains graphical views of the network, in whichnetwork elements are represented with symbols. The views are meant torepresent as closely as possible the actual elements belonging to the network.With these graphical views, the user has a quick but very comprehensive view ofthe network at all times.

One of the main functions of the Top-level User Interface in network monitoringis to show the alarm situation in all managed objects. The objects symbols areused to do this, changing colours to reflect the most severe alarm which iscurrently active in the object. The default colours and their meanings are:

Blinking is another way used in the Top-level User Interface to indicate the alarmsituation. When a symbol blinks, it means that there is at least oneunacknowledged alarm in that managed object.

Colour Meaning

Red At least one critical (***) alarm is active inmanaged object

Orange At least one major (**) alarm is active in object

Yellow At least one minor (*) alarm is active in object

Green No active alarms in object

White No alarms received yet from object

T o p - l e v e l U s e r I n t e r f a c e - m a p . v i e



NTC TAN 0704/1.1 en18

The Top-level User Interface is very effective for presenting this overall view ofthe network fault situation, but other applications are needed to examine thealarms more closely.

3.1.2 Alarm Monitor

Figure 5.Alarm Monitor and Explanation Dialog for Correlated Alarms

Alarm Monitor is your key tool in monitoring the network fault situation, as itgives you a real-time view of network alarms. Alarms are forwarded to AlarmMonitor as they come in to the NMS, so you have constant access to the mostrecent alarm information. Unacknowledged alarms are indicated by the blinkingof the object symbol, and users can acknowledge and cancel alarms directly inthe main window.

You can set up monitoring criteria, which narrows the focus of the monitoring tocover only the network areas or alarm numbers that you need. This makes itpossible to divide the network into regions and monitor each region separately.

The Monitor shows each alarm with the most basic information on it, includingthe symbol of the managed object where the alarm occurred, the alarm numberand text, the object's name, ID and address, and the maintenance region to whichthe object belongs. You have quick access to more comprehensive informationon the alarm through the Alarm Dialog and the Alarm Manual, both of which canbe opened directly from any of the alarms shown in Alarm Monitor.

To make it easier to pinpoint the most urgent alarms, the main window can bedivided into three panes. Each pane shows all alarms of one class, which aresorted in the order they come in to the NMS.

Another function which helps you to be aware of the network situation is theAudio Alarms feature, which allows you to assign a sound to different alarmclasses. When an alarm of a certain class comes in, the sound is given off. This

E x p l a n a t i o n D i a l o g

+

+

+

+

T T

C o r r e l a t e d A l a r m

O r i g i n a l A l a r m s

A l a r m M o n i t o r



NTC TAN 0704/1.1 en19

means that alarms can be monitored even when no one is sitting at the NMSworkstation.

As the most important application for following the network fault situation,Alarm Monitor also gives you other information on alarms, such as which alarmsare correlated and which have a Trouble Ticket attached to them. For correlatedalarms you can open the Explanation dialog, which contains information on thealarms which were correlated and the rule which caused the correlation. TheTrouble Ticket Application can be opened directly from Alarm Monitor.

Alarm Monitor allows you to acknowledge alarms and cancel those whichrequire manual cancelling. It indicates unacknowledged alarms by the blinkingof the object symbol.

3.1.3 Alarm Viewer

Figure 6.Alarm Viewer

All alarms, warnings, and cancels are shown in Alarm Viewer as they come in tothe NMS. It is a good tool for monitoring, for example, alarm/cancel pairs to getan idea of how quickly the alarms are getting cancelled.

You can narrow the focus of the Alarm Viewer to include only certain regions,making it possible to divide the network into areas and monitor each separately.You can also choose to see only alarms, only warnings, or both.

The Audio Alarms function is also present in Alarm Viewer. You can makedifferent sounds be generated for certain alarm classes, so that when an alarm ofthat class comes in, you are notified of it immediately even if you are not sittingat the NMS workstation.

You can use Alarm Viewer to direct incoming alarms to a printer for a record ofalarms on paper.




NTC TAN 0704/1.1 en20

3.1.4 Alarm Manual

Figure 7.Alarm Manual Application

The Modifiable Alarm Manual contains in-depth information on each alarm.There is a manual page for each alarm which describes the alarm and itsmeaning, gives an interpretation of any information given in the supplementaryinformation fields, gives instructions on how to overcome the problem, and tellsyou whether the alarm is cancelled automatically or if it requires manualcancelling.

At the bottom of each manual page is a separate pane where instructions can beadded. This makes it possible to attach your own instructions to an alarm for allother NMS users in your network.

The Alarm Manual is a handy tool because it can be accessed directly from analarm in several of the NMS alarm handling applications, such as Alarm Monitorand Alarm History.



NTC TAN 0704/1.1 en21

3.1.5 Alarm History

Figure 8.Alarm History Application

You have access to all alarms stored in the NMS database using Alarm History.You can use it to focus on certain areas or problems, with the possibility toobserve the alarm situation over a period of time. There are several criteria youcan use to help narrow down your search of the database, allowing you to focuson things like areas of the network, alarm types, alarm classes, and the time whenalarms occurred. Alarms can also be acknowledged and cancelled in AlarmHistory.

Alarm History can also provide you with quick statistics on the alarms in thedatabase. The Database Statistics dialog contains this information on:

• All active alarms in the database, by alarm class

• Top 10 alarming objects in network

The Top Alarming Objects pane tells you which 10 objects in the network havethe most active alarms. To get further information on the objects and theiralarms, you just drop the objects from the Database Statistics dialog directly intothe Setting the Search Criteria dialog and start a search.

The Alarm Counters dialog shows you statistics on active alarms in the database.The number of alarms in each class is given, with information on the followingcategories:

• Total number of active alarms for that class

• Number of active alarms which are not acknowledged yet

• Number of active alarms which are acknowledged

D a t a b a s e

A l a r m H i s t o r y S e t t i n g S e a r c h C r i t e r i a

S e a r c h b y :

M a n a g e d o b j e c tA l a r m s t a t eA c k s t a t eF i l t e r i n gA l a r m c l a s sA l a r m t y p eA l a r m t i m eA c k t i m eC a n c e l t i m eO b j e c t c l a s sA l a r m n u m b e rC o n s e c u t i v e n u m b e rA c k u s e r



NTC TAN 0704/1.1 en22

3.1.6 Alarm Forwarder

Figure 9.Alarm Forwarder Application

In order to ensure the service of the network at all times, certain alarms from themanaged system need to be forwarded without delay to the personnel responsiblefor fault study and correction. However, the assigned personnel may not bepresent at all times at the NMS site.

Alarm Forwarder lets you have key alarms forwarded automatically to e-mailaddresses or pagers. This feature can be used, for example, in communicationsbetween network monitoring centres and maintenance people, or in order toinform remote customer service centres of the alarm situation.



NTC TAN 0704/1.1 en23

3.1.7 Alarm Filtering and Reclassification

The biggest problem facing network monitoring personnel is the fact that theflow of alarms can be huge. Users have to notice alarms, decide which needattention first, focus on those, decide what they mean, and take correctiveactions. They have to do this in a matter of seconds. As the flow of alarms grows,the chance that an important alarm will go without notice also grows. For thisreason anything you can do to control and reduce the alarm flow is extremelyimportant.

The Nokia NMS provides you with three tools for reducing alarm flow: AlarmFiltering, Alarm Reclassification (these are also known as Alarm ParameterHandling) and Alarm Correlation.

Alarm Filtering allows you to block certain alarms from the NMS. You can blockthem only from the views of the alarm handling applications or you can blockthem entirely, so that they are not entered into the database. Another importantfunction of the Alarm Filtering application is auto-ack, which lets you definecertain alarms to be automatically acknowledged as they come in to the NMS.

Alarm Reclassification lets you assign a different class to an alarm so that youmake it more or less visible than it was originally. If there is an alarm which, forsome reason, is of more importance in your network, you can give it a newclassification which reflects this importance.



NTC TAN 0704/1.1 en24

3.1.8 Alarm Correlation

Figure 10.Alarm Correlation

Alarm Correlation consists of the alarm correlator plus the Alarm CorrelationRule Editor application. Correlation rules concerning specific alarms are madewith the Rule Editor. The correlator matches incoming alarms against the rulesand then correlates all relevant alarms. The correlations are sent to AlarmMonitor, along with an explanation of the correlation rule concerned and theoriginal alarms involved. This explanation can be retrieved through a dialog inAlarm Monitor.

When alarms are correlated, you can choose to have the original alarms beautomatically acknowledged as they are correlated.

Nokia NMS Alarm Correlation also features automatic checking of the objecthierarchy. If a rule is made in which either Scope A or Scope B or both have anentire alarm class as the target object, then a check is made before everycorrelation made under that rule to make sure that the suppressing alarmingobject and the suppressed alarming object are close enough in the managedobject hierarchy to allow the correlation. For more information on this, seeRelation Checking.

* * * 2 9 1 5

S i n g l e a l a r m s h o w n

C o r r e l a t i o n

I f m u l t i p l e a ,t h e n a .

I f a a n d b ,t h e n a .

I f m u l t i p l e a ,t h e n b

S m a l l e r n u m b e r o f a l a r m s s h o w nM o r e i n f o r m a t i v e a l a r m s

F a u l t i n N E

S e v e r a l a l a r m s g e n e r a t e d



NTC TAN 0704/1.1 en25

3.1.8.1 Correlation Types

There are several different types of correlation. Each is defined by the way inwhich alarms are correlated. In this release, the Nokia NMS supports thefollowing types:

• Compression

• Count

• Suppression

Compression

Compression involves taking a number of occurrences of one alarm andcombining them to make only one occurrence. The meaning of the correlatedalarm is identical to that of any one occurrence, with the extra information addedthat the alarm has occurred a number of times.

Count

This type of correlation involves implementing time and occurrence thresholdsfor a certain alarm. If the alarm occurs more than the designated number of timeswithin the designated time frame, then the occurrences are correlated and a newalarm, which could be assigned a higher alarm class, is generated. Typically thiswould be used in the case of certain lower class alarms and warnings, whichwould be filtered away, but counted. Should they become too numerous, ahigher-class alarm would result.

Suppression

Suppression correlation means inhibiting a low-priority alarm in the presence ofa high-priority alarm. If a specific lower-severity alarm always occurs inconjunction with a certain higher-severity alarm, then the alarms can becorrelated so that only the high priority alarm is shown to the NMS user. Forexample, a PCM line failure generates a number of BTS alarms, which can becorrelated to a great extent using the suppression rule.

3.1.9 Alarm Statistics in PC

Alarm Statistics in PC provides flexible tools for the offline analysis of alarmdata. With this application you can retrieve alarm data from the NMS databaseand generate graphical and textual reports on the basis of that information. Thefeature is built on Microsoft Windows and uses Microsoft Excel for dataprocessing. Examples of the processing capabilities of Alarm Statistics in PC arethe statistical analysis and cross-tabulation of data.

The statistical analysis of alarms provides information that allows the user toidentify problems in the system and take corrective actions to enhance thefunctioning of the network. For example, statistical alarm analysis can be used



NTC TAN 0704/1.1 en26

to find out the most typical alarms that are generated, or to list the sites ornetwork elements that generate frequent alarms. For more information on offlineanalysis of alarm data, seeChapter 4, Offline Analysis of Alarms.

3.1.10 Tools for Collecting Alarms from Third-partyElements

The Nokia NMS offers you a wide range of possibilities for integrating othermanufacturers’ equipment with the NMS. A vital benefit in this type ofintegration is that alarms from third-party equipment can be collected, viewed,and stored in the NMS along with all other network alarms. Therefore, a singleand centralised view of the network as a whole can be maintained, greatlyreducing the workload and making fault localisation faster and more reliable.And in cases where the third-party equipment does not have its own managementsystem, this feature gives you a fast and simple way to utilise your NMS for thatpurpose.

The NMS integration tools let you take full advantage of the alarm handling toolsalready in place in the NMS (such as Alarm Monitor and the graphic networkview). As alarms are collected, the alarm format of the third-party element ischanged to that of the Nokia NMS, and from then on they are handled like allother alarms. This is a considerable advantage, since the Nokia NMS features acomprehensive set of alarm handling applications, to which enhancements andadditions are made continually.

For more information on these options, seeChapter 6, Alarm Collection fromThird-party Network Elements.



NTC TAN 0704/1.1 en27

3.2 Life Cycle of an Alarm in the NMS

The following picture shows the cycle of an alarm in the NMS. The cycle startswhen the alarm is generated in a network element and sent to the NMS, and endswhen it is cleaned from the database. Following the picture is a step-by-stepexplanation of each phase.

Figure 11.NMS Alarm Life Cycle

The process is described below.

1. Alarm is generated in a network element.

2. Alarm is sent to the NMS.

1

D X 2 0 0

N M S a l a r m p i p e

T o p - l e v e l



A l a r m h a n d l i n g a p p l i c a t i o n s

3

2

4

5

A C K

7

A

! A C

C

9

5 8 1 0

C o r r e l a t o r6

1 1

8

C A N C E L

1 0

! A C

1 2

!

A

A

! C

A L A R M

! C

T r a s h

m a n u a lc a n c e l C

C

1 1

1 0



NTC TAN 0704/1.1 en28

3. Alarm goes into the NMS alarm pipe. An alarm pipe is a set of processesand buffers which is used in collecting, processing, and distributingalarms.

4. During the processing which takes place in the alarm pipe, the alarm isentered into the NMS database. A check is made to see if there areduplicate alarms. The alarm is then sent back to the alarm pipe.

5. The alarm is sentat the same time to alarm handling applications and thealarm correlator.

6. The correlator makes a check to see if there are any active correlation ruleswhich concern the alarm. If there are any count rules which generate a newalarm as a result of the correlation, then this alarm is sent to the alarm pipe.

7. Correlations are sent from the correlator to Alarm Monitor. Because analarm could move from the alarm pipe to the Monitor before the correlationis made, it is possible that an alarm will show up in Alarm Monitor and beremoved again a few seconds later when it is correlated.

8. NMS user notices alarm in one of the alarm handling applications andacknowledges it. This lets the other users know that the alarm has beennoticed and action is being taken on it.

9. The acknowlegement information is sent to the NMS alarm pipe. It is thenentered into the NMS database and sent to alarm handling applications.

10. Situation causing the alarm is over in the network element and the alarm iscancelled. Or, if the alarm has been resolved by an NMS user and the alarmneeds to be cancelled manually, the user makes a cancellation using NMSapplications.

11. Cancel is sent to the NMS alarm pipe. It is then entered into the NMSdatabase and sent to alarm handling applications.

12. Alarm database cleanup processes remove alarm, acknowledgeinformation, and cancel information. The criteria defining what alarmsshould be removed can be configured. For more information on this, seeyour system administrator.



NTC TAN 0704/1.1 en29

3.3 Alarm Number Ranges

Each alarm has an identifying number in the NMS. In general, numbers areassigned to alarms according to the equipment from which it is generated. So thealarm number itself contains information on where the alarm has come from.

A very general breakdown of the alarm number ranges and the elements theybelong to is given below.

0-5999 DX alarms

7000-8999 BTS alarms

9000-9999 Workstation alarms

10 000-99 999 Reserved for future use

3.3.1 DX Equipment Alarms 0-5999

The DX alarms cover the range from 0-5999. They are grouped according towhether they are warnings or alarms, and each of these sets is further brokendown according to type. In addition there are external alarms, or alarms whichcannot be monitored directly by the software. These alarms are generally definedlocally in each network.

Warnings

There are two types of warnings in the DX system, NOTICE and DISTUR. Inthe NMS both types are shown as warnings, and there is no other distinctionmade. The alarm number ranges are:

0-799 Switching equipment NOTICE

800-899 O&M equipment NOTICE

900-999 Transmission equipment NOTICE

1000-1799 Switching equipment DISTUR

1800-1899 O&M equipment DISTUR

1900-1999 Transmission equipment DISTUR

Alarms

There are two types of alarms in the DX system, ALARM and DIAGN. Thealarm number ranges are:

2000-2799 Switching equipment ALARM

2800-2899 O&M equipment ALARM



NTC TAN 0704/1.1 en30

2900-2999 Transmission equipment ALARM

3000-3799 Switching equipment DIAGN

3800-3899 O&M equipment DIAGN

3900-3999 Transmission equipment DIAGN

External Alarms

4000-4799 Switching equipment

4800-4899 O&M equipment

4900-4999 Transmission equipment

5000-5499 Power equipment

5500-5999 External equipment

3.3.2 BTS Alarms 7000-8999

The following ranges are reserved for specific purposes:

7400-7430 External alarms (operator can define the alarm textand alarm class for the alarm)

8000-8255 Transmission equipment (supervised by BTS)

All other BTS alarms are distributed among the remaining numbers of the totalrange.

3.3.3 Workstation Alarms 9000-9999

The alarms are broken down into the following:

9000-9499 Workstation and internal alarms

9400-9449 For alarms generated by correlation rules

9450-9999 For alarms from various elements integrated to theNMS through an RPC or SNMP interface,or alarmsfrom the interface systems themselves.

Strategies for Reducing the Alarm Flow


NTC TAN 0704/1.1 en31

4 STRATEGIES FOR REDUCING THE ALARM FLOW

This chapter contains background information on the filtering, reclassification,and correlation of alarms. If you are new to this area, you should read this chapterbefore starting to make rules. The following subjects are covered in the chapter:

• Methods

• Filtering

• Correlation

• Informing Delay

• Reclassification

4.1 Methods

Normal network monitoring can be a reactive process: alarms come in, personneltake notice of them, try to make conclusions as to the working of the network,try to pinpoint problems, and then react to those problems.

Using filtering and correlation techniques, you can turn this reactive process intoaproactive one: a process in which alarm situations are anticipated and plannedfor in advance, and this planning is used to reduce the alarm flow. The reducedalarm flow makes it easier to spot the real source of problems, and to startworking on solutions for those problems sooner. It makes the monitoringsituation moreeffective.

The Job of Network Monitoring

In a normal situation, alarms come in to the NMS in random order and from allparts of the network. Monitoring personnel have full responsibility forprocessing the alarms. This job includes:

• Sifting through the enormous amount of information presented by alarms.

• Deciding which of the thousands of alarms shown are important.

• Making associations between alarms, trying to decide which ones arepossibly caused by the same fault, and grouping those alarms together.

• Finding solutions for the problems causing the alarms.

Normally, the first three of these activities, although requiring a good deal ofwork, have to be done in a matter of seconds. They also have to be donecontinuously for a huge flow of incoming alarms. The end result can be thatfaults go unnoticed or unresolved.



NTC TAN 0704/1.1 en32

Making the Job More Effective

Using filtering and correlation techniques, part of the responsibility for theseactivities is turned over to the NMS. Using the intelligence of the system, thejobs can be taken care of, in part, before the alarms ever reach the AlarmMonitor. The view of the alarm situation seen by monitoring personnel, then, hasalready been partially sifted through, alarms which are not important are notshown at all, and associations, or correlations, between certain alarms havealready been made and are shown as correlated alarms. Because of this,monitoring is made much more effective, meaning that personnel have moretime to spend on actually resolving the problems.

The basic principles used to achieve this are:

• Reducing the number of alarms shown

• Improving the alarm picture presented by Alarm Monitor

• Making sure that important alarms are easily spotted

Reducing the number of alarms shown means that alarms which are not vital tothe job at hand (monitoring for faults in the network) are not shown or dealt within the immediate monitoring situation. It doesnot mean that the alarms are lost,they are simply not shown in the immediate network monitoring situation. Thealarms are entered into the database and can be retrieved using Alarm Historyand used in making statistics (except in the case that an alarm is filtered from thedatabase).

Improving the information presented by the alarms can be accomplished throughmaking associations between alarms connected to the same problem, correlatingthose alarms, and presenting them in Alarm Monitor as one alarm with the addedinformation from the correlation.

NMS Tools

The Nokia NMS offers three tools for improving the effectiveness of themonitoring situation:

• Alarm Filtering

• Alarm Correlation

• Alarm Reclassification

With the Alarm Filtering application you can make filtering rules for specificalarms or alarm classes. Automatic acknowledgement of alarms can also be setwith this application.

You use the Alarm Correlation Rule Editor to make correlation rules for alarms.Three different rule types are supported: suppression, count, and compression.



NTC TAN 0704/1.1 en33

You can change the class of an alarm using the Alarm Reclassificationapplication.

Each of these tools is explained further in the following sections of this chapter.

Filtering and Correlation in Other Network Elements

DX200 network elements have rule bases which allow you to perform sometypes of correlation in the network. You can make rules preventing certainalarms in the presence of certain other alarms (like suppression in the NMS), orsupporting rules, in which an alarm is generated if there is enough support fromcertain other alarms present.

Alarm blocking is also possible in DX200 elements, which is like the alarmfiltering used in the NMS.

For more information on these methods, see theAlarm AdministrationMaintenance Manual in BSC documentation.

4.2 Filtering

The Alarm Filtering application is used for making filter and auto-ack rules forincoming alarms. For instructions on how the application is used, seeAlarmParameter Handling Help.

4.2.1 Why Filter Alarms?

In fault monitoring, one of the first and most important tasks is to sift through theincoming alarm information and pick out the alarms which are potentiallyimportant to the working of the network. This job is normally made much moredifficult because the number of incoming alarms can be huge. The higher thenumber of incoming alarms, the more difficult the sifting process becomes, andthe more likely it is that alarms and faults will go undetected.

For these reasons, one of the best ways to make the monitoring situation moreeffective is to reduce the number of incoming alarms. Even more important is tomake sure that the alarms which are presented, are the ones that need attentionby monitoring personnel.

Alarm Filtering is the key to doing this. Using Alarm Filtering, you can decideahead of time (and not during monitoring time) which alarms are not ofimmediate importance to monitoring personnel. You can then make filteringrules which will cause those alarms to be filtered from the alarm situationpresented in NMS monitoring software (Alarm Monitor, Alarm Viewer, and theTop-level User Interface).

Filtered alarms are not lost alarms. They are simply not shown in the immediatemonitoring situation. These alarms are, however, entered into the database. Theycan be viewed with Alarm History, and used in making statistics. The oneexception to this is alarms which are filtered from the database.



NTC TAN 0704/1.1 en34

4.2.2 What to Filter

The importance of each alarm is different for every network, and is dependent ona great number of factors such as network conditions, equipment, andenvironmental aspects. You can decide which alarms are necessary for yourpersonnel and your network, and implement a filtering strategy to cover the restof the alarms.

In planning a filtering strategy, you should first consider the most frequentalarms. For each alarm, consider these two basic questions:

• Do I need this alarm and the information contained in it?

• Does anyone else need the alarm?

If the answer to both questions is no, then it could be a good idea to filter thealarm away from view. Remember that every unimportant alarm which is filteredaway from the view, makes it easier and faster to spot important alarms.

4.2.3 Filtering Options

In the NMS, you use the Alarm Filtering application to make filtering rules. Inaddition, this tool can be used to make automatic acknowledgement (auto-ack)rules. Following is an explanation of all filtering and auto-ack options.

Filtering

There are three filtering options:

• No Filter

• Filter

• Filter from Database

No Filter means that the alarm is handled in the normal way: it is sent to all NMSalarm handling software and entered into the database. This option is given incase you want to set an auto-ack rule for an alarm, but do not want the alarm tobe filtered.

Filter causes the alarm to be filtered. This means that:

• The alarm is not shown in Alarm Monitor

• The alarm is not shown in Alarm Viewer

• The alarm does not cause a colouring request to the Top-level UserInterface, meaning that the symbol for the alarming object in the Top-levelUser Interface will not change colours to reflect the severity of that alarm.

• The alarm is entered into the database.



NTC TAN 0704/1.1 en35

Filter from Database means that the alarm is completely filtered from the NMS.It is not shown in any alarm handling software, and is not entered into thedatabase at all.

Auto-ack

There are three auto-ack options you can use:

• No ack

• Ack

• Ack with cancel

No ack means that no automatic acknowledgement of the alarm will take place,and the alarm must be acked manually by a user.

Ack means that the alarm will be acknowledged automatically when it comes intothe NMS, and will be shown as an acknowledged alarm when it is presented in.

Ack with cancel means that, when the alarm is cancelled, it will be automaticallyacknowledged at the same time.



NTC TAN 0704/1.1 en36

4.2.4 Implementation of Alarm Filtering

The following picture shows the process by which alarms are taken into the NMSand filtering/auto-ack rules applied.

Figure 12.How Alarms are Filtered

A l a r m p i p e

A l a r m s

D a t a b a s e

F i l t e r i n g

' F i l t e r e d ' a l a r m sn o t t a k e n

' F i l t e r e d f r o mD B ' a l a r m sn o t t a k e n

F i l t e r e d a l a r m ss h o w n , F i l t e r e df r o m D B n o t s h o w n

T o p - l e v e l







NTC TAN 0704/1.1 en37

4.3 Correlation

One network fault can produce multiple alarms. This is the reason that it can bedifficult to find the real fault in network monitoring. The alarms are normallyseen on a list and associations between them are hard to make quickly.

Alarm correlation works to help in this situation. Alarms known to be associatedwith each other are correlated, resulting in fewer alarms being shown. It is theneasier for the NMS user to pinpoint the real problem and work toward fixing it.The following picture shows this situation.

Figure 13.Fault Situation and Correlation

In this situation, one fault (F1) causes three different alarms to be generated (A1,A2, and A3). A1 and A2, which are known to be associated with each other, arecorrelated to make one alarm. Taken further, the alarm resulting from this firstcorrelation (C1), can be correlated with the third alarm (A3)

The final result of these correlations is that the NMS user sees only onecorrelated alarm. The correlated alarm can be opened up for viewing, showingwhat the original alarms were which went into the correlation. The user, seeingthe case, can come to a conclusion as to what the problem is much quicker thanif he had tried to dig A1, A2 and A3 from a list of many alarms.

Alarm Correlation in the NMS

The Alarm Correlation Rule Editor application is used to makecorrelation rules,which determines what alarms are correlated and how they are correlated. Thereare three different types of correlation rules supported: suppression, count, andcompression.

Correlated alarms are seen in Alarm Monitor, with a + to their left to indicate thatthey are correlated. You can open the Explanation dialog for any correlated

F 1 F a u l t

A 1 A 2 A 3

C 1

C 2

A l a r m s

C o r r e l a t i o n s



NTC TAN 0704/1.1 en38

alarm, and it will give you comprehensive information on the correlation,including:

• Original alarms which went into the correlation (note that even if anoriginal alarm has been filtered from the view, you can see it in this dialog).

• The rule which caused the correlation, shown in the same format as it is inthe Alarm Correlation Rule Editor main window.

A picture of the explanation dialog is shown below.

Figure 14.Explanation Dialog for a Correlated Alarm

4.3.1 Correlation Types

As mentioned above, the three correlation types available in the NMS:

• Suppression

• Count

• Compression

4.3.1.1 Suppression

The governing principle in suppression is that there are two alarms whichcommonly follow each other, and are caused by the same fault. Of the twoalarms, theprimary alarm is the most essential one related to the fault. It is theprimary alarm which gives the user a good idea of the real fault or the serviceimpact of the fault. Thesecondary alarm shows up in the presence of the primaryalarm and it normally does not provide any further information on the fault.

A suppression rule causes the primary alarm to suppress the secondary alarm, sothat it is not shown in the presence of the primary alarm. The rule workswhenever alarm A and alarm B are present together in the NMS. It makes nodifference if alarm B is activated first, when alarm A is activated, alarm B willthen be suppressed. Also, if alarm A is not active, then alarm B will always beshown.



NTC TAN 0704/1.1 en39

Following is a picture showing the basic functioning which takes place insuppression. The picture following it contains a key to all of the pictures shownin this section on suppression.

Figure 15.Alarm Suppression

Figure 16.Notation Used in Suppression Pictures

In this picture, the first occurrence of alarm B is suppressed by the presence ofthe primary alarm (alarm A). However, after alarm A is cancelled, alarm B isgenerated and no longer suppressed, because there is no suppressing alarmactive.

Suppression rules are made by defining the managed object(s) covered by thesuppression rule, then defining the primary and secondary alarms.

Note:

When a suppression rule is made in which the Scope A, Scope B, or both use awhole object class, then the NMS makes an automatic check for hierarchicalrelations before it makes any correlation. The objects in question have to be closeenough to each other in the hierarchy to allow correlation. For more informationon this process, see the section onRelation Checking later in this chapter.



NTC TAN 0704/1.1 en40

Removing Suppression

Another feature of suppression rules is the "Remove suppression of B when A iscancelled" option. In the suppression situation, alarm A is activated, followed ashort time later by alarm B, which is then correlated and not shown. When alarmA is then cancelled, one of two things could happen:

• The suppression remains intact, and alarm B would remain suppressed

• The suppression is removed, making alarm B active again.

The following pictures show each of these options.

Figure 17.Suppression without Removal of Suppression

In this picture, alarm A suppresses alarm B. When alarm A is cancelled, thesuppression is not removed, so that alarm B remains suppressed.

Figure 18.Suppression with Removal of Suppression

In this situation, when alarm A is cancelled, the suppression of alarm B isremoved and the alarm becomes active.

As mentioned earlier, this option is defined when the rule is created using theRemove Suppression of B when A is Cancelled button.

A l a r m A :s u p p r e s s i n ga l a r m

A l a r m B :s u p p r e s s e da l a r m

T i m e

s u p p r e s s e d

s u p p r e s s i o n

A l a r m A :s u p p r e s s i n ga l a r m

A l a r m B :s u p p r e s s e da l a r m

T i m e

s u p p r e s s e d

s u p p r e s s i o n



NTC TAN 0704/1.1 en41

Example for using a suppression rule

The following picture shows an example of a typical fault situation:

Figure 19.Example Fault Situation

In this example, a PCM line between a BSC and a BCF has been cut for somereason. This fault first causes an alarm in the BCF, and after that in the BTSsunder that BCF. In our example you could then have the alarms generated in theBTS (2567) suppressed by the alarm generated in the BCF (7704), as the lattergives you the most essential information about the problem.

If the alarms were correlated in this way, then the user would see only one alarmin the NMS. However, he would have the added information that the alarms arecorrelated, and with a quick look at the original alarms of the correlation, couldquickly make conclusions about the origin of the problem.

4.3.1.2 Count

Certain alarms are not so important if they occur once or twice, but becomeimportant if they occur repeatedly in a short time period. A count rule can beapplied to this type of alarm. If there are enough occurrences of an alarm in acertain time frame, the count rule correlates all occurrences and generates a newalarm. Escalation can be used, giving the newly generated alarm a more severealarm class than the original alarm.

A count rule uses a count ratio, defined by the number of alarms which arenecessary in a certain time frame in order to generate a new alarm. For example,if a count rule is set for alarm 1567 with a count ratio of 3/60, then if the alarmoccurs three times within any 60-second time frame, the alarm will be correlatedand a new alarm generated.

D X 2 0 0

B C F - 1P C M - 6 4 P C M F a i l u r e ( 7 7 0 4 )

B T S - 1 B T S - 2 B T S - 3

B C C H M i s s i n g ( 2 5 6 7 )



NTC TAN 0704/1.1 en42

When you create the count rule, you define the alarm to be generated. You assignthe following to it:

• Alarm text

• Alarm number (the numbers reserved for these alarms are 9400-9449)

• Alarm class

You can also make a manual page for the alarm to go in the Alarm Manual byusing an existing page as a template.

Figure 20.Correlation with Count Rule

In this situation, a count rule was made according to which, if the original alarmoccurs at least three times within a 90-second time frame, a new alarm isgenerated. At the point in which alarm 3 occurs, the new alarm is generated.

The new alarm is active until it is manually cancelled. After it is cancelled, thetime frame is restarted and a new correlation occurs when the count ratio isexceeded.

If you do not want to see the original alarm at all until its frequency is highenough to indicated a fault, you can filter it from view. Using this method, youwould not be informed of the fault until the correlated alarm occurred, but youcould then open the Explanation dialog for that alarm and see all the occurrencesof the original alarm.

1 2 3 4

T i m e

O r i g i n a la l a r m s

N e w l yg e n e r a t e da l a r m

1 0 s .

A l a r m :

A c t i v a t e C a n c e l

A c t i v e

K E Y :

N o t a c t i v e



NTC TAN 0704/1.1 en43

If you are not interested in the original alarm at all until its frequency is highenough to indicate a fault, you can make rules which keep it from being seenuntil the new one is generated. For example, you could make a filtering rulewhich filters the original alarm from view, but not the new alarm generated bythe correlation. Or you could make a suppression rule in which the new alarmsuppresses all instances of the original alarm.

Example

Alarm 860, DISK NOTICE, is not that important in itself. However, when itoccurs frequently in a short time, it indicates a problem.

One strategy:

1. A filter rule is made which puts a normal filter on alarm 860, so that it isnot shown in Alarm Monitor.

2. A count rule is made. The count ratio for the rule is 10/300, meaning thatif the alarm occurs 10 times within a 5-minute time frame, they arecorrelated and a new alarm is generated. The new alarm is given the alarmnumber of 9411, alarm class of major, and the following alarm text: DISKNOTICE 10 TIMES.

Without the correlation, it would take time for monitoring personnel to realizethat the alarm keeps occurring in the same element. In fact, it could go unnoticed.With the strategy given above in effect, the multiple occurrences of alarm 860are not shown at all, but when alarm 9411 occurs, personnel are presented withthe immediate information that a number of occurrences of the alarm haveoccurred. They have a good idea of the fault causing them without having to digfor the information.

4.3.1.3 Compression

It is very common that one fault will generate a series of occurrences of the samealarm. However, after the first one, none of the other occurrences provides anyextra information on the fault. In a case like this, a compression rule can be made.

Compression means that any number of occurrences of an alarm are groupedunder one correlated alarm. Only one alarm, then, is shown to the user, no matterhow many occurrences of the alarm there are. If the user wants the furtherinformation on the exact number of occurrences, he can check the Explanationdialog.



NTC TAN 0704/1.1 en44

Figure 21.Compression Rule

Example

Alarm 2978, TRANSCODER UNIT TRC15 CHANNEL FAILURE, oftenoccurs many times in succession, with several different cards of the transcodergenerating alarms. All of the alarms, however, are caused by the same fault andno new information is gained from new occurrences of the alarm.

One Strategy

1. A correlation rule is made according to which all occurrences of alarm2978 are compressed under one occurrence.

Now the user sees only one alarm, but also the added information that the alarmis correlated, and therefore has occurred a number of times. It is easier to spot thefault, make conclusions as to the real problem, and fix it.

4.3.2 Relation Checking

When you make a suppression rule, you can use either one specific managedobject instance or a whole object class in your scope definition. When you havea specific managed object instance for Scope A and for Scope B, then allcorrelations take place without need of checking on the relationship of the twoobjects.

1A c t u a l a l a r mo c c u r r e n c e s

2

3

A l a r m :

A c t i v a t e C a n c e l

A c t i v e

K E Y :

N o t a c t i v e

C o r r e l a t i o na c t i v e

A l a r m s h o w n i n A l a r m M o n i t o r



NTC TAN 0704/1.1 en45

However, when a rule is made which covers a whole object class (for example,all BTSs), then a check is made before every correlation made under that rule.This check is made to assure that the two alarming objects in question are closeenough to each other in the object hierarchy to allow the correlation.

The relation check rule uses the managed object hierarchy of your system as abase. The places of the two alarming objects in the hierarchy are compared to seeif they areclose enough and if they are, the correlation takes place. If they arenot, then the correlation rule is ignored and both alarms are shown.

4.3.2.1 The Basic Rule

The basic rule used in relation checking is given in this section. However, to fullyunderstand how the check is performed you should go through the two examplesgiven. In each of them an example is taken from a common fault situation. Thesteps used in the relation check are gone through one by one to demonstrate howit works. The first example shows a situation in which the correlation doesnottake place. The second example shows a situation in which the correlation doeswork.

The basic rule is:

A correlation can take place if the object of the suppressing alarm andthe object of the suppressed alarm are close enough to each other in themanaged object hierarchy of the network.

The objects involved in the correlation are considered close enough if they arethe closest possible instances of those object classes possible in the managedobject hierarchy.

To calculate the distances between objects in a hierarchy, steps are used. This isshown in the following picture:



NTC TAN 0704/1.1 en46

Figure 22.How Steps are Counted in Object Hierarchy

The procedure used to calculate whether the two objects are close enough aredivided into two parts. Each of these is described below.

First Part

In the first part, the system checks to see if thesuppressed alarming object isclose enough to thesuppressing alarming object to allow the correlation.

1. The suppressed and suppressing alarming objects are mapped onto themanaged object hierarchy of the network.

2. The distance from the suppressed object to the suppressing object iscalculated using the steps described previously.

3. In the hierarchy, otherpossible instances of the suppressed object’s alarmclass are mapped. If there is a place in the hierarchy where an instancecould occur but does not, it is still mapped as a possible instance.

4. If there are any possible instances of the suppressed object’s class whichare closer to the suppressing object than the suppressed object itself, thenthe two objects are not considered to be close enough to allow thecorrelation. It does not take place.

Second Part

In the second part, the same check is made, only this time it checks if thesuppressing alarming object is close enough to thesuppressed alarming objectto allow the correlation.

1. Steps 1 and 2 from the first part are already done: the suppressing andsuppressed objects have been mapped onto the managed object hierarchyof the network and the distance between them calculated.

O b j e c t 1

O b j e c t 2 O b j e c t 3

O b j e c t 4

S t e p 3

S t e p 2 S t e p 1

O b j e c t 3 i s 3 s t e p s a w a y f r o m O b j e c t 4



NTC TAN 0704/1.1 en47

2. In the hierarchy, otherpossible instances of the suppressing object’s alarmclass are mapped. If there is a place in the hierarchy where an instancecould occur but does not, it is still mapped as a possible instance.

3. If there are any possible instances of the suppressing object’s class whichare closer to the suppressed object than the suppressing object itself, thenthe two objects are not considered to be close enough to allow thecorrelation. It does not take place.

4.3.2.2 Example of Situation in which Correlation Does NotTake Place

The best way to make this rule understandable is to go through some examplesof how it does the checking. The first example demonstrates a fault situation inwhich the relation check is made for two alarms and the correlation isnotallowed.

In this example, a suppression rule has been made in which:

• Scope A (suppressing) covers the DMR object class

• Scope B (suppressed) covers the PCM object class

The rule states that:

• DMR alarm 2984, MICROWAVE RADIO LINK FAULT

suppresses

• PCM alarm 2900, INCOMING SIGNAL MISSING

The example fault situation is shown in the following picture.



NTC TAN 0704/1.1 en48

Figure 23.Fault Situation in Example 1

BCF-9 and BCF-10 are connected to each other via a radio link. For some reasonthe link fails and alarm 2984 is generated in DMR-5. At about the same time,alarm 2900 is generated in PCM-16 for some other, unrelated reason.

Since there is a suppression rule which states that alarm 2900 will be suppressedby alarm 2984, will alarm 2984 in DMR-5 be allowed to suppress alarm 2900 inPCM-16?

To demonstrate, every step of the relation check process, which was outlinedpreviously, will be shown for this example.

Part 1 of Check

1. Suppressing and suppressed objects are mapped onto object hierarchy

First the two alarming objects (that taken from Scope A and that from Scope B)are mapped in the NMS’s object hierarchy. The part of the hierarchy whichcontains the objects in question is shown in this picture.

B S C - 1 1P C M - 1 6

B C F - 9

D M R - 5 D M R - 6

I N C O M I N G S I G N A LM I S S I N G ( 2 9 0 0 )

M I C R O W A V E R A D I OL I N K F A U L T ( 2 9 8 4 )

B C F - 1 0



NTC TAN 0704/1.1 en49

Figure 24.Example Objects in the Object Hierarchy

2. Distance from suppressing object to suppressed object is calculated

The next step is to calculate how far (using the steps described earlier) thesuppressing object (DMR-5) is to the suppressed object (PCM-16).

Figure 25.Distance between Suppressing and Suppressed Objects

DMR-5 is three steps away from PCM-16.

B S C - 1 1

P L M N - 1

P C M - 1 6 B C F - 9 B C F - 1 0

D M R - 6D M R - 5

B S C - 1 1

P L M N - 1

P C M - 1 6 B C F - 9 B C F - 1 0

D M R - 6D M R - 5

S t e p 3

S t e p 2

S t e p 1



NTC TAN 0704/1.1 en50

3. Other possible instances of suppressed object’s class mapped

In this step, the mapping of the objects in question is used. On top of it, any otherpossible instances of the suppressed object’s object class are also mapped.

Figure 26.Other Possible Instances of PCM Class

It is possible that there are other PCMs under the same BSC. In this particularnetwork there is only one actual PCM under BSC-11. However, it is possible thatthere would be more, and in the picture one of these is shown as PCM-x.

4. Are possible instances closer to the suppressing object than thesuppressed object itself is?

The distance from the other possible PCM instance, PCM-x, is three steps

B S C - 1 1

P L M N - 1

P C M - 1 6 B C F - 9 B C F - 1 0

D M R - 6D M R - 5

P C M - x



NTC TAN 0704/1.1 en51

Figure 27.Steps from PCM-x to DMR-5

The distance from other possible instances of the PCM object class to thesuppressing object is three steps, which is the same as the distance from theactual suppressed object, PCM-16.

There is no other possible instance of PCM which is closer to the suppressingobject than PCM-16 itself. Therefore thesuppressed alarming object isconsidered to be close enough to thesuppressing alarming object to allow thecorrelation.

However, now comes Part 2 of the check. This time the same type of check ismade only the other way around. Now it checks if thesuppressing alarmingobject is close enough in the object hierarchy to thesuppressed alarming objectto allow the correlation. The same steps are used for this second part.

Part 2 of Check

1. Objects mapped in hierarchy and distance between them calculated

The mapping has already been done and the distance between the two objectscalculated (three steps) when the first part of the check was made.

2. Other possible instances of suppressing object’s class mapped

Now we go back to the mapping of the suppressing and suppressed objects. Ontop of this we map other possible instances of thesuppressing object’s class(DMR).

B S C - 1 1

P L M N - 1

P C M - 1 6 B C F - 9 B C F - 1 0

D M R - 6D M R - 5

P C M - x

S t e p 1

S t e p 2

S t e p 3



NTC TAN 0704/1.1 en52

Figure 28.Other Possible Instances of DMR Class

Although in this network there are no DMRs under BSC-11, it is possible thatthere could be. One of them is mapped here and called DMR-x.

4. Are possible instances closer to the suppressed object than thesuppressing object itself is?

The distance from DMR-x to the suppressed object, PCM-16, is two steps.

Figure 29.Distance from DMR-x to PCM-16

In this case, there is a possible instance of the DMR class which is closer to thesuppressed object than the suppressing object, DMR-5, is. This means that the

B S C - 1 1

P L M N - 1

P C M - 1 6 B C F - 9 B C F - 1 0

D M R - 6D M R - 5

D M R - x

B S C - 1 1

P L M N - 1

P C M - 1 6 B C F - 9 B C F - 1 0

D M R - 6D M R - 5

D M R - x

S t e p 1S t e p 2



NTC TAN 0704/1.1 en53

suppressing object is not close enough to the suppressed object for thecorrelation to be allowed. It doesnot take place.

Outcome

When the first part of the check was done, it was found that the suppressedalarming object is close enough to the suppressing alarming object to allow thecorrelation.

However, the second part of the check showed that the suppressing alarmingobject wasnot close enough to the suppressed alarming object. So the correlationwas not performed.

4.3.2.3 Example of Situation in which Correlation Does TakePlace

In this example, a suppression rule has been made in which:

• Scope A (suppressing) uses the BCF object class

• Scope B (suppressed) uses the BTS object class

The rule states that:

• BCF alarm 8050, LOSS OF INCOMING SIGNAL

suppresses

• BTS alarm 2567, BCCH MISSING

The example fault is shown in this picture.

B C F - 9 B T S - 3

L O S S O F I N C O M I N G2 M S I G N A L ( 8 0 5 0 )

B C C H M I S S I N G( 2 5 6 7 )

B S C - 2



NTC TAN 0704/1.1 en54

Figure 30.Fault Situation in Example 2

There is a break in the outgoing line from BSC-2 to BCF-9. This disturbancecauses both alarm 8050 in the BCF and 2567 in the BTS.

In this case a check is made to see if alarm 8050 can suppress alarm 2567.

The relation check

This case is a straightforward one. For that reason we will not go through everystep of the checking process as we did in the first example, but will explain thingsmore quickly.

First of all the objects in question are mapped onto the managed object hierarchyof the network:

Figure 31.BCF-9 and BTS-3 in Managed Object Hierarchy

There is only one step between BCF-9 and BTS-3. There can be no other instanceof a BTS which is closer to BCF-9 than that. Therefore the correlation can takeplace.

B C F - 9

B T S - 2 B T S - 3B T S - 3



NTC TAN 0704/1.1 en55

4.3.3 Implementation of Alarm Correlation

The flow of alarms in the correlation process is pictured below.

Figure 32.How Alarms are Correlated

Rules are made using the Alarm Correlation Rule Editor application, from whichthey are sent to the database, and from there are taken into the correlator and usedto perform correlations.

Alarms are sent from the alarm pipe directly to Alarm Monitor and to thedatabase. They are also sent to the correlator, which matches them with existingcorrelation rules and correlates all necessary alarms. For this reason, it could bethat an alarm is seen in Alarm Monitor for a few seconds, and then disappears asit is correlated.

An explanation for each correlation is made and stored in the database. Whenyou see a correlated alarm in Alarm Monitor, you can open the Explanationdialog to see the explanation. The explanation contains information on thecorrelated alarm, the original alarms, and the rule under which they werecorrelated. More information on this is contained inUsing Alarm Monitor withAlarm Correlation in Alarm Monitor’s help.


E x p l a n a t i o n

A l a r m p i p e

D a t a b a s eA l a r m s & e x p l a n a t i o n s

R u l e E d i t o r

F i l t e r i n g

R u l e s

C o r r e l a t i o n s

A l a r m s

R u l e s

C o r r e l a t i o ne x p l a n a t i o n s

C o r r e l a t o r

A l a r m s

A l a r m s

R e f r e s h



NTC TAN 0704/1.1 en56

4.4 Informing Delay

Network monitoring personnel often notice that an alarm will be activated thencancelled again within a short time, then activated a second time and cancelled,and on and on. These are called AC (alarm-cancel) alarms.

The informing delay feature delays the original alarm for a few seconds to waitfor its cancel. If the alarm is cancelled within the time frame defined by theinforming delay feature (default 15 seconds), then it will not be shown to theuser. The information of alarm plus its cancel is combined, and the alarm-cancelpair is filtered from the view, though not from the database.

The default informing delay rule states that:

Alarms are delayed for 15 seconds to see if a cancel arrives. If it doesnot within the 15 seconds, the alarm is shown in the NMS.

This rule applies to all alarms except those which cause resets oruploads.

In practice this 15 seconds means that a check is made every 15 seconds. It ispossible that alarms sit for a few seconds before the check is made. This meansthat in practice, 15 seconds means 15-30 seconds. If the default time werechanged to 30 seconds, then the real check time would be 30-60 seconds, and soon.

If you want to change the default rule, it is best to have Nokia make any changes.

4.5 Reclassification

One of the best indicators connected to an alarm is its class. This is the first thingnoticed by monitoring personnel, and decisions on what alarms to follow up onare in a large part based on exactly this.

However, different alarms can have different real priorities, depending on a widerange of network factors which include the age of equipment, conditions specificto a network, etc. The alarm class originally assigned is not necessarily the onethat you need that alarm to carry in your network.

With the Alarm Reclassification application, you can assign a new class toalarms. The alarm is seen under its new class in all NMS alarm handlingapplications, and entered into the database under both its old and new class.



NTC TAN 0704/1.1 en57

4.5.1 Implementation of Alarm Reclassification

Figure 33.How Alarms are Reclassified

A l a r m p i p e

A l a r m s

D a t a b a s e

T o p - l e v e l




R e c l a s s i f i c a t i o nr u l e s


A l a r m s u n d e rn e w c l a s s

Offline Analysis of Alarms


NTC TAN 0704/1.1 en58

5 OFFLINE ANALYSIS OF ALARMS

Why Use Offline Analysis?

In addition to the daily task of monitoring the alarm situation of the network andcarrying out investigations of current alarm situations, it is important to analysethe alarm situation over a period of time. The long-term view given by ananalysis can identify problems that do not necessarily show up in dailymonitoring. It can also spot problems like a slow decline in the quality of serviceof the network or a part of it.

Alarm analysis is also a vital part of formulating monitoring strategies andmaking filtering and correlation rules. Using alarm filtering and correlationtechniques can greatly reduce the number of incoming alarms which are notimportant in the daily monitoring of the network. Alarm analysis can be used tohelp in determining which alarms should be filtered or correlated.

The following subjects are introduced in this chapter:

• Alarm Statistics in PC

• Working with templates in Alarm Statistics in PC

• Generating reports with Alarm Statistics in PC

• Example of generating a report

5.1 Alarm Statistics in PC

The Nokia NMS has a PC application, Alarm Statistics in PC, which is used totake alarm data from the NMS database and use it to compile statistics andreports on the alarm situation over a defined period of time. You can generateregular daily, weekly, or monthly reports. Alarm Statistics in PC allows you tocreate custom reports by using templates that can be saved and used later ingenerating routine reports. You can also generate ad hoc reports in order topresent information about problematic cells. The flexible and easy-to-use toolsfor the retrieval and manipulation of data simplify and speed up the productionof reports for management purposes. The possibility to customise reports enablesyou to generate highly specific alarm statistics for various needs.

You can query the alarm database using the given criteria in order to find andpresent in a report the alarms that match the criteria. The reports generated withAlarm Statistics in PC can be presented in both textual and graphical form. Thechart properties, the presented study objects and alarm counters, and thesummarising of objects and time in the finished report can be modified. You canalso further manipulate the reports in Microsoft Excel, copy them onto MicrosoftWindows clipboard, save them in Excel format, and print them.

Note that the Alarm Statistics in PC application contains an Online Help withdetailed instructions on using the application.



NTC TAN 0704/1.1 en59

5.2 Working with Templates in Alarm Statistics in PC

The reports are generated according to the templates and counters selected foreach report. You can create new templates and logical counters or use existingtemplates and alarm counters in your reports. You can save your own report andsearch templates and logical counters and use them as such in future reports, oredit them later to fulfil new requirements.

The usage of the templates and counters as report criteria is described below:

Report Template Defines the alarm counters in the NMS database fromwhich data is retrieved, chart properties and dataprocessing options. A report template can beassociated with one or more search templates togenerate same type of reports on various study objectsor during different periods of time.

Global SearchTemplate Defines the study period, study objects and alarm

criteria for the database search. One global searchtemplate can be linked to many report templates toproduce several reports on the same study objects andcovering the same study period. The global searchtemplate is a highly useful feature that providesflexible means for creating reports for your specificneeds: the global search template allows you to selectstudy objects belonging to different parent objects foryour reports, for instance in a densely populatedgeographical area.

Search Template Defines the study period, study objects and alarmcriteria for the database search. A regular searchtemplate can be associated with one report templateonly.

Logical Counters A formula that is formed by combining witharithmetical operations the data collected by alarmcounters. By creating your own logical counters youcan specify more detailed report criteria and thusproduce reports that meet your requirements.



NTC TAN 0704/1.1 en60

5.3 Generating Reports with Alarm Statistics in PC

The reports generated with Alarm Statistics in PC can be saved in textual andgraphical form. In a finished report you can modify the chart properties, thepresented study objects and alarm counters as well as the summarising of objectsand time. This would be useful, for example, if you needed to zoom in on onestudy object.

There are three ways of generating reports with Alarm Statistics in PC. Thereporting types are explained below in more detail.

5.3.1 Using ready-made templates for routine reports

Alarm Statistics in PC is supplied with a number of ready-made report templatesthat you can use for examining the network. With the ready-made reporttemplates you can easily generate highly useful reports on some of the mosttypical alarm situations. A list of the default report templates is provided below:

Alarms/Category/Day

Shows the number of alarms per day sorted out according to alarm class.

Top-15 Alarming Sites

Shows the 15 sites that produce the highest number of alarms.

Top-15 Alarm Active Sites

Shows the number of alarm events and the alarm active time per networkelement.

Top-20 Alarms

Tells the top 20 alarms along with the alarm text.

Top-20 Alarms, Numbers

Gives the top 20 alarms with the alarm number.



NTC TAN 0704/1.1 en61

Figure 34.A report generated using Nokia ready-made report template TOP-15Alarming Sites

5.3.2 Using ReportWizard for ad hoc reports

Reports generated ad hoc are particularly useful in pointing out problematic sitesin the network. You can focus on one or a few network elements, or you canstudy a large number of study objects to obtain an overall picture of the alarmsituation of the network.

Report Wizard is an interactive assistant tool that guides you through the stepsof report generation. You progress through a series of dialogs, and once you havesupplied all necessary information, the report is generated. The applicationpoints out any missing information by displaying a message box. Report Wizardspecifications lack some of the more advanced processing options provided bythe template specifications. The report definitions determined with the help ofReport Wizard can be saved as templates and used in later reports.

Report Wizard has a memory function that remembers the criteria of the reportmost recently created in Report Wizard. This way, the Report Wizard makes iteasy for you to modify the report criteria of the most recent report, whennecessary.

5.3.3 Automatic reports

The automatic reporting functionality is ideal for producing periodical reports or,for example, for processing reports during night time. You can schedule thesereports to be produced daily, weekly or monthly, or even several times a day,according to your needs. These regularly generated reports can be used, for



NTC TAN 0704/1.1 en62

example, to find out the most typical alarms that are generated, or to list the sitesor network elements that generate frequent alarms.

To run a report automatically, you must define a report group. Report groups aresets of reports that are generated in one operation. A report group contains atleast one report with the corresponding report and search templates. You canlater add new templates to the report group or delete unnecessary ones from it.

You can change the reporting schedule at any time. The automatically generatedreports can be displayed on screen, printed on paper or saved in a file. You canname a log file that will record the starting an stopping times of automaticreporting, as well as any disruptions in report generation.

5.4 Example of Report Generation

In this subsection an example of typical usage of Alarm Statistics in PC ispresented.

Generating a graphical report

In a typical situation, the network administrator wants to have an overview of thealarm situation in the whole network during a certain time, for example oneweek, to see the differences in network load on different weekdays. For thispurpose, he generates a graphical report.

The network administrator plans on generating the same report for the comingweeks also. Therefore, it is reasonable to select the global search template forsearch template type, so that it can be used again in reports concerning the samestudy objects and covering the same time period. Instead of making his reportwith Report Wizard that provides only the normal search template type, thenetwork administrator specifies the necessary report criteria separately in eachtemplate dialog.

1. The network administrator starts off by specifying the report template thatdefines the alarm counters, chart properties and data processing options forthe report. For alarm counter he selects the Alarm History Number ofAlarm Events. He selects the 2D Line for chart type and selects no legendfor the chart layout. In the Chart Layout dialog he also adds the chart title.In the processing options the network administrator selects no columnheader for the chart and changes the time summarisation to one week. Tocomplete the report template, he saves the template as ’Number of AlarmEvents’.

2. After this, the network administrator specifies a new global searchtemplate for his report. He defines the study period to be one week.Because he wants the report to cover the whole network, he does not selectany specific study objects. To accomplish the task, he saves global searchtemplate under the name ’week, whole network’.



NTC TAN 0704/1.1 en63

3. Now the report is ready to be generated. The network administrator selectsthe correct global search template under the new report template Numberof Alarm Events and clicks OK. The report generation starts. The databasesearch may take some time, depending on the database load.

The resulting reports is shown below:

Figure 35.Example of report: Number of Alarm Events

The resulting report assists the network administrator in spotting problematicareas within the network and optimising its capacity. He can also generate thesame report during subsequent weeks to obtain long-term alarm data, and zoomin on problematic areas, when necessary.

Alarm Collection from Third-party Network Elements


NTC TAN 0704/1.1 en64

6 ALARM COLLECTION FROM THIRD-PARTYNETWORK ELEMENTS

The Nokia solution for Fault Management includes a wide variety of tools whichallow you to collect alarm information from external systems. This means thatalarms from third-party equipment can be collected, viewed, and stored in theNMS along with all other network alarms. The protocols supported by Nokiainclude:

Table 2.Integration Protocols Supported by the NMS

With integration to the NMS, a single and centralised view of the network as awhole can be maintained, greatly reducing the workload and making faultlocalisation faster and more reliable. And in cases where the external elementdoes not have its own management system, this feature gives you a fast andsimple way to utilise your NMS for that purpose.

Once alarms are collected, they are changed to the normal NMS alarm formatand from then on they are handled like all other alarms. All NMS alarm handlingapplications can be used for the viewing, analysis, and storing of these alarms.

There are two types of feature available for this:

Table 3.NMS Features for External System Integrations

In Alarm Collection via SNMP, ASCII, or RPC, Nokia personnel perform theintegration of one external element to your NMS and the license fee is covered.This is a good choice if you have a limited number of elements to integrate.

An integration toolkit is a good option if you have a number of elements to beintegrated. With no extra licensing fees, you can integrate as many elements asneeded to your NMS.

Protocol NMS Solution Includes

SNMP (Simple NetworkManagement Protocol)

Alarm collection

ASCII Alarm collection and upload

RPC (Remote ProcedureCall)

Alarm collection and upload

NMS Feature Explanation

Alarm Collection viaSNMP, ASCII, or RPC

Integration by Nokia of one external element tothe Nokia NMS.

Integration Toolkits(SNMP, ASCII, or RPC)

Toolkit for integrating any number of externalelements to the Nokia NMS with no separatelicensing fees.



NTC TAN 0704/1.1 en65

For more information on these features, see your Nokia representative.

Following is a further explanation of the NMS solution for each protocol.

6.1 SNMP

Alarm Collection via SNMP and SNMP Integration Toolkit use two differentmethods for relaying alarm information to the NMS: a trap collector and apolling collector. The integrated network element has an SNMP agent in it whichsends trap PDUs to the NMS, and alarms are generated from this information. Inaddition, the polling collector sends request PDUs and collects their responses,generating alarms or cancels when necessary.

Several configuration files are used by these various processes to make sure thatthe information collected can be used by the NMS. The procedure is shown inthe following picture.

Figure 36.SNMP Trap Collection

When an element has been integrated with the NMS, a new object is added to theNMS system for the element. This object will also have a new symbol in NMSviews and in the Top-level User Interface, which will then reflect the real-timealarm situation in the device.

C o n f i g u r a t i o n f i l e s

A l a r m P r o c e s s i n g

S N M P T r a p C o l l e c t o r

S N M P P o l l i n g C o l l e c t o r

D B

S N M P P D U

3 d i f f e r e n t c o n f i g u r a t i o n f i l e s

N M S

( S N M P a g e n t )N E

C o n f i g u r a t i o n f i l e sC o n f i g u r a t i o n f i l e s



NTC TAN 0704/1.1 en66

6.2 ASCII

Alarm Collection via ASCII and the ASCII Integration Toolkit use an analyserwhich defines the standards for syntax and semantics for the alarms going to theNMS. The alarms are sent from the analyser to the NMS alarm pipe. The wholeprocess is shown in the following picture.

Figure 37.Alarm Collection via ASCII

Alarm Collection via ASCII consists of two parts: the alarm collector and thealarm upload part. The alarm collector collects alarms in ASCII format from thenetwork elements and routes them to the NMS. The alarm upload function isused, when the third-party element supports alarm uploads, to make the NokiaNMS database consistent with the network element alarm situation.


N EC o n f i g u r a t i o n f i l e s

C o n f i g u r a t i o n f i l e s

N M S A l a r m P i p e

N M S

N E

A S C I I a l a r m c o l l e c t o r a n du p l o a d e r

P r o t o c o l a d a p t a t i o n m o d u l e

A n a l y s e r

T r a c e f i l e



NTC TAN 0704/1.1 en67

6.3 RPC

Alarm Collection via RPC and the RPC Integration Toolkit consist of two parts:the adapter and the manager. Theadapter is implemented in the external systemwhich is integrated with the NMS. Themanager consists of the manager basiclibrary, the alarm event manager, and the alarm upload manager. Theseimplement the Nokia NMS part of the interface, and are located in the NMS. Thefollowing picture shows the relationship between all of these parts.

Figure 38.Alarm Collection via RPC

Alarms and cancels are sent from the adapter located in the external system tothe manager in the NMS. The manager then sends them on to the NMS alarmprocessing functions. Alarm uploads are handled through the alarm uploadmanager. In addition, the adapter sends regular ’heartbeat’ events to make surethat the connection to the client stays open at all times.


R P C c l i e n t

N E

R P C s e r v e r N M S a l a r m p i p e

N M S

A l a r m

C o n f i g u r a t i o n f i l e

R P C c a l l t o s e n d a n a l a r m

T o N M S d a t a b a s e a n d a l a r m h a n d l i n ga p p l i c a t i o n s


NTC TAN 0704/1.1 en68

Appendix A. MAPPING OF DIFFERENT ALARMFORMATS

The alarm reports from DX and BTS alarms are somewhat different than the onesshown in the NMS. Following is a mapping of the fields shown in each.

• An explanation of each of the fields shown is in the Explanation of Fieldstable at the end of this appendix.

• Fields are numbered so that you can locate their explanations in theExplanation of Fields table.

• Names in brackets ( ) are not shown in the picture, although the fields exist.

DX Alarm Format

Figure 39.DX Alarm

Figure 40.Fields Shown in DX Alarm


NTC TAN 0704/1.1 en69

BTS Alarm Format

Figure 41.BTS Alarm

Figure 42.Fields Shown in BTS Alarm

NMS Alarm Format

Following is an example of an alarm as it is shown in the NMS, in AlarmHistory’s normal format.

Figure 43.NMS Alarm

Figure 44.Fields Shown in NMS Alarm

1 ( T y p e o f 2 O b j e c t n a m e 1 0 B C F I D 1 1 B T S I D 3 A l a r m t y p e 4 A l a r m s t a r t i n g p r i n t - o u t ) ( o r c a n c e l ) t i m e

5 U r g e n c y 6 G e n . 1 2 T R X I D 1 3 B T S n a m e c l a s s a l a r m c l a s s

1 4 ( A l a r m o b j e c t ) 1 5 ( S t a t e o f a l a r m o b j e c t )

7 N o t i f . 8 A l a r m 9 A l a r m t e x t I D n u m b e r

1 6 R a c k 1 7 S h e l f 1 8 P I U 1 9 P I U t y p e 2 0 U n i t 2 1 S u b u n i t

4 U r g e n c y 8 A l a r m i n g 1 O b j e c t n a m e 9 O b j e c t a d d r e s s 1 0 M a i n t e n a n c e c l a s s s i t e r e g i o n 5 A l a r m 4 U r g e n c y 2 A l a r m t y p e 7 A l a r m o b j e c t n u m b e r c l a s s

1 1 C o n s e c u t i v e n u m b e r 3 A l a r m s t a r t i n g t i m e 3 A l a r m c a n c e l t i m e

6 A l a r m t e x t


NTC TAN 0704/1.1 en70

Explanations of Fields

Field Explanation

1 Type of print/out Either standard alarm print-out or alarm updateprint-out

2 Object name Name of the object representing the alarm site.

3 Sending equipment Computer which sent the alarm.

4 Alarm type The mapping of this fields is shown below.

_____________________________________DX200 Field NMS Equivalent

_______________________________________

SWITCH EQUIPMENT

TRANS COMMUNICATIONS

O & M QUALITY OF SERVICE

POWER EQUIPMENT

EXTERN ENVIRONMENTAL

_______________________________________

If the type is unclear, the field contains questionmarks (??????)

5 Alarm starting (orcancel) time

Time that the alarm was generated in the managedobject,or, in the case of a cancel, the time the alarmwas cancelled.

6 Urgency class Indicates the severity of the alarm: either★★★(critical), ★★ (major), or★ (minor).

If the class is unclear, the field contains a questionmark (?).

If an alarm has been cancelled, the stars in the fieldsare replaced by full stops (for example, a cancelled2-star alarm shows ’..’).

7 General alarm class ALARM, CANCEL, DISTUR, or NOTICE.

In NMS alarms, DISTUR and NOTICE arereplaced by WARNING.

8 Accused object Functional unit which is the object of the alarm.

If the object of the alarm is not a functional unit, thefields displays eight dots (........).


NTC TAN 0704/1.1 en71

9 Position coordinatesof accused object

Shows you the exact place in the rack which causedthe alarm. This is given using the following coding:

RTK-V, where:

R (1...64) is the rack row

T (A...Z) is the rack

K (001...255) is the vertical position of the subrack or cartridge in the rack

V (00...99) is the horizontal position of the subrack or cartridge in the rack

If a rack is the object of an alarm, only RT isdisplayed. An unknown position coordinate isprinted as ??????-??.

10 Alarm issuer Process which produced the alarm.

11 Trial information This fields displays TRIAL if the alarm originatedin the trial configuration (in the case that theexchange has been divided into a traffictransmitting part and a trial configuration).

12 Recoveryinformation

When recovery is informed of the alarm in order tostart the automatic recover actions, RECOV isdisplayed.

13 Source information If the alarm is set before the start-up of thedistributed part of the alarm system, LIB isdisplayed.

14 Notification ID Running number assigned to each alarm by theDX200.

15 Alarm number The number assigned to an alarm as its referencenumber.

16 Alarm text Gives a short description of the alarm.

17 Supplementaryinformation fields

Gives more extensive information on the alarm. Tointerpret this field, open the alarm manual page ofthe alarm in question. The page will give anexplanation of each field shown in thesupplementary info.

18 Additional text A more detaile dtext given in some alarms.

19 Alarm operatinginstructions

Operating instructions the user may have definedfor an alarm.

20 BCF ID Identifier of BCF.

21 BTS ID Identifier of BTS.

22 TRX ID Identifier of TRX.

23 BTS name Name given to BTS.

24 Alarm object FU/CU/LAPD/PCM/RTSL

Field Explanation


NTC TAN 0704/1.1 en72

25 State of alarm objectENABLED The alarm object is able to provide traffic services.

DISABLED The alarm object is not able to provide traffic services

26 Rack

27 Shelf

28 Plug-in unit location CU 0H carrier unit

FHU 1H frequency hopping unit

MCLU 2H master clock unit

RFTE 3H rf test equipment

EACB 4H external alarm and control board

OMU 5H operation and maintenance unit

FU 6H frame unit

RTC 7H remote tune combiner

LNA 8H low noise amplifier

CCF 9H cooling fan

SUPS AH station unit power supply

XUPS BH transceiver unit power supply

RMCA CH receiver multicoupler

COMA DH wideband combiner

EXT EH external (not used)

TPFU FH tower power feed unit

BBU 10H battery back up unit

CAB 12H cabinet

RXFE 13H receiver front end

BIE 14H BTS interface equipment

STM 15H site test monitor unit

MHPA 16H mast head preamplifier

AFLx 17H antenna filtering and low noise amplifier

AMUx 18H antenna monitoring unit

OPTLINK 19H optical link between BTS cabinet and remote head

Field Explanation


NTC TAN 0704/1.1 en73

RF_HEAD 1AH remote head

HEPC 1BH heat exchanger power supply unit

AFEx 12 32H Antenna Filter Extension unit with VSWR range (GSM)

AFEx 12 33H Antenna Filter Extension unit with VSWR range (DCS)

AFEx 11 34H Antenna Filter Extension unit (GSM)

AFEx 11 35H Antenna Filter Extension unit (DCS)

BBAC 36H battery module unit

BBUC 37H rectifier unit

BCFA 38H base control function unit

CCFA 39H cabinet cooling fan unit

FTSA 3AH floating transceiver switch unit (GSM)

FTSB 3BH floating transceiver switch unit (DCS)

PSUA 3CH power supply unit (DC)

PSUB 3DH power supply unit (AC)

RMUA 3EH receiver multicoupler unit (GSM)

RMUB 3FH receiver multicoupler unit (DCS)

RRMA 40H radio relay module unit (RRI+RRO; =DMR18-38I, DMR18-38C or DMR18-38W)

RTCA 41H remote tune combiner unit (GSM)

RTCD 42H remote tune combiner unit (DCS)

STMD 43H site test monitor unit (GSM)

STME 44H site test monitor unit (DCS)

TRUA 45H transmission unit (DE34/DF34)

TRXA 46H transceiver unit (GSM)

TRXD 47H transceiver unit (DCS)

MHPA 48H mast head preamplifier unit

HCUA 49H heat control unit

RRS 4AH radio relay single unit (=DMR18- 38 S)

CABINET 4BH cabinet

RTCC 4CH RTC unit for GSM (1..6 TRX)

RTCF 4DH RTC unit for GSM (1..6 TRX)

CSUA 4EH common supply unit (DC)

CSUB 4FH common supply unit (AC)

Field Explanation


NTC TAN 0704/1.1 en74

TE 50H generic transmission equipment

TRUB 51H transmission unit (DE45/DF45)

TRUC 52H transmission unit with integrated

HDSL modem (DE34/DF34)

TRUD 53H transmission unit with integrated


TRUD 53H transmission unit with integrated


TRUE 54H transmission unit (3rd gen. ANSI BTS)

TRUF 55H transmission unit (4th gen. ANSI BTS)

29 Plug-in unit type

30 Unit

31 Subunit

FIELDS SHOWN ONLY IN NMS ALARMS

32 Alarming site The type and ID of the object representing thealarming site.

33 Object address Address of the object representing the alarm site.

34 Maintenance region The name of the maintenance region to which thealarming object is assigned.

35 Consecutive numberRunning number assigned to each alarm by theNMS.

Field Explanation


NTC TAN 0704/1.1 en75

INDEX

A

ad hoc reports 61adapter 67alarm classes 12

default colours on Top-level UI 17alarm collection

from third-party network elements 16, 26, 64

via ascii 66via RPC 67via SNMP 65via SNMP, ASCII, or RPC 64

alarm collection from SNMP, ASCII, and RPC64

alarm correlation 24, 32, 37implementation of 55

alarm correlation process 55Alarm Correlation Rule Editor 37alarm correlation types 25, 38

compression 25, 43count 25, 41informing delay 56suppression 25, 38

alarm filtering 32, 33implementation of 36process of 36

Alarm Filtering and Reclassification 16, 23alarm flow reduction 23, 31Alarm Forwarder 16, 22Alarm History 16, 21alarm life cycle 27alarm lifting

source objects 13target objects 13

Alarm Manual 16, 20Alarm Monitor 16, 18alarm number ranges 11, 29alarm numbers 29

BTS alarms 30DX alarms 29workstation alarms 30

alarm pipe 6, 28, 55, 66alarm probable cause 11alarm reclassification 32, 56

implementation of 57process of 57

alarm report fieldsexplanations of 70

Alarm Statistics in PC 16, 25, 58automatic reporting 61example of graphical report 61generating reports with 60Number of Alarm Events 63ready-made templates 60ReportWizard 61templates in 59

alarm text 12alarm upload 13Alarm Viewer 16, 19alarms 11Alarms/Category/Day 60ASCII 64, 66ASCII Integration Toolkit 64auto-ack 35automatic acknowledgement 35automatic reports 61

B

BTS alarms 30, 68

C

cancels 11child objects 14compression 25, 43compression rule 43, 44concepts

of Fault Management 11of network management 13

correlation rules 37count rule 25, 41

D

default coloursof alarms 17

distinguished name 14relative 14

DX alarm format 68DX alarms 29, 68


NTC TAN 0704/1.1 en76

E

event types 12communication 12environmental 12equipment 12event processing 12quality of service 13

Explanation dialog 18, 38external system integrations 26, 64

NMS features for 64protocols 64

F

Fault Managementalarm upload 13in NMS Online Helps 7in NMS Online Library 8in System Administrator’s Guides 9information on 6, 7, 8, 9Nokia’s 16

Fault Management applications 16alarm collection from external systems 16Alarm Correlation 16, 24Alarm Filtering and Reclassification 16,

23Alarm Forwarder 16, 22Alarm History 16, 21Alarm Manual 16, 20Alarm Monitor 16, 18Alarm Statistics in PC 16, 25Alarm Viewer 16, 19ASCII Integration Toolkit 16RPC Integration Toolkit 16SNMP Integration Toolkit 16

Fault Management concepts 11alarm 11alarm number 11alarm text 12cancel 11probable cause 11

Fault Management principles 11Fault Management tools 16filtering alarms 33filtering options 34FM 6, 7, 8, 9, 16

G

generating reportsexample of 62

with Alarm Statistics in PC 60global search template 59graphical report

example of 61

I

informing delay 56integration protocols 64

ASCII 64RPC 64SNMP 64

Integration ToolkitsSNMP, ASCII, or RPC 64

L

life cycle of alarms 27logical counters 59

M

managed object 13managed object class 14managed object instance 14manager 67mapping

of alarm formats 68of DX, BTS and NMS alarms 68

MML 5

N

network element reset 13network management 13

concepts of 13network monitoring 31

more effective 32NMS tools for 32

NMS alarm format 69NMS Online Helps 5, 6, 7, 58Nokia’s Fault Management 16notification ID 12Number of Alarm Events

example report 63

O

offline analysis of alarmswith Alarm Statistics in PC 58


NTC TAN 0704/1.1 en77

P

parent and child objects 14parent objects 14PDU 65

R

ready-made templatesAlarms/Category/Day 60example 61in Alarm Statistics in PC 60Top-15 Alarm Active Sites 60Top-15 Alarming Sites 60Top-20 Alarms 60Top-20 Alarms, Numbers 60

reclassification of alarms 56reducing alarm flow 23, 31relation checking 44

basic rule 45calculating steps for 46example 47, 53

Remote Procedure Call 64removing suppression 40report template 59ReportWizard 61retargeting alarms 13routine reports 60RPC 64, 67

manager 67RPC Integration Toolkit 64

S

search template 59Simple Network Management Protocol 64site object 14SNMP 64, 65SNMP Integration Toolkit 64SNMP trap collection 65suppression 25, 38

removal of 40suppression rule 38, 41

example 41

T

templatesglobal search template 59in Alarm Statistics in PC 59logical counters 59report template 59

search template 59third party network elements

integration protocols for 64third-party network elements

alarm collection from 64integration protocols for 64tools for collecting alarms from 26

Top-15 Alarm Active Sites 60Top-15 Alarming Sites 60Top-20 Alarms 60Top-20 Alarms, Numbers 60Top-level User Interface 17

default colours 17Top-level views 15, 17topology 15trap collection 65

U

using FM software 7

W

workstation alarms 30

NOKIA NMS/2000

Documents

Transcript of NOKIA NMS/2000