Quality of Service Alerters User Guide ed04.pdf

Alcatel BSS

Quality of Service Alerters

User Guide

OMC Document

User Guide

Release B9

3BK 20963 AAAA PCZZA Ed.04

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/Evolium.

BLANK PAGE BREAK

2 / 54 3BK 20963 AAAA PCZZA Ed.04

Contents

Contents

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

1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.2 Alerter Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.2.1 Alerter Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.2.2 Alarm Field description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

1.3 Basic Alerters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141.4 Operator-Defined Alerters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151.5 System Defense . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

1.5.1 Alarm server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161.5.2 Alarm Generation Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171.5.3 Purge Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

1.6 Differences Between Alerters in B8 and B9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191.6.1 Purge Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191.6.2 Basic Alerters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191.6.3 QoS Alerters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191.6.4 Other Improvements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2 Counters and Indicators Used by Alerters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.1 Counters Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.1.1 BSS Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.1.2 MFS Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.2 Indicators Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.3 Alerter Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3 Managing Alerters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.1 Basic Alerters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.1.1 Enable a Basic Alerter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.1.2 Modify Basic Alerter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.2 QoS Alerters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.2.1 Create QoS Alerter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.2.2 Delete QoS Alerter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.2.3 Enable/Disable Qos Alerter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.2.4 Modify Qos Alerter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.2.5 Import/Export QoS Alerters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.3 Purge Mechanism Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4 Alerter Alarm Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.1 Alarm Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.2 Current Alarm Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.3 Historical Alarm Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394.4 Post Processing Alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

5 Basic Alerters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415.1 Basic Alerters Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425.2 Rate of Successful Outgoing HO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425.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 . . . . . . . . . . . . . . . . . . . . . . . . . 435.7 Rate of Unsuccessful RTCH Seizures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445.8 SDCCH Congestion Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445.9 SDCCH Drop Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445.10 Call Drop Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445.11 A_Channel Average Occupancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

3BK 20963 AAAA PCZZA Ed.04 3 / 54

Contents

6 QoS Alerters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476.1 Syntax for QoS Alerters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

6.1.1 Operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 486.1.2 Threshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

6.2 Examples of QoS Alerters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 506.2.1 Alerter GPRS Sleeping Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 506.2.2 Alerter SDCCH Fail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 516.2.3 Alerter TCH Fail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 526.2.4 Alerter TCH Assignment Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

4 / 54 3BK 20963 AAAA PCZZA Ed.04

Figures

FiguresFigure 1: Alerters: Thresholding Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

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

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

3BK 20963 AAAA PCZZA Ed.04 5 / 54

Tables

TablesTable 1: Set QoS Alerter Predicates Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Table 2: B9 Basic Alerters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

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

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

6 / 54 3BK 20963 AAAA PCZZA Ed.04

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 04Overall document quality was improved following an editorial review.

In Edition 03The section Alerter Domain (Section 2.3) had been updated.

In Edition 02Released for B9 DR4.

In Edition 013BKA55CBR140280 - Alerter improvements. - New section added Alarmserver (Section 1.5.1). The Managing Alerters chapter have been splitted in

Basic Alerters (Section 3.1) and QoS Alerters (Section 3.2) . - New figures

inserted in Alarm Generation Mechanism (Section 1.5.2) and QoS Alerters(Section 3.2) sections.

3BKA55CBR143195 - New Alerters related characteristics in B9. - User Guidefor user-defined QoS Alerter creation in B9.

Audience This document is intended for Network administrators and Network optimizers.

Assumed Knowledge You must have a basic understanding of the following:

Alcatel operations and maintenance concepts

Telecommunications engineering

Alcatel Tool Chain.

3BK 20963 AAAA PCZZA Ed.04 7 / 54

Preface

8 / 54 3BK 20963 AAAA PCZZA Ed.04

1 Introduction

1 Introduction

This contains an introduction to alerters, including information about:

Alerter mechanism

Basic and Operator-defined alerters

System implementation and defense.

3BK 20963 AAAA PCZZA Ed.04 9 / 54

1 Introduction

1.1 OverviewBased on MPM counters/indicators, alerters are dedicated to speed up thereactivity of the operational team to detect and to solve any Quality of Service(QoS) degradation so as to restore telecom resources as fast as possible andto improve network availability seen by the end user. For information:

Only MPM manages alerters

MPM is accessible from the OMC-R

NPA does not manage alerters.

1.2 Alerter MechanismThe 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 arecalculated by MPM 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 most of Basic Alerters related parameters.

1.2.1 Alerter Attributes

Basic and operator-defined alerters have the following attributes:

Alerter name (name of the alerter)

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

Predicate (based on counters and indicators )

Alarm Severity

Validity condition (for algorithm processing) for Basic Alerters only

Stability (time of stability of alarm before commitment)

Preventive action (explanation text)

Activation: Enabling/Disabling (the operator can choose to enable or notthe alerter)

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

involved objects).

10 / 54 3BK 20963 AAAA PCZZA Ed.04

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)

1xReporting Period

2x 3x 4x 5x

Figure 1: Alerters: Thresholding Process

1.2.1.1 PredicateA predicate is the association of a formula (of counters or indicators) with athreshold (appearance or clearing of alarm). An alarm is generated whenthe detection predicate becomes true, and is cleared when the clearancepredicate is reached.

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.

1.2.1.2 ScopeNormally 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:

3BK 20963 AAAA PCZZA Ed.04 11 / 54

1 Introduction

Time scope: allows the operator to define a period of time during which thealarm can be generated

Object scope: defines the objects impacted by the alerter.

1.2.1.3 StabilityStability 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 thatthe 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 ValidityAnother 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.

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

12 / 54 3BK 20963 AAAA PCZZA Ed.04

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, BearerChannel, Sub-BSS (from B7 only)

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 theexceeded threshold; preventive action.

3BK 20963 AAAA PCZZA Ed.04 13 / 54

1 Introduction

1.3 Basic AlertersBasic 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 PMAdministration menu. The operator can enable/disable an alerter or canmodify its atributes.

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

14 / 54 3BK 20963 AAAA PCZZA Ed.04

1 Introduction

1.4 Operator-Defined AlertersQoS Alerter manage the same functionality as Basic Alerter, plus the possibilityto use more counters/indicators in predicate definition. QoS Alerter function isan optional feature of MPM, that allows the operator to add new alerters tothe 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 created afterwards,by the operator, using the dedicated window from PM Administration 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 thecustomer to define up to five predicates: up to 4 appearance predicates

for severity (critical and/or major and/or minor and/or warning) of thegenerated 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, themaximum permitted number of enabled alerters is set to 20. If this threshold

is met, new alerters can be created, but must be disabled.

3BK 20963 AAAA PCZZA Ed.04 15 / 54

1 Introduction

1.5 System Defense

1.5.1 Alarm server

The alarm server use as input alerter definitions, loadmaps and the lif files.

Alerter definition: for each alerter definition is saved 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 evaluatethe formulas expressions and to convert them to a formula of counters

according to the PM file version: B8 or B9 - the lif files.

Lif 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 then deleted.

Configuration files QoS Alerters HMI Basic Alerters HMI

Alarm Server

QoS Alerters definitions

Basic Alerters definitions

Alarms

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: B8 and B9.

The current alarm list is also stored in memory, but it is saved in a file on diskevery time its content is modified. In the initialisation phase the alarm list isloaded 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.

16 / 54 3BK 20963 AAAA PCZZA Ed.04

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 in theactive alarm file. If it is, AS deletes the alarm from its active alarm file andsends the clearance to the OMC-R. If it is not, nothing is done.

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

3BK 20963 AAAA PCZZA Ed.04 17 / 54

1 Introduction

1.5.3 Purge Mechanism

The object which is originator of an alarm is the only one allowed to cancel thisalarm regardless its gravity, if conditions for "CLEAR" are met.

But, in some circumstances, as originator of an alarm may dissapear dueto some actions (move, delete,...) performed by the operator, the alarmremains hanged as system cannot receive anymore a "CLEAR" commandfrom originator.

In this circumstances, the purge mechanism is designed to overcome thisdrawback:

at specified moments, the system generate a purge mechanism which isable to delete alarms older than a specified period

operator can set when purge mechanism is triggered as well as maximum

allowed "life time" of an alarm.

The purge mechanism is included in the alarm server, the parameters that ituses may be configured through a configuration file.

18 / 54 3BK 20963 AAAA PCZZA Ed.04

1 Introduction

1.6 Differences Between Alerters in B8 and B9In this chapter are described on short the main fields impacted by B9:

Purge Mechanism

Basic Alerters

QoS Alerters

Other Improvements.

1.6.1 Purge Mechanism

In B9 purge mechanism parameters are operator configurable, opposite to

B8 where these settings cannot be configured by operator.

In B9, the scope of purge mechanism is significantly reduced. Current

generated alarms list are saved on disk every time the application is

stopped, and loaded when it starts. In this way the hanging alarms notappear anymore (as happens in B8 when loaders are restarted).

1.6.2 Basic Alerters

Basic Alerters list :

Compared to B8 Release, there is only one minor (spelling) differenceregarding Basic Alerter Definition: Alerter TCTRTCE /RTCH_Erlang_per_TCH,(AlarmId 200004) in B8, replaced by Alerter TCTRR /RTCH_Erlang_per_TCH,(AlarmId 200004) in B9.

Basic Alerters Improvements :

New configuration windows offer more friendly ways to modify system

defined Basic Alerters

Time and Object Scope can be set on Basic Alerters (no more limitedto QoS Alerters as in B8)

Predicate tresholds can be set for both "RAISE" and "CLEAR" conditions aswell as Stabilities conditions. In B8 these settings were subject to "RAISE"

condition only.

1.6.3 QoS Alerters

New configuration windows offering more friendly ways to create new QoSAlerters or to modify already defined QoS Alerters

More suggestive table labels in B9 face to B8

In B9, in HMI is provided a list with available counters/indicators from theselected table. So, once the operator select a table, the system provides

operator all counters and indicators to be used in defining the predicates

Stability condition can be set simultaneously for both "RAISE" and "CLEAR"conditions.

3BK 20963 AAAA PCZZA Ed.04 19 / 54

1 Introduction

More robust import/ export operations. Also, operator may select particularalerters to be imported/ exported

There is a check of the predicate formulae for consistency in B9

A selection list with supported operators are provided in B9.

1.6.4 Other Improvements

In B9, the stability may be computed for a period of time from the current

day and the previous day as well. In B8 implementation, the stability can becomputed using data from the current day only.

Dedicated window for defining time and object scope.

20 / 54 3BK 20963 AAAA PCZZA Ed.04

2 Counters and Indicators Used by Alerters


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

3BK 20963 AAAA PCZZA Ed.04 21 / 54


2.1 Counters OverviewA 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.

MPM/NPA retrieve all the GSM counters from the BSS and all the GPRScounters from the MFS. The LCS counters are retrieved from both the BSSand the MFS.

For more information about counters, refer to the:

BSS Surveillance Handbook

Operation Maintenance Principles .

2.1.1 BSS Counters

At 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 BSSmanaged 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. Thegranularity period can be as short as 15 minutes.

22 / 54 3BK 20963 AAAA PCZZA Ed.04


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

100: BSC cumulated measurements

per BSC

per cell

per cell

per BSC

110: Overview per TRX, cell, BSC or N7

Standard Measurementtypes

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

3BK 20963 AAAA PCZZA Ed.04 23 / 54


1: Traffic per cell

2: Resource availability per cell

3: Resource usage on CCCH per TRX_TS of the cell

4: Resource usage on SDCCH per TRX_TS of the cell

5: Resource usage on TCH

6: TCH HO

per TRX_TS of the cell

per cell

Observation Meas:

10: SDCCH

11: TCH measurements

12: Internal HO

13: Incoming external HO

14: Outgoing external HO

15: TCH

per cell

Detailed measurementtypes

26: TCH HO for a variable target cell

27: GSM TCH HO for a fixed target cell

per adjacency: fixed servingcell-variable target cell

per adjacency: fixed variableserving cell-fixed target cell

Note: MPM retrieves and stores all counters types, except type 31 (RMS).

2.1.2 MFS Counters

MPM/NPA retrieves and stores all the MFS counters. The MFS counters areall standard measurement types.

For MFS, the granularity period is fixed to 1 hour.

24 / 54 3BK 20963 AAAA PCZZA Ed.04


2.2 Indicators OverviewIndicators 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 ofthe BSC or MFS

MPM/NPA provides indicators from GSM, GPRS and LCS counters andfrom LASER events.

2.3 Alerter DomainThe domain of an alerter is given by the combination between a measurementtype and an object class. Inside one domain both counters and indicators maybe 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 interfacemeasurements

ACH

TYPE_19: SMS measurements CELL

TYPE_25: SCCP measurements SIGNALING LINK

TYPE_28: SDCCH Handovermeasurements

CELL

TYPE_29: Directed retrymeasurements

CELL

3BK 20963 AAAA PCZZA Ed.04 25 / 54


TYPE_30: SMS Cell BroadcastMeasurements

BSC

TYPE_32: Change of frequency bandmeasurements

CELL

TYPE_110: Overview measurements TRX

TYPE_110: Overview measurements CELL

TYPE_110: Overview measurements BSC

TYPE_110: Overview measurements SIGNALLING LINK

GPRS Mesurements CELL

GPRS Mesurements BSC

GPRS Mesurements LAPD LINK

GPRS Mesurements BEARER CHANNEL

GPRS Mesurements PVC

GPRS Mesurements BTS

26 / 54 3BK 20963 AAAA PCZZA Ed.04

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 MPM viewerand administration.For more information regarding Administration, refer to the A1353-RA NetworkAdministration Handbook , Administration Tasks for MPM.For information regarding counters and indicators, refer to PM Counters andNPA Indicators .

3BK 20963 AAAA PCZZA Ed.04 27 / 54

3 Managing Alerters

3.1 Basic AlertersThe 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 MPM Administration menu, select Basic Alerter->Start 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.

28 / 54 3BK 20963 AAAA PCZZA Ed.04

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 AlertersThe 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 availablecounter/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 MPM Administration menu allows the operator to define theattributes of the operator-defined alerter.

To create a QoS alerter:

1. In the MPM Administration menu, select

QoS Alerter -> Start QoS Alerter... .

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

2. From QoS Alerters Window define new Alerter.

File->NewIn 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 20963 AAAA PCZZA Ed.04 29 / 54

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.

30 / 54 3BK 20963 AAAA PCZZA Ed.04

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

3. 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.

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

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

3.2.2 Delete QoS Alerter

To delete a QoS alerter:

1. In the MPM Administration menu, select QoS Alerter -> Start 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.

3BK 20963 AAAA PCZZA Ed.04 31 / 54

3 Managing Alerters

3.2.5 Import/Export QoS Alerters

In B9, is possible for an operator to export/import specific alerters. So, usingrelated menus, operator can select alerters and afterwards export them to achosen directory. Reverse, he can import selected alerters to MPM.

Exporting a QoS Alerter:

1. On QoS Alerter window, select Tools->Export alerters

2. In the pop-up window, on left-side square, select alerter(s) to be exported.After selection, click on right-headed arrow. Exported alerters are deposedon the right-sided square.

3. On lower side of the window, write down the path to file. You can use[ Browse ] button as well. For example the directory used to store exportedAlerters may be : /tmp/*.* )

4. Click on[ OK ] .

There is no specific procedure for transfering alerters files between 2 differentmachine (Inter OMC-R transfer). You can use any available procedure: byFTP transfer, by tape, etc.You can store on one exported file one or more alerters.

Importing a QoS Alerter:

1. On QoS Alerter window, select Tools->Import alerters.

2. Click on [ Browse ] . Select the file which you want to import.

3. In the pop-up window, on left-side square, the alerter(s) included inselected file shall appear. Select alerter(s) to be imported. After selection,click on right-headed arrow. Alerters to be imported are deposed on theright-side square.

4. Click on[ OK ] .

32 / 54 3BK 20963 AAAA PCZZA Ed.04

3 Managing Alerters

3.3 Purge Mechanism ConfigurationIn B9 BSS, operator may define Purge Mechanism parameters. Operator canset when purge mechanism is triggered as well as maximum allowed "lifetime" of an alarm.

1. Open a terminal. If not so, change your user as metrica and enter yourpassword:

# su - metricaPassword:

2. Enter path to the directory storing the required file (alarm.cfg)hostname:metrica cd/alcatel/npa/mpm/alarm/etc

3. Using vi editor, open the file alarm.cfg

4. Now you can modify purge related parameters: PURGE_AGE andPURGE_PERIOD MAX_ENABLED_ALERTER

PURGE_AGE and PURGE_PERIOD are expressed in seconds.

These parameters are defining Max lifetime of an alarm (PURGE_AGE) andperiod of time between succesive Purge process triggering(PURGE_PERIOD).

To avoid processor overcharging, it is recommended to limit the value ofMAX_ENABLED_ALERTER to 20.

Parameter MAX_ENABLED_ALERTER is limiting the number of simultaneuslyactive alerters.It is possible to have more than 20 alerters.

3BK 20963 AAAA PCZZA Ed.04 33 / 54

3 Managing Alerters

34 / 54 3BK 20963 AAAA PCZZA Ed.04

4 Alerter Alarm Handling


This describes how system handles alarms generated by Alerters.

3BK 20963 AAAA PCZZA Ed.04 35 / 54


4.1 Alarm ManagementThe following figure illustrates the Current Alarm List, the Historical Alarm listand all filters available in alarm management.

Real−Time Management Static Analysis

AS Operator AS Operator

NETWORKRESOURCES

CurrentAlarms

ArchivedAlarms

EXTERNALAPPLICATION

Alarm Flow

Alarm OrderingAlarm Filtering

Alarm Retrieving

SublistOrdering

and Filtering

Auto−beeping

Navigation

Navigation

ARS

Auto−acknowledgement Filter

Autopurge Filter

ArchivingFilter

OverFlowPurge

Navigation

SublistOrdering and Filtering

Auto−trouble Ticket Creation

Defining an alerter involves choosing proper threshold values and formulae.But these values can be different from network to network. So it is quiteimportant to set the proper threshold to avoid getting a very high flow of alarmsat the OMC-R.

In case of a very high alarm flow due to a threshold value not properly set,the user can use the "Autopurge" option in Alarm Surveillance. This actionputs all selected alarms in the Historical Alarm List to avoid getting too manyalarms to be processed at the OMC-R.

MPM Alerters have to be activated with threshold values allowing the detectionof BSS problems that have to be handled quickly by without generating a hugealarm flow. Alcatel recommends choosing sufficiently high values and thenlowering them as hardware and software problems are cleaned.

36 / 54 3BK 20963 AAAA PCZZA Ed.04


4.2 Current Alarm DisplayThe current alarm list maintained by the alarm server, keeps alarms that weregenerated or alarms that were not generated yet from stability reasons. Thealarm server has to keep time information to compute the stability for a periodof time from the current day and the previous day also.

The follow-up of alarms due to Basic Alerters and QoS Alerters is done usingthe Current Alarm List . It is launched through the main A1353-RA window.It displays all active alarms in the whole network.

In this general window, alarms can be counted by user defined sub-list, whichcan be helpful for any investigation process. So to follow only alarms linked toalerters, a specific sub-list can be defined.

Once defined, the filter associated with the following alerters can then beimported in the historical alarm list since it behaves in the same manner asthe current alarm list.

The filter is based on the following attribute set:

Alarm type: Quality of Service

Probable Cause: Threshold crossed.

Another criterion for filtering is the alarm Severity, but keep in mind that theseverity may be different from one alerter to another one. Also, the user mayselect some other alarm fields to build up its sub-list. This selection is doneduring filter definition in the display section. To ease processing of Alerters,additional explanatory text fields for both types of alerters (QoS and Basic) haveto be filled in since they contain all needed information to identify the Alerters.

The figure below presents the window used to define the proper filter associatedwith the QoS alerter sub-list. (Severity: Warning; Alarm type: Quality OfService; Probable Cause: X.721- threshold Crossed).

3BK 20963 AAAA PCZZA Ed.04 37 / 54


Figure 2: Defining filters for Alerters

38 / 54 3BK 20963 AAAA PCZZA Ed.04


4.3 Historical Alarm DisplayOnce an alarm is cleared and acknowledged by the operator, this alarm ispurged and can be saved in the Historical Alarm List.

To display this list, the user launches the AS Historical Alarm applicationfrom the main A1353-RA window. The Historical Alarm Display displays allacknowledged and cleared alarms according to user-defined criteria (begindate and time, end date and time, sub-network...).

In the general window, alarms can be counted by a user-defined sub-list, whichcan be helpful for any investigation process. To follow only alarms linked toalerters, a specific sub-list has to be defined.

Display Historical Alarm

List

To display the Historical Alarm list at the OMC-R:

1. Start AS from the OMC-R desktop by clicking on its icon.

2. Select Archive : Retrieve from Public Archive... and select the OMC-R.

3. In the AS Historical USM window, select the following options:

Event Date Time Ranges: to define the observation period.

Alarm Type : Quality Of Service.

Probable Cause : X721 - thresholdCross.

4. Click on [ Apply ] .

4.4 Post Processing AlarmsTo produce statistics on QoS Alerters and to perform any follow up, the operatorcan use the A9157 LASER tool. Moreover, LASER eases investigation onalerter occurrences since it collects different type of data from the OMC-R (i.e.,alarms, events, operator commands...).

LASER is the post-processing application of the OMC-R.

From each OMC-R, BSS/MFS alarms, OMC-R operator commands, resourcestate changes and BSS/MFS topology are retrieved daily to:

Compute system quality indicators, based on statistics and completetelecom unavailability

Generate events which correspond to synthesis of alarms from customizable

detection rules.

Using Laser, the user can also perform any BSS equipment stabilityfollow-up that leads to:

Better correlation between QoS indicators values and the events(actions/alarms) handled on the network

Evaluation of the BSS equipment efficiency

Better comprehension of events, alarms, operator commands and

network availability indicators

Gaining a real evaluation of transmission node efficiency and reliability

Analyze and report detected incidents, and elaborate, with the customer,

plans for improvement

Computing telecom availability for a part of, or the whole network.

3BK 20963 AAAA PCZZA Ed.04 39 / 54


The following figure shows the position of LASER in the complete Alcatel toolchain solution at the OMC-R site.

Figure 3: Tool Chain

The advantages of using LASER are:

LASER provides another view on network efficiency

The presence of interfaces between LASER and existing peri-OMC-R toolsenhances network analysis from a performance and stability point of view

Some feature of LASER can be used to produce statistics and to deliver

different kind of reports on alerters.

For more information about A9175 LASER, refer to the A957 Laser User Guide .

40 / 54 3BK 20963 AAAA PCZZA Ed.04

5 Basic Alerters

5 Basic Alerters

This section describes the Basic Alerters defined in Alcatel BSS release B9

3BK 20963 AAAA PCZZA Ed.04 41 / 54

5 Basic Alerters

5.1 Basic Alerters OverviewThe 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 BSS ReleaseB9.

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 NPA_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_NPA_rate RTCH_assign_unsuccess_NPA_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

Table 2: B9 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.

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 %

42 / 54 3BK 20963 AAAA PCZZA Ed.04

5 Basic Alerters

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 NPA_RTCH_available_rate/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 %

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 %

3BK 20963 AAAA PCZZA Ed.04 43 / 54

5 Basic Alerters

5.7 Rate of Unsuccessful RTCH Seizures

Indicator Name/Ref name RTCH_assign_unsuccess_NPA_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 %

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 nocall (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 %

44 / 54 3BK 20963 AAAA PCZZA Ed.04

5 Basic Alerters

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

3BK 20963 AAAA PCZZA Ed.04 45 / 54

5 Basic Alerters

46 / 54 3BK 20963 AAAA PCZZA Ed.04

6 QoS Alerters

6 QoS Alerters

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

3BK 20963 AAAA PCZZA Ed.04 47 / 54

6 QoS Alerters

6.1 Syntax for QoS AlertersThe 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 returnszero.

(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

48 / 54 3BK 20963 AAAA PCZZA Ed.04

6 QoS Alerters

6.1.2 Threshold

The following table provides an explanation of the different thresholds presentin the QoS Alerter definition.

ThresholdName

Description Example

Simplethreshold

A column is compared directly against a fixed value.This is the simplest and usually the least useful typeof predicate as it is normally not possible to define asensible threshold value for raw data for all elements.

RFLOSSES > 100

Complexthreshold

An expression is compared to a constant value. Theexpression normally calculates a normalized valuefrom the input data, that is, something that can becompared across multiple elements. For example: %congestion, % call dropped, % RF losses per Erlangcarried traffic, % available channels.

AVAILCH/DEFINEDCH<0.5

Arbitraryconditions

Using expressions you can define arbitrary conditionscomparing columns with other columns or withexpressions.

AVAILCH=DEFINEDCHBLOCKS/ATTEMPS<0.01TRAFFIC>1

Table 4: Thresholds Used in QoS Alerters

3BK 20963 AAAA PCZZA Ed.04 49 / 54

6 QoS Alerters

6.2 Examples of QoS Alerters

6.2.1 Alerter GPRS Sleeping Cells

50 / 54 3BK 20963 AAAA PCZZA Ed.04

6 QoS Alerters

6.2.2 Alerter SDCCH Fail

3BK 20963 AAAA PCZZA Ed.04 51 / 54

6 QoS Alerters

6.2.3 Alerter TCH Fail

52 / 54 3BK 20963 AAAA PCZZA Ed.04

6 QoS Alerters

6.2.4 Alerter TCH Assignment Failure

3BK 20963 AAAA PCZZA Ed.04 53 / 54

6 QoS Alerters

BLANK PAGE BREAK

54 / 54 3BK 20963 AAAA PCZZA Ed.04

Quality of Service Alerters User Guide ed04.pdf

Documents

Transcript of Quality of Service Alerters User Guide ed04.pdf