Profile For The NMC/9153 OMC-R Q3 Interface ED 02 Released

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

ED
02
Released
9654m21r.doc
09/04/2010
3BK 09654 MAAA PBZZA
1/ 2
All rights reserved. Passing on and copying of this

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
ED
02
Released
9654m21r.doc
09/04/2010
1/35

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

ED
02
Released
9654m21r.doc
09/04/2010
2/35

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

ED
02
Released
9654m21r.doc
09/04/2010
3/35

[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]

Management:
State Management Function
[X.733]

Management:
Alarm Reporting Function
[X.734]

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

Management:
Log Control Function
[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
ED
02
Released
9654m21r.doc
09/04/2010
4/35

[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

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

the GDMO Formal Specification
[ANOIcs-gene]
NMC/9153 OMC-R Q3 Interface:

Statements
[ANOIcs-Q3P]
NMC/9153 OMC-R Q3
Statements
[ACIE-gene]
9153 OMC-R Configuration Import/Export interface

For Release B11:
[ACIE-si]
9153 OMC-R Configuration Import/Export Interface: Supplementary

Information
For Release B11:
[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

ED
02
Released
9654m21r.doc
09/04/2010
5/35

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

ED
02
Released
9654m21r.doc
09/04/2010
6/35

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.

ED
02
Released
9654m21r.doc
09/04/2010
7/35

[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
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
ED
02
Released
9654m21r.doc
09/04/2010
8/35

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

ED
02
Released
9654m21r.doc
09/04/2010
9/35

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
ED
02
Released
9654m21r.doc
09/04/2010
10/35

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

ED
02
Released
9654m21r.doc
09/04/2010
11/35
A traffic supervision and a possibility of 2Mbits topology discovery

A traffic supervision independent from the equipment maintenance.

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
State Management
Alarm Reporting
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.

ED
02
Released
9654m21r.doc
09/04/2010
12/35

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
Object Management
Event Report Management
(Abstract Class)
Log Control (Abstract Class)
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
Released
9654m21r.doc
09/04/2010
13/35

MOC name
Related
standard
"X.721":top
"GSM 12.00":transferReadyRecord
X.721
GSM 12.00
Purpose
Log Control
Inheritance root
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":anoiTerminationPointBidirectional
"M.3100":connectionR1
Related
standard
Q.751.1
Q.751.1
M.3100
M.3100
"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

ED
02
Released
9654m21r.doc
09/04/2010
14/35

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":anoiEquipmentR1
"M.3100":equipment
Related
standard
M.3100
M.3100
M.3100
"M.3100":equipmentR1
M.3100
M.3100
"M.3100":pipe
M.3100
Purpose
Equipment Management
(Abstract Class)
(Abstract Class)
(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
02 Released
ED
9654m21r.doc
09/04/2010
15/35

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

ED
02
Released
9654m21r.doc
09/04/2010
16/35

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

ED
02
Released
9654m21r.doc
09/04/2010
17/35

"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
"GSM 12.00":
"ANOI":anoiBssFunction
"ANOI":anoiBsc
"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

ED
02
Released
9654m21r.doc
09/04/2010
18/35

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

ED
02
Released
9654m21r.doc
09/04/2010
19/35

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
Figure 7: Inheritance hierarchy (M.3100-related part)
2.4.3 Q.751.1-related part

"X.721":top
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":
"X.721":logRecord
"GSM 12.00":
simpleFileTransferControl
"M.3100":
network
"ANOI":anoiPlmnNetwork
"X.721":alarmRecord
"GSM 12.00":
bulkTransferErrorRecord
"GSM 12.00":
transferReadyRecord
Figure 9: Inheritance hierarchy (GSM 12.00-related part)

ED
02
Released
9654m21r.doc
09/04/2010
20/35

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
Figure 10: Inheritance hierarchy (GSM 12.20-related part)

ED
02
Released
9654m21r.doc
09/04/2010
21/35

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

ED
02
Released
9654m21r.doc
09/04/2010
22/35

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.
02 Released
9654m21r.doc
09/04/2010
23/35

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"
ED
02
Released
9654m21r.doc
09/04/2010
24/35

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:
ED
02
Released
9654m21r.doc
09/04/2010
25/35

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].
ED
02
Released
9654m21r.doc
09/04/2010
26/35

perceivedSeverity
thresholdInfo
stateChangeDefinition
monitoredAttributes
proposedRepairActions
additionalText
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.
This sub-field, if present, identifies state changes
associated with the alarm.
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
This sub-field, if present, contains a free form text
intended for human readers.
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
ED
02
Released
9654m21r.doc
09/04/2010
27/35

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
ED
02 Released
9654m21r.doc
09/04/2010
28/35

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

ED
02
Released
9654m21r.doc
09/04/2010
29/35

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.

ED
02
Released
9654m21r.doc
09/04/2010
30/35

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.
02 Released
9654m21r.doc
09/04/2010
31/35

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.
ED
02
Released
9654m21r.doc
09/04/2010
32/35

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

ED
02
Released
9654m21r.doc
09/04/2010
33/35

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

ED
02
Released
9654m21r.doc
09/04/2010
34/35

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

ED
02
Released
9654m21r.doc
09/04/2010
35/35

Profile For The NMC/9153 OMC-R Q3 Interface ED 02 Released

Uploaded by

Document Informationclick to expand document information

Copyright:

Available Formats

Profile For The NMC/9153 OMC-R Q3 Interface ED 02 Released

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Profile For The NMC/9153 OMC-R Q3 Interface ED 02 Released

Uploaded by

Copyright:

Available Formats

All rights reserved.

Passing on and copying of this

Profile for the NMC/9153 OMC-R Q3 Interface

Profile for the NMC/9153 OMC-R Q3 Interface

3BK 09654 MAAA PBZZA

All rights reserved. Passing on and copying of this

SYSTEM FUNCTIONAL BLOCKS

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

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

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

3BK 09654 MAAA PBZZA

All rights reserved. Passing on and copying of this

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

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

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

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

Profile for the NMC/9153 OMC-R Q3 Interface

3BK 09654 MAAA PBZZA

All rights reserved. Passing on and copying of this

LIST OF FIGURES AND TABLES

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

B10 is replaced by B11

NMC/9153 OMC-R Q3 INFORMATION MODEL PRESENTATION

15/05/2009: No technical changes.

Introducing ExNe Q3 integration

NMC/9153 OMC-R Q3 INFORMATION MODEL PRESENTATION

Information technology - Telecommunications and information

Profile for the NMC/9153 OMC-R Q3 Interface

3BK 09654 MAAA PBZZA

All rights reserved. Passing on and copying of this

Information Technology - Open Systems Interconnection Structure of

Information Technology - Open Systems Interconnection - Systems

Information Technology - Open Systems Interconnection - Systems

Information Technology - Open Systems Interconnection - Systems

Information Technology - Open Systems Interconnection - Systems

Information Technology - Open Systems Interconnection - Systems

Maintenance: Telecommunications Management Network - Generic

Specifications of Signalling System No. 7 - Q3 interface

Specifications of Signalling System No. 7 - Q3 interface

Digital cellular telecommunications system (Phase 2);

3BK 09654 MAAA PBZZA

All rights reserved. Passing on and copying of this

Digital cellular telecommunications system (Phase 2);

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

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

NMC/9153 OMC-R Q3 Interface:

9153 OMC-R Configuration Import/Export interface

9153 OMC-R Configuration Import/Export Interface: Supplementary

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

Overview and Conformance

Information Technology - Open Systems Interconnection- Structure of

Profile for the NMC/9153 OMC-R Q3 Interface

3BK 09654 MAAA PBZZA

All rights reserved. Passing on and copying of this

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

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

1.2 Presentation of the 9153 OMC-R external interfaces

The NMC/9153 OMC-R Q3 interface