MAAAe 01

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

9654m1re.doc
15/05/2009

3BK 09654 MAAA PBZZA 1/1

A
l
l

r
i
g
h
t
s

r
e
s
e
r
v
e
d
.

P
a
s
s
i
n
g

o
n

a
n
d

c
o
p
y
i
n
g

o
f

t
h
i
s

d
o
c
u
m
e
n
t
,

u
s
e

a
n
d

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

o
f

i
t
s

c
o
n
t
e
n
t
s

n
o
t

p
e
r
m
i
t
t
e
d

w
i
t
h
o
u
t

w
r
i
t
t
e
n

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

f
r
o
m

A
l
c
a
t
e
l
.

Release B11

ED 01 RELEASED

9654m1re.doc
15/05/2009


A
l
l

r
i
g
h
t
s

r
e
s
e
r
v
e
d
.

P
a
s
s
i
n
g

o
n

a
n
d

c
o
p
y
i
n
g

o
f

t
h
i
s

d
o
c
u
m
e
n
t
,

u
s
e

a
n
d

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

o
f

i
t
s

c
o
n
t
e
n
t
s

n
o
t

p
e
r
m
i
t
t
e
d

w
i
t
h
o
u
t

w
r
i
t
t
e
n

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

f
r
o
m

A
l
c
a
t
e
l
.

SYSTEM FUNCTIONAL BLOCKS

TABLE OF CONTENTS
1. INTRODUCTION............................................................................................... 6
1.1 The requirements................................................................................... 6
1.2 Presentation of the 9153 OMC-R external interfaces.......................... 6
1.3 Scope of the document ......................................................................... 7
1.4 Common Conventions........................................................................... 8
1.5 Configuration Parameters..................................................................... 8
2. NMC/9153 OMC-R 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 .........................................................13
2.2.4 The Equipment Fragment .............................................................14
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/9153 OMC-R interface ..............23
4.1.2 Services supported at other 9153 OMC-R 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 Introduction.....................................................................................................25
4.2.3.2 Main fields of an alarm message.....................................................................26
4.2.3.3 Relationship attributes.....................................................................................28
4.3 Event Report Management and Log Control ..................................... 28
4.3.1 Introduction ...................................................................................28

ED 01 RELEASED

9654m1re.doc
15/05/2009


A
l
l

r
i
g
h
t
s

r
e
s
e
r
v
e
d
.

P
a
s
s
i
n
g

o
n

a
n
d

c
o
p
y
i
n
g

o
f

t
h
i
s

d
o
c
u
m
e
n
t
,

u
s
e

a
n
d

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

o
f

i
t
s

c
o
n
t
e
n
t
s

n
o
t

p
e
r
m
i
t
t
e
d

w
i
t
h
o
u
t

w
r
i
t
t
e
n

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

f
r
o
m

A
l
c
a
t
e
l
.

4.3.2 Event Report Management ...........................................................28
4.3.3 Log Control....................................................................................29
5. 9153 OMC-R /NMC SYSTEM RELATIONSHIPS........................................... 31
5.1 Consistency of the NMC, 9153 OMC-R and BSS databases ............ 31
5.2 The ANOI:associationSurvey notification...................................... 32
5.3 NMC resynchronisation....................................................................... 32
5.3.1 The contexts in which a NMC resynchonisation is required.........32
5.3.1.1 NMC start up...................................................................................................32
5.3.1.2 9153 OMC-R initialization .............................................................................32
5.3.1.3 BSS-NE creation and initialization.................................................................33
5.3.1.4 Upon detection of a problem by a NMC.........................................................33
5.3.2 Configuration resynchronisation ...................................................33
5.3.3 Alarm resynchronisation ...............................................................33
6. ACRONYMS................................................................................................... 35

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

ED 01 RELEASED

9654m1re.doc
15/05/2009


A
l
l

r
i
g
h
t
s

r
e
s
e
r
v
e
d
.

P
a
s
s
i
n
g

o
n

a
n
d

c
o
p
y
i
n
g

o
f

t
h
i
s

d
o
c
u
m
e
n
t
,

u
s
e

a
n
d

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

o
f

i
t
s

c
o
n
t
e
n
t
s

n
o
t

p
e
r
m
i
t
t
e
d

w
i
t
h
o
u
t

w
r
i
t
t
e
n

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

f
r
o
m

A
l
c
a
t
e
l
.

LIST OF FIGURES AND TABLES
Figure 1: 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 Model 18
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..............................................................................13
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.............................................................................27
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.
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
[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

ED 01 RELEASED

9654m1re.doc
15/05/2009


A
l
l

r
i
g
h
t
s

r
e
s
e
r
v
e
d
.

P
a
s
s
i
n
g

o
n

a
n
d

c
o
p
y
i
n
g

o
f

t
h
i
s

d
o
c
u
m
e
n
t
,

u
s
e

a
n
d

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

o
f

i
t
s

c
o
n
t
e
n
t
s

n
o
t

p
e
r
m
i
t
t
e
d

w
i
t
h
o
u
t

w
r
i
t
t
e
n

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

f
r
o
m

A
l
c
a
t
e
l
.

CCITT Rec. X.730 (ISO/IEC 10164-1), 1992
Management:
State Management Function
Management:
Alarm Reporting Function
Management:
Event Report Management Function
CCITT Recommendation X.734 (ISO/IEC 10164-5), 1992
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
[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

ED 01 RELEASED

9654m1re.doc
15/05/2009


A
l
l

r
i
g
h
t
s

r
e
s
e
r
v
e
d
.

P
a
s
s
i
n
g

o
n

a
n
d

c
o
p
y
i
n
g

o
f

t
h
i
s

d
o
c
u
m
e
n
t
,

u
s
e

a
n
d

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

o
f

i
t
s

c
o
n
t
e
n
t
s

n
o
t

p
e
r
m
i
t
t
e
d

w
i
t
h
o
u
t

w
r
i
t
t
e
n

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

f
r
o
m

A
l
c
a
t
e
l
.

the GDMO Formal Specification
[ANOIcs-gene] NMC/9153 OMC-R Q3 Interface: Overview and Conformance
Statements
[ANOIcs-Q3P] NMC/9153 OMC-R Q3 Interface: Q3 Protocol Conformance
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
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 01 RELEASED

9654m1re.doc
15/05/2009


A
l
l

r
i
g
h
t
s

r
e
s
e
r
v
e
d
.

P
a
s
s
i
n
g

o
n

a
n
d

c
o
p
y
i
n
g

o
f

t
h
i
s

d
o
c
u
m
e
n
t
,

u
s
e

a
n
d

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

o
f

i
t
s

c
o
n
t
e
n
t
s

n
o
t

p
e
r
m
i
t
t
e
d

w
i
t
h
o
u
t

w
r
i
t
t
e
n

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

f
r
o
m

A
l
c
a
t
e
l
.

1. INTRODUCTION
1.1 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 01 RELEASED

9654m1re.doc
15/05/2009


A
l
l

r
i
g
h
t
s

r
e
s
e
r
v
e
d
.

P
a
s
s
i
n
g

o
n

a
n
d

c
o
p
y
i
n
g

o
f

t
h
i
s

d
o
c
u
m
e
n
t
,

u
s
e

a
n
d

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

o
f

i
t
s

c
o
n
t
e
n
t
s

n
o
t

p
e
r
m
i
t
t
e
d

w
i
t
h
o
u
t

w
r
i
t
t
e
n

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

f
r
o
m

A
l
c
a
t
e
l
.

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:

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 01 RELEASED

9654m1re.doc
15/05/2009


A
l
l

r
i
g
h
t
s

r
e
s
e
r
v
e
d
.

P
a
s
s
i
n
g

o
n

a
n
d

c
o
p
y
i
n
g

o
f

t
h
i
s

d
o
c
u
m
e
n
t
,

u
s
e

a
n
d

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

o
f

i
t
s

c
o
n
t
e
n
t
s

n
o
t

p
e
r
m
i
t
t
e
d

w
i
t
h
o
u
t

w
r
i
t
t
e
n

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

f
r
o
m

A
l
c
a
t
e
l
.

[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 [ANOIcs-
Q3P].
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
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 01 RELEASED

9654m1re.doc
15/05/2009


A
l
l

r
i
g
h
t
s

r
e
s
e
r
v
e
d
.

P
a
s
s
i
n
g

o
n

a
n
d

c
o
p
y
i
n
g

o
f

t
h
i
s

d
o
c
u
m
e
n
t
,

u
s
e

a
n
d

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

o
f

i
t
s

c
o
n
t
e
n
t
s

n
o
t

p
e
r
m
i
t
t
e
d

w
i
t
h
o
u
t

w
r
i
t
t
e
n

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

f
r
o
m

A
l
c
a
t
e
l
.

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.
Table 2: Configuration Parameters

ED 01 RELEASED

9654m1re.doc
15/05/2009


A
l
l

r
i
g
h
t
s

r
e
s
e
r
v
e
d
.

P
a
s
s
i
n
g

o
n

a
n
d

c
o
p
y
i
n
g

o
f

t
h
i
s

d
o
c
u
m
e
n
t
,

u
s
e

a
n
d

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

o
f

i
t
s

c
o
n
t
e
n
t
s

n
o
t

p
e
r
m
i
t
t
e
d

w
i
t
h
o
u
t

w
r
i
t
t
e
n

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

f
r
o
m

A
l
c
a
t
e
l
.

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

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 configuration-
related 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
name clashes for post-processing tools that do not take into account GDMO labels.

ED 01 RELEASED

9654m1re.doc
15/05/2009


A
l
l

r
i
g
h
t
s

r
e
s
e
r
v
e
d
.

P
a
s
s
i
n
g

o
n

a
n
d

c
o
p
y
i
n
g

o
f

t
h
i
s

d
o
c
u
m
e
n
t
,

u
s
e

a
n
d

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

o
f

i
t
s

c
o
n
t
e
n
t
s

n
o
t

p
e
r
m
i
t
t
e
d

w
i
t
h
o
u
t

w
r
i
t
t
e
n

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

f
r
o
m

A
l
c
a
t
e
l
.

2.2 Splitting into fragments
2.2.1 Introduction

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 splitted 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).
A traffic supervision and a possibility of 2Mbits topology discovery
A traffic supervision independent from the equipment maintenance.

ED 01 RELEASED

9654m1re.doc
15/05/2009


A
l
l

r
i
g
h
t
s

r
e
s
e
r
v
e
d
.

P
a
s
s
i
n
g

o
n

a
n
d

c
o
p
y
i
n
g

o
f

t
h
i
s

d
o
c
u
m
e
n
t
,

u
s
e

a
n
d

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

o
f

i
t
s

c
o
n
t
e
n
t
s

n
o
t

p
e
r
m
i
t
t
e
d

w
i
t
h
o
u
t

w
r
i
t
t
e
n

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

f
r
o
m

A
l
c
a
t
e
l
.

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

ED 01 RELEASED

9654m1re.doc
15/05/2009


A
l
l

r
i
g
h
t
s

r
e
s
e
r
v
e
d
.

P
a
s
s
i
n
g

o
n

a
n
d

c
o
p
y
i
n
g

o
f

t
h
i
s

d
o
c
u
m
e
n
t
,

u
s
e

a
n
d

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

o
f

i
t
s

c
o
n
t
e
n
t
s

n
o
t

p
e
r
m
i
t
t
e
d

w
i
t
h
o
u
t

w
r
i
t
t
e
n

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

f
r
o
m

A
l
c
a
t
e
l
.

One "ANOI":anoiGPRSManagedElement managed object instance per GPRS BSS-
NE.
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.
The complete list of the corresponding MOCs is as follows:

MOC name Related
standard
Purpose
"X.721":alarmRecord X.721 Alarm Reporting and
Acknowledgement
"ANOI":anoiCoreManagedElement M.3100 Core BSS-NE management
(see above)
"ANOI":anoiGPRSManagedElement M.3100 GPRS BSS-NE management
(see above)
"ANOI":anoiManagedElement M.3100 BSS-NE management
(Abstract Class)
"ANOI":anoiPlmnNetwork GSM 12.00 GSM Common Functions
"ANOI":associationSurveyRecord X.721 File Transfer Control
"X.721":attributeValueChangeRecord X.721 Object Management
"GSM 12.00":bulkTransferErrorRecord GSM 12.00 File Transfer Control
"X.721":discriminator X.721 Event Report Management
(Abstract Class)
"X.721":eventForwardingDiscriminator X.721 Event Report Management
"X.721":eventLogRecord X.721 Log Control (Abstract Class)
"GSM 12.00":
generalDataTransferControlFunction
GSM 12.00 File Transfer Control
"X.721":log X.721 Log Control
"X.721":logRecord X.721 Log Control (Abstract Class)
"M.3100":managedElement M.3100 BSS-NE management
(Abstract Class)
"M.3100":network M.3100 GSM Common Functions
(Abstract Class)
"X.721":objectCreationRecord X.721 Log Control
"X.721":objectDeletionRecord X.721 Log Control
"GSM 12.00":simpleFileTransferControl GSM 12.00 File Transfer Control
"X.721":stateChangeRecord X.721 State Management
"X.721":system X.721 Event Report Management
Log Control
"X.721":top X.721 Inheritance root
"GSM 12.00":transferReadyRecord GSM 12.00 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.

ED 01 RELEASED

9654m1re.doc
15/05/2009


A
l
l

r
i
g
h
t
s

r
e
s
e
r
v
e
d
.

P
a
s
s
i
n
g

o
n

a
n
d

c
o
p
y
i
n
g

o
f

t
h
i
s

d
o
c
u
m
e
n
t
,

u
s
e

a
n
d

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

o
f

i
t
s

c
o
n
t
e
n
t
s

n
o
t

p
e
r
m
i
t
t
e
d

w
i
t
h
o
u
t

w
r
i
t
t
e
n

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

f
r
o
m

A
l
c
a
t
e
l
.

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 modelling 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 Related
standard
Purpose
"ANOI":anoiSignLinkSetTp Q.751.1 SS No.7
"ANOI":anoiSignLinkTp Q.751.1 SS No.7
"ANOI":anoiTerminationPointBidirectional M.3100 2Mb termination points
"M.3100":connectionR1 M.3100 Abis or AterMux PCM
Circuits
"Q.751.1":mtpSignPoint Q.751.1 SS No.7
"M.3100":terminationPoint M.3100 2Mb termination points
(Abstract Class)
Table 4: MOCs of the Transmission fragment
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

ED 01 RELEASED

9654m1re.doc
15/05/2009


A
l
l

r
i
g
h
t
s

r
e
s
e
r
v
e
d
.

P
a
s
s
i
n
g

o
n

a
n
d

c
o
p
y
i
n
g

o
f

t
h
i
s

d
o
c
u
m
e
n
t
,

u
s
e

a
n
d

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

o
f

i
t
s

c
o
n
t
e
n
t
s

n
o
t

p
e
r
m
i
t
t
e
d

w
i
t
h
o
u
t

w
r
i
t
t
e
n

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

f
r
o
m

A
l
c
a
t
e
l
.

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 Related
standard
Purpose
"ANOI":anoiCircuitPack M.3100 Equipment Management
"ANOI":anoiEquipmentR1 M.3100 Equipment Management
"M.3100":equipment M.3100 Equipment Management
(Abstract Class)
"M.3100":equipmentHolder M.3100 Equipment Management
"M.3100":equipmentR1 M.3100 Equipment Management
(Abstract Class)
"M.3100":pipe M.3100 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
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 Related
standard
Purpose
"ANOI":anoiBsc GSM 12.20 See above
"ANOI":anoiBssFunction GSM 12.00 See above

ED 01 RELEASED

9654m1re.doc
15/05/2009


A
l
l

r
i
g
h
t
s

r
e
s
e
r
v
e
d
.

P
a
s
s
i
n
g

o
n

a
n
d

c
o
p
y
i
n
g

o
f

t
h
i
s

d
o
c
u
m
e
n
t
,

u
s
e

a
n
d

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

o
f

i
t
s

c
o
n
t
e
n
t
s

n
o
t

p
e
r
m
i
t
t
e
d

w
i
t
h
o
u
t

w
r
i
t
t
e
n

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

f
r
o
m

A
l
c
a
t
e
l
.

MOC name Related
standard
Purpose
"ANOI":anoiBts GSM 12.20 See above
"ANOI":anoiBtsSiteManager GSM 12.20 See above
"ANOI":anoiLapdLink GSM 12.20 See above
"GSM 12.00":bssFunction GSM 12.00 Abstract Class
"GSM 12.20":btsSiteManager GSM 12.20 Abstract Class
"GSM 12.20":gsmManagedFunction GSM 12.20 Abstract Class
Table 6: MOCs of the bssFunction fragment

ED 01 RELEASED

9654m1re.doc
15/05/2009


A
l
l

r
i
g
h
t
s

r
e
s
e
r
v
e
d
.

P
a
s
s
i
n
g

o
n

a
n
d

c
o
p
y
i
n
g

o
f

t
h
i
s

d
o
c
u
m
e
n
t
,

u
s
e

a
n
d

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

o
f

i
t
s

c
o
n
t
e
n
t
s

n
o
t

p
e
r
m
i
t
t
e
d

w
i
t
h
o
u
t

w
r
i
t
t
e
n

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

f
r
o
m

A
l
c
a
t
e
l
.

2.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": system

"X.721":
eventForwardingDiscriminator

"X.721":log

"X.721":
alarmRecord
"X.721":
attributeValueChangeRecord
"X.721":
objectCreationRecord

"X.721":
objectDeletionRecord
"X.721":
stateChangeRecord

"GSM 12.00":
bulkTransferErrorRecord
"GSM 12.00":
transferReadyRecord
"ANOI":association
SurveyRecord

"ANOI":
anoiCoreManagedElement

"ANOI":
anoiGPRSManagedElement

ED 01 RELEASED

9654m1re.doc
15/05/2009


A
l
l

r
i
g
h
t
s

r
e
s
e
r
v
e
d
.

P
a
s
s
i
n
g

o
n

a
n
d

c
o
p
y
i
n
g

o
f

t
h
i
s

d
o
c
u
m
e
n
t
,

u
s
e

a
n
d

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

o
f

i
t
s

c
o
n
t
e
n
t
s

n
o
t

p
e
r
m
i
t
t
e
d

w
i
t
h
o
u
t

w
r
i
t
t
e
n

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

f
r
o
m

A
l
c
a
t
e
l
.

"ANOI":
anoiEquipmentR1

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

"M.3100":
equipmentHolder (Rack)
"ANOI":anoiTerminationPoint
Bidirectional

"ANOI":anoiFunction
Coordinator
"ANOI":
anoiSignLinkSetTp

"M.3100":
equipmentHolder (Shelf)

"ANOI":anoiFunction
"ANOI":
anoiSignLinkTp

"ANOI":anoiCircuitPack

"ANOI":anoiBssFunction

"GSM 12.00":

"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

ED 01 RELEASED

9654m1re.doc
15/05/2009


A
l
l

r
i
g
h
t
s

r
e
s
e
r
v
e
d
.

P
a
s
s
i
n
g

o
n

a
n
d

c
o
p
y
i
n
g

o
f

t
h
i
s

d
o
c
u
m
e
n
t
,

u
s
e

a
n
d

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

o
f

i
t
s

c
o
n
t
e
n
t
s

n
o
t

p
e
r
m
i
t
t
e
d

w
i
t
h
o
u
t

w
r
i
t
t
e
n

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

f
r
o
m

A
l
c
a
t
e
l
.

2.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":system

"X.721":eventLogRecord

"X.721":eventForwardingDiscriminator

"X.721":alarmRecord
"X.721":
attributeValueChangeRecord
"X.721":
objectCreationRecord

"X.721":
objectDeletionRecord

"X.721":
stateChangeRecord
"ANOI":
associationSurveyRecord

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

ED 01 RELEASED

9654m1re.doc
15/05/2009


A
l
l

r
i
g
h
t
s

r
e
s
e
r
v
e
d
.

P
a
s
s
i
n
g

o
n

a
n
d

c
o
p
y
i
n
g

o
f

t
h
i
s

d
o
c
u
m
e
n
t
,

u
s
e

a
n
d

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

o
f

i
t
s

c
o
n
t
e
n
t
s

n
o
t

p
e
r
m
i
t
t
e
d

w
i
t
h
o
u
t

w
r
i
t
t
e
n

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

f
r
o
m

A
l
c
a
t
e
l
.

2.4.2 M.3100-related part
"X.721":top

"M.3100":
pipe
"M.3100":
equipment
"ANOI":
anoiManagedElement
"M.3100":
network
"M.3100":
terminationPoint

"M.3100":
connectionR1
"ANOI":anoiTerminationPoint
Bidirectional

"M.3100":
equipmentR1
"ANOI":
anoiCoreManagedElement
"ANOI":
anoiGPRSManagedElement

"ANOI":
anoiCircuitPack
"ANOI":
anoiEquipmentR1

"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":
"GSM 12.00":
simpleFileTransferControl
"M.3100":
network

"X.721":logRecord

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

ED 01 RELEASED

9654m1re.doc
15/05/2009


A
l
l

r
i
g
h
t
s

r
e
s
e
r
v
e
d
.

P
a
s
s
i
n
g

o
n

a
n
d

c
o
p
y
i
n
g

o
f

t
h
i
s

d
o
c
u
m
e
n
t
,

u
s
e

a
n
d

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

o
f

i
t
s

c
o
n
t
e
n
t
s

n
o
t

p
e
r
m
i
t
t
e
d

w
i
t
h
o
u
t

w
r
i
t
t
e
n

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

f
r
o
m

A
l
c
a
t
e
l
.

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

ED 01 RELEASED

9654m1re.doc
15/05/2009


A
l
l

r
i
g
h
t
s

r
e
s
e
r
v
e
d
.

P
a
s
s
i
n
g

o
n

a
n
d

c
o
p
y
i
n
g

o
f

t
h
i
s

d
o
c
u
m
e
n
t
,

u
s
e

a
n
d

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

o
f

i
t
s

c
o
n
t
e
n
t
s

n
o
t

p
e
r
m
i
t
t
e
d

w
i
t
h
o
u
t

w
r
i
t
t
e
n

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

f
r
o
m

A
l
c
a
t
e
l
.

3. 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
CLNS1: A connectionless-mode interface using [ISO/IEC 8802-2] type
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 01 RELEASED

9654m1re.doc
15/05/2009


A
l
l

r
i
g
h
t
s

r
e
s
e
r
v
e
d
.

P
a
s
s
i
n
g

o
n

a
n
d

c
o
p
y
i
n
g

o
f

t
h
i
s

d
o
c
u
m
e
n
t
,

u
s
e

a
n
d

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

o
f

i
t
s

c
o
n
t
e
n
t
s

n
o
t

p
e
r
m
i
t
t
e
d

w
i
t
h
o
u
t

w
r
i
t
t
e
n

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

f
r
o
m

A
l
c
a
t
e
l
.

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

ED 01 RELEASED

9654m1re.doc
15/05/2009


A
l
l

r
i
g
h
t
s

r
e
s
e
r
v
e
d
.

P
a
s
s
i
n
g

o
n

a
n
d

c
o
p
y
i
n
g

o
f

t
h
i
s

d
o
c
u
m
e
n
t
,

u
s
e

a
n
d

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

o
f

i
t
s

c
o
n
t
e
n
t
s

n
o
t

p
e
r
m
i
t
t
e
d

w
i
t
h
o
u
t

w
r
i
t
t
e
n

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

f
r
o
m

A
l
c
a
t
e
l
.

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"
network. The time synchronisation (in case of large shift) is performed by several
little steps.

ED 01 RELEASED

9654m1re.doc
15/05/2009


A
l
l

r
i
g
h
t
s

r
e
s
e
r
v
e
d
.

P
a
s
s
i
n
g

o
n

a
n
d

c
o
p
y
i
n
g

o
f

t
h
i
s

d
o
c
u
m
e
n
t
,

u
s
e

a
n
d

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

o
f

i
t
s

c
o
n
t
e
n
t
s

n
o
t

p
e
r
m
i
t
t
e
d

w
i
t
h
o
u
t

w
r
i
t
t
e
n

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

f
r
o
m

A
l
c
a
t
e
l
.

4.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.
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.
4.2.2 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:
X.721:communicationsAlarm
X.721:environmentalAlarm
X.721:equipmentAlarm
X.721:processingErrorAlarm

ED 01 RELEASED

9654m1re.doc
15/05/2009


A
l
l

r
i
g
h
t
s

r
e
s
e
r
v
e
d
.

P
a
s
s
i
n
g

o
n

a
n
d

c
o
p
y
i
n
g

o
f

t
h
i
s

d
o
c
u
m
e
n
t
,

u
s
e

a
n
d

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

o
f

i
t
s

c
o
n
t
e
n
t
s

n
o
t

p
e
r
m
i
t
t
e
d

w
i
t
h
o
u
t

w
r
i
t
t
e
n

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

f
r
o
m

A
l
c
a
t
e
l
.

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.
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
probableCause This sub-field indicates the probable cause of the alarm
as an OID value.
The set of probableCause values that can be used are
defined in [ANOIgdmo]. These values are all standard
ones.
specificProblems This sub-field is a list of integers that are such that an
alarm emitted by a given object instance with a
perceivedSeverity field equal to 'cleared' can safely clear
the alarms for that managed object instance that have
the same eventType, probableCause and
specificProblems field values.
For more information, see [ANOIcs-gene].
perceivedSeverity This sub-field indicates the perceived severity of the
alarm (indeterminate, critical, major, minor, warning or
cleared).
thresholdInfo This sub-field may only be present for a
qualityofServiceAlarm notification. . If present, it
indicates corresponding threshold information.

ED 01 RELEASED

9654m1re.doc
15/05/2009


A
l
l

r
i
g
h
t
s

r
e
s
e
r
v
e
d
.

P
a
s
s
i
n
g

o
n

a
n
d

c
o
p
y
i
n
g

o
f

t
h
i
s

d
o
c
u
m
e
n
t
,

u
s
e

a
n
d

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

o
f

i
t
s

c
o
n
t
e
n
t
s

n
o
t

p
e
r
m
i
t
t
e
d

w
i
t
h
o
u
t

w
r
i
t
t
e
n

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

f
r
o
m

A
l
c
a
t
e
l
.

FIELD/SUB-FIELD NAME COMMENTS
stateChangeDefinition This sub-field, if present, identifies state changes
associated with the alarm.
monitoredAttributes 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].
proposedRepairActions 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
additionalText This sub-field, if present, contains a free form text
intended for human readers.
additionalInformation 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
ALARM_ACKNOWLEDGEMENT = 1).
For more information, see [ANOIgdmo] and [ANOIcs-
gene].
Table 7: Main fields of an alarm message
N.B.: The reference for the aforementioned information is [ANOIgdmo] and [ANOIcs-
gene].

ED 01 RELEASED

9654m1re.doc
15/05/2009


A
l
l

r
i
g
h
t
s

r
e
s
e
r
v
e
d
.

P
a
s
s
i
n
g

o
n

a
n
d

c
o
p
y
i
n
g

o
f

t
h
i
s

d
o
c
u
m
e
n
t
,

u
s
e

a
n
d

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

o
f

i
t
s

c
o
n
t
e
n
t
s

n
o
t

p
e
r
m
i
t
t
e
d

w
i
t
h
o
u
t

w
r
i
t
t
e
n

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

f
r
o
m

A
l
c
a
t
e
l
.

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

ED 01 RELEASED

9654m1re.doc
15/05/2009


A
l
l

r
i
g
h
t
s

r
e
s
e
r
v
e
d
.

P
a
s
s
i
n
g

o
n

a
n
d

c
o
p
y
i
n
g

o
f

t
h
i
s

d
o
c
u
m
e
n
t
,

u
s
e

a
n
d

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

o
f

i
t
s

c
o
n
t
e
n
t
s

n
o
t

p
e
r
m
i
t
t
e
d

w
i
t
h
o
u
t

w
r
i
t
t
e
n

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

f
r
o
m

A
l
c
a
t
e
l
.

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]
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
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 [ANOIcs-
gene]),
X.721:discriminatorConstruct,
"X.721":logFullAction

ED 01 RELEASED

9654m1re.doc
15/05/2009


A
l
l

r
i
g
h
t
s

r
e
s
e
r
v
e
d
.

P
a
s
s
i
n
g

o
n

a
n
d

c
o
p
y
i
n
g

o
f

t
h
i
s

d
o
c
u
m
e
n
t
,

u
s
e

a
n
d

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

o
f

i
t
s

c
o
n
t
e
n
t
s

n
o
t

p
e
r
m
i
t
t
e
d

w
i
t
h
o
u
t

w
r
i
t
t
e
n

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

f
r
o
m

A
l
c
a
t
e
l
.

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]
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 01 RELEASED

9654m1re.doc
15/05/2009


A
l
l

r
i
g
h
t
s

r
e
s
e
r
v
e
d
.

P
a
s
s
i
n
g

o
n

a
n
d

c
o
p
y
i
n
g

o
f

t
h
i
s

d
o
c
u
m
e
n
t
,

u
s
e

a
n
d

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

o
f

i
t
s

c
o
n
t
e
n
t
s

n
o
t

p
e
r
m
i
t
t
e
d

w
i
t
h
o
u
t

w
r
i
t
t
e
n

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

f
r
o
m

A
l
c
a
t
e
l
.

5. 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:
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 BSS-
NE 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.

ED 01 RELEASED

9654m1re.doc
15/05/2009


A
l
l

r
i
g
h
t
s

r
e
s
e
r
v
e
d
.

P
a
s
s
i
n
g

o
n

a
n
d

c
o
p
y
i
n
g

o
f

t
h
i
s

d
o
c
u
m
e
n
t
,

u
s
e

a
n
d

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

o
f

i
t
s

c
o
n
t
e
n
t
s

n
o
t

p
e
r
m
i
t
t
e
d

w
i
t
h
o
u
t

w
r
i
t
t
e
n

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

f
r
o
m

A
l
c
a
t
e
l
.

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 01 RELEASED

9654m1re.doc
15/05/2009


A
l
l

r
i
g
h
t
s

r
e
s
e
r
v
e
d
.

P
a
s
s
i
n
g

o
n

a
n
d

c
o
p
y
i
n
g

o
f

t
h
i
s

d
o
c
u
m
e
n
t
,

u
s
e

a
n
d

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

o
f

i
t
s

c
o
n
t
e
n
t
s

n
o
t

p
e
r
m
i
t
t
e
d

w
i
t
h
o
u
t

w
r
i
t
t
e
n

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

f
r
o
m

A
l
c
a
t
e
l
.

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

ED 01 RELEASED

9654m1re.doc
15/05/2009


A
l
l

r
i
g
h
t
s

r
e
s
e
r
v
e
d
.

P
a
s
s
i
n
g

o
n

a
n
d

c
o
p
y
i
n
g

o
f

t
h
i
s

d
o
c
u
m
e
n
t
,

u
s
e

a
n
d

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

o
f

i
t
s

c
o
n
t
e
n
t
s

n
o
t

p
e
r
m
i
t
t
e
d

w
i
t
h
o
u
t

w
r
i
t
t
e
n

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

f
r
o
m

A
l
c
a
t
e
l
.

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

ED 01 RELEASED

9654m1re.doc
15/05/2009


A
l
l

r
i
g
h
t
s

r
e
s
e
r
v
e
d
.

P
a
s
s
i
n
g

o
n

a
n
d

c
o
p
y
i
n
g

o
f

t
h
i
s

d
o
c
u
m
e
n
t
,

u
s
e

a
n
d

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

o
f

i
t
s

c
o
n
t
e
n
t
s

n
o
t

p
e
r
m
i
t
t
e
d

w
i
t
h
o
u
t

w
r
i
t
t
e
n

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

f
r
o
m

A
l
c
a
t
e
l
.

6. ACRONYMS
ACIE Alcatel-Lucent 9153 OMC-R Configuration Import/Export interface
ACOM 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.
ANOI 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
ASN1 Abstract Syntax Notation One
BOC baseManagedObjectClass argument of a CMIS M-GET request
BOI baseManagedObjectInstance argument of a CMIS M-GET request
BSC Base Station Controller
BSS Base Station Subsystem
BSS-NE Base Station Subsystem Network Element
BTS Base Transceiver Station
CLNS Connectionless Network Layer Service
CMISE Common Management Information Service Element
CSMA/CD Carrier Sense Multiple Access with Collision Detection
CONS Connection-mode Network Layer Service
GDMO Guidelines for the Definition of Managed Objects
GPRS General Packet Radio Service
GSM Global System for Mobile communications
(whichever technology, i.e. either Circuit-Switched or Packet-Switched)
IP Inter-networking Protocol
LAN Local Area Network
MOC Managed Object Class
MOI Managed Object Instance
NMC Network Management Centre
O&M Operation and Maintenance
OMC-R Operation and Maintenance Centre Radio
SW Software
TCP Transmission Control Protocol
END OF DOCUMENT

MAAAe 01

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

MAAAe 01

Uploaded by

Copyright:

Available Formats

Profile for the NMC/9153 OMC-R Q3 Interface

You might also like