Alcatel BSS

Quality of Service Alerters User Guide

OMC Document User Guide Release B9

3BK 20963 AAAA PCZZA Ed.03

BLANK PAGE BREAK

Status Short title

RELEASED Alerters UG
All rights reserved. Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Alcatel/Evolium.

2 / 54

3BK 20963 AAAA PCZZA Ed.03

Contents

Contents
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Alerter Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.1 Alerter Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.2 Alarm Field description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 Basic Alerters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4 Operator-Defined Alerters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.5 System Defense . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.5.1 Alarm server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.5.2 Alarm Generation Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.5.3 Purge Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.6 Differences Between Alerters in B8 and B9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.6.1 Purge Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.6.2 Basic Alerters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.6.3 QoS Alerters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.6.4 Other Improvements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Counters and Indicators Used by Alerters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1 Counters Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.1 BSS Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.2 MFS Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Indicators Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3 Alerter Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Managing Alerters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1 Basic Alerters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.1 Enable a Basic Alerter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.2 Modify Basic Alerter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 QoS Alerters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.1 Create QoS Alerter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.2 Delete QoS Alerter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.3 Enable/Disable Qos Alerter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.4 Modify Qos Alerter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.5 Import/Export QoS Alerters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3 Purge Mechanism Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Alerter Alarm Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1 Alarm Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Current Alarm Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3 Historical Alarm Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4 Post Processing Alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Basic Alerters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1 Basic Alerters Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2 Rate of Successful Outgoing HO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3 Rate of Successful Incoming HO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.4 Average Rate of Available Static and Dynamic Radio Time Slots for Traffic Usage . . . . . . . . 5.5 Occupation Rate per Radio Traffic Channel (Half Rate and Full Rate) . . . . . . . . . . . . . . . . . . . 5.6 Rate of Failures Due to Congestion on Air Interface Channels . . . . . . . . . . . . . . . . . . . . . . . . . 5.7 Rate of Unsuccessful RTCH Seizures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.8 SDCCH Congestion Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.9 SDCCH Drop Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.10 Call Drop Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.11 A_Channel Average Occupancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 9 10 10 10 13 14 15 16 16 17 18 19 19 19 19 20 21 22 22 24 25 25 27 28 28 28 29 29 31 31 31 32 33 35 36 37 39 39 41 42 42 43 43 43 43 44 44 44 44 45

3BK 20963 AAAA PCZZA Ed.03

3 / 54

Contents

QoS Alerters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.1 Syntax for QoS Alerters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.1.1 Operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.1.2 Threshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2 Examples of QoS Alerters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2.1 Alerter GPRS Sleeping Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2.2 Alerter SDCCH Fail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2.3 Alerter TCH Fail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2.4 Alerter TCH Assignment Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

47 48 48 49 50 50 51 52 53

4 / 54

3BK 20963 AAAA PCZZA Ed.03

Figures

Figures
Figure 1: Alerters: Thresholding Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Figure 2: Defining filters for Alerters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 Figure 3: Tool Chain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

3BK 20963 AAAA PCZZA Ed.03

5 / 54

Tables

Tables
Table 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.03

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.

Whats New

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

In Edition 02
Released for B9 DR4.

In Edition 01
3BKA55CBR140280 - Alerter improvements. - New section added Alarm server (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 Guide for user-defined QoS Alerter creation in B9.

Audience Assumed Knowledge

This document is intended for Network administrators and Network optimizers. You must have a basic understanding of the following: Alcatel operations and maintenance concepts Telecommunications engineering Alcatel Tool Chain.

3BK 20963 AAAA PCZZA Ed.03

7 / 54

Preface

8 / 54

3BK 20963 AAAA PCZZA Ed.03

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

9 / 54

1 Introduction

1.1 Overview
Based on MPM counters/indicators, alerters are dedicated to speed up the reactivity 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 and to 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 Mechanism

The aim of the alerter is to detect and generate alarms towards the OMC-R based 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 reporting period, the loader processes algorithms on these alerters, using thresholds and validity 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 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 not the alerter) Scope (defines the actions range of the alerter on both time scale and involved objects).

10 / 54

3BK 20963 AAAA PCZZA Ed.03

1 Introduction

The following figure illustrates the thresholding mechanism with two hysteresis used for the management of the alarms related to the indicators/alerters. This figure does not take into account the stability associated with the alerter. It only deals with the process of thresholding.

Indicator Value

H2
Alarm (threshold level = H2, severity = major) Alarm (threshold level = L2, severity = cleared)

H1

Starting point

Alarm (threshold level = H1, severity = cleared)

Alarm (threshold level = L1, severity = major)

L2

L1

1x Reporting Period
Figure 1: Alerters: Thresholding Process

2x

3x

4x

5x

1.2.1.1 Predicate
A predicate is the association of a formula (of counters or indicators) with a threshold (appearance or clearing of alarm). An alarm is generated when the detection predicate becomes true, and is cleared when the clearance predicate is reached. Example : a formula Counter1 + Counter2. Two thresholds are defined: 80% and 90%. The predicate for alarm detection is Counter1 + Counter2 > 0.90. When it is true, an alarm detection condition is 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 Scope
Normally an alarm is defined over all data that is loaded into the specified table in the performance database. However, there are circumstances when the user may need to limit the scope of an alarm to a specific network region or a specific time of the day. This can be accomplished by defining an expression for the 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.03

11 / 54

1 Introduction

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 of the predicate being true for an alarm to be generated or cancelled. By default an alarm is generated if the predicate evaluates true for one measurement interval. By setting the Stability field, the user can require that the predicate must be true for N minutes before an alarm is to be generated, where N is 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 mechanism evaluates the defined predicates (evaluation of the formula and the thresholds). If the predicate is true (the alarm condition is reached), the alerter mechanism checks 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. the alerter 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 the clearance 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 is generated when this condition is fullfilled only. This attribute reffers only Basic Alerters. Validity is system defined, the operator can modify the threshold. In most of the cases, Validity condition is satisfied when a threshold is reached by a number of events. For example, the rate of SDCCH_DROP_RATE may generate an alarm only if the number of SDCCH seized is reaching a threshold.

12 / 54

3BK 20963 AAAA PCZZA Ed.03

1 Introduction

1.2.2 Alarm Field description

Alarms are mainly made up of the following fields (according to GSM recommendation 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 (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 the exceeded threshold; preventive action.

3BK 20963 AAAA PCZZA Ed.03

13 / 54

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 are associated to these alerters. The basic alerters attributes are displayed to the operator using the PM Administration menu. The operator can enable/disable an alerter or can modify its atributes. The alarm type, probable cause and alarm severity of the alarm generated by basic 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.

14 / 54

3BK 20963 AAAA PCZZA Ed.03

1 Introduction

1.4 Operator-Defined Alerters

QoS Alerter manage the same functionality as Basic Alerter, plus the possibility to use more counters/indicators in predicate definition. QoS Alerter function is an optional feature of MPM, that allows the operator to add new alerters to the set of Basic Alerters. From now on in this document, operator-defined alerters are also referred to 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 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 threshold is met, new alerters can be created, but must be disabled.

3BK 20963 AAAA PCZZA Ed.03

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 evaluate the 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

QoS Alerters definitions Alarm Server Basic Alerters definitions

Alarms

In the initialisation phase, the alerters definitions are loaded and stored in memory. Based on the counters and indicators formulas from the loadmaps files, the predicates expressions are parsed and converted, resulting one formula 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 disk every time its content is modified. In the initialisation phase the alarm list is loaded from the file in memory. In this way when alarm server is stopped, the alarm list is not lost, being loaded the next time the application starts.

16 / 54

3BK 20963 AAAA PCZZA Ed.03

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 processes algorithms defined in the indicator database using thresholds and validity conditions 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, validity and the predicates in theirs severity order (first is the highest - critical, the last - warning). If one of the predicates conditions is met (together with the stability), the rest of them are ignored and an alarm is generated with the corresponding 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 it to the concerned OMC-R application (BSS-IM or MFS-IM). When an alarm is detected, AS checks if this alarm is already in the active alarm file. If it is, AS updates the generation time of this alarm and nothing is sent to the OMC-R. If it is not, AS adds the new alarm to its active alarm file and 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 the active alarm file. If it is, AS deletes the alarm from 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:

3BK 20963 AAAA PCZZA Ed.03

17 / 54

1 Introduction

1.5.3 Purge Mechanism

The object which is originator of an alarm is the only one allowed to cancel this alarm regardless its gravity, if conditions for "CLEAR" are met. But, in some circumstances, as originator of an alarm may dissapear due to some actions (move, delete,...) performed by the operator, the alarm remains hanged as system cannot receive anymore a "CLEAR" command from originator. In this circumstances, the purge mechanism is designed to overcome this drawback: at specified moments, the system generate a purge mechanism which is able 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 it uses may be configured through a configuration file.

18 / 54

3BK 20963 AAAA PCZZA Ed.03

1 Introduction

1.6 Differences Between Alerters in B8 and B9

In 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 not appear 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) difference regarding 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 limited to QoS Alerters as in B8) Predicate tresholds can be set for both "RAISE" and "CLEAR" conditions as well 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 QoS Alerters 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 the selected 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.03

19 / 54

1 Introduction

More robust import/ export operations. Also, operator may select particular alerters 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 be computed using data from the current day only. Dedicated window for defining time and object scope.

20 / 54

3BK 20963 AAAA PCZZA Ed.03

2 Counters and Indicators Used by Alerters

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

21 / 54

2 Counters and Indicators Used by Alerters

2.1 Counters Overview

A counter is a measurement dedicated to an observed object and a granularity period. 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 GPRS counters from the MFS. The LCS counters are retrieved from both the BSS and 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 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.

22 / 54

3BK 20963 AAAA PCZZA Ed.03

2 Counters and Indicators Used by Alerters

Measurement Type Standard Measurement 7: LAPD types 8: X.25 9: N7 18: A Interface 19: SMS PP 25: SCCP 28: SDCCH HO 29: Directed Retry 30: SMS CB 31: Radio Measurements Statistics 32: Change of frequency band measurements 33: Electro-Magnetic Em. Counters 34: Voice Group Call services 100: BSC cumulated measurements 110: Overview 180: GSM Traffic Flow

Object Observed per LAPD link of the BSC per X.25 link of the BSC per N7 of the BSC per BSC per cell per N7 of the BSC per cell per cell per BSC per cell per BSC

per cell per cell per BSC per TRX, cell, BSC or N7 per adjacency: variable serving cell-variable target cell

3BK 20963 AAAA PCZZA Ed.03

23 / 54

2 Counters and Indicators Used by Alerters

Detailed measurement types

1: Traffic 2: Resource availability 3: Resource usage on CCCH 4: Resource usage on SDCCH 5: Resource usage on TCH 6: TCH HO Observation Meas: 10: SDCCH 11: TCH measurements 12: Internal HO 13: Incoming external HO 14: Outgoing external HO 15: TCH 26: TCH HO for a variable target cell

per cell per cell per TRX_TS of the cell per TRX_TS of the cell per TRX_TS of the cell per cell per cell

per adjacency: fixed serving cell-variable target cell per adjacency: fixed variable serving cell-fixed target cell

27: GSM TCH HO for a 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 are all standard measurement types. For MFS, the granularity period is fixed to 1 hour.

24 / 54

3BK 20963 AAAA PCZZA Ed.03

2 Counters and Indicators Used by Alerters

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 MPM/NPA provides indicators from GSM, GPRS and LCS counters and from LASER events.

2.3 Alerter Domain

The domain of an alerter is given by the combination between a measurement type and an object class. Inside one domain both counters and indicators may be used. The available domains are listed in the table below: Measurements TYPE_1: Traffic Measurement TYPE_1: Traffic Measurement TYPE_2: Resource availability measurements TYPE_6: TCH Handover measurements TYPE_7: LapD measurements TYPE_8: X.25 measurements TYPE_9: N7 measurements TYPE_9: N7 measurements TYPE_18: A interface measurements TYPE_18: A channel interface measurements TYPE_19: SMS measurements TYPE_25: SCCP measurements TYPE_28: SDCCH Handover measurements TYPE_29: Directed retry measurements Object Class CELL TRX CELL

CELL

LAPD X.25 SIGNALING LINK LINK SET BSC ACH

CELL SIGNALING LINK CELL

CELL

3BK 20963 AAAA PCZZA Ed.03

25 / 54

2 Counters and Indicators Used by Alerters

TYPE_30: SMS Cell Broadcast Measurements TYPE_32: Change of frequency band measurements TYPE_110: Overview measurements TYPE_110: Overview measurements TYPE_110: Overview measurements TYPE_110: Overview measurements GPRS Mesurements GPRS Mesurements GPRS Mesurements GPRS Mesurements GPRS Mesurements

BSC

CELL

TRX CELL BSC SIGNALLING LINK CELL BSC LAPD LINK BEARER CHANNEL PVC

26 / 54

3BK 20963 AAAA PCZZA Ed.03

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

3BK 20963 AAAA PCZZA Ed.03

27 / 54

3 Managing Alerters

3.1 Basic Alerters

The Basic Alerter Configuration application provides a common graphical interface, that allows to user to edit the basic alerters. As inputs, it uses the basic alerter definition files. The main window contains a list with the available Basic Alerters, displaying the full 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 or to perform a modification on the selected alerters 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.03

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, that permits 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, the configuration files and the loadmap files (used to display the available counter/indicators).

3.2.1 Create QoS Alerter

This procedure allows the operator to add new alerters to the set of Basic Alerters. The OMC-R alerter can have up to four predicates, one for each severity. It can also have one predicate for clearance. A window from the MPM Administration menu allows the operator to define the attributes 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 the Message Window click on [ OK ] 2. From QoS Alerters Window define new Alerter. File->New In the new window fill in the required fields.The parameters mandatory to be filled 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.03

29 / 54

3 Managing Alerters

Parameters QoS Alerter Scope

Description Defines the Alerters scope. It can be either a particular element e.g. CELL_2-1 or/and a Alerter work period. Regarding period, the stepsize is 15 min. The alarm is perceived as critical. The alarm is perceived as major. The alarm is perceived as minor. The alarm is perceived as a warning. The alarm is cleared (removed) after disappearance.

Critical Predicate Major Predicate Minor Predicate Warning Predicate Clearance Predicate

30 / 54

3BK 20963 AAAA PCZZA Ed.03

3 Managing Alerters

Parameters Stability

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

Alerter Text

Table 1: Set QoS Alerter Predicates Description 3. For defining a Predicates , operator needs to enter Edit Predicate window by clicking on right most button of related predicate. From this window, can be 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 to Syntax 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 the window 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 alerter or to create a copy of the first one. By clicking on the attached buttons of Scope and Predicates entry , dedicated windows are opened for advanced editing.

3BK 20963 AAAA PCZZA Ed.03

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, using related menus, operator can select alerters and afterwards export them to a chosen 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 deposed on 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 exported Alerters may be : /tmp/*.* ) 4. Click on[ OK ] . There is no specific procedure for transfering alerters files between 2 different machine (Inter OMC-R transfer). You can use any available procedure: by FTP 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 in selected file shall appear. Select alerter(s) to be imported. After selection, click on right-headed arrow. Alerters to be imported are deposed on the right-side square. 4. Click on[ OK ] .

32 / 54

3BK 20963 AAAA PCZZA Ed.03

3 Managing Alerters

3.3 Purge Mechanism Configuration

In B9 BSS, operator may define Purge Mechanism parameters. Operator can set when purge mechanism is triggered as well as maximum allowed "life time" of an alarm. 1. Open a terminal. If not so, change your user as metrica and enter your password: # su - metrica Password: 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 and PURGE_PERIOD MAX_ENABLED_ALERTER PURGE_AGE and PURGE_PERIOD are expressed in seconds. These parameters are defining Max lifetime of an alarm (PURGE_AGE) and period of time between succesive Purge process triggering(PURGE_PERIOD). To avoid processor overcharging, it is recommended to limit the value of MAX_ENABLED_ALERTER to 20. Parameter MAX_ENABLED_ALERTER is limiting the number of simultaneusly active alerters. It is possible to have more than 20 alerters.

3BK 20963 AAAA PCZZA Ed.03

33 / 54

3 Managing Alerters

34 / 54

3BK 20963 AAAA PCZZA Ed.03

4 Alerter Alarm Handling

4 Alerter Alarm Handling

This describes how system handles alarms generated by Alerters.

3BK 20963 AAAA PCZZA Ed.03

35 / 54

4 Alerter Alarm Handling

4.1 Alarm Management

The following figure illustrates the Current Alarm List, the Historical Alarm list and all filters available in alarm management.

RealTime Management
AS Operator
Navigation

Navigation

Static Analysis
AS Operator

EXTERNAL APPLICATION

Navigation

Sublist Ordering and Filtering

Sublist Ordering and Filtering

Autobeeping Autotrouble Ticket Creation Archiving Filter Alarm Retrieving

ARS

Current Alarms

Over Flow Purge

Archived Alarms

Autoacknowledgement Filter

Autopurge Filter

Alarm Flow

NETWORK RESOURCES

Alarm Ordering Alarm Filtering

Defining an alerter involves choosing proper threshold values and formulae. But these values can be different from network to network. So it is quite important to set the proper threshold to avoid getting a very high flow of alarms at 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 action puts all selected alarms in the Historical Alarm List to avoid getting too many alarms to be processed at the OMC-R. MPM Alerters have to be activated with threshold values allowing the detection of BSS problems that have to be handled quickly by without generating a huge alarm flow. Alcatel recommends choosing sufficiently high values and then lowering them as hardware and software problems are cleaned.

36 / 54

3BK 20963 AAAA PCZZA Ed.03

4 Alerter Alarm Handling

4.2 Current Alarm Display

The current alarm list maintained by the alarm server, keeps alarms that were generated or alarms that were not generated yet from stability reasons. The alarm server has to keep time information to compute the stability for a period of time from the current day and the previous day also. The follow-up of alarms due to Basic Alerters and QoS Alerters is done using the 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, which can be helpful for any investigation process. So to follow only alarms linked to alerters, a specific sub-list can be defined.

Once defined, the filter associated with the following alerters can then be imported in the historical alarm list since it behaves in the same manner as the 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 the severity may be different from one alerter to another one. Also, the user may select some other alarm fields to build up its sub-list. This selection is done during filter definition in the display section. To ease processing of Alerters, additional explanatory text fields for both types of alerters (QoS and Basic) have to 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 associated with the QoS alerter sub-list. (Severity: Warning; Alarm type: Quality Of Service; Probable Cause: X.721- threshold Crossed).

3BK 20963 AAAA PCZZA Ed.03

37 / 54

4 Alerter Alarm Handling

Figure 2: Defining filters for Alerters

38 / 54

3BK 20963 AAAA PCZZA Ed.03

4 Alerter Alarm Handling

4.3 Historical Alarm Display

Once an alarm is cleared and acknowledged by the operator, this alarm is purged and can be saved in the Historical Alarm List. To display this list, the user launches the AS Historical Alarm application from the main A1353-RA window. The Historical Alarm Display displays all acknowledged and cleared alarms according to user-defined criteria (begin date and time, end date and time, sub-network...). In the general window, alarms can be counted by a user-defined sub-list, which can be helpful for any investigation process. To follow only alarms linked to alerters, 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 Alarms

To produce statistics on QoS Alerters and to perform any follow up, the operator can use the A9157 LASER tool. Moreover, LASER eases investigation on alerter 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, resource state changes and BSS/MFS topology are retrieved daily to: Compute system quality indicators, based on statistics and complete telecom unavailability Generate events which correspond to synthesis of alarms from customizable detection rules. Using Laser, the user can also perform any BSS equipment stability follow-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.03

39 / 54

4 Alerter Alarm Handling

The following figure shows the position of LASER in the complete Alcatel tool chain 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 tools enhances 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.03

5 Basic Alerters

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

3BK 20963 AAAA PCZZA Ed.03

41 / 54

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 BSS Release B9. AlarmId RefName 200001 200002 200003 200004 200005 200006 200007 200008 200009 200014 HOORSUR HOIRSUR TCAVAR TCTRR TCAHCGR TCNAUNR SDAHCGR SDCDR QSCDR QSTRN Mnemonic Out_succ_rate In_succ_rate RTCH_available_rate longName HO_Out_success_rate HO_Inc_success_rate NPA_RTCH_available_rate

Occupation _rate_per_TCH (Half Rate RTCH_fail_rate and Full_Rate) RTCH_cong_rate RTCH_assign_unsuccess_NPA_rate SDCCH_cong_rate SDCCH_drop_rate call_drop_rate A_channel_occ_time_alerter RTCH_cong_rate RTCH_assign_unsuccess_NPA_rate SDCCH_cong_rate SDCCH_drop_rate call_drop_rate 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 Description HO_Out_success_rate/HOORSUR Rate of successful outgoing HO (both Internal and External) (TCH+SDCCH). Note that both preparation and execution phases are considered. %

Unit

42 / 54

3BK 20963 AAAA PCZZA Ed.03

5 Basic Alerters

5.3 Rate of Successful Incoming HO

Indicator Name/Ref. name Description HO_Inc_success_rate/HOIRSUR Rate of successful Incoming intra + intercell HO (TCH+SDCCH). Note that both preparation and execution phase are considered. It corresponds to the real incoming handover efficiency rate. If no Incoming HO, the rate is set to 100. %

Unit

5.4 Average Rate of Available Static and Dynamic Radio Time Slots for Traffic Usage
Indicator Name/Ref. name Description NPA_RTCH_available_rate/RTCH_available_rate. Average rate of available static and dynamic radio time slots for traffic use (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 slot is available if it is not "blocked" or "out of service" - A dynamic SDCCH/8 time slot cannot be a PDCH (it cannot carry GPRS traffic). %

Unit

5.5 Occupation Rate per Radio Traffic Channel (Half Rate and Full Rate)
Indicator Name/Ref. name Description Unit Occupation_Rate_per_TCH/TCTRR Rate of traffic channel usage (FR and HR) %

5.6 Rate of Failures Due to Congestion on Air Interface Channels

Indicator Name/Ref name Description RTCH_cong_rate/TCAHCGR Rate of failures during assignment and handover procedures, due to congestion on the Air Interface channels (RTCH). %

Unit

3BK 20963 AAAA PCZZA Ed.03

43 / 54

5 Basic Alerters

5.7 Rate of Unsuccessful RTCH Seizures

Indicator Name/Ref name Description RTCH_assign_unsuccess_NPA_rate/TCNAUNR Rate of unsuccessful RTCH seizures (congestion + failures) for normal assignment 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 and handover because of congestion on the Air interface over the amount of SDCCH requests for radio link establishment and handover. %

Unit

5.9 SDCCH Drop Rate

Indicator Name/Ref. name Description SDCCH_drop_rate/SDCDR Rate of SDCCH drops due to BSS Problems, Radio Link Failure or during HO procedure. If no SDCCH traffic, the rate is set to 0. HO incoming and outgoing are omitted at denominator because of low probability of occurrence. %

Unit

5.10 Call Drop Rate

Indicator Name/Ref name Description call_drop_rate/QSCDR 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 HO performed an outgoing HO), the rate is set to 0. Incoming HO are added and outgoing HO are removed from the number of TCH seized to have the real number of calls in the cell. TCH drops occurring after successful assignment but before speech connection are considered as call drops. %

Unit

44 / 54

3BK 20963 AAAA PCZZA Ed.03

5 Basic Alerters

5.11 A_Channel Average Occupancy

Indicator Name/Ref name Description A_channel_occ_time_alerter/QSTRN Averaged time during which the A_channel is busy after allocation, in seconds. Seconds

Unit

3BK 20963 AAAA PCZZA Ed.03

45 / 54

5 Basic Alerters

46 / 54

3BK 20963 AAAA PCZZA Ed.03

6 QoS Alerters

6 QoS Alerters
This section describes the syntax used to define QoS Alerters and provides examples.

3BK 20963 AAAA PCZZA Ed.03

47 / 54

6 QoS Alerters

6.1 Syntax for QoS Alerters

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

6.1.1 Operators
Supported operators are available when create Predicates. A description of these operators can be found on following table: Operator +-/* Description Numeric addition, subtraction, division and multiplication. The operands are converted to real, the arithmetic is performed and the result is converted back to a string. If any of the operators is a number, the result is an empty string; no error is raised. The division by zero returns zero. Numeric relational operators. If the predicate is true, the result is a string "true"; else it is "false". Boolean NOT, AND and OR operators whose operands are the strings "true" or "false". Example (TDUR/ (TDEFCHTUNAVAL))/3600

== > < >= <= != ! ||

(TSUCC == 0)

(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.03

6 QoS Alerters

6.1.2 Threshold
The following table provides an explanation of the different thresholds present in the QoS Alerter definition. Threshold Name Simple threshold Description Example

A column is compared directly against a fixed value. This is the simplest and usually the least useful type of predicate as it is normally not possible to define a sensible threshold value for raw data for all elements. An expression is compared to a constant value. The expression normally calculates a normalized value from the input data, that is, something that can be compared across multiple elements. For example: % congestion, % call dropped, % RF losses per Erlang carried traffic, % available channels. Using expressions you can define arbitrary conditions comparing columns with other columns or with expressions.

RFLOSSES > 100

Complex threshold

AVAILCH/DEFINEDCH<0.5

Arbitrary conditions

AVAILCH=DEFINEDCH BLOCKS/ATTEMPS<0.01 TRAFFIC>1

Table 4: Thresholds Used in QoS Alerters

3BK 20963 AAAA PCZZA Ed.03

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

6 QoS Alerters

6.2.2 Alerter SDCCH Fail

3BK 20963 AAAA PCZZA Ed.03

51 / 54

6 QoS Alerters

6.2.3 Alerter TCH Fail

52 / 54

3BK 20963 AAAA PCZZA Ed.03

6 QoS Alerters

6.2.4 Alerter TCH Assignment Failure

3BK 20963 AAAA PCZZA Ed.03

53 / 54

6 QoS Alerters

BLANK PAGE BREAK

54 / 54

3BK 20963 AAAA PCZZA Ed.03