a1353-ra alarm and state change export interface ed02.pdf

A1353-RA Alarm and State Change Export Interface - Release B9 ED 02 RELEASED

Evolium 9829J2RE.WW6

31/03/2006 3BK 09829 JAAA PBZZA 1/1

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

not p

erm

itted

with

out w

ritte

n au

thor

izat

ion

from

Alc

atel

.

A1353-RA Alarm and State Change Export Interface

Release B9 onwards



31/03/2006 3BK 09829 JAAA PBZZA 1/26

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

not p

erm

itted

with

out w

ritte

n au

thor

izat

ion

from

Alc

atel

.

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 A1353-RA 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 .......................................................................... 19

3.2.1 The concerned parameters ................................................................... 19 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



31/03/2006 3BK 09829 JAAA PBZZA 2/26

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

not p

erm

itted

with

out w

ritte

n au

thor

izat

ion

from

Alc

atel

.

02 060331 Update O&M System TD/O&M/OMC3 Spec 01 040510 First issue O&M System TD/O&M/OMC3 Spec ED DATE CHANGE NOTE APPRAISAL AUTHORITY ORIGINATOR



31/03/2006 3BK 09829 JAAA PBZZA 3/26

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

not p

erm

itted

with

out w

ritte

n au

thor

izat

ion

from

Alc

atel

.

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

HISTORY

Ed. 01 − 04/05/2004: Creation from 3BK 09829 JAAA PBZZA Ed.01 Released

• General changes: − B8 is replaced by B9 − Core BSS-NE replaced by BSC-NE and GPRS BSS-NE replaced by MFS-NE

level whenever found clearer. Since purely editorial, the corresponding changes are note detailed hereafter.

• REFERENCED DOCUMENTS: [ACOguide]3BK number updated.

• INTRODUCTION Overview of the AASCE interface

The part on the SCE interface is updated. • SEMANTICS OF THE AASCE FILES

Historical and current alarms export files The concerned parameters

The example for PBCAUSE is aligned on implementation. State changes export files

The concerned parameters In the corresponding table, the MOT entry is updated to indicate the new possible value, namely "RA"

The MOCs corresponding to the MOT parameter values In the corresponding table, a RA entry is added to indicate that the corresponding MOC is "EML":alcatelFunction.

• ACRONYMS The RA accronym is defined.

− 10/05/2004: no technical changes. Ed. 02 − 10/03/2006:

• SEMANTICS OF THE AASCE FILES Historical and current alarms export files

The concerned parameters The new parameter “ALARMNB” is added.

− 31/03/2006: no technical changes.

REFERENCED DOCUMENTS



31/03/2006 3BK 09829 JAAA PBZZA 4/26

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

not p

erm

itted

with

out w

ritte

n au

thor

izat

ion

from

Alc

atel

.

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 Transfer Part (MTP) ITU-T Recommendation Q.751.1, October 1995

Alcatel documents

[ACOguide] Alarm Call Out User Guide 3BK 20917 AAAA PCZZA



31/03/2006 3BK 09829 JAAA PBZZA 5/26

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

not p

erm

itted

with

out w

ritte

n au

thor

izat

ion

from

Alc

atel

.

1. INTRODUCTION

1.1 Scope of the document

The A1353-RA provides several file-based interfaces to external applications. This document specifies the A1353-RA 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 A1353-RA 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 A1353-RA internal database for Alarm Surveillance (AS). There is one AS database per A1353-RA 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.



31/03/2006 3BK 09829 JAAA PBZZA 6/26

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

not p

erm

itted

with

out w

ritte

n au

thor

izat

ion

from

Alc

atel

.

The figure below sketches out these interfaces:

A1353 RA

completealarmhistoryexport

directoryCurrent/ Historical alarms

BSS-NE level state changes

GPRS BSS-NE level state changes

ASdatabase

Statechangesexport

directory

BSS-NE process

GPRS BSS-NEprocess

snapshotof the last

currentalarmsexport

directory

Current alarms

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.



31/03/2006 3BK 09829 JAAA PBZZA 7/26

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

not p

erm

itted

with

out w

ritte

n au

thor

izat

ion

from

Alc

atel

.

2. THE A1353-RA ALARM AND STATE CHANGE REPOSITORIES

2.1 Organization of the AASCE repository.

The A1353-RA has a file repository dedicated to file transfers to external clients: the A1353- RA File Transfer Repository (AFTR). The information required to reach this more general file repository is predefined at the installation of an A1353-RA instance.

At the A1353-RA 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



31/03/2006 3BK 09829 JAAA PBZZA 8/26

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

not p

erm

itted

with

out w

ritte

n au

thor

izat

ion

from

Alc

atel

.

− 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



31/03/2006 3BK 09829 JAAA PBZZA 9/26

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

not p

erm

itted

with

out w

ritte

n au

thor

izat

ion

from

Alc

atel

.

− <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 A1353-RA 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;[ARCHIVETIME;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;UNKNSTATUS;

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.



31/03/2006 3BK 09829 JAAA PBZZA 10/26

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

not p

erm

itted

with

out w

ritte

n au

thor

izat

ion

from

Alc

atel

.

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



31/03/2006 3BK 09829 JAAA PBZZA 11/26

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

not p

erm

itted

with

out w

ritte

n au

thor

izat

ion

from

Alc

atel

.

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 AdditionalInformation

Additional information This parameter contains at most 3 elements.

((alcatelAdditionalInformation,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:

“alcatelAdditionalInformation”

• 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,


“urlAddressOnAlarmDicti



31/03/2006 3BK 09829 JAAA PBZZA 12/26

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

not p

erm

itted

with

out w

ritte

n au

thor

izat

ion

from

Alc

atel

.

Parameter AASCE Type Description Example onary”

• the significance field contains the string:

“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,


“reservedForTest” • the significance field

contains the string: “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

ARCHIVETIME

Time Archiving time 19991202121931.0Z

ARCHIVECAUSE

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



31/03/2006 3BK 09829 JAAA PBZZA 13/26

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

not p

erm

itted

with

out w

ritte

n au

thor

izat

ion

from

Alc

atel

.

Parameter AASCE Type Description Example 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 This parameter identifies the 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.20#1/0.0.13.3100.0.7.20#1/0.0.13.3100.0.7.20#10

MONITOR MonitoredAttributes

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 A1353-RA security management.

((availabilityStatus,degraded ),(administrativeState,unlocked ),(operationalState,enabled ),(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 This parameter indicates the number of times the alarm has been sent by the MO.

0

SEV PerceivedSeverity

Perceived severity This parameter indicates the

major (2)



31/03/2006 3BK 09829 JAAA PBZZA 14/26

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

not p

erm

itted

with

out w

ritte

n au

thor

izat

ion

from

Alc

atel

.

Parameter AASCE Type Description Example perceived severity of the alarm (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,,degraded (6)))

USRNOTE String User note This parameter contains a free text that has been entered by an A1353-RA operator, if any. Otherwise, it is absent.

this is a user note

Table 2: The parameters in alarms export files



31/03/2006 3BK 09829 JAAA PBZZA 15/26

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

not p

erm

itted

with

out w

ritte

n au

thor

izat

ion

from

Alc

atel

.

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



31/03/2006 3BK 09829 JAAA PBZZA 16/26

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

not p

erm

itted

with

out w

ritte

n au

thor

izat

ion

from

Alc

atel

.

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” :alcatelBaseBandTransceiver

<mdrAlcatelManagedObjectClass>.1002

“GSM 12.20”:baseBandTransceiverID

“ EML” :alcatelBsc <mdrAlcatelManagedObjectClass>.1003

“GSM 12.20”:bscID

“EML”:alcatelBssFunction <mdrAlcatelManagedObjectClass>.1004

"GSM 12.00":bssFunctionId

“ EML” :alcatelBts-Sector <mdrAlcatelManagedObjectClass>.1005

“GSM 12.20”:btsID

“ EML” :alcatelBtsSiteManager


“GSM 12.20”:btsSiteManagerID

“ EML” :alcatelCircuitPack <mdrAlcatelManagedObjectClass>.1013

“M.3100”:equipmentId

“ EML” :alcatelFunction <mdrAlcatelManagedObjectClass>.1026

“EML”:functionId

“EML”:alcatelFunctionCoordinator


“EML”:aFuntionCoordinatorId

“ EML” :alcatelManagedElement


“M.3100”:equipmentId

“EML”:alcatelManagedElementComplex


“M.3100”:managedElementComplexId

“ EML” :alcatelSignLinkN7 <mdrAlcatelManagedObjectClass>.1021

“Q.751.1”:slCode

“ EML” :alcatelSignLinkSetTp


“Q.751.1”:signLinkSetTpId

“M.3100”:equipmentHolder <m3100ObjectClass>.32 “M.3100”:equipmentId

“Q.751.1”:mtpSignPoint <mtpObjectClass>.6 “Q.751.1”:mtpSignPointId

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:



31/03/2006 3BK 09829 JAAA PBZZA 17/26

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

not p

erm

itted

with

out w

ritte

n au

thor

izat

ion

from

Alc

atel

.

"NMD":neGroup

"NMD" :networkElement

"NMD" : neSupervisionCoordinator

"AS": activeProblemTable

"NMD": alarmSynthesis

"ABSS" : aGprsBssFunction

"AMFSME" : aGprs2MbTTP

"AGVC": aGprsNse

"M.3100" : equipmentHolder

"ABSS": aGprsBtsSiteManager

"AGFR": aGprsBearerChannel

"AGVC" : aGprsNsvc


"ABSS" : aGprsBts

"AGFR": aGprsPvc

"AATER" : aGprsLapdLink

"M.3100" :circuitPack

"LAPF" : nectarCircuitPack


"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” :aGprsBearerChannel

<aGprsFrFunctionManagedObjectClass>.1

"AGFR":aGprsBearerChannelId

“ ABSS” :aGprsBssFunction <agBssManagedObjectClass>.1 "GSM 12.00":bssFunctionId

“ ABSS” :aGprsBts <agBssManagedObjectClass>.2 "GSM 12.20":btsID “ABSS”:aGprsBtsSiteManager

<agBssManagedObjectClass>.7 "GSM 12.20":btsSiteManagerID

“ AATER” :aGprsLapdLink <aGprsAterManagedObjectClass>.2

"A12.20":lapdLinkID

“AGVC":aGprsNse <aGprsGvcFunctionManagedObjectClass>.1

"AGVC":aGprsNseId



31/03/2006 3BK 09829 JAAA PBZZA 18/26

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

not p

erm

itted

with

out w

ritte

n au

thor

izat

ion

from

Alc

atel

.

“ AGVC” :aGprsNsvc <aGprsGvcFunctionManagedObjectClass>.2

"AGVC":aGprsNsvcId

“ AGFR” :aGprsPvc <aGprsFrFunctionManagedObjectClass>.2

"AGFR":aGprsDlcId

“ M.3100” :circuitPack <m3100ObjectClass>.30 "M.3100":equipmentId

“ M.3100” :equipmentHolder <m3100ObjectClass>.32 "M.3100":equipmentId

“ LAPF” :nectarCircuitPack <nectarManagedObjectClass>.1 "M.3100":equipmentId

“NMD”:neGroup <axIMeqpObjectClass>.4 “NMD”:neGroupId “ NMD” :neSupervisionCoordinator

<axIMeqpObjectClass>.5 “NMD”:neSupervisionCoordinatorId

“ NMD” :networkElement <axIMeqpObjectClass>.10 "NMD":networkElementId

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

Attributes with the "NMD" label “NMD”:neGroupId <axIMeqpAttribute>.7 INTEGER “NMD”:neSupervisionCoordinatorId

<axIMeqpAttribute>.9 INTEGER

“NMD":networkElementId <axIMeqpAttribute>.13 INTEGER Attribute with the "ALM" label

“ALM”:accessControlDomain <axTempAliasAttribute>.0 String Attributes with the "EML" label



31/03/2006 3BK 09829 JAAA PBZZA 19/26

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

not p

erm

itted

with

out w

ritte

n au

thor

izat

ion

from

Alc

atel

.

“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”:baseBandTransceiverID

<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”:managedElementComplexId

<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

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);



31/03/2006 3BK 09829 JAAA PBZZA 20/26

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

not p

erm

itted

with

out w

ritte

n au

thor

izat

ion

from

Alc

atel

.

− its description; − a valid value for that parameter. Parameter AASCE Type Description Example 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. This parameter identifies the 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. 19991219080823.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 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



31/03/2006 3BK 09829 JAAA PBZZA 21/26

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

not p

erm

itted

with

out w

ritte

n au

thor

izat

ion

from

Alc

atel

.

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)

} ArchiveCause ::= ENUMERATED {

overflowPurge (0), ackAndClear (1), autoPurge (2), manualPurge (3), synchronization (4), invalidation (5), agentRemoval (6)

}



31/03/2006 3BK 09829 JAAA PBZZA 22/26

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

not p

erm

itted

with

out w

ritte

n au

thor

izat

ion

from

Alc

atel

.

-- 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)

} -- Pseudo ASN1 type definition 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), enabled (1)

} PerceivedSeverity ::= ENUMERATED {

indeterminate (0), critical (1), major (2), minor (3),



31/03/2006 3BK 09829 JAAA PBZZA 23/26

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

not p

erm

itted

with

out w

ritte

n au

thor

izat

ion

from

Alc

atel

.

warning (4), cleared (5)

} ProceduralStatus ::= SET OF INTEGER {

initializationRequired (0) , notInitialized (1) , initializing (2) , reporting (3) , terminating (4)

} -- Pseudo ASN1 type definition SpecificPb ::= SET OF StringOrInteger -- See section 3.1.1 -- Pseudo ASN1 type definition 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



31/03/2006 3BK 09829 JAAA PBZZA 24/26

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

not p

erm

itted

with

out w

ritte

n au

thor

izat

ion

from

Alc

atel

.

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 script’s 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 A1353-RA operator’s 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:



31/03/2006 3BK 09829 JAAA PBZZA 25/26

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

not p

erm

itted

with

out w

ritte

n au

thor

izat

ion

from

Alc

atel

.

The file containing the current alarm list is generated and, once completed, exported in the directory “SOCAD”

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 A1353-RA 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.

Error/Warning handling: 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.

Error/Warning handling: None



31/03/2006 3BK 09829 JAAA PBZZA 26/26

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

not p

erm

itted

with

out w

ritte

n au

thor

izat

ion

from

Alc

atel

.

5. ACRONYMS

AASCE A1353-RA Alarm and State Change Export ACO Alarm Call Out AFTR A1353-RA 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 d’Analyse Statistique des Evènements du Réseau 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

a1353-ra alarm and state change export interface ed02.pdf

Documents

aasce files

aasce interface

aasce repository

corresponding naming

naming attributes

state changes export

a1353ra alarm

current alarms export