09654MAAAe02.pdf

Profile for the NMC/9153 OMC-R Q3 Interface

ED 02

Released

9654m21r.doc 09/04/2010

3BK 09654 MAAA PBZZA 1/ 2

All

rights

reserv

ed. P

assin

g o

n a

nd c

opyi

ng o

f th

is

docum

ent, u

se a

nd c

om

munic

ation o

f its c

onte

nts

not perm

itte

d w

ithout w

ritten a

uth

orization f

rom

Alc

ate

l .


Release B11


ED 02 Released

9654m21r.doc 09/04/2010

3BK 09654 MAAA PBZZA 1/35

All

rights

reserv

ed. P

assin

g o

n a

nd c

opyi

ng o

f th

is

docum

ent, u

se a

nd c

om

munic

ation o

f its c

onte

nts

not perm

itte

d w

ithout w

ritten a

uth

orization f

rom

Alc

ate

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........................................................14 2.2.4 The Equipment Fragment............................................................15 2.2.5 The bssFunction Fragment..........................................................15

2.3 Naming Tree .........................................................................................17 2.3.1 Conventions.................................................................................17 2.3.2 General Naming Tree ..................................................................17 2.3.3 Complement for GPRS Alarms Reporting ...................................19

2.4 Inheritance hierarchy ..........................................................................19 2.4.1 X.721-related part........................................................................19 2.4.2 M.3100-related part .....................................................................20 2.4.3 Q.751.1-related part ....................................................................20 2.4.4 GSM 12.00-related part ...............................................................20 2.4.5 GSM 12.20-related part ...............................................................21

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

4. SUPPORTED SERVICES...............................................................................23

4.1 Configuration Management ................................................................23 4.1.1 Services supported at the NMC/A1353-RA interface ..................23 4.1.2 Services supported at other A1353-RA external interfaces.........24 4.1.3 Date and time management ........................................................24

4.2 Fault management ...............................................................................25 4.2.1 Introduction..................................................................................25 4.2.2 State Management ......................................................................25 4.2.3 Alarm Reporting & Acknowledgement .........................................25

4.2.3.1 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 02 Released

9654m21r.doc 09/04/2010


All

rights

reserv

ed. P

assin

g o

n a

nd c

opyi

ng o

f th

is

docum

ent, u

se a

nd c

om

munic

ation o

f its c

onte

nts

not perm

itte

d w

ithout w

ritten a

uth

orization f

rom

Alc

ate

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

02 YYMMDD Update O&M System TD/MRC/OMD Spec

01 090515 First issue O&M System TD/MRC/OMD Spec

ED DATE CHANGE NOTE APPRAISAL AUTHORITY ORIGINATOR


ED 02 Released

9654m21r.doc 09/04/2010


All

rights

reserv

ed. P

assin

g o

n a

nd c

opyi

ng o

f th

is

docum

ent, u

se a

nd c

om

munic

ation o

f its c

onte

nts

not perm

itte

d w

ithout w

ritten a

uth

orization f

rom

Alc

ate

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 Model18 Figure 5: Complement to the Naming Tree for GPRS Alarms Reporting ............................ 19 Figure 6: Inheritance hierarchy (X.721-related part) ........................................................... 19 Figure 7: Inheritance hierarchy (M.3100-related part) ......................................................... 20 Figure 8: Inheritance hierarchy (Q.751.1-related part) ........................................................ 20 Figure 9: Inheritance hierarchy (GSM 12.00-related part)................................................... 20 Figure 10: Inheritance hierarchy (GSM 12.20-related part) ................................................. 21 Table 1: Common conventions ............................................................................................. 8 Table 2: Configuration Parameters ....................................................................................... 9 Table 3: MOCs of the Common fragment ........................................................................... 14 Table 4: MOCs of the Transmission fragment .................................................................... 14 Table 5: MOCs of the Equipment fragment ........................................................................ 15 Table 6: MOCs of the bssFunction fragment ...................................................................... 16 Table 7: Main fields of an alarm message .......................................................................... 28

HISTORY

Ed. 01

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

General Changes

B10 is replaced by B11

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

NMC/9153 OMC-R Q3 INFORMATION MODEL PRESENTATION Naming Tree

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

15/05/2009: No technical changes.

Ed. 02

10/03/2010

General Changes

Introducing ExNe Q3 integration

NMC/9153 OMC-R Q3 INFORMATION MODEL PRESENTATION Naming Tree

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

REFERENCED DOCUMENTS

Standards

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


ED 02 Released

9654m21r.doc 09/04/2010


All

rights

reserv

ed. P

assin

g o

n a

nd c

opyi

ng o

f th

is

docum

ent, u

se a

nd c

om

munic

ation o

f its c

onte

nts

not perm

itte

d w

ithout w

ritten a

uth

orization f

rom

Alc

ate

l.

[X.721] Information Technology - Open Systems Interconnection Structure of Management Information - Part 2: Definition of Management Information CCITT Recommendation X.721 (ISO/IEC 10165-2); 1991 with the technical Corrigendum 1,1994

[X.730] Information Technology - Open Systems Interconnection - Systems Management: Object Management Function CCITT Rec. X.730 (ISO/IEC 10164-1), 1992

[X.731] Information Technology - Open Systems Interconnection - Systems Management: State Management Function CCITT Rec. X.731 (ISO/IEC 10164-2), 1992

[X.733] Information Technology - Open Systems Interconnection - Systems Management: Alarm Reporting Function CCITT Rec. X.733 (ISO/IEC 10164-4), 1992

[X.734] Information Technology - Open Systems Interconnection - Systems Management: Event Report Management Function CCITT Recommendation X.734 (ISO/IEC 10164-5), 1992

[X.735] Information Technology - Open Systems Interconnection - Systems Management: Log Control Function CCITT Recommendation X.735 (ISO/IEC 10164-6), 1992

[M.3100] Maintenance: Telecommunications Management Network - Generic Network Information Model; CCITT Recommendation M.3100, July 1995

[Q.751.1] Specifications of Signalling System No. 7 - Network Element Management Information Model for the Message Transfer Part (MTP) ITU-T Recommendation Q.751.1, October 1995

[Q.811] Specifications of Signalling System No. 7 - Q3 interface Lower layer protocol profiles for the Q3 and X interfaces ITU-T Recommendation Q.811, June 1997

[Q.812] Specifications of Signalling System No. 7 - Q3 interface Upper Layer protocol profiles for the Q3 and X interfaces ITU-T Recommendation Q.812, June 1997

[GSM12.00] Digital cellular telecommunications system (Phase 2); Network Management (NM); Part 1: Objectives and structure of Network Management GSM 12.00 version 4.5.1, ETS 300 612-1, August 1996


ED 02 Released

9654m21r.doc 09/04/2010


All

rights

reserv

ed. P

assin

g o

n a

nd c

opyi

ng o

f th

is

docum

ent, u

se a

nd c

om

munic

ation o

f its c

onte

nts

not perm

itte

d w

ithout w

ritten a

uth

orization f

rom

Alc

ate

l.

[GSM12.20] Digital cellular telecommunications system (Phase 2); Base Station System (BSS) Management Information GSM 12.20 version 4.2.1, ETS 300 622, June 1996

Alcatel-Lucent documents

[ANOIgdmo] NMC/9153 OMC-R Q3 Interface: GDMO Formal Specification 3BK 09707 MAAA PBZZA

[ANOIappli] NMC/9153 OMC-R Q3 Interface: Position with respect to standards of the GDMO Formal Specification 3BK 09708 MAAA PBZZA

[ANOIcs-gene] NMC/9153 OMC-R Q3 Interface: Overview and Conformance Statements 3BK 09709 MAAA PBZZA

[ANOIcs-Q3P] NMC/9153 OMC-R Q3 Interface: Q3 Protocol Conformance Statements 3BK 09772 MAAA PBZZA

[ACIE-gene] 9153 OMC-R Configuration Import/Export interface For Release B11:

3BK 09661 MAAA PBZZA

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

3BK 09773 MAAA PBZZA

[ANIE] 9153 OMC-R Import/Export Interface for client nodeIdentifier values For Release B10 (onward):

3BK 09797 LAAA PBZZA

RELATED DOCUMENTS

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

[GDMO] Information Technology - Open Systems Interconnection- Structure of Management Information: Guidelines for the Definition of Management Information CCITT Recommendation X.722 (ISO/IEC 10165-4), 1992


ED 02 Released

9654m21r.doc 09/04/2010


All

rights

reserv

ed. P

assin

g o

n a

nd c

opyi

ng o

f th

is

docum

ent, u

se a

nd c

om

munic

ation o

f its c

onte

nts

not perm

itte

d w

ithout w

ritten a

uth

orization f

rom

Alc

ate

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 02 Released

9654m21r.doc 09/04/2010


All

rights

reserv

ed. P

assin

g o

n a

nd c

opyi

ng o

f th

is

docum

ent, u

se a

nd c

om

munic

ation o

f its c

onte

nts

not perm

itte

d w

ithout w

ritten a

uth

orization f

rom

Alc

ate

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:

Import files

transfer

Export files

transfer

File upload

control

CMIS operation

requests

CMIS operation

responses

9153 OMC-R

Radio Network Level

BSS-NE Level

Q3

External

Interface

File-based

External

Interfaces

NMCs

Figure 1: The 9153 OMC-R external interfaces

1.3 Scope of the document

This document deals with the NMC/9153 OMC-R Q3 Interface. It is a high level specification of this Q3 interface which presents notably the corresponding information model and the supported services.

In particular, it introduces the more technical GDMO-related documents specifying precisely the NMC/9153 OMC-R Q3 Information model. These documents are the following:

[ANOIgdmo] for the GDMO Formal Specification.


ED 02 Released

9654m21r.doc 09/04/2010


All

rights

reserv

ed. P

assin

g o

n a

nd c

opyi

ng o

f th

is

docum

ent, u

se a

nd c

om

munic

ation o

f its c

onte

nts

not perm

itte

d w

ithout w

ritten a

uth

orization f

rom

Alc

ate

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 or .log are as close as possible to the behaviour in B7. Otherwise, their behaviour is different in that it is closer to standards.

ALARM_ACKNOWLEDGEMENT Configuration parameter specific to the NMC/9153 OMC-R Q3 interface. When it is equal to '0' (which is its default value), none of the peculiarities introduced in B9 to support alarm acknowledgement is accurate. Otherwise, alarm acknowledgement is supported (with the associated peculiarities specified hereafter).

PLMN_ELEMENT_BINDING_OID

Configuration parameter specific to the NMC/9153 OMC-R Q3 interface. When it is equal to the string 0.0.13.3100.0.6.0.15 then the Name Binding `M.3100`:managedElement-network (which is its default value) is used . Otherwise, when it is


ED 02 Released

9654m21r.doc 09/04/2010


All

rights

reserv

ed. P

assin

g o

n a

nd c

opyi

ng o

f th

is

docum

ent, u

se a

nd c

om

munic

ation o

f its c

onte

nts

not perm

itte

d w

ithout w

ritten a

uth

orization f

rom

Alc

ate

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.

EX_NE_ALARMS Configuration parameter specific to the NMC/9153 OMC-R Q3 interface. When it s equal with False the alarms coming from External Ne are not forward to NMC. Otherwise, when it is equal with True forwards External Ne alarms.

Table 2: Configuration Parameters


ED 02 Released

9654m21r.doc 09/04/2010


All

rights

reserv

ed. P

assin

g o

n a

nd c

opyi

ng o

f th

is

docum

ent, u

se a

nd c

om

munic

ation o

f its c

onte

nts

not perm

itte

d w

ithout w

ritten a

uth

orization f

rom

Alc

ate

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:

Configuration

Supervision

Supervision

Standard

Information Model

NMC/9153 OMC-R Q3

Information Model

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

Moreover, the NMC/9153 OMC-R Q3 information model is cleanly defined over standards. Since, in a (significant) number of standard Managed Object Classes, the 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


ED 02 Released

9654m21r.doc 09/04/2010


All

rights

reserv

ed. P

assin

g o

n a

nd c

opyi

ng o

f th

is

docum

ent, u

se a

nd c

om

munic

ation o

f its c

onte

nts

not perm

itte

d w

ithout w

ritten a

uth

orization f

rom

Alc

ate

l.

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

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

9153 OMC-R managed sub-network

9153 OMC-R 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 9153 OMC-R instance and the sub-network managed by it

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

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

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

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


ED 02 Released

9654m21r.doc 09/04/2010


All

rights

reserv

ed. P

assin

g o

n a

nd c

opyi

ng o

f th

is

docum

ent, u

se a

nd c

om

munic

ation o

f its c

onte

nts

not perm

itte

d w

ithout w

ritten a

uth

orization f

rom

Alc

ate

l.

A traffic supervision and a possibility of 2Mbits topology discovery

A traffic supervision independent from the equipment maintenance.

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

9130 BSC/MFS Evolution equipment (also called MFS which stands for Multi-BSS Fast

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

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

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

A transmission fragment based on [M.3100] and [Q.751.1] which supports Managed Object Classes to represent the different types of connections and termination points.

An equipment fragment based on [M.3100] which supports Managed Object Classes to represent the equipments. This is in conformance with [GSM12.20], which refers to [M.3100] for equipment management.

A bssFunction fragment based on [GSM12.20] which supports Managed Object Classes to model the functionalities of the corresponding equipments. This fragment supports QoS alarms and enables traffic surveillance independently from equipment supervision.

Given that only overall supervision is supported for the GPRS-specific part, the last three fragments only concern the core part.

N.B.: In what follows, the expression 'Abstract Class' is used to qualify a Managed Object Class that is used for inheritance purposes only.

2.2.2 The Common Fragment

The following common functions are supported:

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

The "X.721":system MOC is used to serve as naming sub-root for the corresponding managed object instances.

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

Object Management (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.


ED 02 Released

9654m21r.doc 09/04/2010


All

rights

reserv

ed. P

assin

g o

n a

nd c

opyi

ng o

f th

is

docum

ent, u

se a

nd c

om

munic

ation o

f its c

onte

nts

not perm

itte

d w

ithout w

ritten a

uth

orization f

rom

Alc

ate

l.

This managed object instance provides a synthesized view of the corresponding Transmission, Equipment and bssFunction fragments. It also provides an alarm synthesis of the object instances of these fragments.

One "ANOI":anoiGPRSManagedElement managed object instance per GPRS 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.

One "ANOI":anoiSNMPManagedElement one managed object instance per OMC. Alarms emitted by any declared External Ne are mapped onto alarms emitted by

"ANOI":anoiSNMPManagedElement, these alarms cannot be acknowledged and resynchronization is possible using Log function.

The complete list of the corresponding MOCs is as follows:

MOC name 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:anoiSNMPManagedElement M.3100 SNMP Ex Ne management

"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


ED 02 Released

9654m21r.doc 09/04/2010


All

rights

reserv

ed. P

assin

g o

n a

nd c

opyi

ng o

f th

is

docum

ent, u

se a

nd c

om

munic

ation o

f its c

onte

nts

not perm

itte

d w

ithout w

ritten a

uth

orization f

rom

Alc

ate

l.

MOC name Related

standard

Purpose

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. This management is performed thanks to the following instantiable MOCs:

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

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

of an Alcatel BTS equipment

of a BSC at the Abis, Ater or AterMux interface

of a transcoder at the AterMux or A interface. In particular, this MOC is instantiated:

to represent the two termination points with which an instance of "M.3100":connectionR1 is in relation

for each Ater and A PCM Circuit. This makes it possible to supervise the Ater and A interface.

This modeling enables, in case of failure, to precisely determinate which side of the 2 Mb links is concerned.

In addition, the following Managed Object Classes are supported for Signalling System No.7 management:

"Q.751.1":mtpSignPoint

"ANOI":anoiSignLinkSetTp

"ANOI":anoiSignLinkTp

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

MOC name 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


ED 02 Released

9654m21r.doc 09/04/2010


All

rights

reserv

ed. P

assin

g o

n a

nd c

opyi

ng o

f th

is

docum

ent, u

se a

nd c

om

munic

ation o

f its c

onte

nts

not perm

itte

d w

ithout w

ritten a

uth

orization f

rom

Alc

ate

l.

2.2.4 The Equipment Fragment

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

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

the BSC

the BTS equipments

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

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

"M.3100":equipmentHolder Managed object instances of this MOC are used to model racks and shelfs that group replaceable equipment items.

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

MOC name 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


ED 02 Released

9654m21r.doc 09/04/2010


All

rights

reserv

ed. P

assin

g o

n a

nd c

opyi

ng o

f th

is

docum

ent, u

se a

nd c

om

munic

ation o

f its c

onte

nts

not perm

itte

d w

ithout w

ritten a

uth

orization f

rom

Alc

ate

l.

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

"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 02 Released

9654m21r.doc 09/04/2010


All

rights

reserv

ed. P

assin

g o

n a

nd c

opyi

ng o

f th

is

docum

ent, u

se a

nd c

om

munic

ation o

f its c

onte

nts

not perm

itte

d w

ithout w

ritten a

uth

orization f

rom

Alc

ate

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 ANOI:anoiSNMPManagedElement


ED 02 Released

9654m21r.doc 09/04/2010


All

rights

reserv

ed. P

assin

g o

n a

nd c

opyi

ng o

f th

is

docum

ent, u

se a

nd c

om

munic

ation o

f its c

onte

nts

not perm

itte

d w

ithout w

ritten a

uth

orization f

rom

Alc

ate

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


"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 02 Released

9654m21r.doc 09/04/2010


All

rights

reserv

ed. P

assin

g o

n a

nd c

opyi

ng o

f th

is

docum

ent, u

se a

nd c

om

munic

ation o

f its c

onte

nts

not perm

itte

d w

ithout w

ritten a

uth

orization f

rom

Alc

ate

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 02 Released

9654m21r.doc 09/04/2010


All

rights

reserv

ed. P

assin

g o

n a

nd c

opyi

ng o

f th

is

docum

ent, u

se a

nd c

om

munic

ation o

f its c

onte

nts

not perm

itte

d w

ithout w

ritten a

uth

orization f

rom

Alc

ate

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

ment

"ANOI":anoiGPRSManagedElement

"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": 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 02 Released

9654m21r.doc 09/04/2010


All

rights

reserv

ed. P

assin

g o

n a

nd c

opyi

ng o

f th

is

docum

ent, u

se a

nd c

om

munic

ation o

f its c

onte

nts

not perm

itte

d w

ithout w

ritten a

uth

orization f

rom

Alc

ate

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 02 Released

9654m21r.doc 09/04/2010


All

rights

reserv

ed. P

assin

g o

n a

nd c

opyi

ng o

f th

is

docum

ent, u

se a

nd c

om

munic

ation o

f its c

onte

nts

not perm

itte

d w

ithout w

ritten a

uth

orization f

rom

Alc

ate

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 02 Released

9654m21r.doc 09/04/2010


All

rights

reserv

ed. P

assin

g o

n a

nd c

opyi

ng o

f th

is

docum

ent, u

se a

nd c

om

munic

ation o

f its c

onte

nts

not perm

itte

d w

ithout w

ritten a

uth

orization f

rom

Alc

ate

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 02 Released

9654m21r.doc 09/04/2010


All

rights

reserv

ed. P

assin

g o

n a

nd c

opyi

ng o

f th

is

docum

ent, u

se a

nd c

om

munic

ation o

f its c

onte

nts

not perm

itte

d w

ithout w

ritten a

uth

orization f

rom

Alc

ate

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"


ED 02 Released

9654m21r.doc 09/04/2010


All

rights

reserv

ed. P

assin

g o

n a

nd c

opyi

ng o

f th

is

docum

ent, u

se a

nd c

om

munic

ation o

f its c

onte

nts

not perm

itte

d w

ithout w

ritten a

uth

orization f

rom

Alc

ate

l.

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

4.2 Fault management

4.2.1 Introduction

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

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

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

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

request to acknowledge a given set of alarms and is warned

whenever an alarm has been acknowledged. State Management

The State Management function is supported as defined in [X.731]. In particular, a number of state and status attributes are supported among which:

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

M.3100:alarmStatus which, when supported, gives a synthesis of the alarms concerning the corresponding managed object instance and those named under it. This synthesis actually characterises the highest perceived severity of the concerned alarms. For instance, the M.3100:alarmStatus attribute of an ANOI:anoiEquipmentR1 managed object instance provides the synthesis of the alarms emitted by the contained ANOI:anoiCircuitPack and ANOI:anoiTerminationPointBidirectional managed object instances.

For ANOI:anoiBsc andANOI:anoiBtsSiteManager, this attribute reflects, in addition, the alarm situation of the corresponding ANOI:anoiEquipmentR1 managed object instance in order to facilitate alarm detection.

N.B.: The actual rule is defined in [ANOIcs-gene].

4.2.3 Alarm Reporting & Acknowledgement

4.2.3.1 Introduction

The Alarm Management function is supported as defined in [X.733].

The supported alarm notifications are the following ones:


ED 02 Released

9654m21r.doc 09/04/2010


All

rights

reserv

ed. P

assin

g o

n a

nd c

opyi

ng o

f th

is

docum

ent, u

se a

nd c

om

munic

ation o

f its c

onte

nts

not perm

itte

d w

ithout w

ritten a

uth

orization f

rom

Alc

ate

l.

X.721:communicationsAlarm

X.721:environmentalAlarm

X.721:equipmentAlarm

X.721:processingErrorAlarm

X.721:qualityofServiceAlarm.

In addition, if ALARM_ACKNOWLEDGEMENT = 1:

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

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

Alarm acknowledge is not available on alarms emitted on anoiSNMPManagedElement.

4.2.3.2 Main fields of an alarm message

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

identify the managed object instance emitting the alarm,

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

the type and time of the alarm,

together with other pertinent information.

The table below indicates the main fields that can be present and a short description of the latter:

FIELD/SUB-FIELD NAME COMMENTS

managedObjectClass This field identifies the Managed Object Class to which the object instance emitting the notification belongs.

managedObjectInstance This field identifies the object instance emitting the notification.

eventTime This field contains a BSS time-stamp

eventType This field indicates the category of the alarm (communication, environmental, equipment, processingError or qualityofService alarm).

eventInfo

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


ED 02 Released

9654m21r.doc 09/04/2010


All

rights

reserv

ed. P

assin

g o

n a

nd c

opyi

ng o

f th

is

docum

ent, u

se a

nd c

om

munic

ation o

f its c

onte

nts

not perm

itte

d w

ithout w

ritten a

uth

orization f

rom

Alc

ate

l.


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. For more information, see [ANOIcs-gene].

stateChangeDefinition This sub-field, if present, identifies state changes associated with the alarm. For more information, see [ANOIcs-gene].

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 For more information, see [ANOIcs-gene].

additionalText This sub-field, if present, contains a free form text intended for human readers. For more information, see [ANOIcs-gene].

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


ED 02 Released

9654m21r.doc 09/04/2010


All

rights

reserv

ed. P

assin

g o

n a

nd c

opyi

ng o

f th

is

docum

ent, u

se a

nd c

om

munic

ation o

f its c

onte

nts

not perm

itte

d w

ithout w

ritten a

uth

orization f

rom

Alc

ate

l.


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

4.2.3.3 Relationship attributes

Relationship attributes are supported to enable the navigation between the transmission/equipment fragments and the bssFunction fragment. In particular, it enables, knowing that an object of the transmission or equipment fragment is in alarm, to reach easily the concerned object in the bssFunction fragment.

To have a summary of the supported relationship attributes, see [ANOIcs-gene]: this document contains a table indicating, for each concerned MOC, which relationship attributes are supported and the object instances that can be referred to by these attributes.

4.3 Event Report Management and Log Control

4.3.1 Introduction

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

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

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

alarm notifications (see above)

X.721:objectCreation to report object creations.

X.721:objectDeletion to report object deletions.

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

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

Log Control through X.721:log and logRecord objects. log objects can be used to select the potential event reports that are to be logged in the form of appropriate logRecords.

4.3.2 Event Report Management

The Event Report Management function is supported as defined in [X.734]. In particular, X.721:eventForwardingDiscriminator objects are supported. They notably allow to define the conditions which must be satisfied by potential event reports to be actually forwarded to a particular destination.

N.B.: In this document or in the other NMC/9153 OMC-R Q3 Interface specification documents, the expression 'a notification is sent to the NMCs' shall be interpreted as 'a potential notification is sent to the EFD system'. Whether or not this


ED 02 Released

9654m21r.doc 09/04/2010


All

rights

reserv

ed. P

assin

g o

n a

nd c

opyi

ng o

f th

is

docum

ent, u

se a

nd c

om

munic

ation o

f its c

onte

nts

not perm

itte

d w

ithout w

ritten a

uth

orization f

rom

Alc

ate

l.

notification is actually forwarded to a given NMC depends on the definition of the EFD object instances which exit at that moment. This remark also applies to all the similar expressions.

A NMC can create X.721:eventForwardingDiscriminator objects. These objects can be deleted either by a NMC or by a 9153 OMC-R operator. The other requests that are allowed for a NMC are as follows:

M-GET on all attributes

M-SET on:

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

X.721:discriminatorConstruct

X.721:destination

A NMC can find out all the existing X.721:eventForwardingDiscriminator object instances by an M-GET request of the following form:

BOC: X.721:system MOC BOI see [ANOIcs-gene] scope: firstLevelOnly filter: see [ANOIcs-gene]

A NMC can perform M-GET requests with a BOC argument equal to the X.721:eventForwardingDiscriminator MOC. In this case, there is no restriction on the allowed filter argument.

EFDs are persistent and support the possibility to forward events to several destinations.

4.3.3 Log Control

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

X.721:alarmRecord,

X.721:attributeValueChangeRecord,

X.721:objectCreationRecord,

X.721:objectDeletionRecord,

X.721:stateChangeRecord,

"GSM 12.00":bulkTransferErrorRecord,

"GSM 12.00":transferReadyRecord,

"ANOI":associationSurveyRecord.

Logs are global to the sub-network managed by the 9153 OMC-R and are in wrap mode.

A NMC can create X.721:log objects. These objects can be deleted either by a NMC or by a 9153 OMC-R operator. The other requests that are allowed for a NMC are as follows:

M-GET on all attributes


ED 02 Released

9654m21r.doc 09/04/2010


All

rights

reserv

ed. P

assin

g o

n a

nd c

opyi

ng o

f th

is

docum

ent, u

se a

nd c

om

munic

ation o

f its c

onte

nts

not perm

itte

d w

ithout w

ritten a

uth

orization f

rom

Alc

ate

l.

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

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

A NMC can find out all the existing X.721:log object instances by a M-GET request of the following form:

BOC: X.721:system MOC BOI see [ANOIcs-gene] scope: firstLevelOnly filter: see [ANOIcs-gene]

A NMC can perform M-GET requests with a BOC argument equal to the X.721:log MOC. In this case, there is no restriction on the allowed filter argument.


ED 02 Released

9654m21r.doc 09/04/2010


All

rights

reserv

ed. P

assin

g o

n a

nd c

opyi

ng o

f th

is

docum

ent, u

se a

nd c

om

munic

ation o

f its c

onte

nts

not perm

itte

d w

ithout w

ritten a

uth

orization f

rom

Alc

ate

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 02 Released

9654m21r.doc 09/04/2010


All

rights

reserv

ed. P

assin

g o

n a

nd c

opyi

ng o

f th

is

docum

ent, u

se a

nd c

om

munic

ation o

f its c

onte

nts

not perm

itte

d w

ithout w

ritten a

uth

orization f

rom

Alc

ate

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 02 Released

9654m21r.doc 09/04/2010


All

rights

reserv

ed. P

assin

g o

n a

nd c

opyi

ng o

f th

is

docum

ent, u

se a

nd c

om

munic

ation o

f its c

onte

nts

not perm

itte

d w

ithout w

ritten a

uth

orization f

rom

Alc

ate

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 ANOI:anoiCoreManagedElement or ANOI:anoiGPRSManagedElement managed object instance contains the value initializing.

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

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

for a GPRS BSS-NE, the notifications that are sent by the corresponding ANOI:anoiGPRSManagedElement MOI

(if any) shall not be relied upon together with the attribute values of those MOIs.

5.3.1.4 Upon detection of a problem by a NMC

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

5.3.2 Configuration resynchronisation

A NMC can perform a configuration resynchonisation

at Network level through a Network discovery

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

Both discoveries are dealt with in section 4.1.1.

5.3.3 Alarm resynchronisation

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

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

BOC: X.721:log Scope: firstLevelOnly Filter: lessOrEqual (t1, X.721:eventTime) and

greaterOrEqual (t2, X.721:eventTime)


ED 02 Released

9654m21r.doc 09/04/2010


All

rights

reserv

ed. P

assin

g o

n a

nd c

opyi

ng o

f th

is

docum

ent, u

se a

nd c

om

munic

ation o

f its c

onte

nts

not perm

itte

d w

ithout w

ritten a

uth

orization f

rom

Alc

ate

l.

This requests sufficient knowledge from this NMC to be able to decide of an appropriate time interval (e.g. memorizing the time at which two subsequent ANOI:associationSurvey notifications are actually received).

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

If ALARM_ACKNOWLEDGEMENT = 1, to resynchronize its knowledge of alarm

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

With ANOI:retrieveCurrentAlarmsData, whether or not a current alarm retrieved that way has been acknowledged by the 9153 OMC-R instance is directly indicated in the associated data: the information associated with the element of the additionalInformation field corresponding to the "ACOM":alarmAcknowledgementIndication parameter contains 'TRUE' if it has been acknowledged and 'FALSE' otherwise.

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


ED 02 Released

9654m21r.doc 09/04/2010


All

rights

reserv

ed. P

assin

g o

n a

nd c

opyi

ng o

f th

is

docum

ent, u

se a

nd c

om

munic

ation o

f its c

onte

nts

not perm

itte

d w

ithout w

ritten a

uth

orization f

rom

Alc

ate

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

Date post:	24-Sep-2015
Category:	Documents
Upload:	hosyphuoc
View:	3 times
Download:	0 times

09654MAAAe02.pdf

Documents