MAAAe 01

9153 OMC-R Alarm and State Change Export Interface - Release B11
ED 01 RELEASED

9829m1re.doc
24/09/2008

3BK 09829 MAAA PBZZA 1/1

A
l
l

r
i
g
h
t
s

r
e
s
e
r
v
e
d
.

P
a
s
s
i
n
g

o
n

a
n
d

c
o
p
y
i
n
g

o
f

t
h
i
s

d
o
c
u
m
e
n
t
,

u
s
e

a
n
d

c
o
m
m
u
n
i
c
a
t
i
o
n

o
f

i
t
s

c
o
n
t
e
n
t
s

n
o
t

p
e
r
m
i
t
t
e
d

w
i
t
h
o
u
t

w
r
i
t
t
e
n

a
u
t
h
o
r
i
z
a
t
i
o
n

f
r
o
m

A
l
c
a
t
e
l
.

9135 OMC-R Alarm and State Change Export
Interface
Release B11 onwards

ED 01 RELEASED

9829m1re.doc
24/09/2008


A
l
l

r
i
g
h
t
s

r
e
s
e
r
v
e
d
.

P
a
s
s
i
n
g

o
n

a
n
d

c
o
p
y
i
n
g

o
f

t
h
i
s

d
o
c
u
m
e
n
t
,

u
s
e

a
n
d

c
o
m
m
u
n
i
c
a
t
i
o
n

o
f

i
t
s

c
o
n
t
e
n
t
s

n
o
t

p
e
r
m
i
t
t
e
d

w
i
t
h
o
u
t

w
r
i
t
t
e
n

a
u
t
h
o
r
i
z
a
t
i
o
n

f
r
o
m

A
l
c
a
t
e
l
.

SYSTEM FUNCTIONAL BLOCKS

TABLE OF CONTENTS
1. INTRODUCTION............................................................................................... 5
1.1 Scope of the document ......................................................................... 5
1.2 Overview of the AASCE interface......................................................... 5
1.3 Convention and notations..................................................................... 6
2. THE 9153 OMC-R ALARM AND STATE CHANGE REPOSITORIES ............. 7
2.1 Organization of the AASCE repository. ............................................... 7
2.2 Name of the AASCE files....................................................................... 7
2.3 Format of the AASCE files .................................................................... 8
2.4 Structure of the AASCE files ................................................................ 8
2.4.1 The header of an AASCE file......................................................... 8
2.4.2 The sub-header of an AASCE file.................................................. 9
2.4.3 The body of an AASCE file............................................................ 9
3. SEMANTICS OF THE AASCE FILES ............................................................ 11
3.1 Historical and current alarms export files ......................................... 11
3.1.1 The concerned parameters.......................................................... 11
3.1.2 The concerned MOs and their naming attributes......................... 15
3.1.2.1 MOs emitting GSM alarms .............................................................................15
3.1.2.1.1 Corresponding naming sub-tree.................................................................. 15
3.1.2.1.2 Corresponding MOC OID values and Naming attributes ........................... 16
3.1.2.2 MOs emitting GPRS alarms............................................................................16
3.1.2.2.1 Corresponding naming sub-tree.................................................................. 16
3.1.2.2.2 Corresponding MOC OID values and Naming attributes ........................... 17
3.1.3 The concerned Attributes............................................................. 18
3.2 State changes export files .................................................................. 20
3.2.1 The concerned parameters.......................................................... 20
3.2.2 The MOCs corresponding to the MOT parameter values ............ 20
3.3 AASCE type definitions....................................................................... 21
3.3.1 Introduction.................................................................................. 21
3.3.2 Corresponding definitions............................................................ 21
4. EXPORT MECHANISM.................................................................................. 24
4.1 Historical alarm lists export sessions ............................................... 24
4.2 Snapshot of current alarm list export sessions................................ 24
4.3 State changes export sessions .......................................................... 25
5. ACRONYMS................................................................................................... 26

ED 01 RELEASED

9829m1re.doc
24/09/2008


A
l
l

r
i
g
h
t
s

r
e
s
e
r
v
e
d
.

P
a
s
s
i
n
g

o
n

a
n
d

c
o
p
y
i
n
g

o
f

t
h
i
s

d
o
c
u
m
e
n
t
,

u
s
e

a
n
d

c
o
m
m
u
n
i
c
a
t
i
o
n

o
f

i
t
s

c
o
n
t
e
n
t
s

n
o
t

p
e
r
m
i
t
t
e
d

w
i
t
h
o
u
t

w
r
i
t
t
e
n

a
u
t
h
o
r
i
z
a
t
i
o
n

f
r
o
m

A
l
c
a
t
e
l
.

01 080924 First issue O&M System TD/MRC/OMD Spec
ED DATE CHANGE NOTE APPRAISAL AUTHORITY ORIGINATOR

ED 01 RELEASED

9829m1re.doc
24/09/2008


A
l
l

r
i
g
h
t
s

r
e
s
e
r
v
e
d
.

P
a
s
s
i
n
g

o
n

a
n
d

c
o
p
y
i
n
g

o
f

t
h
i
s

d
o
c
u
m
e
n
t
,

u
s
e

a
n
d

c
o
m
m
u
n
i
c
a
t
i
o
n

o
f

i
t
s

c
o
n
t
e
n
t
s

n
o
t

p
e
r
m
i
t
t
e
d

w
i
t
h
o
u
t

w
r
i
t
t
e
n

a
u
t
h
o
r
i
z
a
t
i
o
n

f
r
o
m

A
l
c
a
t
e
l
.

LIST OF FIGURES AND TABLES
Figure 1: Overview of the AASCE interface.............................................................................6
Figure 2: Organization of the AASCE repository .....................................................................7
Figure 3: Naming Tree for MOs at the BSC-NE level that can emit alarms...........................15
Figure 4: Naming Tree for MOs at the MFS-NE level that can emit alarms ..........................17

Table 1: Representation of values in AASCE files ................................................................10
Table 2: The parameters in alarms export files .....................................................................14
Table 3: MOC OID values and Naming attributes for GSM alarms .......................................16
Table 4: MOC OID values and Naming attributes for GPRS alarms .....................................18
Table 5: OID values and AASCE types for attributes in alarms export files ..........................19
Table 6: The parameters in state changes export files..........................................................20
Table 7: The MOCs corresponding to the MOT parameter values........................................21
HISTORY
Ed. 01
09/09/2008: Creation from 3BK 09829 LAAA PBZZA Ed.02 Released
SEMANTICS OF THE AASCE FILES
Historical and current alarms export files
The concerned MOs and their naming attributes
The relationship between aGprsFabric and aGprsSgsnIpEndPoint is
not applicable to B11 release.
24/09/2008: no technical changes.
REFERENCED DOCUMENTS
Standards
[ASN1] Information Processing Systems - Open Systems Interconnection -
Specification of Abstract Syntax Notation One (ASN.1)
CCITT Rec. X.208 (1988) | ISO/IEC 8824
[X.721] Information Technology - Open Systems Interconnection Structure of
Management Information - Part 2: Definition of Management
Information
CCITT Recommendation X.721 (ISO/IEC 10165-2); 1991 with the
technical Corrigendum 1,1994
[M.3100] Maintenance: Telecommunications Management Network - Generic
Network Information Model;
CCITT Recommendation M.3100, July 1995
[GSM 12.00] Digital cellular telecommunications system (Phase 2);
Network Management (NM);
Part 1: Objectives and structure of Network Management
GSM 12.00 version 4.5.1, ETS 300 612-1, August 1996
[GSM 12.20] Digital cellular telecommunications system (Phase 2);
Base Station System (BSS) Management Information
GSM 12.20 version 4.2.1, ETS 300 622, June 1996
[Q.751.1] Specifications of signalling system No. 7 -
Network Element Management Information Model for the Message

ED 01 RELEASED

9829m1re.doc
24/09/2008


A
l
l

r
i
g
h
t
s

r
e
s
e
r
v
e
d
.

P
a
s
s
i
n
g

o
n

a
n
d

c
o
p
y
i
n
g

o
f

t
h
i
s

d
o
c
u
m
e
n
t
,

u
s
e

a
n
d

c
o
m
m
u
n
i
c
a
t
i
o
n

o
f

i
t
s

c
o
n
t
e
n
t
s

n
o
t

p
e
r
m
i
t
t
e
d

w
i
t
h
o
u
t

w
r
i
t
t
e
n

a
u
t
h
o
r
i
z
a
t
i
o
n

f
r
o
m

A
l
c
a
t
e
l
.

Transfer Part (MTP)
ITU-T Recommendation Q.751.1, October 1995
Alcatel documents
[ACOguide] Alarm Call Out User Guide
3BK 21217 AAAA PCZZA

ED 01 RELEASED

9829m1re.doc
24/09/2008


A
l
l

r
i
g
h
t
s

r
e
s
e
r
v
e
d
.

P
a
s
s
i
n
g

o
n

a
n
d

c
o
p
y
i
n
g

o
f

t
h
i
s

d
o
c
u
m
e
n
t
,

u
s
e

a
n
d

c
o
m
m
u
n
i
c
a
t
i
o
n

o
f

i
t
s

c
o
n
t
e
n
t
s

n
o
t

p
e
r
m
i
t
t
e
d

w
i
t
h
o
u
t

w
r
i
t
t
e
n

a
u
t
h
o
r
i
z
a
t
i
o
n

f
r
o
m

A
l
c
a
t
e
l
.

1. INTRODUCTION
1.1 Scope of the document
The 9153 OMC-R provides several file-based interfaces to external applications. This
document specifies the Alcatel-Lucent 9153 OMC-R Alarm and State Change Export
(AASCE) Interface. This interface can be viewed as a collection of several file-based sub-
interfaces:
The Historical Alarm List Export (HALE) interface
This interface enables to export the archived alarms in order to have an accurate
viewpoint of what happened on the network.
The Snapshot Of the last Current Alarm list Export (SOCAE) interface
This interface provides the operator with a recent viewpoint of the network concerning
the active alarms.
The State Changes Export (SCE) interface
The way files are transferred is out of the scope of this document.
1.2 Overview of the AASCE interface
The HALE interface gives, on 9153 OMC-R operator request, the list of all the alarms that
have been archived for a given period of time. Alarms are archived when they are cleared
and acknowledged or when they have been purged.
The SOCAE interface, on the contrary, is aimed at providing, at regular intervals, an output
of the current alarm list in order to give a follow-up on all the active alarms.
The information exported at each of these two interfaces is obtained thanks to the 9153
OMC-R internal database for Alarm Surveillance (AS). There is one AS database per 9153
OMC-R instance.
This implies that both GSM alarms (alarms on the BSC equipment and the sub-network
managed by that equipment) and GPRS alarms (alarms on the MFS equipment and the sub-
network managed by that equipment) are taken into account in an export session.

The SCE interface provides a real-time log of all the state changes which have occurred on
specific network elements. There are 2 levels of log:
The core BSS-NE level (sometimes called BSC-NE level for short) that logs the state
changes which occurred on objects managed by the BSC-NE (TRX, cell, BSC, N7,...).
The GPRS BSS-NE level (sometimes called MFS-NE level for short), that logs the state
changes which have occurred on the A9135 (also called MFS which stands for Multi-
BSS Fast packet Server) as well as the cells and BSC carrying GPRS traffic.

ED 01 RELEASED

9829m1re.doc
24/09/2008


A
l
l

r
i
g
h
t
s

r
e
s
e
r
v
e
d
.

P
a
s
s
i
n
g

o
n

a
n
d

c
o
p
y
i
n
g

o
f

t
h
i
s

d
o
c
u
m
e
n
t
,

u
s
e

a
n
d

c
o
m
m
u
n
i
c
a
t
i
o
n

o
f

i
t
s

c
o
n
t
e
n
t
s

n
o
t

p
e
r
m
i
t
t
e
d

w
i
t
h
o
u
t

w
r
i
t
t
e
n

a
u
t
h
o
r
i
z
a
t
i
o
n

f
r
o
m

A
l
c
a
t
e
l
.

The figure below sketches out these interfaces:
A1353 RA
complete
alarm
history
export
directory
Current/ Historical alarms
BSS-NElevel state changes
GPRSBSS-NElevel state changes
AS
database
State
changes
export
directory
BSS-NEprocess
GPRSBSS-NE
process
snapshot
of the last
current
alarms
export
directory
C
u
rre
n
t a
la
rm
s

Figure 1: Overview of the AASCE interface
1.3 Convention and notations
To specify the form taken by a number of items (names, parts of AASCE files, etc..), the
following conventions are used:

Item Meaning
CR carriage return
<productionName> references a part (called a production)
whose semantics and syntax are described
separately
<n> represents any integer value
<string> represents any ASN1 string value
<form1> | <form2> indicates that the form can be either the one
referenced by <form1> (exclusive) or the one
referenced by <form2> where <form1> and
<form2> denote either production names or
particular constant parts.
[...] delimits a part that may either be absent or
present only once.
[...]
*
delimits a part that may be present zero or
more times.
[...]
+
delimits a part that may be present once or
more times.

ED 01 RELEASED

9829m1re.doc
24/09/2008


A
l
l

r
i
g
h
t
s

r
e
s
e
r
v
e
d
.

P
a
s
s
i
n
g

o
n

a
n
d

c
o
p
y
i
n
g

o
f

t
h
i
s

d
o
c
u
m
e
n
t
,

u
s
e

a
n
d

c
o
m
m
u
n
i
c
a
t
i
o
n

o
f

i
t
s

c
o
n
t
e
n
t
s

n
o
t

p
e
r
m
i
t
t
e
d

w
i
t
h
o
u
t

w
r
i
t
t
e
n

a
u
t
h
o
r
i
z
a
t
i
o
n

f
r
o
m

A
l
c
a
t
e
l
.

2. THE 9153 OMC-R ALARM AND STATE CHANGE REPOSITORIES
2.1 Organization of the AASCE repository.
The 9153 OMC-R has a file repository dedicated to file transfers to external clients: the
Alcatel-Lucent 9153 OMC-R File Transfer Repository (AFTR). The information required to
reach this more general file repository is predefined at the installation of an 9153 OMC-R
instance.
At the 9153 OMC-R installation, 3 sub-directories (collectively referred to as the AASCE
repository) are also created in AFTR:
Historical Alarm Lists Directory
This directory is named ''HALD
Snapshot Of Current Alarms directory
This directory is named ''SOCAD
State Changes Directory
This directory is named SCD.
This can be pictured out as follows:

AFTR
AASCE repository
SCD
SOCAD
HALD

Figure 2: Organization of the AASCE repository
For each of these directories, a peer entity (e.g. the tool LASER) is allowed to:
list the contents
transfer files
but not to add or delete files.
2.2 Name of the AASCE files
The name of one historical alarm list export file is of the form: hal_<YYYYMMDD>.csv
where <YYYYMMDD> is the date of the archive day.
The historical alarm list export files corresponding to one export session are
compressed (.zip and .tar) into a unique file whose name is hal.tgz
The name of a current alarm export file is cal.csv

ED 01 RELEASED

9829m1re.doc
24/09/2008


A
l
l

r
i
g
h
t
s

r
e
s
e
r
v
e
d
.

P
a
s
s
i
n
g

o
n

a
n
d

c
o
p
y
i
n
g

o
f

t
h
i
s

d
o
c
u
m
e
n
t
,

u
s
e

a
n
d

c
o
m
m
u
n
i
c
a
t
i
o
n

o
f

i
t
s

c
o
n
t
e
n
t
s

n
o
t

p
e
r
m
i
t
t
e
d

w
i
t
h
o
u
t

w
r
i
t
t
e
n

a
u
t
h
o
r
i
z
a
t
i
o
n

f
r
o
m

A
l
c
a
t
e
l
.

The name of a state change export file is of the form
<bsc/mfs><xxx>_stc_day<n>.csv where
<bsc/mfs> is the string bsc or mfs according to the level of the logged state
changes: bsc corresponds to BSC-NE level states changes and mfs
corresponds to MFS-NE level state changes.
<xxx> corresponds to the BSC or MFS identifier.
<n> is a number between 0 and 6. It corresponds to the weekday (0 meaning
Sunday, 1 meaning Monday, and so on)
2.3 Format of the AASCE files
The format used for an AASCE file is the Comma Separated Value (CSV) format that
consists in several lines separated by CR, each line being of the form:
<linePart>[;<linePart>]*;
where each <line part> is separated by a semi-colon (;).
For example,
aaaaaaaaaa;bbbbbbbbbb;cccccccccc;dddddddddd;eeeeeeeee;
1111111;2222222222;333333333;444444444;555555555;
fffffff;gggggggg;hhhhhhhhh;iiiiiiiiiiiii;jjjjjjjjjjjjjjjjjjj;
The advantages of this format are as follows:
These files are readable without any specific tool.
The contents of these files can easily be interpreted/converted as a table in which the
lines of the table correspond to the lines of the text and the columns of the tables are
split using the character ; in the text.
For example, the aforementioned text in CSV format can be interpreted as:
aaaaaaaaaa bbbbbbbbbb cccccccccc dddddddddd eeeeeeeee
1111111 2222222222 333333333 444444444 555555555
fffffff gggggggg hhhhhhhhh iiiiiiiiiiiii jjjjjjjjjjjjjjjjjjj
2.4 Structure of the AASCE files
An AASCE file is composed of:
a header
a sub-header
a body
2.4.1 The header of an AASCE file
This header is placed on the first line of the file and is composed of only one line. This
enables the header to be easily extracted from the file.
For example, under Unix, the header of a file named cal.csv can be extracted taking
advantage of the following command:
head-1 cal.csv
The structure of the header is as follows:
<date>;<hour>;<creator>;
where:
<date> indicates the (local) date at which the file was created.
It is of the form YYYY-MM-DD

ED 01 RELEASED

9829m1re.doc
24/09/2008


A
l
l

r
i
g
h
t
s

r
e
s
e
r
v
e
d
.

P
a
s
s
i
n
g

o
n

a
n
d

c
o
p
y
i
n
g

o
f

t
h
i
s

d
o
c
u
m
e
n
t
,

u
s
e

a
n
d

c
o
m
m
u
n
i
c
a
t
i
o
n

o
f

i
t
s

c
o
n
t
e
n
t
s

n
o
t

p
e
r
m
i
t
t
e
d

w
i
t
h
o
u
t

w
r
i
t
t
e
n

a
u
t
h
o
r
i
z
a
t
i
o
n

f
r
o
m

A
l
c
a
t
e
l
.

<hour> indicates the (local) time at which the file was created.
It is of the form hh:mm
<creator> is a character string that indicates the concerned 9153 OMC-R instance
2.4.2 The sub-header of an AASCE file
The sub-header corresponds to the column titles of the table associated with the body part
of the AASCE file; i.e. it describes the type of information contained in the columns.
This sub-header is placed on the second line of the file and is composed of only one line.
This enables the sub-header to be easily extracted from the file.
For example, under Unix, the sub-header of a file named cal.csv can be extracted taking
advantage of the following command:
head 2 cal.csv | tail 1
The structure of the sub-header is as follows:
For historical and current alarms export files:
EVTTIME;FRDNAME;SEV;EVTTYPE;PBCAUSE;SPECPB;MONITOR;STATECHG
;ADDINFO;REPCOUNT;ACKSTS;CLRSTS;CLRTIME;USRNOTE;MOC;MOI;[ARC
HIVETIME;ARCHIVECAUSE;]ALARMNB;
N.B.: Parameters within '[' and ']' are only present in historical alarm export
files.
The meaning of the aforementioned parameters is described in chapter 3.1.
For state changes export files:
STCHTIME;MOT;MOI;FRDNAME;ADMINSTATE;OPERSTATE;AVAILSTATE;UNK
NSTATUS;
The meaning of the aforementioned parameters is described in chapter 3.2.
2.4.3 The body of an AASCE file
The body of an AASCE file consists of lines separated by CR. The structure of a line is as
follows:
[[<parameter value>];]
+
where <parameter value> is either absent when the corresponding parameter is not
significant or is defined as follows according to the type of that parameter (called its AASCE
type):

AASCE Type Description Example
AASCE basic types
AVA OID#<n> or
OID#<string>
where:
OID corresponds to the OID of the
naming attribute for the associated
MOC
<n> or <string> correspond to the
instance identifier value
1.2.9.7.1#0
1.2.9.7.5#my_value
BOOLEAN 0 (FALSE) or 1 (TRUE) 0
FDN AVA [/ AVA ]* 2.4.5.0.7.10#1/2.4.5.

ED 01 RELEASED

9829m1re.doc
24/09/2008


A
l
l

r
i
g
h
t
s

r
e
s
e
r
v
e
d
.

P
a
s
s
i
n
g

o
n

a
n
d

c
o
p
y
i
n
g

o
f

t
h
i
s

d
o
c
u
m
e
n
t
,

u
s
e

a
n
d

c
o
m
m
u
n
i
c
a
t
i
o
n

o
f

i
t
s

c
o
n
t
e
n
t
s

n
o
t

p
e
r
m
i
t
t
e
d

w
i
t
h
o
u
t

w
r
i
t
t
e
n

a
u
t
h
o
r
i
z
a
t
i
o
n

f
r
o
m

A
l
c
a
t
e
l
.

AASCE Type Description Example
where AVA are ordered according to
the naming tree (see sections
3.1.2.1.1 and 3.1.2.2.1)
0.7.12#1
INTEGER <n> (INTEGER value) 247
OID or OBJECT
IDENTIFIER
<n> [.<n>]* 1.2.9.23.4.7.1
String or GraphicString <string> (string value) My_String
StringOrInteger <string> (string value) or
<n> (INTEGER value)
225
Time yyyymmddhhmmss.t[ Z ]
If it ends with Z, it represents an
UTC time,
else it represents a local time.
19980624120000.0Z
Other AASCE types
N.B.: The definitions for these types can be found in section 0.
ENUMERATED {
enum1 (0),
enum2 (1),
.....
enumn (<n>)
}
Symbolic name of the enumerated
value followed by its corresponding
integer value between parenthesis.
critical (1)
INTEGER {
int1 (0),
int2 (1),
.....
intn (<n>)
}
Symbolic name of the integer value
followed by its corresponding integer
value in parenthesis.
failed (1)
SEQUENCE {
f1 <T1>,
f2 <T2> OPTIONAL,
...
fn <Tn>
}
or SET {
f1 <T1>,
f2 <T2>,
...
fn <Tn>
}
List of field names and values of the
associated type separated with , and
enclosed between ( and ).
If a field is OPTIONAL and is not
present, it does not appear in the list.
(string1, string2,
string3)

(value of
SEQUENCE {
f1 GraphicString,
f2 GraphicString,
f3 GraphicString
})
SEQUENCE OF<T>
or SET OF <T>
If <T> is an INTEGER type:
List of values of type <T> separated
with ,.
else:
List of values of type <T> separated
with , and enclosed between ( and
).
12,13,14
(value of type SET
OF INTEGER)
Table 1: Representation of values in AASCE files

ED 01 RELEASED

9829m1re.doc
24/09/2008


A
l
l

r
i
g
h
t
s

r
e
s
e
r
v
e
d
.

P
a
s
s
i
n
g

o
n

a
n
d

c
o
p
y
i
n
g

o
f

t
h
i
s

d
o
c
u
m
e
n
t
,

u
s
e

a
n
d

c
o
m
m
u
n
i
c
a
t
i
o
n

o
f

i
t
s

c
o
n
t
e
n
t
s

n
o
t

p
e
r
m
i
t
t
e
d

w
i
t
h
o
u
t

w
r
i
t
t
e
n

a
u
t
h
o
r
i
z
a
t
i
o
n

f
r
o
m

A
l
c
a
t
e
l
.

3. SEMANTICS OF THE AASCE FILES
3.1 Historical and current alarms export files
3.1.1 The concerned parameters
The table below lists the alarm parameters in alphabetical order and, for each of them:
its corresponding AASCE type (see section 2.4.3);
its description;
a valid value for that parameter.

Parameter AASCE Type Description Example
ACKSTS Acknowledge
mentStatus
Acknowledgement status.
This parameter indicates if the
alarm has been acknowledged by
an operator.
unAcknowledged(0)
ADDINFO AdditionalInfor
mation
Additional information
This parameter contains at most 3
elements.
((alcatelAdditionalInf
ormation,significant,
Additional

alcatelAdditionalInformation
element:
This element is only present if an
additional information is available
for the corresponding BSS
alarm. In that case,
the identifier field contains
the string:
alcatelAdditionalInformat
ion
the significance field
contains the string:
significant
the information field
contains a String value
which corresponds to a
human readable version of
the additionalInformation of
that BSS alarm.
Information is Alarm
Cause = Bar/unbar
cell request
RACH = 0000
Cell Bar Access = 00
Cell Bar Qualifier =
00 ))

urlAddressOnAlarmDictionary
element:
This element is only present if an
URL address of a WEB page
describing the alarm is available.
In that case,
the string:
urlAddressOnAlarmDicti

ED 01 RELEASED

9829m1re.doc
24/09/2008


A
l
l

r
i
g
h
t
s

r
e
s
e
r
v
e
d
.

P
a
s
s
i
n
g

o
n

a
n
d

c
o
p
y
i
n
g

o
f

t
h
i
s

d
o
c
u
m
e
n
t
,

u
s
e

a
n
d

c
o
m
m
u
n
i
c
a
t
i
o
n

o
f

i
t
s

c
o
n
t
e
n
t
s

n
o
t

p
e
r
m
i
t
t
e
d

w
i
t
h
o
u
t

w
r
i
t
t
e
n

a
u
t
h
o
r
i
z
a
t
i
o
n

f
r
o
m

A
l
c
a
t
e
l
.

onary
significant
the information field of that
element contains a string
value indicating this
address.

reservedForTest element
The element is only present if the
MO is subject to test. In that
case,
the string:
reservedForTest
significant
the information field of that
element contains the string:
subject to test.

ALARMNB INTEGER Alarm number
This parameter indicates the alarm
number, which is extracted from
the aditionalText of the alarm, if
the aditionalText contains this
information. Otherwise, this field
will be empty.
0
ARCHIVETI
ME
Time Archiving time 19991202121931.0Z
ARCHIVEC
AUSE
ArchiveCause Reason why the alarm has been
archived.
manualPurge (3)
CLRSTS ClearingStatus Clearing status
Indicates if the alarm is cleared.
cleared (1)
CLRTIME Time Clearing time 19991203081827.0Z
EVTTYPE String Event type
This field indicates the category of
the alarm.
equipmentAlarm
The possible values are:
communicationAlarm
environmentalAlarm
equipmentAlarm
processingErrorAlarm
qualityofServiceAlarm

EVTTIME Time Event time
This parameter contains a BSS
time-stamp
19991202121931.0Z
FRDNAME String Friendly name
This parameter enables to locate
precisely the alarm.
bss1 BTS_001 rack1
shelf1 trgm 10

ED 01 RELEASED

9829m1re.doc
24/09/2008


A
l
l

r
i
g
h
t
s

r
e
s
e
r
v
e
d
.

P
a
s
s
i
n
g

o
n

a
n
d

c
o
p
y
i
n
g

o
f

t
h
i
s

d
o
c
u
m
e
n
t
,

u
s
e

a
n
d

c
o
m
m
u
n
i
c
a
t
i
o
n

o
f

i
t
s

c
o
n
t
e
n
t
s

n
o
t

p
e
r
m
i
t
t
e
d

w
i
t
h
o
u
t

w
r
i
t
t
e
n

a
u
t
h
o
r
i
z
a
t
i
o
n

f
r
o
m

A
l
c
a
t
e
l
.

MOC OID Managed Object Class
This parameter identifies the
Managed Object Class to which
the object instance emitting the
notification belongs.
See section 3.1.2 for the definition
of all the possible Managed Object
Class values.
1.3.12.2.1006.53.1.2
.0.3.1013
MOI FDN Managed Object Instance
managed object instance emitting
the notification.
See section 3.1.3 for the definition
of the OIDs of the concerned
attributes.
0.0.13.3100.0.7.68#
1/0.0.13.3100.0.7.20
#3/0.0.13.3100.0.7.2
0#1/0.0.13.3100.0.7.
20#1/0.0.13.3100.0.
7.20#10
MONITOR MonitoredAttri
butes
Monitored attributes
The monitoredAttributes contains
one element (of type Attribute) for:
each of the following attributes,
provided they are present in the
corresponding MO:
"X.721":administrativeState
"M.3100":alarmStatus
"X.721":availabilityStatus
"X.721":operationalState
"M.3100":userLabel
ALM:accessControlDomain, if
relevant.
This (internal) attribute is used
for 9153 OMC-R security
management.
((availabilityStatus,d
egraded
),(administrativeStat
e,unlocked
),(operationalState,e
nabled
),(alarmStatus,major
(4)),(userLabel, bss1
BTS_001 rack1
shelf1 trgm 10 ))

The attributeValue field contains
For all these attributes except
"M.3100":userLabel, the value
contained in the attribute.
For "M.3100":userLabel, a
string corresponding to the
FRDNAME value (see
definition of FRDNAME
above).

PBCAUSE String Probable cause
This parameter indicates the
probable cause of the alarm as a
string value.
X721-corruptData
REPCOUNT INTEGER Repetition counter
number of times the alarm has
been sent by the MO.
0
SEV PerceivedSeve
rity
Perceived severity
perceived severity of the alarm
major (2)

ED 01 RELEASED

9829m1re.doc
24/09/2008


A
l
l

r
i
g
h
t
s

r
e
s
e
r
v
e
d
.

P
a
s
s
i
n
g

o
n

a
n
d

c
o
p
y
i
n
g

o
f

t
h
i
s

d
o
c
u
m
e
n
t
,

u
s
e

a
n
d

c
o
m
m
u
n
i
c
a
t
i
o
n

o
f

i
t
s

c
o
n
t
e
n
t
s

n
o
t

p
e
r
m
i
t
t
e
d

w
i
t
h
o
u
t

w
r
i
t
t
e
n

a
u
t
h
o
r
i
z
a
t
i
o
n

f
r
o
m

A
l
c
a
t
e
l
.

(indeterminate, critical, major,
minor, warning or cleared).
SPECPB SpecificPb Specific problems
This parameter is an unordered list
of
integer values that are such that
an alarm emitted by a given
object instance with a
perceivedSeverity field equal to
'cleared' can safely clear the
alarms for that managed object
instance that have the same
eventType, probableCause and
specificProblems field values.
RX-TX [10] RX-
CABLE[3],100002
a string value that corresponds
to the name of the alarm in the
alarm dictionary.

STATECHG StateChange State change information
This parameter is only present if
state changes are associated with
the alarm. It can contain the value
of the following attributes:
"X.721":administrativeState
"M.3100":alarmStatus
"X.721":availabilityStatus
X.721:controlStatus
"X.721":operationalState
X.721:proceduralStatus
X.721:unknownStatus
((availabilityStatus,,d
egraded (6)))
USRNOTE String User note
This parameter contains a free text
that has been entered by an 9153
OMC-R operator, if any.
Otherwise, it is absent.
this is a user note
Table 2: The parameters in alarms export files

ED 01 RELEASED

9829m1re.doc
24/09/2008


A
l
l

r
i
g
h
t
s

r
e
s
e
r
v
e
d
.

P
a
s
s
i
n
g

o
n

a
n
d

c
o
p
y
i
n
g

o
f

t
h
i
s

d
o
c
u
m
e
n
t
,

u
s
e

a
n
d

c
o
m
m
u
n
i
c
a
t
i
o
n

o
f

i
t
s

c
o
n
t
e
n
t
s

n
o
t

p
e
r
m
i
t
t
e
d

w
i
t
h
o
u
t

w
r
i
t
t
e
n

a
u
t
h
o
r
i
z
a
t
i
o
n

f
r
o
m

A
l
c
a
t
e
l
.

3.1.2 The concerned MOs and their naming attributes
3.1.2.1 MOs emitting GSM alarms
3.1.2.1.1 Corresponding naming sub-tree
The naming sub-tree for the MOs that can emit alarms is as follows:

EML:
alcatelManagedElementComplex

"EML":
alcatelManagedElement

"EML":
alcatelFunctionCoordinator
"Q.751.1":
mtpSignPoint

"EML":
alcatelFunction
"EML ":
alcatelSignLinkSetTp

"EML":
alcatelSignLinkN7

"M.3100":
equipmentHolder (Rack)
"EML":
alcatel2MbTTP

"M.3100":
equipmentHolder (Shelf)

"EML":
alcatelCircuitPack

"EML":
alcatelBssFunction

"EML":
alcatelBsc
"EML":
alcatelBtsSiteManager

"EML":
alcatelBts-Sector

"EML":
alcatelBasebandTransceiver

Legend:

The corresponding MOs can emit alarms
Figure 3: Naming Tree for MOs at the BSC-NE level that can emit alarms

ED 01 RELEASED

9829m1re.doc
24/09/2008


A
l
l

r
i
g
h
t
s

r
e
s
e
r
v
e
d
.

P
a
s
s
i
n
g

o
n

a
n
d

c
o
p
y
i
n
g

o
f

t
h
i
s

d
o
c
u
m
e
n
t
,

u
s
e

a
n
d

c
o
m
m
u
n
i
c
a
t
i
o
n

o
f

i
t
s

c
o
n
t
e
n
t
s

n
o
t

p
e
r
m
i
t
t
e
d

w
i
t
h
o
u
t

w
r
i
t
t
e
n

a
u
t
h
o
r
i
z
a
t
i
o
n

f
r
o
m

A
l
c
a
t
e
l
.

3.1.2.1.2 Corresponding MOC OID values and Naming attributes
MOC name (1) MOC OID value (2) Naming attribute
EML:alcatel2MbTTP <mdrAlcatelManagedObjectClass>.
1014
"M.3100":tTPId
EML:alcatelBaseBandTra
nsceiver
<mdrAlcatelManagedObjectClass>.
1002
GSM 12.20:baseB
andTransceiverID
EML:alcatelBsc <mdrAlcatelManagedObjectClass>.
1003
GSM 12.20:bscID
EML:alcatelBssFunction <mdrAlcatelManagedObjectClass>.
1004
"GSM 12.00":bssFun
ctionId
EML:alcatelBts-Sector <mdrAlcatelManagedObjectClass>.
1005
GSM 12.20:btsID
EML:alcatelBtsSiteManag
er
1006
GSM 12.20:btsSite
ManagerID
EML:alcatelCircuitPack <mdrAlcatelManagedObjectClass>.
1013
M.3100:equipmentI
d
EML:alcatelFunction <mdrAlcatelManagedObjectClass>.
1026
EML:functionId
EML:alcatelFunctionCoordi
nator
1025
EML:aFuntionCoor
dinatorId
EML:alcatelManagedEle
ment
1010
M.3100:equipmentI
d
EML:alcatelManagedEleme
ntComplex
1015
M.3100:managedEl
ementComplexId
EML:alcatelSignLinkN7 <mdrAlcatelManagedObjectClass>.
1021
Q.751.1:slCode
EML:alcatelSignLinkSetT
p
1011
Q.751.1:signLinkS
etTpId
M.3100:equipmentHolder <m3100ObjectClass>.32 M.3100:equipmentI
d
Q.751.1:mtpSignPoint <mtpObjectClass>.6 Q.751.1:mtpSignP
ointId
Table 3: MOC OID values and Naming attributes for GSM alarms
(1) The entries for which the MOC name in the table above is not in bold correspond to
MOCs whose managed object instances cannot emit alarms. These entries are
nevertheless added since the corresponding naming attribute is used to value the
parameter MOI.
(2) For the MOC OID values:
<m3100ObjectClass> is equal to 0.0.13.3100.0.3
<mdrAlcatelManagedObjectClass> is equal to 1.3.12.2.1006.53.1.2.0.3
<mtpObjectClass> is equal to 0.0.17.751.1.0.3
3.1.2.2 MOs emitting GPRS alarms
3.1.2.2.1 Corresponding naming sub-tree
The naming sub-tree for the objects that can emit alarms is as follows:

ED 01 RELEASED

9829m1re.doc
24/09/2008


A
l
l

r
i
g
h
t
s

r
e
s
e
r
v
e
d
.

P
a
s
s
i
n
g

o
n

a
n
d

c
o
p
y
i
n
g

o
f

t
h
i
s

d
o
c
u
m
e
n
t
,

u
s
e

a
n
d

c
o
m
m
u
n
i
c
a
t
i
o
n

o
f

i
t
s

c
o
n
t
e
n
t
s

n
o
t

p
e
r
m
i
t
t
e
d

w
i
t
h
o
u
t

w
r
i
t
t
e
n

a
u
t
h
o
r
i
z
a
t
i
o
n

f
r
o
m

A
l
c
a
t
e
l
.

"NMD":neGroup

"NMD":networkElement

"NMD":
neSupervisionCoordinator
"AS":
activeProblemTable
"NMD":
alarmSynthesis

"ABSS":
aGprsBssFunction
"AMFSME":
aGprs2MbTTP
"AGVC":
aGprsNse
"AMFSME":
aGprsFabric
"M.3100":
equipmentHolder

"ABSS":
aGprsBtsSiteManager
"AGFR":
aGprsBearerChannel
"AGVC":
aGprsNsvc
"M.3100":
equipmentHolder

"ABSS":
aGprsBts
"AGFR":
aGprsPvc
"AATER":
aGprsLapdLink
"AGVC":
aGprsSgsnIpEndPoint

"M.3100":circuitPack
"LAPF":
nectarCircuitPack
"M.3100":
equipmentHolder

"LAPF":
nectarCircuitPack

Legend:

The corresponding MOs can emit GPRS alarms (in bold type face)
Figure 4: Naming Tree for MOs at the MFS-NE level that can emit alarms
3.1.2.2.2 Corresponding MOC OID values and Naming attributes
MOC name (1) MOC OID value (2) Naming attribute
AMFSME:aGprs2MbTTP <agMeManagedObjectClass>.1 "M.3100":tTPId
AGFR:aGprsBearerChan
nel
<aGprsFrFunctionManagedObject
Class>.1
"AGFR":aGprsBeare
rChannelId
ABSS:aGprsBssFunction <agBssManagedObjectClass>.1 "GSM 12.00":bssFun
ctionId
ABSS:aGprsBts <agBssManagedObjectClass>.2 "GSM 12.20":btsID
ABSS:aGprsBtsSiteManage
r
<agBssManagedObjectClass>.7 "GSM 12.20":btsSite
ManagerID
AMFSME:aGprsFabric <agMeManagedObjectClass>.3 "M.3100":fabricId
AATER:aGprsLapdLink <aGprsAterManagedObjectClass>.
2
"A12.20":lapdLinkID
AGVC":aGprsNse <aGprsGvcFunctionManagedObjec
tClass>.1
"AGVC":aGprsNseId

ED 01 RELEASED

9829m1re.doc
24/09/2008


A
l
l

r
i
g
h
t
s

r
e
s
e
r
v
e
d
.

P
a
s
s
i
n
g

o
n

a
n
d

c
o
p
y
i
n
g

o
f

t
h
i
s

d
o
c
u
m
e
n
t
,

u
s
e

a
n
d

c
o
m
m
u
n
i
c
a
t
i
o
n

o
f

i
t
s

c
o
n
t
e
n
t
s

n
o
t

p
e
r
m
i
t
t
e
d

w
i
t
h
o
u
t

w
r
i
t
t
e
n

a
u
t
h
o
r
i
z
a
t
i
o
n

f
r
o
m

A
l
c
a
t
e
l
.

AGVC:aGprsNsvc <aGprsGvcFunctionManagedObjec
tClass>.2
"AGVC":aGprsNsvcI
d
AGFR:aGprsPvc <aGprsFrFunctionManagedObject
Class>.2
"AGFR":aGprsDlcId
"AGVC":aGprsSgsnIpEndP
oint
<aGprsGvcFunctionManagedObjec
tClass>.3
"AGVC":aGprsSgsnI
pEndpointId
M.3100:circuitPack <m3100ObjectClass>.30 "M.3100":equipmentI
d
M.3100:equipmentHolder <m3100ObjectClass>.32 "M.3100":equipmentI
d
LAPF:nectarCircuitPack <nectarManagedObjectClass>.1 "M.3100":equipmentI
d
NMD:neGroup <axIMeqpObjectClass>.4 NMD:neGroupId
NMD:neSupervisionCoor
dinator
<axIMeqpObjectClass>.5 NMD:neSupervisio
nCoordinatorId
NMD:networkElement <axIMeqpObjectClass>.10 "NMD":networkElem
entId
Table 4: MOC OID values and Naming attributes for GPRS alarms
(1) The entries for which the MOC name in the table above is not in bold correspond to
MOCs whose managed object instances cannot emit alarms. These entries are
nevertheless added since the corresponding naming attribute is used to value the
parameter MOI.
(2) For the MOC OID values:
<agBssManagedObjectClass> is equal to 1.3.12.2.1006.53.1.4.5.0.3
<agMeManagedObjectClass> is equal to 1.3.12.2.1006.53.1.4.1.0.3
<aGprsAterManagedObjectClass> is equal to 1.3.12.2.1006.53.1.4.3.0.3
<aGprsFrFunctionManagedObjectClass> is equal to 1.3.12.2.1006.53.1.4.6.0.3
<aGprsGvcFunctionManagedObjectClass> is equal to 1.3.12.2.1006.53.1.4.2.0.3
<axIMeqpObjectClass> is equal to 0.3.0.2.3
<gsm1220objectClass> is equal to 0.4.0.0.3.20.0.3
<m3100ObjectClass> is equal to 0.0.13.3100.0.3
<nectarManagedObjectClass> is equal to 1.3.12.2.1006.64.3.1.0.3
3.1.3 The concerned Attributes
Attribute OID value AASCE Type
Attributes with the "AGFR" label
"AGFR":aGprsBearerChannelId <aGprsFrFunctionAttribute>.1 INTEGER
"AGFR":aGprsDlcId <aGprsFrFunctionAttribute>.4 INTEGER
Attributes with the "AGVC" label
"AGVC":aGprsNseId <aGprsGvcFunctionAttribute>.1 INTEGER
"AGVC":aGprsNsvcId <aGprsGvcFunctionAttribute>.3 INTEGER
"AGVC":aGprsSgsnIpEndpointId <aGprsGvcFunctionAttribute>.3
1
INTEGER
Attributes with the "NMD" label
NMD:neGroupId <axIMeqpAttribute>.7 INTEGER
NMD:neSupervisionCoordinator
Id
<axIMeqpAttribute>.9 INTEGER
NMD":networkElementId <axIMeqpAttribute>.13 INTEGER

ED 01 RELEASED

9829m1re.doc
24/09/2008


A
l
l

r
i
g
h
t
s

r
e
s
e
r
v
e
d
.

P
a
s
s
i
n
g

o
n

a
n
d

c
o
p
y
i
n
g

o
f

t
h
i
s

d
o
c
u
m
e
n
t
,

u
s
e

a
n
d

c
o
m
m
u
n
i
c
a
t
i
o
n

o
f

i
t
s

c
o
n
t
e
n
t
s

n
o
t

p
e
r
m
i
t
t
e
d

w
i
t
h
o
u
t

w
r
i
t
t
e
n

a
u
t
h
o
r
i
z
a
t
i
o
n

f
r
o
m

A
l
c
a
t
e
l
.

Attribute with the "ALM" label
ALM:accessControlDomain <axTempAliasAttribute>.0 String
Attributes with the "EML" label
EML:aFunctionCoordinatorId <mdrAlcatelAttribute>.1097 INTEGER
EML:functionId <mdrAlcatelAttribute>.1098 INTEGER
Attribute with the "GSM 12.00" label
"GSM 12.00":bssFunctionId <gsm1200Aattribute>.20 INTEGER
Attributes with the "GSM 12.20" label
GSM 12.20:baseBandTransceiv
erID
<gsm1220attribute>.40 INTEGER
GSM 12.20:bscID <gsm1220attribute>.70 INTEGER
GSM 12.20:btsID <gsm1220attribute>.100 INTEGER
GSM 12.20:btsSiteManagerID <gsm1220attribute>.110 INTEGER
GSM 12.20:lapdLinkID <gsm1220attribute>.410 INTEGER
Attributes with the "Q.751.1" label
Q.751.1:mtpSignPointId <mtpAttribute>.47 INTEGER
Q.751.1:signLinkSetTpId <mtpAttribute>.91 INTEGER
Q.751.1:slCode <mtpAttribute>.104 INTEGER
Attributes with the "M.3100" label
M.3100:alarmStatus <m3100Attribute>.6 AlarmStatus
M.3100:equipmentId <m3100Attribute>.20 StringOrInteger
M.3100:fabricId <m3100Attribute>.22 INTEGER
M.3100:managedElementComp
lexId
<m3100Attribute>.68 INTEGER
M.3100:userLabel <m3100Attribute>.50 UserLabel
"M.3100":tTPId <m3100Attribute>.48 INTEGER
Attributes with the "X.721" label
X.721:administrativeState <smi2AttributeID>.31 AdministrativeState
X.721:availabilityStatus <smi2AttributeID>.33 AvailabilityStatus
X.721:controlStatus <smi2AttributeID>.34 ControlStatus
X.721:operationalState <smi2AttributeID>.35 OperationalState
X.721:unknownStatus <smi2AttributeID>.38 UnknownStatus
X721:proceduralStatus <smi2AttributeID>.36 ProceduralStatus
Table 5: OID values and AASCE types for attributes in alarms export files
where:
<aGprsFrFunctionAttribute> is equal to 1.3.12.2.1006.53.1.4.6.0.7
<aGprsGvcFunctionAttribute> is equal to 1.3.12.2.1006.53.1.4.2.0.7
<axIMeqpAttribute> is equal to 0.3.0.2.7
<axTempAliasAttribute> is equal to 1.3.12.2.1006.63.0.5.7
<gsm1200Aattribute> is equal to 0.4.0.0.3.0.0.0.7
<gsm1220attribute> is equal to 0.4.0.0.3.20.0.7
<m3100Attribute> is equal to 0.0.13.3100.0.7
<mdrAlcatelAttribute> is equal to 1.3.12.2.1006.53.1.2.0.7
<mtpAttribute> is equal to 0.0.17.751.1.0.7
<smi2AttributeID> is equal to 2.9.3.2.7

ED 01 RELEASED

9829m1re.doc
24/09/2008


A
l
l

r
i
g
h
t
s

r
e
s
e
r
v
e
d
.

P
a
s
s
i
n
g

o
n

a
n
d

c
o
p
y
i
n
g

o
f

t
h
i
s

d
o
c
u
m
e
n
t
,

u
s
e

a
n
d

c
o
m
m
u
n
i
c
a
t
i
o
n

o
f

i
t
s

c
o
n
t
e
n
t
s

n
o
t

p
e
r
m
i
t
t
e
d

w
i
t
h
o
u
t

w
r
i
t
t
e
n

a
u
t
h
o
r
i
z
a
t
i
o
n

f
r
o
m

A
l
c
a
t
e
l
.

3.2 State changes export files
3.2.1 The concerned parameters
The table below lists the state change parameters in alphabetical order and, for each of
them:
its corresponding AASCE type (see section 2.4.3);
its description;
a valid value for that parameter.

ADMINSTATE AdministrativeState Current administrative state unlocked (1)
AVAILSTATE AvailabilityStatus Current availability status failed (1)
FRDNAME String Friendly name of the MO:
This parameter enables to
locate precisely the alarm.
ddu_bcv17x14
_bss12
MOI FDN Managed Object Instance.
object instance emitting the
notification. See chapter 3.2.2
for the possible values.
0.0.13.3100.0.
7.68#1/0.0.13.
3100.0.7.20#1
MOT String Type of the object on which the
state change has occurred.
BSC (GSM)
Possible values are:
TRX,
cell (GSM),
cell (GPRS),
BSC (GSM),
BSC (GPRS),
MFS,
N7

RA
OPERSTATE OperationalState Current operational state enabled (1)
STCHTIME Time Time at which the state change
occurred.
199912190808
23.0Z
UNKNSTATUS UnknownStatus Current unknown status (only for
BSC and MFS)
1
Table 6: The parameters in state changes export files
3.2.2 The MOCs corresponding to the MOT parameter values
The following tables indicate, for each MOT parameter value, the name of the corresponding
MOC to which the MO concerned with the state change belongs. For more information about
the MOC, refer to section 3.1.2.
MO Type Corresponding MOC
BSC-NE level
TRX "EML":alcatelBaseBandTransceiver
cell (GSM) "EML":alcatelBts-Sector
BSC (GSM) "EML":alcatelBssFunction

ED 01 RELEASED

9829m1re.doc
24/09/2008


A
l
l

r
i
g
h
t
s

r
e
s
e
r
v
e
d
.

P
a
s
s
i
n
g

o
n

a
n
d

c
o
p
y
i
n
g

o
f

t
h
i
s

d
o
c
u
m
e
n
t
,

u
s
e

a
n
d

c
o
m
m
u
n
i
c
a
t
i
o
n

o
f

i
t
s

c
o
n
t
e
n
t
s

n
o
t

p
e
r
m
i
t
t
e
d

w
i
t
h
o
u
t

w
r
i
t
t
e
n

a
u
t
h
o
r
i
z
a
t
i
o
n

f
r
o
m

A
l
c
a
t
e
l
.

N7 "EML":alcatelSignLinkN7
RA "EML":alcatelFunction
MFS-NE level
cell (GPRS) "ABSS":aGprsBts
BSC (GPRS) "ABSS":aGprsBssFunction
MFS "NMD":networkElement
Table 7: The MOCs corresponding to the MOT parameter values
3.3 AASCE type definitions
3.3.1 Introduction
Among the AASCE basic types (listed in section 2.4.3), two categories can be distinguished:
ASN1 simple types
These types are ASN1 simple types as defined in [ASN1].
String-related types
String and StringOrInteger are not defined using the ASN1 notation (see [ASN1]).
Instead, these types are defined only through the way values of these types are
represented (see section 2.4.3).
The subsequent session defines the other AASCE types. This is performed using the ASN.1
notation (see [ASN1]) except for the type definitions referring to one type of the second
category. The types thus defined (using the so-called pseudo ASN1 notation) are preceded
with a comment.
3.3.2 Corresponding definitions
AcknowledgementStatus ::= ENUMERATED {
unAcknowledged (0),
acknowledged (1)
}

AdditionalInformation ::= SET OF ManagementExtension

AdministrativeState ::= ENUMERATED {
locked (0),
unlocked (1),
shuttingDown (2)
}

AlarmStatus ::= ENUMERATED {
cleared (0) ,
indeterminate (1) ,
warning (2) ,
minor (3) ,
major (4) ,
critical (5) ,
activePending (6)
}

ED 01 RELEASED

9829m1re.doc
24/09/2008


A
l
l

r
i
g
h
t
s

r
e
s
e
r
v
e
d
.

P
a
s
s
i
n
g

o
n

a
n
d

c
o
p
y
i
n
g

o
f

t
h
i
s

d
o
c
u
m
e
n
t
,

u
s
e

a
n
d

c
o
m
m
u
n
i
c
a
t
i
o
n

o
f

i
t
s

c
o
n
t
e
n
t
s

n
o
t

p
e
r
m
i
t
t
e
d

w
i
t
h
o
u
t

w
r
i
t
t
e
n

a
u
t
h
o
r
i
z
a
t
i
o
n

f
r
o
m

A
l
c
a
t
e
l
.

ArchiveCause ::= ENUMERATED {
overflowPurge (0),
ackAndClear (1),
autoPurge (2),
manualPurge (3),
synchronization (4),
invalidation (5),
agentRemoval (6)
}

-- Pseudo ASN1 type definition
Attribute ::= SEQUENCE {
attributeId String, -- Name of the attribute
attributeValue ANY DEFINED BY attributeId
}

AttributeIdentifier ::= OBJECT IDENTIFIER

AvailabilityStatus ::= SET OF INTEGER {
inTest (0),
failed (1),
powerOff (2),
offLine (3),
offDuty (4),
dependency (5),
degraded (6),
notInstalled (7),
logFull (8)
}

ClearingStatus ::= ENUMERATED {
notCleared (0),
cleared (1)
}

ControlStatus ::= SET OF INTEGER {
subjectToTest (0),
partOfServicesLocked (1),
reservedForTest (2),
suspended (3)
}

ManagementExtension ::= SEQUENCE {
identifier String, -- See section 3.1.1
significance [1] String,
-- The possible values are significant and not significant
information [2] ANY DEFINED BY identifier -- See section 3.1.1
}

MonitoredAttributes ::= SET OF Attribute

OperationalState ::= ENUMERATED {
disabled (0),

ED 01 RELEASED

9829m1re.doc
24/09/2008


A
l
l

r
i
g
h
t
s

r
e
s
e
r
v
e
d
.

P
a
s
s
i
n
g

o
n

a
n
d

c
o
p
y
i
n
g

o
f

t
h
i
s

d
o
c
u
m
e
n
t
,

u
s
e

a
n
d

c
o
m
m
u
n
i
c
a
t
i
o
n

o
f

i
t
s

c
o
n
t
e
n
t
s

n
o
t

p
e
r
m
i
t
t
e
d

w
i
t
h
o
u
t

w
r
i
t
t
e
n

a
u
t
h
o
r
i
z
a
t
i
o
n

f
r
o
m

A
l
c
a
t
e
l
.

enabled (1)
}

PerceivedSeverity ::= ENUMERATED {
indeterminate (0),
critical (1),
major (2),
minor (3),
warning (4),
cleared (5)
}

ProceduralStatus ::= SET OF INTEGER {
initializationRequired (0) ,
notInitialized (1) ,
initializing (2) ,
reporting (3) ,
terminating (4)
}

SpecificPb ::= SET OF StringOrInteger -- See section 3.1.1

StateChange ::= SET OF SEQUENCE {
attributeID String, -- Name of the attribute
oldAttributeValue [1] ANY DEFINED BY attributeID OPTIONAL,
newAttributeValue [2] ANY DEFINED BY attributeID
}

UnknownStatus ::= BOOLEAN

UserLabel ::= GraphicString

ED 01 RELEASED

9829m1re.doc
24/09/2008


A
l
l

r
i
g
h
t
s

r
e
s
e
r
v
e
d
.

P
a
s
s
i
n
g

o
n

a
n
d

c
o
p
y
i
n
g

o
f

t
h
i
s

d
o
c
u
m
e
n
t
,

u
s
e

a
n
d

c
o
m
m
u
n
i
c
a
t
i
o
n

o
f

i
t
s

c
o
n
t
e
n
t
s

n
o
t

p
e
r
m
i
t
t
e
d

w
i
t
h
o
u
t

w
r
i
t
t
e
n

a
u
t
h
o
r
i
z
a
t
i
o
n

f
r
o
m

A
l
c
a
t
e
l
.

4. EXPORT MECHANISM
N.B.: The location and the name of the exported files are described in sections 2.1 and
2.2.
4.1 Historical alarm lists export sessions
Triggers/Input:
The historical alarm lists are exported on operator request by triggering a script that has
the following characteristics:
export_hal <date 1> [<date 2>]
where :
<date 1> is either the letter t (for today), the letter y (for yesterday) or a date of the
form YYYY-MM-DD.
<date 2> is any date of the form YYYY-MM-DD
Pre-conditions:
None
Output:
The scripts output is one compressed file made from all the historical alarm files (there
is one historical alarm file per day). This compressed file is put in the HALD directory
only when it is complete.
Description:
The script exports all the alarms that have been archived during <date 1> or
between <date 1> and <date 2>.
If no data was found for a given day, the corresponding historical alarm file is
created but contains the string no data available. This means either that no alarm
was put in the historical alarm list that day or that the data has been removed in
the meanwhile.
File cleanup:
The output file name is designed so that the file is overwritten each time the script is
triggered.
N.B.: It is the 9153 OMC-R operators responsability to synchronize the different
export requests in order to avoid any unexpected data removal.
Error/Warning handling:
Bad input parameters
4.2 Snapshot of current alarm list export sessions
Triggers/Input:
The current alarm list is periodically exported by the system.
Pre-condition:
None
Output:
The file containing the current alarm list is generated and, once completed, exported in
the directory SOCAD

ED 01 RELEASED

9829m1re.doc
24/09/2008


A
l
l

r
i
g
h
t
s

r
e
s
e
r
v
e
d
.

P
a
s
s
i
n
g

o
n

a
n
d

c
o
p
y
i
n
g

o
f

t
h
i
s

d
o
c
u
m
e
n
t
,

u
s
e

a
n
d

c
o
m
m
u
n
i
c
a
t
i
o
n

o
f

i
t
s

c
o
n
t
e
n
t
s

n
o
t

p
e
r
m
i
t
t
e
d

w
i
t
h
o
u
t

w
r
i
t
t
e
n

a
u
t
h
o
r
i
z
a
t
i
o
n

f
r
o
m

A
l
c
a
t
e
l
.

Description:
The current alarm list is exported every <currentAlarmListExportPeriod>.
The default value of <currentAlarmListExportPeriod> is 15 minutes.
N.B.: The <currentAlarmListExportPeriod> value is also used as the export period
for the 9153 OMC-R Alarm Call Out (ACO) feature defined in [ACOguide].
File cleanup:
The output file name is designed so that the file containing the current alarm list is
automatically overwritten when the newer version is exported.
None
4.3 State changes export sessions
Triggers/Input:
The state changes are exported automatically.
Pre-condition:
None
Output:
One state change file per day and per level of log (core BSS-NE and GPRS BSS-NE).
Description:
The state changes occurring on the concerned object instances (see section 3.2.2)
are logged in the corresponding state changes export files as soon as they occur.
These state change files are located in the directory SCD, so the latest status of
the files is always ready to be exported.
In order to avoid saturation of the disk space, the size of a state change file is
limited to 5 400 000 octets. If the maximum file size is reached, the string
overflow will be appended to the file and the new state changes will not be logged
for that day.
File cleanup:
Due to the way state changes export files are named (see section 2.2), a state change
file for a given BSS-NE is automatically overwritten after one week.
None

ED 01 RELEASED

9829m1re.doc
24/09/2008


A
l
l

r
i
g
h
t
s

r
e
s
e
r
v
e
d
.

P
a
s
s
i
n
g

o
n

a
n
d

c
o
p
y
i
n
g

o
f

t
h
i
s

d
o
c
u
m
e
n
t
,

u
s
e

a
n
d

c
o
m
m
u
n
i
c
a
t
i
o
n

o
f

i
t
s

c
o
n
t
e
n
t
s

n
o
t

p
e
r
m
i
t
t
e
d

w
i
t
h
o
u
t

w
r
i
t
t
e
n

a
u
t
h
o
r
i
z
a
t
i
o
n

f
r
o
m

A
l
c
a
t
e
l
.

5. ACRONYMS
AASCE Alcatel-Lucent 9153 OMC-R Alarm and State Change Export
ACO Alarm Call Out
AFTR Alcatel-Lucent 9153 OMC-R File Transfer Repository
AS Alarm Surveillance
AVA Attribute Value Assertion
BSC Base Station Controller
BSS Base Station Subsystem
CAL Current Alarm List
EML Equipment Management Layer
FDN Full Distinguish Name
GPRS General Packet Radio Service
GSM Global System for Mobile Communication
HAL Historical Alarm List
HALD Historical Alarm Lists Directory
HALE Historical Alarm List Export
LASER Logiciel dAnalyse Statistique des Evnements du Rseau
MFS Multi-BSS Fast packet Server (A9135 component)
MO Managed Object
MOC ManagedObject Class
MOI Managed Object Instance parameter
N.B.: MO is used instead of MOI to denote Managed Object instances
so as to avoid any confusion with this AASCE parameter.
NE Network Element
OID Object Identifier Description
RA Radio Access (function)
SCD State Changes Directory
SCE State Changes Export
SOCAD Snapshot Of Current Alarms Directory
SOCAE Snapshot Of Current Alarms Export
TRX Transceiver

END OF DOCUMENT

MAAAe 01

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

MAAAe 01

Caricato da

Copyright:

Formati disponibili

9153 OMC-R Alarm and State Change Export Interface - Release B11

Potrebbero piacerti anche