212630000 e 06

8/13/2019 212630000 e 06

http://slidepdf.com/reader/full/212630000-e-06 1/56

Alcatel-Lucent GSM

Quality of Service Alerters

User Guide

OMC Document

User Guide

Release B10

3BK 21263 AAAA PCZZA Ed.06

8/13/2019 212630000 e 06


Status RELEASED

Short title Alerters UG

All rights reserved. Passing on and copying of this document, useand communication of its contents not permitted without writtenauthorization from Alcatel-Lucent.

BLANK PAGE BREAK

2 / 56 3BK 21263 AAAA PCZZA Ed.06

8/13/2019 212630000 e 06


Contents

Contents

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.2 Alerter Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.2.1 Alerter Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.2.2 Alarm Field Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

1.3 Basic Alerters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151.4 Operator-Defined Alerters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161.5 System Defense . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

1.5.1 Alarm Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171.5.2 Alarm Generation Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181.5.3 Purge Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

1.6 Differences Between Alerters in B9 and B10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201.6.1 OBSAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201.6.2 Basic Alerters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

1.6.3 Indicators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212 Counters and Indicators Used by Alerters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.1 Counters Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242.1.1 BSS Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242.1.2 MFS Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.2 Indicators Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.3 Alerter Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3 Managing Alerters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.1 Basic Alerters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.1.1 Enable a Basic Alerter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.1.2 Modify Basic Alerter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.2 QoS Aler ters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.2.1 Create QoS Alerter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.2.2 Delete QoS Alerter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.2.3 Enable/Disable Qos Alerter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.2.4 Modify Qos Alerter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.2.5 Import/Export QoS Alerters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4 Alerter Alarm Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.1 Alarm Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.2 Current Alarm Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.3 Historical Alarm Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394.4 Post Processing Alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

5 Basic Alerters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

5.1 Basic Alerters Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425.2 Rate of Successful Outgoing HO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435.3 Rate of Successful Incoming HO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435.4 Average Rate of Available Static and Dynamic Radio Time Slots for Traffic Usage . . . . . . . . 435.5 Occupation Rate per Radio Traffic Channel (Half Rate and Full Rate) . . . . . . . . . . . . . . . . . . . 435.6 Rate of Failures Due to Congestion on Air Interface Channels . . . . . . . . . . . . . . . . . . . . . . . . . 445.7 Rate of Unsuccessful RTCH Seizures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445.8 SDCCH Congestion Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445.9 SDCCH Drop Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445.10 Call Drop Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455.11 A_Channel Average Occupancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455.12 Cell with no RTCH Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5.13 Sleeping GPRS Cells Excluding Radio and Ater Congestion . . . . . . . . . . . . . . . . . . . . . . . . . . . 465.14 Sleeping GPRS Cells Partially or Totally Due to Ater Congestion . . . . . . . . . . . . . . . . . . . . . . . 46

3BK 21263 AAAA PCZZA Ed.06 3 / 56

8/13/2019 212630000 e 06


Contents

5.15 Sleeping GPU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465.16 Sleeping GPRS Cells Partially or Totally due to Radio Congestion . . . . . . . . . . . . . . . . . . . . . . 47

6 QoS Alerters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

6.1 Syntax for QoS Alerters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 506.1.1 Operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

6.1.2 Threshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 516.2 Examples of QoS Alerters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 526.2.1 Alerter GPRS Sleeping Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 526.2.2 Alerter SDCCH Fail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 536.2.3 Alerter TCH Fail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 546.2.4 Alerter TCH Assignment Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

4 / 56 3BK 21263 AAAA PCZZA Ed.06

8/13/2019 212630000 e 06


Figures

Figures

Figure 1: Alerters: Thresholding Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Figure 2: Defining filters for Alerters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Figure 3: Tool Chain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

3BK 21263 AAAA PCZZA Ed.06 5 / 56

8/13/2019 212630000 e 06


Tables

Tables

Table 1: Set QoS Alerter Predicates Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Table 2: B10 Basic Alerters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

Table 3: Operators Used in QoS Alerters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

Table 4: Thresholds Used in QoS Alerters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

6 / 56 3BK 21263 AAAA PCZZA Ed.06

8/13/2019 212630000 e 06


Preface

Preface

Purpose This document provides an introduction to alerters and describes how to create,handle and post-process Quality of Service alerters, either the Basic Alerters,defined by default in the OMC-R or the customer-defined QoS Alerters.

What’s New In Edition 06

The following section was updated Differences Betw een Alerters in B9 and B10 (Section 1.6).

In Edition 05The following sections have been updated:

Modify Qos Alerter (Section 3.2.4)

Predicate ( Section 1.2.1.1 )

Stability ( Section 1.2.1.3 )

In Edition 04

Update in the section Create QoS Alerter (Section 3.2.1).

In Edition 03

Update for new equipment naming.

In Edition 02

Update the sections: Basic Alerters Overview (Section 5.1).

Add the sections: Sleeping GPRS Cells Partially or Totally Due to Ater Congestion (Section 5.14), Sleeping GPU (Section 5.15), Sleeping GPRS Cells Partially or Totally due to Radio Congestion (Section 5.16), Cell with no RTCH Traffic (Section 5.12), Sleeping GPRS Cells Excluding Radio and Ater Congestion (Section 5.13)

Editorial update in the section: Indicators Overview (Section 2.2) and Post Processing Alarms (Section 4.4).

In Edition 01

Editorial improvement done in Import/Export QoS Alerters (Section 3.2.5).

3BK 21263 AAAA PCZZA Ed.06 7 / 56

8/13/2019 212630000 e 06


8/13/2019 212630000 e 06


1 Introduction

1 Introduction

This section contains an introduction to alerters, including information about:

Alerter mechanism

Basic and Operator-defined alerters

System implementation and defense.

3BK 21263 AAAA PCZZA Ed.06 9 / 56

8/13/2019 212630000 e 06


1 Introduction

1.1 Overview

Based on counters/indicators, alerters are dedicated to speed up the reactivityof the operational team to detect and to solve any Quality of Service (QoS)degradation so as to restore telecom resources as fast as possible and toimprove network availability seen by the end user. OBSAL is a new OMC-R

component that allow management of alerters and alarm generation.

1.2 Alerter Mechanism

The aim of the alerter is to detect and generate alarms towards the OMC-Rbased on Performance Measurement data.

Alerters have associated some attributes: name, alarm id, table name,predicates, validity and stability conditions. At the end of each PM reportingperiod, the loader processes algorithms on these alerters, using thresholds andvalidity conditions, to detect the appearance or suppression of an alarm.

Each alarm is processed by the OMC-R like all other alarms. The alerters are

calculated by OBSAL from counters/indicators.

There are two types of alerters:

Basic alerter

Operator-defined alerter.

Basic alerters are delivered with the system and cannot be defined by operator.The operator can modify only a part of Basic Alerters related parameters.

1.2.1 Alerter Attributes

Basic and operator-defined alerters have the following attributes:Alerter name: a short string displayed in AS main screen to characterise

the alarm

Alarm id: identifies the alarm associated with the alerter. It is automatically

computed by the system

Predicate

Alarm Severity

Validity condition: applicable only for Basic Alerters

Stability: the time for a predicate to be true before the alarm commitmentPreventive action

Activation: the operator can enable or disable the alerter

Scope: defines the action’s range of the alerter on both time scale and

involved objects.

10 / 56 3BK 21263 AAAA PCZZA Ed.06

8/13/2019 212630000 e 06


1 Introduction

The following figure illustrates the thresholding mechanism with two hysteresisused for the management of the alarms related to the indicators/alerters.

This figure does not take into account the stability associated with the alerter. Itonly deals with the process of thresholding.

Indicator Value

H2

H1

Startingpoint

L2

L1

Alarm(threshold level = H2,severity = major)

Alarm(threshold level = H1,severity = cleared)

Alarm(threshold level = L1,severity = major)

Alarm(threshold level = L2,severity = cleared)

1x

Reporting Period

2x 3x 4x 5x

Figure 1: Alerters: Thresholding Process

1.2.1.1 Predicate

A predicate is the association of a formula of counters or indicators with athreshold (appearance or clearing of alarm). The formulas can only combinecounters/indicators relative to same object, and belonging to the same PMtype. Only simple operators can be used (‘+’, ‘-‘, ‘*’, ‘/’).

An alarm is generated when the detection predicate becomes true, and iscleared when the clearance predicate is reached.

For Basic Alerters, the following predicates are defined

Validity

Raise Predicate

Clear Predicate

For each of them, only the comparison values used in the predicate formula(thethresholds), can be modified.

For QoS Alerters, operator can define predicate to raise alarms per severity.The clearing predicate is unique. In case it is not defined, the alarm will becleared by the purge mechanism, ie if during 6 hours, either predicate for ON

conditions is false or counters are missing. and is mandatory

3BK 21263 AAAA PCZZA Ed.06 11 / 56

8/13/2019 212630000 e 06


1 Introduction

Example: a formula Counter1 + Counter2.

Two thresholds are defined: 80% and 90%. The predicate for alarm detectionis Counter1 + Counter2 > 0.90. When it is true, an alarm detection conditionis reached. The predicate for alarm clearing is Counter1 + Counter2 < 0.80.When it is true and if there was an alarm, it is a condition for alarm clearance.

For details about the mechanism of raise/ clear alarm, refer sections Stability (Section 1.2.1.3 ) and Validity ( Section 1.2.1.4 )

For details refer Syntax for QoS Alerters (Section 6.1).

1.2.1.2 Scope

Normally an alarm is defined over all data that is loaded into the specified tablein the performance database. However, there are circumstances when theuser may need to limit the scope of an alarm to a specific network region or aspecific time of the day. This can be accomplished by defining an expression forthe alarm scope. If the scope expression evaluates is true, the alarm is tested.

There are two parameters defining the scope of an alarm:

Time scope: allows the operator to define a period of time during which the

alarm can be generated

Object scope: defines the objects impacted by the alerter.

1.2.1.3 Stability

Stability defines the number of minutes for which there must be evidence ofthe predicate being true for an alarm to be generated or cancelled. By defaultan alarm is generated if the predicate evaluates true for one measurementinterval. By setting the Stability field, the user can require that the predicatemust be true for N minutes before an alarm is to be generated, where Nis a multiple of the PM load period.

There are two distinct values to be set regarding stability:

for RAISE condition

for CLEAR condition.

When the period and object scope are reached, the alerter mechanismevaluates the defined predicates (evaluation of the formula and the thresholds).If the predicate is true (the alarm condition is reached), the alerter mechanismchecks if the predicate was true during the last stability period. For example:the scope is from 2h00 p.m. and stability is 60 minutes. At 2h p.m. thealerter mechanism checks the predicate. if it is true, the alerter checks that

the predicate was true from 1 p.m. to 2 p.m. If yes, the alarm is generated:otherwise, it is generated only after 60 minutes of the alarm condition being true.

An alarm is cleared only if the detection predicate has remained false and theclearance predicate has remained true during the specified number of minutes.

1.2.1.4 Validity

Another type of limitation on the scope of an alarm is its validity. An alarm isgenerated when this condition is fullfilled only.

This attribute reffers only Basic Alerters. Validity is system defined, the operatorcan modify the threshold. In most of the cases, Validity condition is satisfiedwhen a threshold is reached by a number of events.

12 / 56 3BK 21263 AAAA PCZZA Ed.06

8/13/2019 212630000 e 06


1 Introduction

For example, the rate of SDCCH_DROP_RATE may generate an alarm only ifthe number of SDCCH seized is reaching a threshold.

3BK 21263 AAAA PCZZA Ed.06 13 / 56

8/13/2019 212630000 e 06


1 Introduction

1.2.2 Alarm Field Description

Alarms are mainly made up of the following fields (according to GSMrecommendation X.733):

Alarm type = Quality of Service

Event time = Time and date when event was detected

Probable cause = threshold crossed

Managed object class = GSM: Cell, BSC, TRX, N7SL, X25, N7 LS,

A_interface Channel. For Managed object class = GPRS: PVC, Bearer

Channel, Sub-BSS

Specific problem: Alarm id (range 200001 to 200030 for Basic Alerters,

200031 to 300000 for Operator Defined Alerters)

Severity = minor/ major/ critical/ warning/ indeterminate (customizable) upon

alarm appearance, or cleared upon alarm disappearance

Additional text: friendly name of the alerter, formula with the value of the

exceeded threshold; preventive action.

14 / 56 3BK 21263 AAAA PCZZA Ed.06

8/13/2019 212630000 e 06


1 Introduction

1.3 Basic Alerters

Basic alerters are defined like standard indicators, except that an alarm id,preventive action and default values of thresholds and validity condition areassociated to these alerters.

The basic alerter’s attributes are displayed to the operator using the OBSALapplication. The operator can enable/disable an alerter or can modify itsatributes.

The alarm type, probable cause and alarm severity of the alarm generated bybasic alerters are set by default to following values:

Alarm type: quality of service

Probable cause: threshold crossed

Alarm severity: warning.

For basic alerters there are two predicates with the same formulae but different

thresholds: one for alarm appearance and one for the clearance of the alarm.

Operator is not allowed to modify formulae of the predicate for Basic Alerter.

3BK 21263 AAAA PCZZA Ed.06 15 / 56

8/13/2019 212630000 e 06


1 Introduction

1.4 Operator-Defined Alerters

QoS Alerter manage the same functionality as Basic Alerter, plus the possibilityto use more counters/indicators in predicate definition. QoS Alerter function isan optional feature acesible trough OBSAL. It allows the operator to add newalerters to the set of Basic Alerters.

From now on in this document, operator-defined alerters are also referredto as QoS Alerters.

After installation, there are no QoS Alerter defined. They are createdafterwards, by the operator, using the dedicated window from OBSAL module.

QoS Alerters have some specific characteristics:

The predicates of an alerter are based on counter formulae or stored

indicator formulae. It is possible to create alerters from counter types 1, 2, 6,

7, 8, 9, 18, 19, 25, 28, 29, 30, 32, 110 and from all GPRS counters.

It is not possible to create operator-defined Alerters for the A_channel and

sub-BSS objects.

The operator may create and modify attributes of an already existed

QoS Alerter.

For operator-defined alerters only, there are five entries which allow the

customer to define up to five predicates: up to 4 appearance predicates

for severity (critical and/or major and/or minor and/or warning) of the

generated alarm, and one clearance predicate. The predicates used to

define detection and clearance conditions may be different.

To avoid the system overload by using a big number of enabled alerters, the

maximum permitted number of enabled alerters is set to 20. If this thresholdis met, new alerters can be created, but must be disabled.

16 / 56 3BK 21263 AAAA PCZZA Ed.06

8/13/2019 212630000 e 06


1 Introduction

1.5 System Defense

1.5.1 Alarm Server

The alarm server use as input alerter definitions, loadmaps and files containing

the network configuration (MIPM files).

Alerter definition are stored on disk, in separate files: each alerter in one

file. All definition files are stored archived in a configuration directory.

The loadmaps are stored in the configuration directory and updated

periodically, in case they are changed. The loadmaps are used to evaluate

the formulas expressions and to convert them to a formula of counters

according to the PM file version: B9 or B10

MIPM files are copied by the parsers in 2 directories, depending on

technology: GSM and GPRS. The alarm server is testing the content of

these directories periodically. The found files are processed and thendeleted.

MIPM files

Config files

Alarm Server

QoS Alerters HMI

Basic Alerters HMI

QoS Alerters Definitions

Basic Alerters DefinitionsAlarms

In the initialisation phase, the alerters definitions are loaded and stored inmemory. Based on the counters and indicators formulas from the loadmapsfiles, the predicates expressions are parsed and converted, resulting oneformula of counters for each supported PM files: B9 and B10.

The current alarm list is also stored in memory. This list is saved in a file ondisk every time its content is modified. Also in initialisation phase, the alarm listis loaded from the file in memory. In this way when alarm server is stopped, thealarm list is not lost, being loaded the next time the application starts.

3BK 21263 AAAA PCZZA Ed.06 17 / 56

8/13/2019 212630000 e 06


1 Introduction

1.5.2 Alarm Generation Mechanism

This function detects and generates alarms towards the OMC-R.

At the end of each PM reporting period, the alarm detector processesalgorithms defined in the indicator database using thresholds and validityconditions to detect the appearance (alarm generation) or the end of an alarm(alarm clearance). The algorithms are based on indicators.

The order in which appearance conditions are evaluated is scope, validityand the predicates in theirs severity order (first is the highest - critical, thelast - warning). If one of the predicates conditions is met (together with thestability), the rest of them are ignored and an alarm is generated with thecorresponding severity.

When the begin or the end of an alarm is detected, the Alarm Server (AS)writes it in an active alarm file, puts it in the X.733 format and then dispatches itto the concerned OMC-R application (BSS-IM or MFS-IM).

When an alarm is detected, AS checks if this alarm is already in the activealarm file. If it is, AS updates the generation time of this alarm and nothing issent to the OMC-R. If it is not, AS adds the new alarm to its active alarm fileand sends it to the OMC-R.

If one of the predicates is true, the server uses the following algorithm:

When an alarm clearance is detected, AS checks if the alarm raised is inthe active alarm file. If it is and if the stability is met, AS deletes the alarmfrom its active alarm file and sends the clearance to the OMC-R. If it is not,nothing is done.

The following algorithm is applied if the clearance predicate is true:

18 / 56 3BK 21263 AAAA PCZZA Ed.06

8/13/2019 212630000 e 06


8/13/2019 212630000 e 06


1 Introduction

1.6 Differences Between Alerters in B9 and B10

1.6.1 OBSAL

In B10, alerter function is still available as an option of the OMC-R but with

some slight changes due to MPM replacement by NPO. OBSAL, a new OMC-Rspecific component, is now dedicated to alerter definition and management.So OBSAL function can be available without having MPM/NPO embeddedinstalled on OMC-R. OBSAL parses the PM result files received from NEs(BSC and MFS). OBSAL generates csv files that will be used by NPO and alsogenerate the OBSYNT files.

Alerter definitions as well as the history of active alarms are stored by OBSALcomponent itself.

The OBSAL functionality is fully similar with what was previously implementedin previous releases: from custoemr point of view the same mechanism isavailable to create and manage alerters, both basic and customer-defined.

At graphical interface level, a new icon is available in the OMC-R IconBox. Byclicking on the "Parser, Obsynt & Alerter (OBSAL)" icon, operator will accessalerter definitions and administration, as shown below:

1.6.2 Basic Alerters

Definitions of B10 basic alerters are the same with the ones used in B9.

Two minor changes of basic alerters names have been performed due toNPO replacement of the old NPA/RN:

B9 Basic Alerter Name B10 Basic Aler ter Name

RTCH_assign_unsuccess_NPA_rate RTCH_assign_unsuccess_rate

NPA_RTCH_available_rate RTCH_available_rate

20 / 56 3BK 21263 AAAA PCZZA Ed.06

8/13/2019 212630000 e 06


1 Introduction

1.6.3 Indicators

Difference with METRICA/MPM: in METRICA/MPM, one could use ‘operatordefined indicators’ but this will not be possible anymore.

3BK 21263 AAAA PCZZA Ed.06 21 / 56

8/13/2019 212630000 e 06


1 Introduction

22 / 56 3BK 21263 AAAA PCZZA Ed.06

8/13/2019 212630000 e 06


2 Counters and Indicators Used by Alerters


This contains a brief description of the counters and indicators used by alerters.

3BK 21263 AAAA PCZZA Ed.06 23 / 56

8/13/2019 212630000 e 06



2.1 Counters Overview

A counter is a measurement dedicated to an observed object and a granularityperiod. A counter is release dependant. Counters are used:

To calculate the raw indicators, at the end of each period

For operator consultation, using the PM browser.

OBSAL retrieve GSM counters from the BSS and GPRS counters from theMFS. The LCS counters are retrieved from both the BSS and the MFS.

Only a part of these counters are used at alerters generation.

For more information about counters, refer to the:

BSS Surveillance

Operation Maintenance Principles .

2.1.1 BSS CountersAt the OMC-R there are two types of counters: standard and detailed.

Standard counters: (also called raw types) can be activated on a whole

BSC. Some of them are permanent. In this case they run on all BSS

managed by the OMC-R. The standard types not in the permanent raw

types list can be provided on user demand as detailed counters.

The granularity period can be as short as 30 minutes, except for:

Type 180 which has granularity period of four hours

RMS counters which have a granularity period of once a day.

Detailed counters: used for further analysis of network behavior. They can

be activated only on a limited number of cells and on user demand. The

granularity period can be as short as 15 minutes.

24 / 56 3BK 21263 AAAA PCZZA Ed.06

8/13/2019 212630000 e 06



Measurement Type Object Observed

7: LAPD

8: X.25

per LAPD link of the BSC

per X.25 link of the BSC

9: N7 per N7 of the BSC

18: A Interface per BSC

19: SMS PP

25: SCCP

28: SDCCH HO

29: Directed Retry

per cell

per N7 of the BSC

per cell

per cell

30: SMS CB per BSC

31: Radio Measurements Statistics per cell

32: Change of frequency bandmeasurements

33: Electro-Magnetic Em. Counters

34: Voice Group Call services

per cell

per cell

per cell

110: Overview per TRX, cell, BSC or N7

Standard Measurementtypes

180: GSM Traffic Flow per adjacency: variable servingcell-variable target cell

3BK 21263 AAAA PCZZA Ed.06 25 / 56

8/13/2019 212630000 e 06


8/13/2019 212630000 e 06



2.2 Indicators Overview

Indicators have the following characteristics:

An indicator is a formula of counters or stored indicators. It can be a simple

counter or a complex formula

Indicators allow long-term analysis of QoS

An Indicator is multi-released but its formula may depend on release of

the BSC or MFS

OBSAL provides indicators from GSM, GPRS and LCS counters.

2.3 Alerter Domain

The domain of an alerter is given by the combination between a measurementtype and an object class. Inside one domain both counters and indicators may

be used. The available domains are listed in the table below:

Measurements Object Class

TYPE_1: Traffic Measurement CELL

TYPE_1: Traffic Measurement TRX

TYPE_2: Resource availabilitymeasurements

CELL

TYPE_6: TCH Handovermeasurements

CELL

TYPE_7: LapD measurements LAPD

TYPE_8: X.25 measurements X.25

TYPE_9: N7 measurements SIGNALING LINK

TYPE_9: N7 measurements LINK SET

TYPE_18: A interface measurements BSC

TYPE_18: A channel interface

measurements

ACH

TYPE_19: SMS measurements CELL

TYPE_25: SCCP measurements SIGNALING LINK

TYPE_28: SDCCH Handovermeasurements

CELL

TYPE_29: Directed retrymeasurements

CELL

TYPE_30: SMS Cell Broadcast

Measurements

BSC

3BK 21263 AAAA PCZZA Ed.06 27 / 56

8/13/2019 212630000 e 06


8/13/2019 212630000 e 06


3 Managing Alerters

3 Managing Alerters

This section provides the procedures used to manage alerters.

You must have a profile including a FAD allowing access to the OBSAL.For more information regarding Administration, refer to the 9153 OMC-R Network Administration Handbook , Administration Tasks for MPM.For information regarding counters and indicators, refer to PM Counters andNPO Indicators .

3BK 21263 AAAA PCZZA Ed.06 29 / 56

8/13/2019 212630000 e 06


3 Managing Alerters

3.1 Basic Alerters

The Basic Alerter Configuration application provides a common graphicalinterface, that allows to user to edit the basic alerters. As inputs, it uses thebasic alerter definition files.

The main window contains a list with the available Basic Alerters, displaying thefull definition of the selected one from the list, as in the following figure:

The operator can select one basic alerter from the list and enable/disable it orto perform a modification on the selected alerter’s attributes.

3.1.1 Enable a Basic Alerter

To enable/disable a Basic Alerter:

1. In the OBSAL menu, select Basic Alerter

2. In Basic Alerter Window (on the left), select the Alerter you want to disable.

3. Select/Unselect [ Alerter enabled ]

4. Click on [ Save. ]

3.1.2 Modify Basic Alerter

The operator can modify the value of the following attributes of an basic alerter:

Alerter severity

Time and object scope

Predicate threshold (both the upper and the lower)

Validity threshold

Appearance and clearance stabilities

Preventive action text.

30 / 56 3BK 21263 AAAA PCZZA Ed.06

8/13/2019 212630000 e 06


3 Managing Alerters

To modify a Basic Alerter:

1. In Basic Alerter Window (on the left), select the Alerter you want to modify.

2. Modify the related fields.

3. Click on [ Save ] to update the parameters for the Basic Alerter.

3.2 QoS Alerters

The QoS Alerter configuration application provides a graphical interface, thatpermits to the user to perform a series of operations on the QoS Alerter:create, enable/disable, edit, delete, import/export.

The inputs of this application are the QoS Alerters definition files, theconfiguration files and the loadmap files (used to display the availablecounters/indicators).

3.2.1 Create QoS Alerter

This procedure allows the operator to add new alerters to the set of BasicAlerters.

The OMC-R alerter can have up to four predicates, one for each severity. It canalso have one predicate for clearance.

A window from the OBSAL menu allows the operator to define the attributes ofthe operator-defined alerter.

To create a QoS alerter:

1. From the 9153 OMC-R Iconbox, click on the [ Paser, Obsynt & Alerter(OBSAL) ] icon.

2. The "OBSAL" window opens.

3. Select QoS Alerter.

A new window appears if there were no QoS Alerters defined. On theMessage Window click on [ OK ]

4. From QoS Alerters Window define new Alerter.

File->New

In the new window fill in the required fields.The parameters mandatory to befilled with data are the following:

’Name’

’Domain’ (you have to select for both ’Measurement’ and ’Object Class’

) from attached select window

You must select at least one predicate except the clearance predicate.

3BK 21263 AAAA PCZZA Ed.06 31 / 56

8/13/2019 212630000 e 06


3 Managing Alerters

Parameters Description

QoS Alerter Scope Defines the Alerters scope. It can be either a particular element e.g. CELL_2-1or/and a Alerter work period. Regarding period, the stepsize is 15 min.

Critical Predicate The alarm is perceived as critical.

Major Predicate The alarm is perceived as major.

Minor Predicate The alarm is perceived as minor.

Warning Predicate The alarm is perceived as a warning.

Clearance Predicate The alarm is cleared (removed) after disappearance.

32 / 56 3BK 21263 AAAA PCZZA Ed.06

8/13/2019 212630000 e 06


3 Managing Alerters

Parameters Description

Stability The number of minutes before an alert is generated after crossing the threshold(RAISE field), respectively before an alert is cancelled (CLEAR field).

Alerter Text Friendly description of the Alerter.

Table 1: Set QoS Alerter Predicates Description

5. For defining a ’Predicates’ , operator needs to enter ’Edit Predicate’ windowby clicking on right most button of related predicate. From this window, canbe selected operators and counters/indicators as terms of predicate.

6. After you have entered the necessary parameters, click on [ OK ].

7. After each declaration of the new alerter, all "USMs" windows must beclosed and re-opened again in order to see in "AS Current USM" windowthe correct description of that alerter.

Note: For further information on the syntax used for Alerter predicates, referto Syntax for QoS Alerters .

3.2.2 Delete QoS Alerter

To delete a QoS alerter:

1. In the "OBSAL" window, select QoS Alerter.

The QoS Alerter window opens.

2. Select the name of the Alerter you want to delete on ’ Select Alerter’ field.

3. Select File->Delete.

3.2.3 Enable/Disable Qos Alerter

To enable/disable an QoS Alerter:

1. After you select the alerter you want to disable, choose: File->Edit . In thewindow that appeared select/unselect [ QoS Alerter enabled ].

2. Click on [ OK ].

The window closes and the alerter is locked.

3.2.4 Modify Qos Alerter

Modifying QoS Alerter:

1. In QoS Alerter Window (on the left), select the Alerter you want to modify.

2. Choose from the menu: File->Edit

3. Modify the related fields, and click on [ OK ].

If the name is modified, the operator is asked if he wants to rename the alerteror to create a copy of the first one.

By clicking on the attached buttons of Scope and Predicates entry , dedicatedwindows are opened for advanced editing.

For details about the QoS Alerters fields, refer section Create QoS Alerter ( Section 3.2.1).

3BK 21263 AAAA PCZZA Ed.06 33 / 56

8/13/2019 212630000 e 06


8/13/2019 212630000 e 06


4 Alerter Alarm Handling


This describes how system handles alarms generated by Alerters.

3BK 21263 AAAA PCZZA Ed.06 35 / 56

8/13/2019 212630000 e 06


8/13/2019 212630000 e 06



Figure 2: Defining filters for Alerters

38 / 56 3BK 21263 AAAA PCZZA Ed.06

8/13/2019 212630000 e 06


8/13/2019 212630000 e 06


5 Basic Alerters

5 Basic Alerters

This section describes the Basic Alerters defined in Alcatel-Lucent BSSrelease B10

3BK 21263 AAAA PCZZA Ed.06 41 / 56

8/13/2019 212630000 e 06


5 Basic Alerters

5.1 Basic Alerters Overview

The following attributes cannot be changed:

Alerter name (name of the alerter)

Alarm id (identification of the alarm associated with the alerter)

Formula (alerter formula based on counters, no clearance formula).

The table below presents the Basic Alerters available in Alcatel-Lucent BSSRelease B10.

AlarmId RefName Mnemonic longName

200001 HOORSUR Out_succ_rate HO_Out_success_rate

200002 HOIRSUR In_succ_rate HO_Inc_success_rate

200003 TCAVAR RTCH_available_rate RTCH_available_rate

200004 TCTRR Occupation _rate_per_TCH (Half Rateand Full_Rate)

RTCH_fail_rate

200005 TCAHCGR RTCH_cong_rate RTCH_cong_rate

200006 TCNAUNR RTCH_assign_unsuccess_rate RTCH_assign_unsuccess_rate

200007 SDAHCGR SDCCH_cong_rate SDCCH_cong_rate

200008 SDCDR SDCCH_drop_rate SDCCH_drop_rate

200009 QSCDR call_drop_rate call_drop_rate

200014 QSTRN A_channel_occ_time_alerter A_channel_occ_time_alerter

200015 Cell_no_RTCH_traffic Cell_no_RTCH_traffic

200016 Sleeping_GPRS_cells_excl_cong Sleeping_GPRS_cells_excluding_radio_

and_ater_cong

200017 Sleeping_GPRS_cells(ater_cong) Sleeping_GPRS_cells_partially_or_

totally_due_to_ater_cong

200018 Sleeping_GPU Sleeping_GPU

200019 Sleeping_GPRS_cells(radio_cong) Sleeping_GPRS_cells_partially_or_ totally_due_to_radio_cong

Table 2: B10 Basic Alerters

All these Basic Alerters have the following features set by default:

Alarm Type: Quality Of Service

Probable cause: Threshold Crossed

Alarm severity: Warning

For the Basic Alerter, there is only one rule defined in the formula.

42 / 56 3BK 21263 AAAA PCZZA Ed.06

8/13/2019 212630000 e 06


5 Basic Alerters

5.2 Rate of Successful Outgoing HO

Indicator Name/Ref. name HO_Out_success_rate/HOORSUR

Description Rate of successful outgoing HO (both Internal and External)

(TCH+SDCCH). Note that both preparation and execution phases areconsidered.

Unit %

5.3 Rate of Successful Incoming HO

Indicator Name/Ref. name HO_Inc_success_rate/HOIRSUR

Description Rate of successful Incoming intra + intercell HO (TCH+SDCCH).Note that both preparation and execution phase are considered. Itcorresponds to the real incoming handover efficiency rate. If no IncomingHO, the rate is set to 100.

Unit %

5.4 Average Rate of Available Static and Dynamic Radio TimeSlots for Traffic Usage

Indicator Name/Ref. name RTCH_available_rate

Description Average rate of available static and dynamic radio time slots for trafficuse (i.e., TCH (for HR or FR usage) or PDCH). Note: here "Available"has to be understood as the operational state of a time slot. The time slotis available if it is not "blocked" or "out of service" - A dynamic SDCCH/8time slot cannot be a PDCH (it cannot carry GPRS traffic).

Unit %

5.5 Occupation Rate per Radio Traffic Channel (Half Rate andFull Rate)

Indicator Name/Ref. name Occupation_Rate_per_TCH/TCTRR

Description Rate of traffic channel usage (FR and HR)

Unit %

3BK 21263 AAAA PCZZA Ed.06 43 / 56

8/13/2019 212630000 e 06


5 Basic Alerters

5.6 Rate of Failures Due to Congestion on Air InterfaceChannels

Indicator Name/Ref name RTCH_cong_rate/TCAHCGR

Description Rate of failures during assignment and handover procedures, due tocongestion on the Air Interface channels (RTCH).

Unit %

5.7 Rate of Unsuccessful RTCH Seizures

Indicator Name/Ref name RTCH_assign_unsuccess_rate/TCNAUNR

Description Rate of unsuccessful RTCH seizures (congestion + failures) for normalassignment purposes.

Unit %

5.8 SDCCH Congestion Rate

Indicator Name/Ref name SDCCH_cong_rate/SDAHCGR

Description Rate of SDCCH not allocated during radio link establishment andhandover because of congestion on the Air interface over the amount ofSDCCH requests for radio link establishment and handover.

Unit %

5.9 SDCCH Drop Rate

Indicator Name/Ref. name SDCCH_drop_rate/SDCDR

Description Rate of SDCCH drops due to BSS Problems, Radio Link Failure orduring HO procedure. If no SDCCH traffic, the rate is set to 0. HOincoming and outgoing are omitted at denominator because of lowprobability of occurrence.

Unit %

44 / 56 3BK 21263 AAAA PCZZA Ed.06

8/13/2019 212630000 e 06


5 Basic Alerters

5.10 Call Drop Rate

Indicator Name/Ref name call_drop_rate/QSCDR

Description Rate of call drop: % of TCH dropped after successful assignment. If no

call (either no call setup and no HO or all call setup and incoming HOperformed an outgoing HO), the rate is set to 0. Incoming HO are addedand outgoing HO are removed from the number of TCH seized to havethe real number of calls in the cell. TCH drops occurring after successfulassignment but before speech connection are considered as call drops.

Unit %

5.11 A_Channel Average Occupancy

Indicator Name/Ref name A_channel_occ_time_alerter/QSTRN

Description Averaged time during which the A_channel is busy after allocation,in seconds.

Unit Seconds

5.12 Cell with no RTCH Traffic

Indicator Name Cell_no_RTCH_traffic

Description Sleeping RTCH traffic with SDCCH traffic (RTCH unavailability).Applies to RTCH assignment failure because of BSS orradio congestion. The alerter is raised when: (the number ofSDCCH_assign_allocated > 50) AND (the number of RTCHassignment request > 0) AND (the number of RTCH assignmentFR+HR allocated == 0).

Critical Predicate (MC148>50)&&(MC140a>0)&&

(MC702a+MC702c+MC704a+MC702b+MC704b==0)

Clearance Predicate MC702a+MC702c+MC704a+MC702b+MC704b>0

Unit c

3BK 21263 AAAA PCZZA Ed.06 45 / 56

8/13/2019 212630000 e 06


5 Basic Alerters

5.13 Sleeping GPRS Cells Excluding Radio and Ater Congestion

Indicator Name Sleeping_GPRS_cells_excluding_radio_and_ater_cong

Description This aler ter is raised for sleeping GPRS cells when (the number of

UL TBF estab success = 0) AND (the number of UL TBF requests> 20) AND (the number of DL TBF estab requests =0) AND (thenumber of UL estab failure radio cong =0) AND (the number ofUL estab failure ater cong =0)

Critical Predicate (P30a+P30b+P30c==0)&&(P62a+P62b+P62c-P438c>20)&&

(P91a+P91b+P91c+P91d+P91e+P91f==0)&&(P27==0)&&(P105h==0)

Clearance Predicate (P30a+P30b+P30c>0)||(P91a+P91b+P91c+P91d+P91e+P91f>0)

Unit %

5.14 Sleeping GPRS Cells Partially or Totally Due to AterCongestion

Indicator Name Sleeping_GPRS_cells_partially_or_totally_due_to_ater_cong

Description This alerter is raised for partially or totally sleeping GPRS cellswhen (the number of UL TBF estab success = 0) AND (the numberof UL TBF requests > 20) AND (the number of DL TBF estabrequests =0) AND (the number of UL estab failure ater cong >0)


(P91a+P91b+P91c+P91d+P91e+P91f==0)&&(P105h>0)


Unit %

5.15 Sleeping GPU

Indicator Name Sleeping_GPU

Description This aler ter aim is to detect sleeping GPU for mono GPU BSCs. Itlooks for a very low GPU TBF establishment success rate. Thealerter is raised when (the number of UL and DL TBF estab requestsat BSC level = 0) OR (the TBF establishment success rate < 10%).

Critical Predicate P107==0||(P106/P107<0.1)

Clearance Predicate P106/P107>0.85

Unit %

46 / 56 3BK 21263 AAAA PCZZA Ed.06

8/13/2019 212630000 e 06


5 Basic Alerters

5.16 Sleeping GPRS Cells Partially or Totally due to RadioCongestion

Indicator Name Sleeping_GPRS_cells_partially_or_totally_due_to_radio_cong

Description This alerter is raised for partially or totally sleeping GPRS cellswhen (the number of UL TBF estab success = 0) AND (the numberof UL TBF requests > 20) AND (the number of DL TBF estabrequests =0) AND (the number of UL estab failure radio cong >0)


(P91a+P91b+P91c+P91d+P91e+P91f==0)&&(P27>0)


Unit %

3BK 21263 AAAA PCZZA Ed.06 47 / 56

8/13/2019 212630000 e 06


5 Basic Alerters

48 / 56 3BK 21263 AAAA PCZZA Ed.06

8/13/2019 212630000 e 06


6 QoS Alerters

6 QoS Alerters

This section describes the syntax used to define QoS Alerters and providesexamples.

3BK 21263 AAAA PCZZA Ed.06 49 / 56

8/13/2019 212630000 e 06


6 QoS Alerters

6.1 Syntax for QoS Alerters

The formula of a QoS alerter can be a formula of counters or a formula ofindicators. But the advantage of defining alerters on indicators is that indicatorsare release independent.

6.1.1 Operators

Supported operators are available when create Predicates. A description ofthese operators can be found on following table:

Operator Description Example

+ - / * Numeric addition, subtraction, division and multiplication.The operands are converted to real, the arithmetic isperformed and the result is converted back to a string. Ifany of the operators is a number, the result is an emptystring; no error is raised. The division by zero returns

zero.

(TDUR/ (TDEFCH-TUNAVAL))/3600

== > < >= <=!=

Numeric relational operators. If the predicate is true, theresult is a string "true"; else it is "false".

(TSUCC == 0)

! || Boolean NOT, AND and OR operators whose operandsare the strings "true" or "false".

(TSUCC == 0) (IHOSUCC> 0)) || ((TSUCC > 0)(IHOSUCC == 0)) || ((TSUCC+ IHOSUCC== 0) (TUNAVAIL== 0) (TDEFCH > 0))

Table 3: Operators Used in QoS Alerters

50 / 56 3BK 21263 AAAA PCZZA Ed.06

8/13/2019 212630000 e 06


8/13/2019 212630000 e 06


6 QoS Alerters

6.2 Examples of QoS Alerters

6.2.1 Alerter GPRS Sleeping Cells

52 / 56 3BK 21263 AAAA PCZZA Ed.06

8/13/2019 212630000 e 06


6 QoS Alerters

6.2.2 Alerter SDCCH Fail

3BK 21263 AAAA PCZZA Ed.06 53 / 56

8/13/2019 212630000 e 06


6 QoS Alerters

6.2.3 Alerter TCH Fail

54 / 56 3BK 21263 AAAA PCZZA Ed.06

8/13/2019 212630000 e 06


6 QoS Alerters

6.2.4 Alerter TCH Assignment Failure

3BK 21263 AAAA PCZZA Ed.06 55 / 56

8/13/2019 212630000 e 06


212630000 e 06

Documents