profile for the nmc/a1353-ra q3 interface

8/13/2019 Profile for the NMC/A1353-RA Q3 Interface

http://slidepdf.com/reader/full/profile-for-the-nmca1353-ra-q3-interface 1/36

Profile for the NMC/A1353-RA Q3 Interface

ED 01 RELEASED

Evolium 9654l1re.doc01/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


(B10 onwards)




ED 01 RELEASED







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







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







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 thecorresponding references in the body of the document.

• NMC/A1353-RA Q3 INFORMATION MODEL PRESENTATIONNaming 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 informationexchange between systems - Local and metropolitan area networks -Specific requirements - Part 2: Logical Link ControlRecommendation ISO/IEC 8802-2, 1994

[X.721] Information Technology - Open Systems Interconnection Structure of

Management Information - Part 2: Definition of ManagementInformationCCITT Recommendation X.721 (ISO/IEC 10165-2); 1991 with thetechnical Corrigendum 1,1994

[X.730] Information Technology - Open Systems Interconnection - SystemsManagement:Object Management Function




ED 01 RELEASED







CCITT Rec. X.730 (ISO/IEC 10164-1), 1992

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

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

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

[X.735] Information Technology - Open Systems Interconnection - SystemsManagement:Log Control Function

CCITT Recommendation X.735 (ISO/IEC 10164-6), 1992

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

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

[Q.811] Specifications of Signalling System No. 7 - Q3 interfaceLower 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 interfaceUpper Layer protocol profiles for the Q3 and X interfacesITU-T Recommendation Q.812, June 1997

[GSM12.00] Digital cellular telecommunications system (Phase 2);Network Management (NM);Part 1: Objectives and structure of Network ManagementGSM 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 Specification3BK 09707 AAA PBZZA

[ANOIappli] NMC/A1353-RA Q3 Interface: Position with respect to standards of the




ED 01 RELEASED







GDMO Formal Specification3BK 09708 AAA PBZZA

[ANOIcs-gene] NMC/A1353-RA Q3 Interface: Overview and Conformance Statements3BK 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 interfaceFor Release B:

3BK 09661 AAA PBZZA

[ACIE-si] A1353-RA Configuration Import/Export Interface: SupplementaryInformationFor Release B:

3BK 09773 AAA PBZZA

[ANIE] A1353-RA Import/Export Interface for client nodeIdentifier valuesFor 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 ofManagement Information:Guidelines for the Definition of Management InformationCCITT Recommendation X.722 (ISO/IEC 10165-4), 1992




ED 01 RELEASED







1. INTRODUCTION

1.1 The requirements

The intention is to enable network information exchange from the A1353-RA to a NMC in aninteractive, reliable and efficient way while hiding network complexity and supporting anhomogeneous equipment management.This should operate in multi-vendor context and must be as A1353-RA release independentas 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 andthe 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 tospontaneous and self routing events which allow an upper layer to be warned aboutchanges in alarms situations, attribute values, states, creations and deletions.

−The major disadvantage remains weaknesses for functional areas concerned with alarge amount of data, such as the configuration, performance and trace managementfunctional areas.This aspect is especially important for the A1353-RA since the number of objectshandled by this new Alcatel OMC-R is great and could increase; in particular, theA1353-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 modelbased on standards, especially [GSM12.20] and [M.3100].

− Avoid the disadvantages of a Q3 interface for the aforementioned areas by usinginterfaces 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 timethrough resources alarm, state change, attribute value change, create and deletenotifications.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 onthat issue.

− The other A1353 external interfaces These interfaces are based on ASCII files which can be transferred (i.e. exported andpossibly imported) using either FTAM or FTP. They are distinguished according to thedomain they are concerned with (e.g. configuration management, performancemanagement, ....).

An example of such an interface is the A1353-RA Configuration Import/Export (ACIE)interface. This interface enables to:




ED 01 RELEASED







• 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 givenBSS-NE.In addition, the corresponding export sessions can be requested and theassociated 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 operationresponses

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 correspondinginformation model and the supported services.

In particular, it introduces the more technical GDMO-related documents specifying preciselythe 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 FormalSpecification.




ED 01 RELEASED







− [ANOIcs-gene] for an overview of the information model and the related ConformanceStatements, i.e. peculiarities with respect to the GDMO Formal Specification that applyto the objects of the instantiable Managed Object Classes. In particular, it describes, foreach instantiable Managed Object Classes, which of the applicable packages areactually instantiated and the corresponding list of attributes/actions/notifications withnoticeable 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 conditionallyinstantiated, conditionally present or conditionally relevant

Dark grey is used to highlight items that are neverinstantiated, 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 installationtime (from a NMC viewpoint).The following table indicates how these parameters are denoted hereafter and theirdescription:

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), thebehaviour of GET/SET and DELETE requests with BOI<syst_Id > or <syst_Id >.log are as close as possible to thebehaviour in B7. Otherwise, their behaviour is different inthat it is closer to standards.

ALARM_ACKNOWLEDGEMENT Configuration parameter specific to the NMC/A1353-RAQ3 interface.When it is equal to '0' (which is its default value), none ofthe peculiarities introduced in B9 to support alarmacknowledgement is accurate. Otherwise, alarmacknowledgement is supported (with the associatedpeculiarities specified hereafter).

PLMN_ELEMENT_BINDING_OID Configuration parameter specific to the NMC/A1353-RA

Q3 interface.When it is equal to the string ‘0.0.13.3100.0.6.0.15’ thenthe Name Binding `M.3100`:managedElement-network(which is its default value) is used . Otherwise, when it isequal to the string ‘1.3.12.2.1006.53.1.3.0.6.4015’ then theName Binding `ANOI`:anoi-managedElement-network issupported.



P r of i l ef or t h eN M C / A 1 3

5 3 - R A Q 3 I n t er f a c e

E D

0 1

R E L E A S E D

E v ol i um

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 reservdocument, use




ED 01 RELEASED







2. NMC/A1353-RA Q3 INFORMATION MODEL PRESENTATION

2.1 Information model policy

Broadly speaking, the NMC/A1353 Q3 information model provides a supervisionmanagement 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 ofM.3100, 1996 version of GSM 12.20) in order to get an interface that is as stable aspossible and as independent as possible of the A1353-RA releases;

− takes only the supervision part of these standards, i.e. the managed objects at theNMC/A1353-RA Q3 interface contain identification, state, status and relationshipattributes but do not include configuration-related attributes.

− completes the supervision part of these standards whenever appropriate (throughproprietary 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 themby 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 Q3information model is “ANOI”. Besides, the names of GDMO definitions that have astandard counterpart are prefixed with “anoi” so as to avoid any potential nameclashes for post-processing tools that do not take into account GDMO labels.




ED 01 RELEASED







2.2 Splitting into fragments

2.2.1 Introduction

!"

#

!"

$ !"%& % $ %

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 mainparts:

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

−

The core part made of core BSS-NEs, a core BSS-NE (sometimes called BSS-NE forshort) consisting of a BSC equipment and the sub-network managed by thatequipment).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







− The GPRS-specific part made of GPRS BSS-NEs, a GPRS BSS-NE consisting of anA9135 equipment (also called MFS which stands for Multi-BSS Fast packet Server) andthe sub-network managed by that equipment.This part being not yet standardized, supporting the same level of supervision as for thecore part would have lead to add fully proprietary features in the model, which is not inline with the aforementioned information model policy. As a consequence, only overallsupervision 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 ManagedObject Classes to represent the different types of connections and termination points.

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

− A bssFunction fragment based on [GSM12.20] which supports Managed ObjectClasses 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 threefragments only concern the core part.

N.B.: In what follows, the expression 'Abstract Class' is used to qualify a ManagedObject 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 correspondingmanaged 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 theGSM-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 correspondingTransmission, Equipment and bssFunction fragments. It also provides an alarmsynthesis of the object instances of these fragments.




ED 01 RELEASED







− One "ANOI":anoiGPRSManagedElement managed object instance per GPRS BSS-NE.This managed object instance supports overall supervision of the GPRS-specific part ofan A1353-RA managed sub-network, i.e. all the alarms emitted by managed objectinstances at the A1353-RA/A9135 internal interface are mapped onto alarms emitted bythe corresponding "ANOI":anoiGPRSManagedElement managed object instance atthe NMC/A1353-RA Q3 interface.

The complete list of the corresponding MOCs is as follows:

MOC name Relatedstandard

Purpose

"X.721":alarmRecord X.721 Alarm Reporting andAcknowledgement

"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 ManagementLog 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 thatpurpose) is too weak as regards the capability to build the corresponding topology.




ED 01 RELEASED







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 PCMCircuits 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 andA interface.

This modelling enables, in case of failure, to precisely determinate which side of the 2 Mblinks is concerned.

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

−"Q.751.1":mtpSignPoint

− "ANOI":anoiSignLinkSetTp

− "ANOI":anoiSignLinkTp

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


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

− "M.3100":equipmentHolder




ED 01 RELEASED







Managed object instances of this MOC are used to model racks and shelfs that groupreplaceable equipment items.

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


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 followinginstantiable Managed Object Classes:

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

− "ANOI":anoiBsc allows to supervise the overall BSC telecom activity and to report thestate of the A1353-RA/BSC interface. A managed object instance of this MOC has an"M.3100":alarmStatus attribute and sends (notably) "X.721":qualityofServiceAlarmnotifications.

− "ANOI":anoiBtsSiteManager is instantiated for each managed BTS equipment tocontrol 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 controlsthe telecom activity of a cell referenced by its cell identity (CI) and the location areacode (LAC). Its sends (notably) "X.721":qualityofServiceAlarm notifications wheneverthe operational state or the availability status of the corresponding cell is affected due tofaulty BTS hardware resource (e.g. frame unit, carrier unit). The A1353-RA is able tosupport 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:


Purpose

"ANOI":anoiBsc GSM 12.20 See above

"ANOI":anoiBssFunction GSM 12.00 See above




ED 01 RELEASED








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







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 Q3Interface. They only serve to model corresponding internal MOIs for Alarm Reporting andAcknowledgement purposes (in case ALARM_ACKNOWLEDGEMENT = 1).

Idem but the corresponding internal MOIs are present only for Naming purposes (i.e. theycannot 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":associationSurveyRecord

"ANOI":anoiCoreManagedElement

"ANOI":anoiGPRSManagedElement




ED 01 RELEASED







"ANOI":anoiEquipmentR1

"M.3100":connectionR1

"Q.751.1":mtpSignPoint

"M.3100":equipmentHolder (Rack)

"ANOI":anoiTerminationPointBidirectional

"ANOI":anoiFunction

Coordinator"ANOI":

anoiSignLinkSetTp

"M.3100":equipmentHolder (Shelf) "ANOI":anoiFunction

"ANOI":anoiSignLinkTp

"ANOI":anoiCircuitPack

"ANOI":anoiBssFunction"GSM 12.00":

generalDataTransferControlFunction

"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







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

"AGVC":aGprsLapdLink "AGVC":aGprsNsvc

"ABSS":aGprsBts "AGFR":aGprsPvc

"M.3100":equipment

Holder (rack)"AGVC":aGprsSgsnIpEndPoint

"M.3100":equipmentHolder (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







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

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

"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







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







3. THE Q3 PROCOCOL

The NMC/A1353-RA Q3 interface complies with [Q.811] for the lower layers and [Q.812] forthe upper layers of the Q3 Protocol. The corresponding Conformance Statements arespecified 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] typeLANs using Carrier Sense Multiple Access with CollisionDetection (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] isrelevant for the NMC/A1353-RA Q3 Interface (Session and Presentation layers, ACSE,ROSE and CMISE).




ED 01 RELEASED







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 ConfigurationManagement 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 theA1353-RA managed sub-network.This can be performed using the following GET request:

BOC: "ANOI":anoiPlmnNetwork MOCscope: firstLevelOnly

which makes it possible to know all the "ANOI":anoiCoreManagedElement and"ANOI":anoiGPRSManagedElement managed object instances, i.e. all thecorresponding BSS-NEs.

− Core BSS-NE Discovery:Core BSS-NE discovery consists in getting all the available information concerning agiven core BSS-NE.This can be performed by using GET requests of the form:

BOC: "ANOI":anoiCoreManagedElement MOC orany MOC under it in the naming tree

scope: no restrictionN.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-REPLACEattribute 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 thismanaged 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 coreBSS-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 thatGPRS BSS-NE.




ED 01 RELEASED







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 wheneverpossible 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 sincethis 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 instanceby using an M-GET request with no attributeIdentifierList field.

• the value of specific attributes by using an M-GET request with a valuedattributeIdentifierList field.

− Controlling the export of A1353-RA configuration data:It is possible to request and transfer in a controlled way the A1353-RA configurationdata

•

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 objectinstances, as described in [ACIE-gene]. The supported file transfer protocol is indicatedin the “ACOM”:typeOfFileTransfer attribute of the “ANOI”:anoiPlmnNetwork managedobject 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 objectinstances named under it, it is not allowed for a NMC to request a change in the value ofany 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 forattributes 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 onthe "M.3100":externalTime attribute of the "ANOI":anoiPlmnNetwork managed objectinstance.

On the other hand, it is not possible to set the date and time of a A1353-RA instance at theNMC/A1353-RA Q3 interface nor at the A1353-RA Configuration Import/Export interface. ANMC 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). Thisapplication is compliant to “RFC 1035”. The protocol is exchanged on an "ip"network. The time synchronisation (in case of large shift) is performed by severallittle steps.




ED 01 RELEASED







4.2 Fault management

4.2.1 Introduction

The NMC/A1353-RA Q3 interface supports the following functions:

−

State ManagementWhenever relevant, objects support a number of state and status attributes that can beread and the changes in the value of these attributes (due to events occurring in theradio 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 arestated in [ANOIcs-gene].

− Alarm Reporting & AcknowledgementWhenever relevant, the detection of faults or abnormal conditions (due to eventsoccurring in the radio sub-system or internally to the A1353-RA) are reported to theNMCs through alarm notifications emitted by the appropriate managed object instance.In addition, if ALARM_ACKNOWLEDGEMENT = 1, a NMC can request to acknowledge agiven 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 alarmsconcerning the corresponding managed object instance and those named under it. Thissynthesis actually characterises the highest perceived severity of the concernedalarms.For instance, the “M.3100”:alarmStatus attribute of an “ANOI”:anoiEquipmentR1managed object instance provides the synthesis of the alarms emitted by the contained“ANOI”:anoiCircuitPack and “ANOI”:anoiTerminationPointBidirectional managed objectinstances.

For “ANOI”:anoiBsc and“ANOI”:anoiBtsSiteManager, this attribute reflects, in addition,the alarm situation of the corresponding “ANOI”:anoiEquipmentR1 managed objectinstance 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







− “X.721”:qualityofServiceAlarm.

In addition, if ALARM_ACKNOWLEDGEMENT = 1:

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

− NMCs are warned that an alarm has been acknowledged by receiving a simplified (butstandard) version of this alarm with notably the information sub-field of the element ofthe 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. Thecorresponding 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 thealarm 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 thelatter:

FIELD/SUB-FIELD NAME COMMENTS

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

managedObjectInstance This field identifies the object instance emitting thenotification.

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 alarmas an OID value.The set of probableCause values that can be used aredefined in [ANOIgdmo]. These values are all standardones.

− specificProblems This sub-field is a list of integers that are such that analarm emitted by a given object instance with aperceivedSeverity field equal to 'cleared' can safely clearthe alarms for that managed object instance that havethe same eventType, probableCause andspecificProblems field values.

For more information, see [ANOIcs-gene].− perceivedSeverity This sub-field indicates the perceived severity of the

alarm (indeterminate, critical, major, minor, warning orcleared).

− thresholdInfo This sub-field may only be present for aqualityofServiceAlarm notification. . If present, itindicates corresponding threshold information.For more information, see [ANOIcs-gene].




ED 01 RELEASED







FIELD/SUB-FIELD NAME COMMENTS

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

− monitoredAttributes This sub-field, if present, contains one element for anumber 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 itcontains the concatenation of a number of informationenabling to locate precisely the alarm.For example this element for an alarm concerning acircuitPack can contain something like:

"BSS 1 Shelf 1 Rack 1 swch-aa 1"When this sub-field is present together with the list ofconcerned attributes and the exact contents of theelement corresponding to “M.3100”:userLabel is definedin [ANOIcs-gene].

− proposedRepairActions This sub-field, if present, indicates whether or not arepair 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 textintended for human readers.For more information, see [ANOIcs-gene].

− additionalInformation This sub-field contains at most as many elements asthere 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 listof repair actions that can be performed to clear thealarm are specified.

− To indicate the managedObjectClass andmanagedObjectInstance values corresponding to theinternal MOI that has emitted the alarm (from anNMC/A1353-RA Q3 Interface viewpoint).

− To indicate that the alarm only serves to warn theNMCs that the corresponding internal alarm has been

acknowledged (present only ifALARM_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







4.2.3.3 Relationship attributes

Relationship attributes are supported to enable the navigation between thetransmission/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 easilythe concerned object in the bssFunction fragment.

To have a summary of the supported relationship attributes, see [ANOIcs-gene]: thisdocument contains a table indicating, for each concerned MOC, which relationship attributesare 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 theA1353-RA. They can be reported to the NMCs as a notification corresponding to the type ofevent 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, thefollowing 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 theform 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 notablyallow to define the conditions which must be satisfied by potential event reports to beactually 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 interpretedas 'a potential notification is sent to the EFD system'. Whether or not thisnotification 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 bedeleted 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







• “X.721”:administrativeStateSetting this attribute to the ‘locked’ value enables to suspend the EFD activity. Inthis state, M-SET requests on the modifiable EFD attributes are allowed.Setting this attribute again to the ‘unlocked’ value enables to resume the EFDactivity.

• “X.721”:discriminatorConstruct

• “X.721”:destination

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

BOC: “X.721”:system MOCBOI see [ANOIcs-gene]scope: firstLevelOnlyfilter: 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 theallowed 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 conditionswhich must be satisfied by potential event reports to be actually logged in a particular logobject instance.A log object instance contains logRecord object instances belonging to one of the followingManaged 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 bya 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 thisstate, M-SET requests on the modifiable log attributes are allowed.Setting this attribute again to the ‘unlocked’ value enables to resume the logactivity.

• “X.721”:capacityAlarmThreshold (provided this attribute is present, see [ANOIcs-gene]),

• “X.721”:discriminatorConstruct,

• "X.721":logFullAction




ED 01 RELEASED







• “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 thefollowing form:

BOC: “X.721”:system MOCBOI 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 01 RELEASED







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 and3) BSS-NE.It must be guaranteed that the databases at these three levels are consistent. This is doneby three main mechanisms on which a NMC and the A1353-RA instance rely on fordatabase updating, initialization phase and resynchronization:

1) A1353-RA to NMC notificationsAll changes done in the A1353-RA databases are propagated to the NMCs by means ofthe following notifications:

• “X.721”:stateChange,

• “X.721”:attributeValueChange,• “X.721”:objectDeletion,

• “X.721”:objectCreation,

• alarmsIn this way, in a normal working mode, the database of a NMC is always consistent withthe A1353-RA databases.

2) A1353-RA/BSS-NE auditThe purpose of the audit is to align the A1353-RA and a BSS-NE databases. In case ofdiscrepancies, the following rules apply:

• The BSS-NE radio configuration is aligned on A1353-RA values. The A1353-RAdatabases are regarded as containing the correct values in terms of radio

configuration. The A1353-RA updates the BSS-NE database without warning theNMCs because all changes done in the A1353-RA databases are propagated tothe NMCs.

• The A1353-RA hardware and transmission configuration is aligned on the BSS-NEvalues. The BSS-NE database is regarded as the reference concerning hardwareand transmission configuration. The A1353-RA updates its own databases andwarns 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 thechanges 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 iswarned that these requests may return consistent but not accurate (since not updated)values thanks to this "X.721":stateChange notification.




ED 01 RELEASED







When the audit phase is terminated, the NMCs are warned via a "X.721":stateChangenotification sent by the same MOI with 'reporting' as new “X.721”:proceduralStatusattribute value.

3) NMC resynchronisationThe previous mechanisms do not guarantee that the database of a NMC is consistentwith 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 (seesection 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 tofully survey the communication link between the A1353-RA and the primary NMC. For moreinformation 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 theA1353-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 instancesit 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”:stateChangenotification sent by the “ANOI”:anoiPlmnNetwork managed object instance indicatingthat 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







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 objectinstance (see section 4.1.1). The “X.721”:proceduralStatus attribute of the corresponding“ANOI”:anoiCoreManagedElement or “ANOI”:anoiGPRSManagedElement managed objectinstance contains the value ‘initializing’.

Then the BSS-NE is initialized. A NMC is warned that the BSS-NE has been correctlyinitialized via a "X.721":stateChange notification sent by the corresponding“ANOI”:anoiCoreManagedElement or “ANOI”:anoiGPRSManagedElement managed objectinstance with 'reporting' as new “X.721”:proceduralStatus attribute value.When this initialization phase of the BSS-NE is completed, a NMC should perform aconfiguration resynchronization (only for core BSS-NEs) then an alarm resynchronization forthat 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 theA1353-RA:

− Using the Log Control function:A NMC can retrieve all the logRecord object instances of a given log object instancewhose “X.721”:eventTime attribute is within a time interval that is sufficiently great tocover 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”:logScope: firstLevelOnlyFilter: 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 appropriatetime interval (e.g. memorizing the time at which two subsequent“ANOI”:associationSurvey notifications are actually received).




ED 01 RELEASED







− Using “ANOI”:retrieveCurrentAlarmsDataA 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 managedobject 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 theassociated data: the information associated with the element of theadditionalInformation field corresponding to the"ACOM":alarmAcknowledgementIndication parameter contains 'TRUE' if it has beenacknowledged and 'FALSE' otherwise.

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

acknowledged.








6. ACRONYMS

ACIE A1353-RA Configuration Import/Export interfaceACOM A1353-RA Common

Acronym used to denote the proprietary part used by the AlcatelNMC/A1353-RA Q3 Interface gathering A1353-RA Common purposedefinitions.

ANOI Alcatel NMC/OMC3 (i.e. A1353-RA) Q3 InterfaceAcronym used to denote the proprietary part specific to the AlcatelNMC/A1353-RA Q3 Interface

ASN1 Abstract Syntax Notation OneBOC baseManagedObjectClass argument of a CMIS M-GET requestBOI baseManagedObjectInstance argument of a CMIS M-GET requestBSC Base Station ControllerBSS Base Station SubsystemBSS-NE Base Station Subsystem Network ElementBTS Base Transceiver StationCLNS Connectionless Network Layer Service

CMISE Common Management Information Service ElementCSMA/CD Carrier Sense Multiple Access with Collision DetectionCONS Connection-mode Network Layer ServiceGDMO Guidelines for the Definition of Managed ObjectsGPRS General Packet Radio ServiceGSM Global System for Mobile communications

(whichever technology, i.e. either Circuit-Switched or Packet-Switched)IP Inter-networking ProtocolLAN Local Area NetworkMOC Managed Object ClassMOI Managed Object InstanceNMC Network Management CentreO&M Operation and Maintenance

OMC-R Operation and Maintenance Centre RadioSW SoftwareTCP Transmission Control Protocol

END OF DOCUMENT

profile for the nmc/a1353-ra q3 interface

Documents