Profile For The NMC/A1353-RA Q3 Interface

Profile for the NMC/A1353-RA Q3 Interface
ED 01 RELEASED
Evolium
9654l1re.doc
01/10/2007

3BK 09654 LAAA 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
.

(B10 onwards)

ED 01 RELEASED
Evolium
9654l1re.doc
01/10/2007


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 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 ........................................................ 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/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 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
Evolium
9654l1re.doc
01/10/2007


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. A1353-RA/NMC SYSTEM RELATIONSHIPS ................................................ 31
5.1 Consistency of the NMC, A1353-RA 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 A1353-RA 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 070924 First issue O&M System TD/O&M/OMC-R Spec
ED DATE CHANGE NOTE APPRAISAL AUTHORITY ORIGINATOR

ED 01 RELEASED
Evolium
9654l1re.doc
01/10/2007


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 A1353-RA external interfaces ...........................................................................7
Figure 2: NMC/A1353-RA Q3 versus standard information models......................................10
Figure 3: The A1353-RA instance and the sub-network managed by it ................................11
Figure 4: General Naming Tree for the NMC/A1353-RA 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
05/09/2007: Creation from 3BK 09654 JAAA PBZZA Ed.02 Released.
General Changes
B9 is replaced by B10
The REFERENCED DOCUMENTS part is updated for B10 together with the
corresponding references in the body of the document.
NMC/A1353-RA Q3 INFORMATION MODEL PRESENTATION
Naming Tree
Complement for GPRS Alarms Reporting
"AGVC":aGprsSgsnIpEndPoint is added.
24/09/2007: 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
Evolium
9654l1re.doc
01/10/2007


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 documents
[ANOIgdmo] NMC/A1353-RA Q3 Interface: GDMO Formal Specification
3BK 09707 AAA PBZZA
[ANOIappli] NMC/A1353-RA Q3 Interface: Position with respect to standards of the

ED 01 RELEASED
Evolium
9654l1re.doc
01/10/2007


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
.

GDMO Formal Specification
3BK 09708 AAA PBZZA
[ANOIcs-gene] NMC/A1353-RA Q3 Interface: Overview and Conformance Statements
3BK 09709 AAA PBZZA
[ANOIcs-Q3P] NMC/A1353-RA Q3 Interface: Q3 Protocol Conformance Statements
3BK 09772 AAA PBZZA
[ACIE-gene] A1353-RA Configuration Import/Export interface
For Release B:
3BK 09661 AAA PBZZA
[ACIE-si] A1353-RA Configuration Import/Export Interface: Supplementary
Information
For Release B:
3BK 09773 AAA PBZZA
[ANIE] A1353-RA Import/Export Interface for client nodeIdentifier values
For Release B8 (onward):
3BK 09797 HAAA 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
Evolium
9654l1re.doc
01/10/2007


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 A1353-RA 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 A1353-RA release independent
as possible in order to avoid the development of NMC proxies for each A1353-RA 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 A1353-RA since the number of objects
handled by this new Alcatel OMC-R is great and could increase; in particular, the
A1353-RA manages up to 3600 cells.
As a consequence, the strategy adopted by the A1353-RA 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 A1353-RA external interfaces
The A1353-RA has several external interfaces:
The NMC/A1353-RA 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 A1353-RA 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 A1353 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, ....).
An example of such an interface is the A1353-RA Configuration Import/Export (ACIE)
interface. This interface enables to:

ED 01 RELEASED
Evolium
9654l1re.doc
01/10/2007


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
.

Import whole or part of the A1353-RA Radio Network Level (externally accessible)
configuration data.
Export whole (or part for an external application other than a NMC) of the A1353-
RA (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/A1353-RA 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:
Import files
transfer
Export files
transfer
File upload
control
CMIS operation
requests
CMIS operation
responses
A1353-RA
Radio Network Level
BSS-NE Level Q3
External
Interface
File-based
External
Interfaces
NMCs

Figure 1: The A1353-RA external interfaces
1.3 Scope of the document
This document deals with the NMC/A1353-RA 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/1353 RA Q3 Information model. These documents are the following:
[ANOIgdmo] for the GDMO Formal Specification.
[ANOIappli] for the position with respect to standards of this GDMO Formal
Specification.

ED 01 RELEASED
Evolium
9654l1re.doc
01/10/2007


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
.

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

P
r
o
f
i
l
e

f
o
r

t
h
e

N
M
C
/
A
1
3
5
3
-
R
A

Q
3

I
n
t
e
r
f
a
c
e

E
D

0
1

R
E
L
E
A
S
E
D

E
v
o
l
i
u
m

9
6
5
4
l
1
r
e
.
d
o
c

0
1
/
1
0
/
2
0
0
7

3
B
K

0
9
6
5
4

L
A
A
A

P
B
Z
Z
A

9
/
3
5

All rights reserved. Passing on and copying of this
document, use and communication of its contents
not permitted without written authorization from Alcatel.

T
a
b
l
e

2
:

C
o
n
f
i
g
u
r
a
t
i
o
n

P
a
r
a
m
e
t
e
r
s

ED 01 RELEASED
Evolium
9654l1re.doc
01/10/2007


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/A1353-RA Q3 INFORMATION MODEL PRESENTATION
2.1 Information model policy
Broadly speaking, the NMC/A1353 Q3 information model provides a supervision
management view of the A1353-RA internal information model.
This NMC/A1353 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 A1353-RA releases;
takes only the supervision part of these standards, i.e. the managed objects at the
NMC/A1353-RA 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:
Configuration
Supervision
Supervision
Standard
Information Model
NMC/A1353-RA Q3
Information Model

Figure 2: NMC/A1353-RA Q3 versus standard information models
Moreover, the NMC/A1353-RA 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/A1353-RA 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
Evolium
9654l1re.doc
01/10/2007


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
BSC
BTS
BTS
BTS
(Core) BSS-NE
BSC
BTS
BTS
BTS
(Core) BSS-NE
BSC
BTS
BTS
BTS
(Core) BSS-NE
A1353-RA managed sub-network
A1353-RA instance
A9135 managed
sub-network
GPRS BSS-NE
DCN
A9135 managed
sub-network
GPRS BSS-NE
The GPRS-specific part The core part

Figure 3: The A1353-RA instance and the sub-network managed by it
A A1353-RA 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
Evolium
9654l1re.doc
01/10/2007


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
A9135 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
Evolium
9654l1re.doc
01/10/2007


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 A1353-RA managed sub-network, i.e. all the alarms emitted by managed object
instances at the A1353-RA/A9135 internal interface are mapped onto alarms emitted by
the corresponding "ANOI":anoiGPRSManagedElement managed object instance at
the NMC/A1353-RA 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
Evolium
9654l1re.doc
01/10/2007


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
Evolium
9654l1re.doc
01/10/2007


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 A1353-RA/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 A1353-RA 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
Evolium
9654l1re.doc
01/10/2007


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
Evolium
9654l1re.doc
01/10/2007


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/A1353-RA 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
Evolium
9654l1re.doc
01/10/2007


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/A1353-RA Q3 Interface Information Model

ED 01 RELEASED
Evolium
9654l1re.doc
01/10/2007


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)

"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
Evolium
9654l1re.doc
01/10/2007


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
Evolium
9654l1re.doc
01/10/2007


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
Evolium
9654l1re.doc
01/10/2007


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/A1353-RA 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/A1353-RA Q3 Interface (Session and Presentation layers, ACSE,
ROSE and CMISE).

ED 01 RELEASED
Evolium
9654l1re.doc
01/10/2007


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/A1353-RA interface
At the NMC/A1353-RA 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
A1353-RA 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
Evolium
9654l1re.doc
01/10/2007


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 A1353-RA configuration data:
It is possible to request and transfer in a controlled way the A1353-RA 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 A1353-RA 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/A1353-RA Q3 interface. Such an attribute value change can be
requested
either directly by a A1353-RA operator;
or via an import session
(at Network Level) at the A1353-RA 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 A1353-RA 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 A1353-RA instance at the
NMC/A1353-RA Q3 interface nor at the A1353-RA Configuration Import/Export interface. A
NMC can use the same UNIX routine as the one used by the A1353-RA 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
Evolium
9654l1re.doc
01/10/2007


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/A1353-RA 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 A1353-RA) 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 A1353-RA) 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
Evolium
9654l1re.doc
01/10/2007


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
Evolium
9654l1re.doc
01/10/2007


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/A1353-RA 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
Evolium
9654l1re.doc
01/10/2007


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
A1353-RA. 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/A1353-RA 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 A1353-RA operator.
The other requests that are allowed for a NMC are as follows:
M-GET on all attributes
M-SET on:

ED 01 RELEASED
Evolium
9654l1re.doc
01/10/2007


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 A1353-RA 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 A1353-RA 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
Evolium
9654l1re.doc
01/10/2007


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
Evolium
9654l1re.doc
01/10/2007


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. A1353-RA/NMC SYSTEM RELATIONSHIPS
This part describes the relationships concerning the NMC/A1353-RA system.
5.1 Consistency of the NMC, A1353-RA and BSS databases
There are three hierarchical levels as regards data, which are, from top to bottom:
1) NMC,
2) A1353-RA 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 A1353-RA instance rely on for
database updating, initialization phase and resynchronization:
1) A1353-RA to NMC notifications
All changes done in the A1353-RA 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 A1353-RA databases.
2) A1353-RA/BSS-NE audit
The purpose of the audit is to align the A1353-RA and a BSS-NE databases. In case of
discrepancies, the following rules apply:
The BSS-NE radio configuration is aligned on A1353-RA values. The A1353-RA
databases are regarded as containing the correct values in terms of radio
configuration. The A1353-RA updates the BSS-NE database without warning the
NMCs because all changes done in the A1353-RA databases are propagated to
the NMCs.
The A1353-RA 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 A1353-RA updates its own databases and
warns the NMCs against changes by sending the corresponding notification.
Concerning alarms, the A1353-RA alarm situation is aligned on the BSS-NE one.
The A1353-RA 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
Evolium
9654l1re.doc
01/10/2007


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 A1353-RA databases in case of a Q3 link failure with that NMC or a A1353-RA
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 A1353-RA 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
A1353-RA, 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 A1353-RA initialization
At the A1353-RA 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 A1353-RA 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
Evolium
9654l1re.doc
01/10/2007


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 A1353-RA offers two mechanisms to resynchronise the alarms between a NMC and the
A1353-RA:
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
Evolium
9654l1re.doc
01/10/2007


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 A1353-RA 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
Evolium
9654l1re.doc
01/10/2007


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 A1353-RA Configuration Import/Export interface
ACOM A1353-RA Common
Acronym used to denote the proprietary part used by the Alcatel
NMC/A1353-RA Q3 Interface gathering A1353-RA Common purpose
definitions.
ANOI Alcatel NMC/OMC3 (i.e. A1353-RA) Q3 Interface
Acronym used to denote the proprietary part specific to the Alcatel
NMC/A1353-RA 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

Profile For The NMC/A1353-RA Q3 Interface

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/A1353-RA Q3 Interface

Uploaded by

Copyright:

Available Formats

Profile for the NMC/A1353-RA Q3 Interface

You might also like