You are on page 1of 36

All rights reserved.

Passing on and copying of this


document, use and communication of its contents
not permitted without written authorization from Alcatel.

Profile for the NMC/9153 OMC-R Q3 Interface


Release B11

Profile for the NMC/9153 OMC-R Q3 Interface


ED

02

Released
9654m21r.doc
09/04/2010

3BK 09654 MAAA PBZZA

1/ 2

All rights reserved. Passing on and copying of this


document, use and communication of its contents
not permitted without written authorization from Alcatel.

SYSTEM FUNCTIONAL BLOCKS

TABLE OF CONTENTS
1.

INTRODUCTION...............................................................................................6
1.1
The requirements...................................................................................6
1.2
Presentation of the A1353-RA external interfaces ..............................6
1.3
Scope of the document .........................................................................7
1.4
Common Conventions...........................................................................8
1.5
Configuration Parameters.....................................................................8

2.

NMC/A1353-RA Q3 INFORMATION MODEL PRESENTATION ...................10


2.1
Information model policy ....................................................................10
2.2
Splitting into fragments.......................................................................11
2.2.1
Introduction..................................................................................11
2.2.2
The Common Fragment ..............................................................12
2.2.3
The Transmission Fragment........................................................14
2.2.4
The Equipment Fragment............................................................15
2.2.5
The bssFunction Fragment..........................................................15
2.3
Naming Tree .........................................................................................17
2.3.1
Conventions.................................................................................17
2.3.2
General Naming Tree ..................................................................17
2.3.3
Complement for GPRS Alarms Reporting ...................................19
2.4
Inheritance hierarchy ..........................................................................19
2.4.1
X.721-related part........................................................................19
2.4.2
M.3100-related part .....................................................................20
2.4.3
Q.751.1-related part ....................................................................20
2.4.4
GSM 12.00-related part ...............................................................20
2.4.5
GSM 12.20-related part ...............................................................21

3.

THE Q3 PROCOCOL .....................................................................................22

4.

SUPPORTED SERVICES...............................................................................23
4.1
Configuration Management ................................................................23
4.1.1
Services supported at the NMC/A1353-RA interface ..................23
4.1.2
Services supported at other A1353-RA external interfaces .........24
4.1.3
Date and time management ........................................................24
4.2
Fault management ...............................................................................25
4.2.1
Introduction..................................................................................25
4.2.2
State Management ......................................................................25
4.2.3
Alarm Reporting & Acknowledgement .........................................25
4.2.3.1
4.2.3.2
4.2.3.3

4.3

Introduction.....................................................................................................25
Main fields of an alarm message ....................................................................26
Relationship attributes ....................................................................................28

Event Report Management and Log Control .....................................28


4.3.1
Introduction..................................................................................28
Profile for the NMC/9153 OMC-R Q3 Interface

ED

02

Released
9654m21r.doc
09/04/2010

3BK 09654 MAAA PBZZA

1/35

All rights reserved. Passing on and copying of this


document, use and communication of its contents
not permitted without written authorization from Alcatel.

4.3.2
4.3.3
5.
5.1
5.2
5.3

Event Report Management..........................................................28


Log Control ..................................................................................29

A1353-RA/NMC SYSTEM RELATIONSHIPS.................................................31


Consistency of the NMC, A1353-RA and BSS databases.................31
The ANOI:associationSurvey notification ......................................32
NMC resynchronisation.......................................................................32
5.3.1
The contexts in which a NMC resynchonisation is required ........32
5.3.1.1
5.3.1.2
5.3.1.3
5.3.1.4

5.3.2
5.3.3
6.
02
01
ED

NMC start up ..................................................................................................32


A1353-RA initialization..................................................................................32
BSS-NE creation and initialization.................................................................33
Upon detection of a problem by a NMC.........................................................33

Configuration resynchronisation ..................................................33


Alarm resynchronisation ..............................................................33

ACRONYMS ...................................................................................................35
YYMMDD
090515
DATE

Update
First issue
CHANGE NOTE

O&M System
O&M System
APPRAISAL AUTHORITY

TD/MRC/OMD Spec
TD/MRC/OMD Spec
ORIGINATOR

Profile for the NMC/9153 OMC-R Q3 Interface


ED

02

Released
9654m21r.doc
09/04/2010

3BK 09654 MAAA PBZZA

2/35

All rights reserved. Passing on and copying of this


document, use and communication of its contents
not permitted without written authorization from Alcatel.

LIST OF FIGURES AND TABLES


Figure 1: The 9153 OMC-R external interfaces .................................................................... 7
Figure 2: NMC/9153 OMC-R Q3 versus standard information models................................ 10
Figure 3: The 9153 OMC-R instance and the sub-network managed by it.......................... 11
Figure 4: General Naming Tree for the NMC/9153 OMC-R Q3 Interface Information Model18
Figure 5: Complement to the Naming Tree for GPRS Alarms Reporting ............................ 19
Figure 6: Inheritance hierarchy (X.721-related part) ........................................................... 19
Figure 7: Inheritance hierarchy (M.3100-related part) ......................................................... 20
Figure 8: Inheritance hierarchy (Q.751.1-related part) ........................................................ 20
Figure 9: Inheritance hierarchy (GSM 12.00-related part)................................................... 20
Figure 10: Inheritance hierarchy (GSM 12.20-related part) ................................................. 21
Table 1: Common conventions ............................................................................................. 8
Table 2: Configuration Parameters ....................................................................................... 9
Table 3: MOCs of the Common fragment ........................................................................... 14
Table 4: MOCs of the Transmission fragment .................................................................... 14
Table 5: MOCs of the Equipment fragment ........................................................................ 15
Table 6: MOCs of the bssFunction fragment ...................................................................... 16
Table 7: Main fields of an alarm message .......................................................................... 28

HISTORY
Ed. 01

29/04/2009: Creation from 3BK 09654 LAAA PBZZA Ed.02 Released.

General Changes

B10 is replaced by B11

The REFERENCED DOCUMENTS part is updated for B11 together with the
corresponding references in the body of the document.

NMC/9153 OMC-R Q3 INFORMATION MODEL PRESENTATION


Naming Tree
Complement for GPRS Alarms Reporting
"AMFSME":aGprsFabric is added.

15/05/2009: No technical changes.


Ed. 02

10/03/2010

General Changes

Introducing ExNe Q3 integration

NMC/9153 OMC-R Q3 INFORMATION MODEL PRESENTATION


Naming Tree
Complement for GPRS Alarms Reporting
"ANOI":anoiSNMPManagedElement is added.

REFERENCED DOCUMENTS
Standards
[ISO/IEC 8802-2]

Information technology - Telecommunications and information


exchange between systems - Local and metropolitan area networks Specific requirements - Part 2: Logical Link Control
Recommendation ISO/IEC 8802-2, 1994

Profile for the NMC/9153 OMC-R Q3 Interface


ED

02

Released
9654m21r.doc
09/04/2010

3BK 09654 MAAA PBZZA

3/35

All rights reserved. Passing on and copying of this


document, use and communication of its contents
not permitted without written authorization from Alcatel.

[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

[X.730]

Information Technology - Open Systems Interconnection - Systems


Management:
Object Management Function
CCITT Rec. X.730 (ISO/IEC 10164-1), 1992

[X.731]

Information Technology - Open Systems Interconnection - Systems


Management:
State Management Function
CCITT Rec. X.731 (ISO/IEC 10164-2), 1992

[X.733]

Information Technology - Open Systems Interconnection - Systems


Management:
Alarm Reporting Function
CCITT Rec. X.733 (ISO/IEC 10164-4), 1992

[X.734]

Information Technology - Open Systems Interconnection - Systems


Management:
Event Report Management Function
CCITT Recommendation X.734 (ISO/IEC 10164-5), 1992

[X.735]

Information Technology - Open Systems Interconnection - Systems


Management:
Log Control Function
CCITT Recommendation X.735 (ISO/IEC 10164-6), 1992

[M.3100]

Maintenance: Telecommunications Management Network - Generic


Network Information Model;
CCITT Recommendation M.3100, July 1995

[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

[Q.811]

Specifications of Signalling System No. 7 - Q3 interface


Lower layer protocol profiles for the Q3 and X interfaces
ITU-T Recommendation Q.811, June 1997

[Q.812]

Specifications of Signalling System No. 7 - Q3 interface


Upper Layer protocol profiles for the Q3 and X interfaces
ITU-T Recommendation Q.812, June 1997

[GSM12.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
Profile for the NMC/9153 OMC-R Q3 Interface

ED

02

Released
9654m21r.doc
09/04/2010

3BK 09654 MAAA PBZZA

4/35

All rights reserved. Passing on and copying of this


document, use and communication of its contents
not permitted without written authorization from Alcatel.

[GSM12.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
Alcatel-Lucent documents

[ANOIgdmo]

NMC/9153 OMC-R Q3 Interface: GDMO Formal Specification


3BK 09707 MAAA PBZZA

[ANOIappli]

NMC/9153 OMC-R Q3 Interface: Position with respect to standards of


the GDMO Formal Specification
3BK 09708 MAAA PBZZA

[ANOIcs-gene]

NMC/9153 OMC-R Q3 Interface:


Statements
3BK 09709 MAAA PBZZA

[ANOIcs-Q3P]

NMC/9153 OMC-R Q3
Statements
3BK 09772 MAAA PBZZA

[ACIE-gene]

9153 OMC-R Configuration Import/Export interface


For Release B11:
3BK 09661 MAAA PBZZA

[ACIE-si]

9153 OMC-R Configuration Import/Export Interface: Supplementary


Information
For Release B11:
3BK 09773 MAAA PBZZA

[ANIE]

9153 OMC-R Import/Export Interface for client nodeIdentifier values


For Release B10 (onward):
3BK 09797 LAAA PBZZA

Interface:

Overview and Conformance

Q3

Protocol

Conformance

RELATED DOCUMENTS
[ASN1]

Information Processing Systems - Open Systems Interconnection Specification of Abstract Syntax Notation One (ASN.1)
CCITT Rec. X.208 (1988) | ISO/IEC 8824

[GDMO]

Information Technology - Open Systems Interconnection- Structure of


Management Information:
Guidelines for the Definition of Management Information
CCITT Recommendation X.722 (ISO/IEC 10165-4), 1992

Profile for the NMC/9153 OMC-R Q3 Interface


ED

02

Released
9654m21r.doc
09/04/2010

3BK 09654 MAAA PBZZA

5/35

All rights reserved. Passing on and copying of this


document, use and communication of its contents
not permitted without written authorization from Alcatel.

1. INTRODUCTION
1.1 The requirements
The intention is to enable network information exchange from the 9153 OMC-R to a NMC in
an interactive, reliable and efficient way while hiding network complexity and supporting an
homogeneous equipment management.
This should operate in multi-vendor context and must be as 9153 OMC-R release
independent as possible in order to avoid the development of NMC proxies for each 9153
OMC-R evolution.
Part of these requirements lead to choose an interface based on a normalised model and
the Q3 protocol.
Advantages and disadvantages of a Q3 interface are well known:

A Q3 interface is well-suited for real time TMN supervision and control thanks to
spontaneous and self routing events which allow an upper layer to be warned about
changes in alarms situations, attribute values, states, creations and deletions.

The major disadvantage remains weaknesses for functional areas concerned with a
large amount of data, such as the configuration, performance and trace management
functional areas.
This aspect is especially important for the 9153 OMC-R since the number of objects
handled by this new Alcatel OMC-R is great and could increase; in particular, the 9153
OMC-R manages up to 3600 cells.
As a consequence, the strategy adopted by the 9153 OMC-R is as follows:

Take the best of a Q3 interface for network supervision, relying on an information


model based on standards, especially [GSM12.20] and [M.3100].

Avoid the disadvantages of a Q3 interface for the aforementioned areas by using


interfaces based on ASCII file transfer instead.

1.2 Presentation of the 9153 OMC-R external interfaces


The 9153 OMC-R has several external interfaces:

The NMC/9153 OMC-R Q3 interface


This interface enables to answer the set of network supervision requirements.
In particular, all events concerning network resources can be notified in real time
through resources alarm, state change, attribute value change, create and delete
notifications.
To one 9153 OMC-R instance can be connected one primary NMC and a number
(possibly equal to 0) of secondary NMCs. See [ANOIcs-Q3P] for more information on
that issue.

The other 9153 OMC-R external interfaces


These interfaces are based on ASCII files which can be transferred (i.e. exported and
possibly imported) using either FTAM or FTP. They are distinguished according to the
domain they are concerned with (e.g. configuration management, performance
management, ....).

Profile for the NMC/9153 OMC-R Q3 Interface


ED

02

Released
9654m21r.doc
09/04/2010

3BK 09654 MAAA PBZZA

6/35

All rights reserved. Passing on and copying of this


document, use and communication of its contents
not permitted without written authorization from Alcatel.

An example of such an interface is the 9153 OMC-R Configuration Import/Export


(ACIE) interface. This interface enables to:

Import whole or part of the 9153 OMC-R Radio Network Level (externally
accessible) configuration data.

Export whole (or part for an external application other than a NMC) of the 9153
OMC-R (externally accessible) configuration data either at Network Level or for a
given BSS-NE.
In addition, the corresponding export sessions can be requested and the
associated file transfer controlled through the NMC/9153 OMC-R Q3 interface.
This interface is specified in:

[ACIE-gene] for the issues that are not release-dependent,

dedicated documents for the (release-dependent) supplementary information,


notably [ACIE-si].
This can be pictured as follows:
9153 OMC-R

Import files
transfer

Radio Network Level

File-based
External
Interfaces

Export files
transfer

File upload
control

BSS-NE Level

Q3
External
Interface

NMCs

CMIS operation
requests
CMIS operation
responses

Figure 1: The 9153 OMC-R external interfaces

1.3 Scope of the document


This document deals with the NMC/9153 OMC-R Q3 Interface.
It is a high level specification of this Q3 interface which presents notably the corresponding
information model and the supported services.
In particular, it introduces the more technical GDMO-related documents specifying precisely
the NMC/9153 OMC-R Q3 Information model. These documents are the following:

[ANOIgdmo] for the GDMO Formal Specification.

Profile for the NMC/9153 OMC-R Q3 Interface


ED

02

Released
9654m21r.doc
09/04/2010

3BK 09654 MAAA PBZZA

7/35

All rights reserved. Passing on and copying of this


document, use and communication of its contents
not permitted without written authorization from Alcatel.

[ANOIappli] for the position with respect to standards of this GDMO Formal
Specification.

[ANOIcs-gene] for an overview of the information model and the related Conformance
Statements, i.e. peculiarities with respect to the GDMO Formal Specification that apply
to the objects of the instantiable Managed Object Classes. In particular, it describes, for
each instantiable Managed Object Classes, which of the applicable packages are
actually instantiated and the corresponding list of attributes/actions/notifications with
noticeable issues with respect to the latter.

In addition, Conformance Statements concerning the Q3 Protocol are specified in [ANOIcsQ3P].

1.4 Common Conventions


The following conventions are used hereafter:
CONVENTION

SEMANTICS
Light grey is used to highlight items that are conditionally
instantiated, conditionally present or conditionally relevant
Dark grey is used to highlight items that are never
instantiated, never present, not supported or not
applicable
Table 1: Common conventions

1.5 Configuration Parameters


There are two configuration parameters whose values is assigned at 9153 OMC-R
installation time (from a NMC viewpoint).
The following table indicates how these parameters are denoted hereafter and their
description:
NOTATION
DESCRIPTION
STD_SYSTEM_BOI
Configuration parameter specific to the NMC/9153 OMC-R
Q3 interface.
When it is equal to '0' (which is its default value), the
behaviour of GET/SET and DELETE requests with BOI
<syst_Id> or <syst_Id>.log are as close as possible to the
behaviour in B7. Otherwise, their behaviour is different in
that it is closer to standards.
ALARM_ACKNOWLEDGEMENT
Configuration parameter specific to the NMC/9153 OMC-R
Q3 interface.
When it is equal to '0' (which is its default value), none of
the peculiarities introduced in B9 to support alarm
acknowledgement is accurate. Otherwise, alarm
acknowledgement is supported (with the associated
peculiarities specified hereafter).
PLMN_ELEMENT_BINDING_O Configuration parameter specific to the NMC/9153 OMC-R
ID
Q3 interface.
When it is equal to the string 0.0.13.3100.0.6.0.15 then
the Name Binding `M.3100`:managedElement-network
(which is its default value) is used . Otherwise, when it is
Profile for the NMC/9153 OMC-R Q3 Interface
ED

02

Released
9654m21r.doc
09/04/2010

3BK 09654 MAAA PBZZA

8/35

All rights reserved. Passing on and copying of this


document, use and communication of its contents
not permitted without written authorization from Alcatel.

NOTATION

DESCRIPTION
equal to the string 1.3.12.2.1006.53.1.3.0.6.4015 then the
Name Binding `ANOI`:anoi-managedElement-network is
supported.
Configuration parameter specific to the NMC/9153 OMC-R
Q3 interface.
When it s equal with False the alarms coming from
External Ne are not forward to NMC. Otherwise, when it is
equal with True forwards External Ne alarms.

EX_NE_ALARMS

Table 2: Configuration Parameters

Profile for the NMC/9153 OMC-R Q3 Interface


ED

02

Released
9654m21r.doc
09/04/2010

3BK 09654 MAAA PBZZA

9/35

All rights reserved. Passing on and copying of this


document, use and communication of its contents
not permitted without written authorization from Alcatel.

2. NMC/9153 OMC-R Q3 INFORMATION MODEL PRESENTATION


2.1 Information model policy
Broadly speaking, the NMC/9153 OMC-R Q3 information model provides a supervision
management view of the 9153 OMC-R internal information model.
This NMC/9153 OMC-R Q3 information model

is based on up to date releases of the concerned standards (e.g. 1995 version of


M.3100, 1996 version of GSM 12.20) in order to get an interface that is as stable as
possible and as independent as possible of the 9153 OMC-R releases;

takes only the supervision part of these standards, i.e. the managed objects at the
NMC/9153 OMC-R Q3 interface contain identification, state, status and relationship
attributes but do not include configuration-related attributes.

completes the supervision part of these standards whenever appropriate (through


proprietary specializations of standard Managed Object Classes).
This can be sketched out as follows:

Supervision

Supervision

Configuration

Standard
Information Model

NMC/9153 OMC-R Q3
Information Model

Figure 2: NMC/9153 OMC-R Q3 versus standard information models


Moreover, the NMC/9153 OMC-R Q3 information model is cleanly defined over standards.
Since, in a (significant) number of standard Managed Object Classes, the configurationrelated attributes are contained in mandatory packages, this policy implies to replace them
by similar Managed Object Classes from a supervision viewpoint but defined as proprietary
(with a dedicated registration node).
N.B.:

The GDMO label used for the resulting proprietary part of the NMC/9153 OMC-R
Q3 information model is ANOI. Besides, the names of GDMO definitions that
have a standard counterpart are prefixed with anoi so as to avoid any potential
Profile for the NMC/9153 OMC-R Q3 Interface

ED

02

Released
9654m21r.doc
09/04/2010

3BK 09654 MAAA PBZZA

10/35

All rights reserved. Passing on and copying of this


document, use and communication of its contents
not permitted without written authorization from Alcatel.

name clashes for post-processing tools that do not take into account GDMO
labels.

2.2 Splitting into fragments


2.2.1 Introduction

9153 OMC-R instance

9153 OMC-R managed sub-network


DCN

A9135 managed
sub-network
GPRS BSS-NE

A9135 managed
sub-network
GPRS BSS-NE

BSC
BSC
BTS
BTS
BTS

BSC

BTS
BTS
BTS
(Core) BSS-NE
BTS
BTS
BTS
(Core) BSS-NE
(Core) BSS-NE

The GPRS-specific part

The core part

Figure 3: The 9153 OMC-R instance and the sub-network managed by it


A 9153 OMC-R instance and the sub-network managed by it can be split into three main
parts:

The common part made of the components supporting a number of common functions,
notably Event Report management, Log control, Object Management and File Transfer
Control.

The core part made of core BSS-NEs, a core BSS-NE (sometimes called BSS-NE for
short) consisting of a BSC equipment and the sub-network managed by that
equipment).
For this part, the services to be supported are:

A complete supervision view on equipment (down to board).


Profile for the NMC/9153 OMC-R Q3 Interface

ED

02

Released
9654m21r.doc
09/04/2010

3BK 09654 MAAA PBZZA

11/35

A traffic supervision and a possibility of 2Mbits topology discovery


A traffic supervision independent from the equipment maintenance.

All rights reserved. Passing on and copying of this


document, use and communication of its contents
not permitted without written authorization from Alcatel.

The GPRS-specific part made of GPRS BSS-NEs, a GPRS BSS-NE consisting of an


9130 BSC/MFS Evolution equipment (also called MFS which stands for Multi-BSS Fast
packet Server) and the sub-network managed by that equipment.
This part being not yet standardized, supporting the same level of supervision as for
the core part would have lead to add fully proprietary features in the model, which is not
in line with the aforementioned information model policy. As a consequence, only
overall supervision of the corresponding alarms is supported.

This leads to an information model that can be splitted into the following fragments:

A common fragment based on [X.721] and [GSM12.00] to model the common part.

A transmission fragment based on [M.3100] and [Q.751.1] which supports Managed


Object Classes to represent the different types of connections and termination points.

An equipment fragment based on [M.3100] which supports Managed Object Classes


to represent the equipments.
This is in conformance with [GSM12.20], which refers to [M.3100] for equipment
management.

A bssFunction fragment based on [GSM12.20] which supports Managed Object


Classes to model the functionalities of the corresponding equipments.
This fragment supports QoS alarms and enables traffic surveillance independently from
equipment supervision.
Given that only overall supervision is supported for the GPRS-specific part, the last three
fragments only concern the core part.
N.B.:

In what follows, the expression 'Abstract Class' is used to qualify a Managed


Object Class that is used for inheritance purposes only.

2.2.2 The Common Fragment


The following common functions are supported:

Event Report Management (as defined in [X.734]) and


Log Control
(as defined in [X.735])
The "X.721":system MOC is used to serve as naming sub-root for the corresponding
managed object instances.

Common functions of the GSM-related Managed Object Classes, notably:

Object Management
(as defined in [X.730])

State Management
(as defined in [X.731])

Alarm Reporting
(as defined in [X.733])

Alarm Acknowledgement (if ALARM_ACKNOWLEDGEMENT = 1)

File Transfer Control


(as defined in [GSM12.00])

In addition, the "ANOI":anoiPlmnNetwork MOC is used to serve as naming sub-root for


the GSM-related managed object instances.
The latter contains:

One "ANOI":anoiCoreManagedElement managed object instance per core BSS-NE.


Profile for the NMC/9153 OMC-R Q3 Interface

ED

02

Released
9654m21r.doc
09/04/2010

3BK 09654 MAAA PBZZA

12/35

All rights reserved. Passing on and copying of this


document, use and communication of its contents
not permitted without written authorization from Alcatel.

This managed object instance provides a synthesized view of the corresponding


Transmission, Equipment and bssFunction fragments. It also provides an alarm
synthesis of the object instances of these fragments.

One "ANOI":anoiGPRSManagedElement managed object instance per GPRS BSSNE.


This managed object instance supports overall supervision of the GPRS-specific part of
an 9153 OMC-R managed sub-network, i.e. all the alarms emitted by managed object
instances at the 9153 OMC-R/9130 BSC/MFS Evolution internal interface are mapped
onto alarms emitted by the corresponding "ANOI":anoiGPRSManagedElement
managed object instance at the NMC/9153 OMC-R Q3 interface.

One "ANOI":anoiSNMPManagedElement one managed object instance per OMC.


Alarms emitted by any declared External Ne are mapped onto alarms emitted by
"ANOI":anoiSNMPManagedElement, these alarms cannot be acknowledged and
resynchronization is possible using Log function.

The complete list of the corresponding MOCs is as follows:


MOC name
"X.721":alarmRecord

Related
standard
X.721

"ANOI":anoiCoreManagedElement

M.3100

"ANOI":anoiGPRSManagedElement

M.3100

ANOI:anoiSNMPManagedElement
"ANOI":anoiManagedElement

M.3100
M.3100

"ANOI":anoiPlmnNetwork
"ANOI":associationSurveyRecord
"X.721":attributeValueChangeRecord
"GSM 12.00":bulkTransferErrorRecord
"X.721":discriminator

GSM 12.00
X.721
X.721
GSM 12.00
X.721

"X.721":eventForwardingDiscriminator
"X.721":eventLogRecord
"GSM 12.00":
generalDataTransferControlFunction
"X.721":log
"X.721":logRecord
"M.3100":managedElement

X.721
X.721
GSM 12.00

"M.3100":network
"X.721":objectCreationRecord
"X.721":objectDeletionRecord
"GSM 12.00":simpleFileTransferControl
"X.721":stateChangeRecord
"X.721":system
ED

02

Purpose
Alarm
Reporting
and
Acknowledgement
Core BSS-NE management
(see above)
GPRS BSS-NE management
(see above)
SNMP Ex Ne management
BSS-NE
management
(Abstract Class)
GSM Common Functions
File Transfer Control
Object Management
File Transfer Control
Event Report Management
(Abstract Class)
Event Report Management
Log Control (Abstract Class)
File Transfer Control

X.721
X.721
M.3100

Log Control
Log Control (Abstract Class)
BSS-NE
management
(Abstract Class)
M.3100
GSM Common Functions
(Abstract Class)
X.721
Log Control
X.721
Log Control
GSM 12.00 File Transfer Control
X.721
State Management
X.721
Event Report Management
Profile for the NMC/9153 OMC-R Q3 Interface

Released
9654m21r.doc
09/04/2010

3BK 09654 MAAA PBZZA

13/35

All rights reserved. Passing on and copying of this


document, use and communication of its contents
not permitted without written authorization from Alcatel.

MOC name

Related
standard

"X.721":top
"GSM 12.00":transferReadyRecord

X.721
GSM 12.00

Purpose
Log Control
Inheritance root
File Transfer Control

Table 3: MOCs of the Common fragment

2.2.3 The Transmission Fragment


To model the management of PCM Circuits, [M3100] has been preferred to [GSM 12.20]
because [GSM 12.20] (which defines only the pcmCircuit Managed Object Class for that
purpose) is too weak as regards the capability to build the corresponding topology.
This management is performed thanks to the following instantiable MOCs:

"M.3100":connectionR1
Managed object instances of this MOC provide a synthesis of Abis and AterMux PCM
Circuits supported by telecom operators.

"ANOI":anoiTerminationPointBidirectional
Managed object instances of this MOC are used to represent 2Mb termination points

of an Alcatel BTS equipment

of a BSC at the Abis, Ater or AterMux interface

of a transcoder at the AterMux or A interface.


In particular, this MOC is instantiated:

to represent the two termination points with which an instance of


"M.3100":connectionR1 is in relation

for each Ater and A PCM Circuit. This makes it possible to supervise the Ater and
A interface.
This modeling enables, in case of failure, to precisely determinate which side of the 2 Mb
links is concerned.
In addition, the following Managed Object Classes are supported for Signalling System No.7
management:

"Q.751.1":mtpSignPoint

"ANOI":anoiSignLinkSetTp

"ANOI":anoiSignLinkTp
The complete list of the transmission-related MOCs is as follows:
MOC name
"ANOI":anoiSignLinkSetTp
"ANOI":anoiSignLinkTp
"ANOI":anoiTerminationPointBidirectional
"M.3100":connectionR1

Related
standard
Q.751.1
Q.751.1
M.3100
M.3100

"Q.751.1":mtpSignPoint
"M.3100":terminationPoint

Q.751.1
M.3100

Purpose
SS No.7
SS No.7
2Mb termination points
Abis or AterMux PCM
Circuits
SS No.7
2Mb termination points
(Abstract Class)

Table 4: MOCs of the Transmission fragment

Profile for the NMC/9153 OMC-R Q3 Interface


ED

02

Released
9654m21r.doc
09/04/2010

3BK 09654 MAAA PBZZA

14/35

All rights reserved. Passing on and copying of this


document, use and communication of its contents
not permitted without written authorization from Alcatel.

2.2.4 The Equipment Fragment


Equipment management is modelled via the following instantiable Managed Object Classes:

"ANOI":anoiEquipmentR1
One managed object instance of this MOC is created for each equipment of a core
BSS-NE:

the BSC

the BTS equipments

the transcoder.
It also provides a synthesis of the hardware alarms.

"ANOI":anoiCircuitPack
Managed object instances of this MOC are created for each replaceable equipment
item.

"M.3100":equipmentHolder
Managed object instances of this MOC are used to model racks and shelfs that group
replaceable equipment items.
The complete list of the equipment-related MOCs is as follows:
MOC name
"ANOI":anoiCircuitPack
"ANOI":anoiEquipmentR1
"M.3100":equipment

Related
standard
M.3100
M.3100
M.3100

"M.3100":equipmentHolder
"M.3100":equipmentR1

M.3100
M.3100

"M.3100":pipe

M.3100

Purpose
Equipment Management
Equipment Management
Equipment Management
(Abstract Class)
Equipment Management
Equipment Management
(Abstract Class)
Equipment Management
(Abstract Class)

Table 5: MOCs of the Equipment fragment

2.2.5 The bssFunction Fragment


The functionalities of the corresponding equipments are modelled via the following
instantiable Managed Object Classes:

" ANOI ":anoiBssFunction is instantiated for each core BSS-NE to model its O&M
functionality.

"ANOI":anoiBsc allows to supervise the overall BSC telecom activity and to report the
state of the 9153 OMC-R/BSC interface. A managed object instance of this MOC has
an "M.3100":alarmStatus attribute and sends (notably) "X.721":qualityofServiceAlarm
notifications.

"ANOI":anoiBtsSiteManager is instantiated for each managed BTS equipment to


control the corresponding O&M functions. An instance of this MOC sends (notably)
"X.721":processingErrorAlarm notifications.

"ANOI":anoiBts is instantiated for each BTS sector. An instance of this MOC controls
the telecom activity of a cell referenced by its cell identity (CI) and the location area
Profile for the NMC/9153 OMC-R Q3 Interface
02 Released

ED

9654m21r.doc
09/04/2010

3BK 09654 MAAA PBZZA

15/35

All rights reserved. Passing on and copying of this


document, use and communication of its contents
not permitted without written authorization from Alcatel.

code (LAC). Its sends (notably) "X.721":qualityofServiceAlarm notifications whenever


the operational state or the availability status of the corresponding cell is affected due
to faulty BTS hardware resource (e.g. frame unit, carrier unit). The 9153 OMC-R is able
to support threshold formula associated with "X.721":qualityofServiceAlarm
notifications.

"ANOI":anoiLapdLink is instantiated to supervise the RSL and OML links states. An


instance of this MOC sends (notably) "X.721":communicationsAlarm notifications.

The complete list of the bss function-related MOCs is as follows:


MOC name
"ANOI":anoiBsc
"ANOI":anoiBssFunction
"ANOI":anoiBts
"ANOI":anoiBtsSiteManager
"ANOI":anoiLapdLink
"GSM 12.00":bssFunction
"GSM 12.20":btsSiteManager
"GSM 12.20":gsmManagedFunction

Related
standard
GSM 12.20
GSM 12.00
GSM 12.20
GSM 12.20
GSM 12.20
GSM 12.00
GSM 12.20
GSM 12.20

Purpose
See above
See above
See above
See above
See above
Abstract Class
Abstract Class
Abstract Class

Table 6: MOCs of the bssFunction fragment

Profile for the NMC/9153 OMC-R Q3 Interface


ED

02

Released
9654m21r.doc
09/04/2010

3BK 09654 MAAA PBZZA

16/35

All rights reserved. Passing on and copying of this


document, use and communication of its contents
not permitted without written authorization from Alcatel.

2.3 Naming Tree


2.3.1 Conventions
In the Naming Trees below, the following conventions are used:
Properly speaking, the corresponding MOIs are not instantiated at the NMC/9153 OMC-R Q3
Interface. They only serve to model corresponding internal MOIs for Alarm Reporting and
Acknowledgement purposes (in case ALARM_ACKNOWLEDGEMENT = 1).
Idem but the corresponding internal MOIs are present only for Naming purposes (i.e. they
cannot send alarms).

2.3.2 General Naming Tree


root

"ANOI":
anoiPlmnNetwork

"X.721":
alarmRecord

"ANOI":
anoiCoreManagedElement

"X.721": system

"X.721":
eventForwardingDiscriminator

"X.721":log

"X.721":
attributeValueChangeRecord

"X.721":
objectCreationRecord

"X.721":
objectDeletionRecord

"X.721":
stateChangeRecord

"GSM 12.00":
bulkTransferErrorRecord

"GSM 12.00":
transferReadyRecord

"ANOI":
anoiGPRSManagedElement

"ANOI":association
SurveyRecord

ANOI:anoiSNMPManagedElement

Profile for the NMC/9153 OMC-R Q3 Interface


ED

02

Released
9654m21r.doc
09/04/2010

3BK 09654 MAAA PBZZA

17/35

All rights reserved. Passing on and copying of this


document, use and communication of its contents
not permitted without written authorization from Alcatel.

"ANOI":
anoiEquipmentR1

"M.3100":
equipmentHolder (Rack)

"M.3100":
connectionR1

"ANOI":anoiTerminationPoint
Bidirectional

"M.3100":
equipmentHolder (Shelf)

"Q.751.1":
mtpSignPoint

"ANOI":anoiFunction
Coordinator

"ANOI":
anoiSignLinkSetTp

"ANOI":anoiFunction

"ANOI":
anoiSignLinkTp

"ANOI":anoiCircuitPack

"GSM 12.00":
generalDataTransferControlFunction

"ANOI":anoiBssFunction

"ANOI":anoiBsc

"ANOI":anoiBtsSiteManager

"ANOI":
anoiLapdLink

"GSM 12.00":
simpleFileTransferControl

"ANOI":anoiBts

"ANOI":anoiBasebandTransceiver

Figure 4: General Naming Tree for the NMC/9153 OMC-R Q3 Interface Information
Model

Profile for the NMC/9153 OMC-R Q3 Interface


ED

02

Released
9654m21r.doc
09/04/2010

3BK 09654 MAAA PBZZA

18/35

All rights reserved. Passing on and copying of this


document, use and communication of its contents
not permitted without written authorization from Alcatel.

2.3.3 Complement for GPRS Alarms Reporting


"NMD":neGroup

"NMD":networkElement

"ABSS":aGprs
BssFunction

"AMFSME":aGprs2MbTTP

"NMD":neSupervision
Coordinator

"AGVC":aGprsNse

"ABSS":aGprs
BtsSiteManager

"AGFR":aGprs
BearerChannel

"AGVC":aGprsLapdLink

"AGVC":aGprsNsvc

"ABSS":aGprsBts

"AGFR":aGprsPvc

"M.3100":equipment
Holder (rack)

"AMFSME":aGprsFabric

"AGVC":aGprsSgsnIpEndPoint

"M.3100":equipment
Holder (shelf)

"M.3100":equipmentHolder (ASpack)

"M.3100":circuitPack

"LAPF":nectarCircuitPack

"LAPF":nectarCircuitPack

Figure 5: Complement to the Naming Tree for GPRS Alarms Reporting

2.4 Inheritance hierarchy


2.4.1 X.721-related part
"X.721":top

"X.721":log

"X.721":logRecord

"X.721":eventLogRecord

"X.721":discriminator

"X.721":eventForwardingDiscriminator

"X.721":
attributeValueChangeRecord

"X.721":alarmRecord

"X.721":
objectDeletionRecord

"X.721":system

"X.721":
stateChangeRecord

"X.721":
objectCreationRecord

"ANOI":
associationSurveyRecord

Figure 6: Inheritance hierarchy (X.721-related part)


Profile for the NMC/9153 OMC-R Q3 Interface
ED

02

Released
9654m21r.doc
09/04/2010

3BK 09654 MAAA PBZZA

19/35

All rights reserved. Passing on and copying of this


document, use and communication of its contents
not permitted without written authorization from Alcatel.

2.4.2 M.3100-related part


"X.721":top

"M.3100":
pipe

"M.3100":
equipment

"ANOI":
anoiManagedElement

"M.3100":
network

"M.3100":
connectionR1

"M.3100":
terminationPoint

"ANOI":anoiTerminationPoint
Bidirectional

"M.3100":
equipmentR1

"ANOI":
anoiCircuitPack

"ANOI":
anoiCoreManagedEle
ment

"ANOI":
anoiEquipmentR1

"ANOI":anoiGPRS
ManagedElement

"ANOI":anoiGPRSM
anagedElement

"M.3100":equipmentHolder

Figure 7: Inheritance hierarchy (M.3100-related part)

2.4.3 Q.751.1-related part


"X.721":top

"Q.751.1":mtpSignPoint

"ANOI":anoiSignLinkSetTp

"ANOI":anoiSignLinkTp

Figure 8: Inheritance hierarchy (Q.751.1-related part)

2.4.4 GSM 12.00-related part


"X.721":top

"GSM 12.00":
bssFunction

"GSM 12.00":
generalDataTransferControlFunction

"X.721":logRecord

"GSM 12.00":
simpleFileTransferControl

"M.3100":
network

"ANOI":anoiPlmnNetwork

"X.721":eventLogRecord

"X.721":alarmRecord
"GSM 12.00":
bulkTransferErrorRecord

"GSM 12.00":
transferReadyRecord

Figure 9: Inheritance hierarchy (GSM 12.00-related part)


Profile for the NMC/9153 OMC-R Q3 Interface
ED

02

Released
9654m21r.doc
09/04/2010

3BK 09654 MAAA PBZZA

20/35

All rights reserved. Passing on and copying of this


document, use and communication of its contents
not permitted without written authorization from Alcatel.

2.4.5 GSM 12.20-related part


"X.721":top

"GSM 12.20":gsmManagedFunction

"ANOI":anoiBsc

"ANOI":anoiBts

"GSM 12.20":btsSiteManager

"ANOI":anoiLapdLink

"ANOI":anoiBtsSiteManager

Figure 10: Inheritance hierarchy (GSM 12.20-related part)

Profile for the NMC/9153 OMC-R Q3 Interface


ED

02

Released
9654m21r.doc
09/04/2010

3BK 09654 MAAA PBZZA

21/35

All rights reserved. Passing on and copying of this


document, use and communication of its contents
not permitted without written authorization from Alcatel.

3. THE Q3 PROCOCOL
The NMC/9153 OMC-R Q3 interface complies with [Q.811] for the lower layers and [Q.812]
for the upper layers of the Q3 Protocol. The corresponding Conformance Statements are
specified in [ANOIcs-Q3P].
In particular,

The following lower layer protocol profiles defined in [Q.811] are supported:

CONS1:
A connection-mode packet interface using X.25
A connectionless-mode interface using [ISO/IEC 8802-2] type

CLNS1:
LANs using Carrier Sense Multiple Access with Collision
Detection (CSMA/CD)

RFC1006/TCP/IP: OSI Transport class 0 over Internet TCP.

Only the upper layer protocol profile for Interactive Class services defined in [Q.812] is
relevant for the NMC/9153 OMC-R Q3 Interface (Session and Presentation layers,
ACSE, ROSE and CMISE).

Profile for the NMC/9153 OMC-R Q3 Interface


ED

02

Released
9654m21r.doc
09/04/2010

3BK 09654 MAAA PBZZA

22/35

All rights reserved. Passing on and copying of this


document, use and communication of its contents
not permitted without written authorization from Alcatel.

4. SUPPORTED SERVICES
4.1 Configuration Management
4.1.1 Services supported at the NMC/9153 OMC-R interface
At the NMC/9153 OMC-R Q3 Interface, the services pertaining to the Configuration
Management domain (concerned by all the object instances named under
"ANOI":anoiPlmnNetwork) are restricted to the following ones:

Network Discovery:
Network discovery consists in requesting the list of BSS-NEs which compose the 9153
OMC-R managed sub-network.
This can be performed using the following GET request:
BOC:
"ANOI":anoiPlmnNetwork MOC
scope:
firstLevelOnly
which makes it possible to know all the "ANOI":anoiCoreManagedElement and
"ANOI":anoiGPRSManagedElement managed object instances, i.e. all the
corresponding BSS-NEs.

Core BSS-NE Discovery:


Core BSS-NE discovery consists in getting all the available information concerning a
given core BSS-NE.
This can be performed by using GET requests of the form:
BOC:
"ANOI":anoiCoreManagedElement MOC or
any MOC under it in the naming tree
scope:
no restriction
N.B.:
For performance reasons, it is recommended to split a request with a
large scope into several requests, which individually generate less
responses.

Related Object Management:


The Object Management function defined in [X.730] is supported.
More precisely:

ED

If, for a given managed object instance, the value of a GET or GET-REPLACE
attribute that is not a state or status attribute changes, then the
"X.721":attributeValueChange notification is sent by this managed object instance.
Only exceptions to this (standard) general rule are stated in [ANOIcs-gene].

If a given object instance is created (resp. deleted), a corresponding


X.721:objectCreation (resp. X.721:objectDeletion) notification is sent by this
managed object instance whenever necessary.
In particular, when a core BSS-NE is created (resp. deleted), an
X.721:objectCreation (resp.X.721:objectDeletion) notification is sent by the
ANOI:anoiCoreManagedElement managed object instance representing that
core BSS-NE. Similarly, when a GPRS BSS-NE is created (resp. deleted), an
X.721:objectCreation (resp.X.721:objectDeletion) notification is sent by the
ANOI:anoiGPRSManagedElement managed object instance representing that
GPRS BSS-NE.
Profile for the NMC/9153 OMC-R Q3 Interface
02 Released
9654m21r.doc
09/04/2010

3BK 09654 MAAA PBZZA

23/35

All rights reserved. Passing on and copying of this


document, use and communication of its contents
not permitted without written authorization from Alcatel.

This allows a NMC to update the list of BSS resulting from a Network discovery.
In that respect however, the policy is to avoid sending unecessary
X.721:objectCreation/X.721:objectDeletion
notifications
whenever
possible so as not to overflow the external Q3 links. For example, only one
X.721:objectDeletion notification is sent when a core BSS-NE is deleted since
this undoubtedly implies that all the managed object instances named under it
have been deleted. See also section 5.3.1.3.

Reading attribute values:


For a given managed object instance, it is possible to read:

the value of all the attributes that are present for a given managed object instance
by using an M-GET request with no attributeIdentifierList field.

the value of specific attributes by using an M-GET request with a valued


attributeIdentifierList field.

Controlling the export of 9153 OMC-R configuration data:


It is possible to request and transfer in a controlled way the 9153 OMC-R configuration
data

either at network level

or for a given core BSS-NE

or for a given GPRS BSS-NE.


This service takes advantage of the GSM 12.00:simpleFileTransferControl object
instances, as described in [ACIE-gene]. The supported file transfer protocol is indicated
in the ACOM:typeOfFileTransfer attribute of the ANOI:anoiPlmnNetwork managed
object instance (see [ANOIcs-gene]).

4.1.2 Services supported at other 9153 OMC-R external interfaces


For the "ANOI":anoiPlmnNetwork managed object instance and all managed object
instances named under it, it is not allowed for a NMC to request a change in the value of
any attribute at the NMC/9153 OMC-R Q3 interface. Such an attribute value change can be
requested

either directly by a 9153 OMC-R operator;

or via an import session

(at Network Level) at the 9153 OMC-R Configuration Import/Export interface for
attributes other than "ACOM":clientNodeIdentifier (see [ACIE-gene]);

at a dedicated interface for the "ACOM":clientNodeIdentifier attribute (see [ANIE]).

4.1.3 Date and time management


It is possible to fetch the date and time of a 9153 OMC-R instance through a GET request
on the "M.3100":externalTime attribute of the "ANOI":anoiPlmnNetwork managed object
instance.
On the other hand, it is not possible to set the date and time of a 9153 OMC-R instance at
the NMC/9153 OMC-R Q3 interface nor at the 9153 OMC-R Configuration Import/Export
interface. A NMC can use the same UNIX routine as the one used by the 9153 OMC-R for
setting time, namely the Network Time Protocol (XNTP), a UNIX application over UDP.
N.B.:
XNTP manages the time for a set of stations. The primary clock (source time) can
be a station or an external equipment (radio receiver type for example). This
application is compliant to RFC 1035. The protocol is exchanged on an "ip"
Profile for the NMC/9153 OMC-R Q3 Interface
ED

02

Released
9654m21r.doc
09/04/2010

3BK 09654 MAAA PBZZA

24/35

All rights reserved. Passing on and copying of this


document, use and communication of its contents
not permitted without written authorization from Alcatel.

network. The time synchronisation (in case of large shift) is performed by several
little steps.

4.2 Fault management


4.2.1 Introduction
The NMC/9153 OMC-R Q3 interface supports the following functions:

State Management
Whenever relevant, objects support a number of state and status attributes that can be
read and the changes in the value of these attributes (due to events occurring in the
radio sub-system or internally to the 9153 OMC-R) is reported to the NMCs through
X.721:stateChange notifications. Only exceptions to this (standard) general rule are
stated in [ANOIcs-gene].

Alarm Reporting & Acknowledgement


Whenever relevant, the detection of faults or abnormal conditions (due to events
occurring in the radio sub-system or internally to the 9153 OMC-R) are reported to the
NMCs through alarm notifications emitted by the appropriate managed object instance.

4.2.2 In addition, if ALARM_ACKNOWLEDGEMENT = 1, a NMC can


request to acknowledge a given set of alarms and is warned
whenever an alarm has been acknowledged. State Management
The State Management function is supported as defined in [X.731].
In particular, a number of state and status attributes are supported among which:

The generic state attributes X.721:administrativeState and X.721:operationalState

M.3100:alarmStatus which, when supported, gives a synthesis of the alarms


concerning the corresponding managed object instance and those named under it. This
synthesis actually characterises the highest perceived severity of the concerned
alarms.
For instance, the M.3100:alarmStatus attribute of an ANOI:anoiEquipmentR1
managed object instance provides the synthesis of the alarms emitted by the contained
ANOI:anoiCircuitPack and ANOI:anoiTerminationPointBidirectional managed object
instances.
For ANOI:anoiBsc andANOI:anoiBtsSiteManager, this attribute reflects, in addition,
the alarm situation of the corresponding ANOI:anoiEquipmentR1 managed object
instance in order to facilitate alarm detection.
N.B.:
The actual rule is defined in [ANOIcs-gene].

4.2.3 Alarm Reporting & Acknowledgement


4.2.3.1 Introduction
The Alarm Management function is supported as defined in [X.733].
The supported alarm notifications are the following ones:
Profile for the NMC/9153 OMC-R Q3 Interface
ED

02

Released
9654m21r.doc
09/04/2010

3BK 09654 MAAA PBZZA

25/35

All rights reserved. Passing on and copying of this


document, use and communication of its contents
not permitted without written authorization from Alcatel.

X.721:communicationsAlarm
X.721:environmentalAlarm
X.721:equipmentAlarm
X.721:processingErrorAlarm
X.721:qualityofServiceAlarm.

In addition, if ALARM_ACKNOWLEDGEMENT = 1:

A NMC can request the acknowledgement of a given set of alarms concerning either a
given core BSS-NE or a given GPRS BSS-NE by using a "ANOI":acknowledgeAlarms
M-ACTION request.

NMCs are warned that an alarm has been acknowledged by receiving a simplified (but
standard) version of this alarm with notably the information sub-field of the element of
the
additionalInformation
field
corresponding
to
the
"ACOM":alarmAcknowledgementIndication parameter containing TRUE.
Alarm acknowledge is not available on alarms emitted on anoiSNMPManagedElement.

4.2.3.2 Main fields of an alarm message


An alarm message is sent by using the CMIS M-EVENT-REPORT service. The
corresponding fields:

identify the managed object instance emitting the alarm,

indicate if the notification corresponds to the beginning or the end of the alarm, or if the
alarm will not be cleared.

the type and time of the alarm,

together with other pertinent information.


The table below indicates the main fields that can be present and a short description of the
latter:
FIELD/SUB-FIELD NAME
COMMENTS
managedObjectClass
This field identifies the Managed Object Class to which
the object instance emitting the notification belongs.
managedObjectInstance
This field identifies the object instance emitting the
notification.
eventTime
This field contains a BSS time-stamp
eventType
This field indicates the category of the alarm
(communication,
environmental,
equipment,
processingError or qualityofService alarm).
eventInfo
This sub-field indicates the probable cause of the alarm
probableCause
as an OID value.
The set of probableCause values that can be used are
defined in [ANOIgdmo]. These values are all standard
ones.
This sub-field is a list of integers that are such that an
specificProblems
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.
For more information, see [ANOIcs-gene].
Profile for the NMC/9153 OMC-R Q3 Interface
ED

02

Released
9654m21r.doc
09/04/2010

3BK 09654 MAAA PBZZA

26/35

All rights reserved. Passing on and copying of this


document, use and communication of its contents
not permitted without written authorization from Alcatel.

FIELD/SUB-FIELD NAME
perceivedSeverity
thresholdInfo

stateChangeDefinition
monitoredAttributes

proposedRepairActions

additionalText
additionalInformation

COMMENTS
This sub-field indicates the perceived severity of the
alarm (indeterminate, critical, major, minor, warning or
cleared).
This sub-field may only be present for a
qualityofServiceAlarm notification. . If present, it
indicates corresponding threshold information.
For more information, see [ANOIcs-gene].
This sub-field, if present, identifies state changes
associated with the alarm.
For more information, see [ANOIcs-gene].
This sub-field, if present, contains one element for a
number of attributes among which M.3100:alarmStatus
and M.3100:userLabel.
These elements contain:
the value of the corresponding attribute,
except for M.3100:userLabel in which case it
contains the concatenation of a number of information
enabling to locate precisely the alarm.
For example this element for an alarm concerning a
circuitPack can contain something like:
"BSS 1 Shelf 1 Rack 1 swch-aa 1"
When this sub-field is present together with the list of
concerned attributes and the exact contents of the
element corresponding to M.3100:userLabel is defined
in [ANOIcs-gene].
This sub-field, if present, indicates whether or not a
repair action can be performed.
It contains one of the two OID values defined in [X.721],
namely:
either noActionRequired
or repairActionRequired
For more information, see [ANOIcs-gene].
This sub-field, if present, contains a free form text
intended for human readers.
For more information, see [ANOIcs-gene].
This sub-field contains at most as many elements as
there are applicable ANOI parameters.
For example, such an element may serve one of the
following purposes:
To indicate the additional information carried out by a
BSS Alarm (if any) in a human readable form.
To help find out a location (if any) where, notably, a list
of repair actions that can be performed to clear the
alarm are specified.
To
indicate
the
managedObjectClass
and
managedObjectInstance values corresponding to the
internal MOI that has emitted the alarm (from an
NMC/9153 OMC-R Q3 Interface viewpoint).
To indicate that the alarm only serves to warn the
NMCs that the corresponding internal alarm has been
acknowledged
(present
only
if
Profile for the NMC/9153 OMC-R Q3 Interface

ED

02

Released
9654m21r.doc
09/04/2010

3BK 09654 MAAA PBZZA

27/35

All rights reserved. Passing on and copying of this


document, use and communication of its contents
not permitted without written authorization from Alcatel.

FIELD/SUB-FIELD NAME

COMMENTS
ALARM_ACKNOWLEDGEMENT = 1).
For more information, see [ANOIgdmo] and [ANOIcsgene].

Table 7: Main fields of an alarm message


N.B.:

The reference for the aforementioned information is [ANOIgdmo] and [ANOIcsgene].

4.2.3.3 Relationship attributes


Relationship attributes are supported to enable the navigation between the
transmission/equipment fragments and the bssFunction fragment. In particular, it enables,
knowing that an object of the transmission or equipment fragment is in alarm, to reach
easily the concerned object in the bssFunction fragment.
To have a summary of the supported relationship attributes, see [ANOIcs-gene]: this
document contains a table indicating, for each concerned MOC, which relationship
attributes are supported and the object instances that can be referred to by these attributes.

4.3 Event Report Management and Log Control


4.3.1 Introduction
A number of events emanate from the radio sub-system or are generated internally in the
9153 OMC-R. They can be reported to the NMCs as a notification corresponding to the type
of event emitted by an appropriate object according to the definition of the Managed Object
Class to which the object belongs. The main possible notifications are:

X.721:stateChange to report changes in the value of state and status attributes

X.721:attributeValueChange to report changes in the value of the other attributes

alarm notifications (see above)

X.721:objectCreation to report object creations.

X.721:objectDeletion to report object deletions.


Concerning the actual forwarding and the logging of these potential event reports, the
following functions are supported:

Event Report Management through X.721:eventForwardingDiscriminator (EFD)


objects.

Log Control through X.721:log and logRecord objects.


log objects can be used to select the potential event reports that are to be logged in the
form of appropriate logRecords.

4.3.2 Event Report Management


The Event Report Management function is supported as defined in [X.734].
In particular, X.721:eventForwardingDiscriminator objects are supported. They notably
allow to define the conditions which must be satisfied by potential event reports to be
actually forwarded to a particular destination.
N.B.:
In this document or in the other NMC/9153 OMC-R Q3 Interface specification
documents, the expression 'a notification is sent to the NMCs' shall be interpreted
as 'a potential notification is sent to the EFD system'. Whether or not this
Profile for the NMC/9153 OMC-R Q3 Interface
ED
02 Released
9654m21r.doc
09/04/2010

3BK 09654 MAAA PBZZA

28/35

All rights reserved. Passing on and copying of this


document, use and communication of its contents
not permitted without written authorization from Alcatel.

notification is actually forwarded to a given NMC depends on the definition of the


EFD object instances which exit at that moment.
This remark also applies to all the similar expressions.
A NMC can create X.721:eventForwardingDiscriminator objects. These objects can be
deleted either by a NMC or by a 9153 OMC-R operator.
The other requests that are allowed for a NMC are as follows:

M-GET on all attributes

M-SET on:

X.721:administrativeState
Setting this attribute to the locked value enables to suspend the EFD activity. In
this state, M-SET requests on the modifiable EFD attributes are allowed.
Setting this attribute again to the unlocked value enables to resume the EFD
activity.

X.721:discriminatorConstruct

X.721:destination
A NMC can find out all the existing X.721:eventForwardingDiscriminator object instances
by an M-GET request of the following form:
BOC:
X.721:system MOC
BOI
see [ANOIcs-gene]
scope:
firstLevelOnly
filter:
see [ANOIcs-gene]
A NMC can perform M-GET requests with a BOC argument equal to the
X.721:eventForwardingDiscriminator MOC. In this case, there is no restriction on the
allowed filter argument.
EFDs are persistent and support the possibility to forward events to several destinations.

4.3.3 Log Control


The Log Control function is supported as defined in [X.735].
In particular, X.721:log objects are supported. They notably allow to define the conditions
which must be satisfied by potential event reports to be actually logged in a particular log
object instance.
A log object instance contains logRecord object instances belonging to one of the following
Managed Object Classes:

X.721:alarmRecord,

X.721:attributeValueChangeRecord,

X.721:objectCreationRecord,

X.721:objectDeletionRecord,

X.721:stateChangeRecord,

"GSM 12.00":bulkTransferErrorRecord,

"GSM 12.00":transferReadyRecord,

"ANOI":associationSurveyRecord.
Logs are global to the sub-network managed by the 9153 OMC-R and are in wrap mode.
A NMC can create X.721:log objects. These objects can be deleted either by a NMC or by
a 9153 OMC-R operator.
The other requests that are allowed for a NMC are as follows:

M-GET on all attributes


Profile for the NMC/9153 OMC-R Q3 Interface
ED

02

Released
9654m21r.doc
09/04/2010

3BK 09654 MAAA PBZZA

29/35

All rights reserved. Passing on and copying of this


document, use and communication of its contents
not permitted without written authorization from Alcatel.

M-SET on:

X.721:administrativeState,
Setting this attribute to the locked value enables to suspend the log activity. In
this state, M-SET requests on the modifiable log attributes are allowed.
Setting this attribute again to the unlocked value enables to resume the log
activity.

X.721:capacityAlarmThreshold (provided this attribute is present, see [ANOIcsgene]),

X.721:discriminatorConstruct,

"X.721":logFullAction

X.721:maxLogSize (provided this attribute is present, see [ANOIcs-gene]).

A NMC can find out all the existing X.721:log object instances by a M-GET request of the
following form:
BOC:
X.721:system MOC
BOI
see [ANOIcs-gene]
scope:
firstLevelOnly
filter:
see [ANOIcs-gene]
A NMC can perform M-GET requests with a BOC argument equal to the X.721:log MOC.
In this case, there is no restriction on the allowed filter argument.

Profile for the NMC/9153 OMC-R Q3 Interface


ED

02

Released
9654m21r.doc
09/04/2010

3BK 09654 MAAA PBZZA

30/35

All rights reserved. Passing on and copying of this


document, use and communication of its contents
not permitted without written authorization from Alcatel.

5. 9153 OMC-R /NMC SYSTEM RELATIONSHIPS


This part describes the relationships concerning the NMC/9153 OMC-R system.

5.1 Consistency of the NMC, 9153 OMC-R and BSS databases


There are three hierarchical levels as regards data, which are, from top to bottom:
1) NMC,
2) 9153 OMC-R and
3) BSS-NE.
It must be guaranteed that the databases at these three levels are consistent. This is done
by three main mechanisms on which a NMC and the 9153 OMC-R instance rely on for
database updating, initialization phase and resynchronization:
1)

9153 OMC-R to NMC notifications


All changes done in the 9153 OMC-R databases are propagated to the NMCs by
means of the following notifications:

X.721:stateChange,

X.721:attributeValueChange,

X.721:objectDeletion,

X.721:objectCreation,

alarms
In this way, in a normal working mode, the database of a NMC is always consistent with
the 9153 OMC-R databases.

2)

9153 OMC-R/BSS-NE audit


The purpose of the audit is to align the 9153 OMC-R and a BSS-NE databases. In case
of discrepancies, the following rules apply:

ED

The BSS-NE radio configuration is aligned on 9153 OMC-R values. The 9153
OMC-R databases are regarded as containing the correct values in terms of radio
configuration. The 9153 OMC-R updates the BSS-NE database without warning
the NMCs because all changes done in the 9153 OMC-R databases are
propagated to the NMCs.

The 9153 OMC-R hardware and transmission configuration is aligned on the BSSNE values. The BSS-NE database is regarded as the reference concerning
hardware and transmission configuration. The 9153 OMC-R updates its own
databases and warns the NMCs against changes by sending the corresponding
notification.

Concerning alarms, the 9153 OMC-R alarm situation is aligned on the BSS-NE
one. The 9153 OMC-R updates its view of the alarm situation and informs the
NMCs of the changes by sending alarm notifications.

When an audit is performed for a given BSS-NE, the NMCs are warned via a
"X.721":stateChange
notification
sent
by
the
corresponding
ANOI:anoiCoreManagedElement or ANOI:anoiGPRSManagedElement MOI with
'reporting' as old X.721:proceduralStatus attribute value.
During a BSS-NE audit phase, a NMC is allowed to perform M-GET requests but it is
warned that these requests may return consistent but not accurate (since not updated)
values thanks to this "X.721":stateChange notification.
Profile for the NMC/9153 OMC-R Q3 Interface
02 Released
9654m21r.doc
09/04/2010

3BK 09654 MAAA PBZZA

31/35

All rights reserved. Passing on and copying of this


document, use and communication of its contents
not permitted without written authorization from Alcatel.

When the audit phase is terminated, the NMCs are warned via a "X.721":stateChange
notification sent by the same MOI with 'reporting' as new X.721:proceduralStatus
attribute value.
3)

NMC resynchronisation
The previous mechanisms do not guarantee that the database of a NMC is consistent
with the 9153 OMC-R databases in case of a Q3 link failure with that NMC or a 9153
OMC-R system failure (detected as described in section 5.2).
To handle these cases, the NMC resynchonisation mechanism is supported (see
section 5.3).

5.2 The ANOI:associationSurvey notification


The ANOI:associationSurvey notification is sent periodically to the NMCs by the
ANOI:anoiPlmnNetwork managed object instance. This notification makes it possible to
fully survey the communication link between the 9153 OMC-R and the primary NMC. For
more information on that notification, see its definition in [ANOIgdmo].

5.3 NMC resynchronisation


5.3.1 The contexts in which a NMC resynchonisation is required
This section describes the situations in which a NMC needs to resynchronize itself with the
9153 OMC-R, i.e. in which a NMC may need to perform:

a configuration resynchonisation (either at network level or for a given BSS-NE)

and/or an alarm resynchonisation.

5.3.1.1 NMC start up


At NMC start-up, a NMC has to do the following:

first perform a full configuration resynchonisation;

then create the X.721:eventForwardingDiscriminator and X.721:log object instances


it needs;

finally perform an alarm resynchonisation.

5.3.1.2 9153 OMC-R initialization


At the 9153 OMC-R initialization (from a NMC viewpoint),

The "ANOI":anoiPlmnNetwork object instance is created and a corresponding


"X.721":objectCreation
notification
is
sent
to
the
NMCs
with
the
"X.721":proceduralStatus attribute value assigned to 'initializing'.

The 9153 OMC-R performs an internal checking.


The NMCs are warned that this phase has succeeded via a X.721:stateChange
notification sent by the ANOI:anoiPlmnNetwork managed object instance indicating
that the "X.721":proceduralStatus attribute value has changed from 'initializing' to
'reporting'.

Then, for each BSS-NE, the steps described in section 5.3.1.3 are performed.
Profile for the NMC/9153 OMC-R Q3 Interface

ED

02

Released
9654m21r.doc
09/04/2010

3BK 09654 MAAA PBZZA

32/35

All rights reserved. Passing on and copying of this


document, use and communication of its contents
not permitted without written authorization from Alcatel.

5.3.1.3 BSS-NE creation and initialization


A NMC is warned of the creation of a BSS-NE and its components (if any) by a single
X.721:objectCreation
notification
emitted
by
the
corresponding
ANOI:anoiCoreManagedElement or ANOI:anoiGPRSManagedElement managed object
instance (see section 4.1.1). The X.721:proceduralStatus attribute of the corresponding
ANOI:anoiCoreManagedElement or ANOI:anoiGPRSManagedElement managed object
instance contains the value initializing.
Then the BSS-NE is initialized. A NMC is warned that the BSS-NE has been correctly
initialized via a "X.721":stateChange notification sent by the corresponding
ANOI:anoiCoreManagedElement or ANOI:anoiGPRSManagedElement managed object
instance with 'reporting' as new X.721:proceduralStatus attribute value.
When this initialization phase of the BSS-NE is completed, a NMC should perform a
configuration resynchronization (only for core BSS-NEs) then an alarm resynchronization for
that BSS-NE. In particular, during this initialization phase,

for a core BSS-NE, the notifications that are sent by the corresponding
ANOI:anoiCoreManagedElement MOI or a MOI named under it

for a GPRS BSS-NE, the notifications that are sent by the corresponding
ANOI:anoiGPRSManagedElement MOI
(if any) shall not be relied upon together with the attribute values of those MOIs.

5.3.1.4 Upon detection of a problem by a NMC


In case a NMC has detected a problem thanks to the ANOI:associationSurvey notification
(see section 5.2), it needs to perform an alarm resynchonization.

5.3.2 Configuration resynchronisation


A NMC can perform a configuration resynchonisation

at Network level through a Network discovery

or for a given core BSS-NE through a core BSS-NE discovery.


Both discoveries are dealt with in section 4.1.1.

5.3.3 Alarm resynchronisation


The 9153 OMC-R offers two mechanisms to resynchronise the alarms between a NMC and
the 9153 OMC-R:

Using the Log Control function:


A NMC can retrieve all the logRecord object instances of a given log object instance
whose X.721:eventTime attribute is within a time interval that is sufficiently great to
cover the period during which alarms have been lost (e.g. between the two subsequent
reception of the ANOI:associationSurvey notification framing a Q3 link failure).
This can be performed using an M-GET request of the following form:
BOC:
X.721:log
Scope:
firstLevelOnly
Filter:
lessOrEqual
(t1, X.721:eventTime) and
greaterOrEqual (t2, X.721:eventTime)

Profile for the NMC/9153 OMC-R Q3 Interface


ED

02

Released
9654m21r.doc
09/04/2010

3BK 09654 MAAA PBZZA

33/35

All rights reserved. Passing on and copying of this


document, use and communication of its contents
not permitted without written authorization from Alcatel.

This requests sufficient knowledge from this NMC to be able to decide of an


appropriate time interval (e.g. memorizing the time at which two subsequent
ANOI:associationSurvey notifications are actually received).

Using ANOI:retrieveCurrentAlarmsData
A NMC can retrieve the current alarms of a BSS-NE through an
ANOI:retrieveCurrentAlarmsData M-ACTION request on the corresponding
ANOI:anoiCoreManagedElement or ANOI:anoiGPRSManagedElement managed
object instance. This option is not available for alarms
emitted on
ANOI:anoiSNMPManagedElement.

If ALARM_ACKNOWLEDGEMENT = 1, to resynchronize its knowledge of alarm


acknowledgement, a NMC can use one of the aforementioned methods but the simplest
(and recommended) method is the second one:

With ANOI:retrieveCurrentAlarmsData, whether or not a current alarm retrieved that


way has been acknowledged by the 9153 OMC-R instance is directly indicated in the
associated data: the information associated with the element of the
additionalInformation
field
corresponding
to
the
"ACOM":alarmAcknowledgementIndication parameter contains 'TRUE' if it has been
acknowledged and 'FALSE' otherwise.

On the other hand, using the Log Control Function is more tricky since, with the
afomentioned M-GET request, the full length alarms issued following the standard
Alarm reporting mechanism are retrieved separately from the simplified version of the
alarm sent to warn a NMC that the corresponding internal alarm has been
acknowledged.

Profile for the NMC/9153 OMC-R Q3 Interface


ED

02

Released
9654m21r.doc
09/04/2010

3BK 09654 MAAA PBZZA

34/35

All rights reserved. Passing on and copying of this


document, use and communication of its contents
not permitted without written authorization from Alcatel.

6. ACRONYMS
ACIE
ACOM

ANOI

ASN1
BOC
BOI
BSC
BSS
BSS-NE
BTS
CLNS
CMISE
CSMA/CD
CONS
GDMO
GPRS
GSM
IP
LAN
MOC
MOI
NMC
O&M
OMC-R
SW
TCP

Alcatel-Lucent 9153 OMC-R Configuration Import/Export interface


Alcatel-Lucent 9153 OMC-R Common
Acronym used to denote the proprietary part used by the Alcatel
NMC/9153 OMC-R Q3 Interface gathering 9153 OMC-R Common
purpose definitions.
Alcatel-Lucent NMC/OMC-R (i.e. 9153 OMC-R) Q3 Interface
Acronym used to denote the proprietary part specific to the Alcatel
NMC/9153 OMC-R Q3 Interface
Abstract Syntax Notation One
baseManagedObjectClass argument of a CMIS M-GET request
baseManagedObjectInstance argument of a CMIS M-GET request
Base Station Controller
Base Station Subsystem
Base Station Subsystem Network Element
Base Transceiver Station
Connectionless Network Layer Service
Common Management Information Service Element
Carrier Sense Multiple Access with Collision Detection
Connection-mode Network Layer Service
Guidelines for the Definition of Managed Objects
General Packet Radio Service
Global System for Mobile communications
(whichever technology, i.e. either Circuit-Switched or Packet-Switched)
Inter-networking Protocol
Local Area Network
Managed Object Class
Managed Object Instance
Network Management Centre
Operation and Maintenance
Operation and Maintenance Centre Radio
Software
Transmission Control Protocol
END OF DOCUMENT

Profile for the NMC/9153 OMC-R Q3 Interface


ED

02

Released
9654m21r.doc
09/04/2010

3BK 09654 MAAA PBZZA

35/35