M2000 Northbound CORBA Interface Developer Guide

M2000V200R010

Northbound CORBA InterfaceDeveloper Guide

Issue 03

Date 2010-12-31

HUAWEI TECHNOLOGIES CO., LTD.

Copyright © Huawei Technologies Co., Ltd. 2010. All rights reserved.No part of this document may be reproduced or transmitted in any form or by any means without prior writtenconsent of Huawei Technologies Co., Ltd. Trademarks and Permissions

and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd.All other trademarks and trade names mentioned in this document are the property of their respective holders. NoticeThe purchased products, services and features are stipulated by the contract made between Huawei and thecustomer. All or part of the products, services and features described in this document may not be within thepurchase scope or the usage scope. Unless otherwise specified in the contract, all statements, information,and recommendations in this document are provided "AS IS" without warranties, guarantees or representationsof any kind, either express or implied.

The information in this document is subject to change without notice. Every effort has been made in thepreparation of this document to ensure accuracy of the contents, but all statements, information, andrecommendations in this document do not constitute the warranty of any kind, express or implied.

Huawei Technologies Co., Ltd.Address: Huawei Industrial Base

Bantian, LonggangShenzhen 518129People's Republic of China

Website: http://www.huawei.com

Email: [email protected]

Issue 03 (2010-12-31) Huawei Proprietary and ConfidentialCopyright © Huawei Technologies Co., Ltd.

i

http://www.huawei.com

mailto:[email protected]

About This Document

PurposeThis document provides information about the M2000 northbound CORBA interface. Thedocument also provides operation guidelines for connecting the network management system(NMS).

Related VersionsThe following table lists product versions related to this document.

Product Name Version

M2000 V200R010

Intended AudienceThis document is intended for:

l Network administrator

Update History

03 (2010-12-31)This is the third commercial release.

Compared with the second release, the changes in the third release are as follows:

M2000Northbound CORBA Interface Developer Guide About This Document


iii

Content Modification Description

1.4 TechnicalSpecifications ofNorthbound CORBAInterface

The content descriptions are changed.

02 (2010-10-30)This is the second commercial release.

Compared with the first release, the changes in the second release are as follows:

Content Modification Description

1.4 TechnicalSpecifications ofNorthbound CORBAInterface

The description of technical specifications is added.

01 (2010-07-31)Initial release.

Organization

1 Introduction to Northbound CORBA Interface

This introduction defines the Northbound CORBA interface provided by the M2000 anddescribes the functions of the Northbound CORBA interface.

2 Common Management Function of the CORBA Interface

The function of common management interface consists of a cluster of management functions.These functions are EPIRP, NotificationIRP and CSIRP.

3 Configuration Management Function of the CORBA Interface

The configuration management interface has the following three functions: BasicCMIRP,KernelCMIRP, and BulkCMIRP.

4 Alarm Management Function of the CORBA Interface

The AlarmIRP interface is the only interface used in alarm management. The alarm managementhas the following functions: querying alarms, clearing alarms, acknowledging alarms,unacknowledging alarms, and reporting alarms in real time.

5 Preparations for Interconnection Commissioning of the Northbound CORBA Interface

About This DocumentM2000

Northbound CORBA Interface Developer Guide

iv Huawei Proprietary and ConfidentialCopyright © Huawei Technologies Co., Ltd.

Issue 03 (2010-12-31)

Before interconnecting the NMS to the M2000, you need to make certain preparations. If youcomplete the preparations, you can infer that the northbound CORBA interface meets theconditions for the interconnection.

6 Troubleshooting the Northbound CORBA Interface

The NMS interconnects with the M2000 through the northbound CORBA interface. If a faultoccurs when the NMS is obtaining the data, refer to relevant troubleshooting methods in thischapter.

7 Appendix

A collection of supplementary material.

ConventionsSymbol Conventions

The symbols that may be found in this document are defined as follows.

Symbol Description

Indicates a hazard with a high level of risk, which if notavoided, will result in death or serious injury.

Indicates a hazard with a medium or low level of risk, whichif not avoided, could result in minor or moderate injury.

Indicates a potentially hazardous situation, which if notavoided, could result in equipment damage, data loss,performance degradation, or unexpected results.

Indicates a tip that may help you solve a problem or savetime.

Provides additional information to emphasize or supplementimportant points of the main text.

General Conventions

The general conventions that may be found in this document are defined as follows.

Convention Description

Times New Roman Normal paragraphs are in Times New Roman.

Boldface Names of files, directories, folders, and users are inboldface. For example, log in as user root.

Italic Book titles are in italics.

Courier New Examples of information displayed on the screen are inCourier New.



v

Command Conventions

The command conventions that may be found in this document are defined as follows.


Boldface The keywords of a command line are in boldface.

Italic Command arguments are in italics.

[ ] Items (keywords or arguments) in brackets [ ] are optional.

{ x | y | ... } Optional items are grouped in braces and separated byvertical bars. One item is selected.

[ x | y | ... ] Optional items are grouped in brackets and separated byvertical bars. One item is selected or no item is selected.

{ x | y | ... }* Optional items are grouped in braces and separated byvertical bars. A minimum of one item or a maximum of allitems can be selected.

[ x | y | ... ]* Optional items are grouped in brackets and separated byvertical bars. Several items or no item can be selected.

GUI Conventions

The GUI conventions that may be found in this document are defined as follows.


Boldface Buttons, menus, parameters, tabs, window, and dialog titlesare in boldface. For example, click OK.

> Multi-level menus are in boldface and separated by the ">"signs. For example, choose File > Create > Folder.

Keyboard Operations

The keyboard operations that may be found in this document are defined as follows.

Format Description

Key Press the key. For example, press Enter and press Tab.

Key 1+Key 2 Press the keys concurrently. For example, pressing Ctrl+Alt+A means the three keys should be pressed concurrently.

Key 1, Key 2 Press the keys in turn. For example, pressing Alt, A meansthe two keys should be pressed in turn.

Mouse Operations

About This DocumentM2000


vi Huawei Proprietary and ConfidentialCopyright © Huawei Technologies Co., Ltd.

Issue 03 (2010-12-31)

The mouse operations that may be found in this document are defined as follows.

Action Description

Click Select and release the primary mouse button without movingthe pointer.

Double-click Press the primary mouse button twice continuously andquickly without moving the pointer.

Drag Press and hold the primary mouse button and move thepointer to a certain position.



vii

Contents

About This Document...................................................................................................................iii

1 Introduction to Northbound CORBA Interface...................................................................1-11.1 Definition of Northbound Interface.................................................................................................................1-21.2 Definition of Northbound CORBA Interface..................................................................................................1-21.3 Function of Northbound CORBA Interface....................................................................................................1-5

1.3.1 Interface Management of the CORBA...................................................................................................1-51.3.2 About IRP...............................................................................................................................................1-6

1.4 Technical Specifications of Northbound CORBA Interface...........................................................................1-7

2 Common Management Function of the CORBA Interface................................................2-12.1 Entry Point of the CORBA Interface.............................................................................................................. 2-2

2.1.1 Interface Description of the Entry Point of the CORBA Interface........................................................ 2-22.1.2 Notification Description of the Entry Point of the CORBA Interface...................................................2-9

2.2 Notification Management Function of the CORBA Interface......................................................................2-112.2.1 Introduction to Notification Management Function of the CORBA....................................................2-112.2.2 Interface Description of the CORBA Notification Management.........................................................2-12

2.3 Communication Surveillance Function of the CORBA Interface.................................................................2-232.3.1 Interface Description of the CORBA Communication Surveillance...................................................2-232.3.2 Heartbeat Notification of the CORBA Communication Surveillance.................................................2-29

3 Configuration Management Function of the CORBA Interface.......................................3-13.1 Getting to Know Configuration Management of the CORBA Interface.........................................................3-23.2 Common Configuration Management of the CORBA....................................................................................3-3

3.2.1 Interface Description of the Common Configuration Management of the CORBA..............................3-43.2.2 Notification Description of the Common Configuration Management of the CORBA.........................3-8

3.3 Function and Interface of Basic Configuration Management of the CORBA..............................................3-15

4 Alarm Management Function of the CORBA Interface.....................................................4-14.1 Introduction to the CORBA Alarm Management...........................................................................................4-24.2 Alarm Management of the CORBA................................................................................................................4-2

4.2.1 Interface Description of the CORBA Alarm Management....................................................................4-24.2.2 Notification Description of the CORBA Alarm Management.............................................................4-294.2.3 Mechanism for Forwarding Common Alarms.....................................................................................4-47

M2000Northbound CORBA Interface Developer Guide Contents


ix

5 Preparations for Interconnection Commissioning of the Northbound CORBA Interface...........................................................................................................................................................5-1

5.1 Negotiating the Interconnection Parameters of the Northbound CORBA Interface.......................................5-25.2 Obtaining the IDL File....................................................................................................................................5-35.3 Checking the CORBA Version.......................................................................................................................5-35.4 Obtaining the Reference of the Entry Point Object.........................................................................................5-45.5 Modifying the hosts File of the Server............................................................................................................5-55.6 Using the CORBA Interface...........................................................................................................................5-5

6 Troubleshooting the Northbound CORBA Interface.........................................................6-16.1 Common Troubleshooting and Information Collection (CORBA Interface).................................................6-26.2 Troubleshooting Failure to Obtain Data..........................................................................................................6-26.3 Operations Required When the IP Address or Hostname of the M2000 Server Changes..............................6-5

7 Appendix......................................................................................................................................7-17.1 Description of filter.........................................................................................................................................7-2

7.1.1 Notification filter Description................................................................................................................7-27.1.2 Description of filter in get_alarm_list....................................................................................................7-47.1.3 Description of filter in get_alarm_count................................................................................................7-5

7.2 Description of DN String................................................................................................................................7-57.3 Description of Alarm Location Detailed Information.....................................................................................7-6

ContentsM2000


x Huawei Proprietary and ConfidentialCopyright © Huawei Technologies Co., Ltd.

Issue 03 (2010-12-31)

Figures

Figure 1-1 Location of the northbound interface................................................................................................. 1-2Figure 1-2 Interface management functions.........................................................................................................1-5Figure 1-3 Relation between managed object by the management domain.........................................................1-6Figure 1-4 Getting object reference of other IRPs by entry points...................................................................... 1-7Figure 1-5 Relations between IRPs......................................................................................................................1-7Figure 3-1 Querying the event flow of MOs......................................................................................................3-22Figure 4-1 Event flow of alarm information........................................................................................................4-8Figure 7-1 DN string............................................................................................................................................ 7-6

M2000Northbound CORBA Interface Developer Guide Figures


xi

Tables

Table 1-1 Interface protocol.................................................................................................................................1-3Table 2-1 Values of getting EPIRP versions........................................................................................................2-2Table 2-2 Exceptions of getting EPIRP version...................................................................................................2-3Table 2-3 Parameters for getting EPIRP operation profile...................................................................................2-3Table 2-4 Values of getting EPIRP operation profile...........................................................................................2-3Table 2-5 Exceptions of getting EPIRP operation profile....................................................................................2-4Table 2-6 Parameters for getting EPIRP notification profile...............................................................................2-4Table 2-7 Values of getting EPIRP notification profile.......................................................................................2-4Table 2-8 Exceptions of getting EPIRP notification profile.................................................................................2-5Table 2-9 Parameters for getting IRP outline.......................................................................................................2-5Table 2-10 Values of getting IRP outline.............................................................................................................2-6Table 2-11 Exceptions of getting IRP outline......................................................................................................2-6Table 2-12 Parameters for getting IRP reference.................................................................................................2-7Table 2-13 Values of getting IRP reference.........................................................................................................2-8Table 2-14 Exceptions of getting IRP reference...................................................................................................2-8Table 2-15 Parameters for releasing IRP reference..............................................................................................2-8Table 2-16 Values of releasing IRP reference......................................................................................................2-9Table 2-17 Exceptions of releasing IRP reference...............................................................................................2-9Table 2-18 Format of the notification of entry point register information change.............................................2-10Table 2-19 Notification management function of the CORBA interface...........................................................2-12Table 2-20 Values of getting notificationIRP versions......................................................................................2-13Table 2-21 Exceptions of getting notificationIRP versions................................................................................2-13Table 2-22 Parameters for getting notificationIRP operation profile.................................................................2-13Table 2-23 Values of getting notificationIRP operation profile.........................................................................2-14Table 2-24 Exceptions of getting notificationIRP operation profile..................................................................2-14Table 2-25 Parameters for getting notificationIRP notification profile..............................................................2-14Table 2-26 Values of getting notificationIRP notification profile.....................................................................2-15Table 2-27 Exceptions of getting notificationIRP notification profile...............................................................2-15Table 2-28 Parameters for getting notification categories..................................................................................2-15Table 2-29 Values of getting notification categories..........................................................................................2-16Table 2-30 Exceptions of getting notification categories...................................................................................2-16Table 2-31 Parameters for subscribing specified notifications...........................................................................2-17Table 2-32 Values of subscribing specified notifications..................................................................................2-18

M2000Northbound CORBA Interface Developer Guide Tables


xiii

Table 2-33 Exceptions of subscribing specified notifications............................................................................2-19Table 2-34 Parameters for detaching notification subscription..........................................................................2-19Table 2-35 Exceptions of detaching notification subscription...........................................................................2-20Table 2-36 Parameters for changing subscription filter conditions....................................................................2-20Table 2-37 Values of changing subscription filter conditions............................................................................2-20Table 2-38 Exceptions of changing subscription filter conditions.....................................................................2-21Table 2-39 Parameters for querying subscription IDs........................................................................................2-21Table 2-40 Values of querying subscription IDs................................................................................................2-21Table 2-41 Exceptions of querying subscription IDs.........................................................................................2-22Table 2-42 Parameters for querying specified subscription parameters.............................................................2-22Table 2-43 Values of querying specified subscription parameters.....................................................................2-23Table 2-44 Exceptions of querying specified subscription parameters..............................................................2-23Table 2-45 Values of getting CSIRP versions....................................................................................................2-24Table 2-46 Exceptions of getting CSIRP versions.............................................................................................2-24Table 2-47 Parameters for getting CSIRP operation profile.............................................................................. 2-24Table 2-48 Values of getting CSIRP operation profile...................................................................................... 2-25Table 2-49 Exceptions of getting CSIRP operation profile................................................................................2-25Table 2-50 Parameters for getting CSIRP notification profile...........................................................................2-25Table 2-51 Values of getting CSIRP notification profile...................................................................................2-26Table 2-52 Exceptions of getting CSIRP notification profile............................................................................ 2-26Table 2-53 Parameters for getting heartbeat period........................................................................................... 2-26Table 2-54 Values of getting heartbeat period................................................................................................... 2-27Table 2-55 Exceptions of getting heartbeat period.............................................................................................2-27Table 2-56 Parameters for setting heartbeat period............................................................................................2-27Table 2-57 Values of setting heartbeat period....................................................................................................2-28Table 2-58 Exceptions of setting heartbeat period.............................................................................................2-28Table 2-59 Parameters for triggering heartbeat notifications.............................................................................2-29Table 2-60 Values of triggering heartbeat notifications.....................................................................................2-29Table 2-61 Exceptions of triggering heartbeat notifications.............................................................................. 2-29Table 2-62 Format of the heartbeat notification.................................................................................................2-30Table 3-1 Values of getting KernelCMIRP versions............................................................................................3-4Table 3-2 Exceptions of getting KernelCMIRP versions.....................................................................................3-4Table 3-3 Parameters for getting KernelCMIRP operation profile......................................................................3-5Table 3-4 Values of getting KernelCMIRP operation profile..............................................................................3-5Table 3-5 Exceptions of getting KernelCMIRP operation profile.......................................................................3-5Table 3-6 Parameters for getting KernelCMIRP notification profile...................................................................3-6Table 3-7 Values of getting KernelCMIRP notification profile...........................................................................3-6Table 3-8 Exceptions of getting KernelCMIRP notification profile....................................................................3-6Table 3-9 Parameters for getting NRMIRP versions............................................................................................3-7Table 3-10 Exceptions of getting NRMIRP versions...........................................................................................3-7Table 3-11 Notification of notifyObjectCreation.................................................................................................3-8Table 3-12 Notification of notifyObjectDeletion...............................................................................................3-10

TablesM2000


xiv Huawei Proprietary and ConfidentialCopyright © Huawei Technologies Co., Ltd.

Issue 03 (2010-12-31)

Table 3-13 Notification of notifyAttributeValueChange................................................................................... 3-12Table 3-14 Notification of notifyCMSynchronizationRecommended...............................................................3-13Table 3-15 Values of getting BasicCMIRP versions..........................................................................................3-15Table 3-16 Exceptions of getting BasicCMIRP versions...................................................................................3-15Table 3-17 Parameters for getting BasicCMIRP operation profile....................................................................3-16Table 3-18 Values of getting BasicCMIRP operation profile............................................................................3-16Table 3-19 Exceptions of getting BasicCMIRP operation profile.....................................................................3-16Table 3-20 Parameters for getting BasicCMIRP notification profile.................................................................3-17Table 3-21 Values of getting BasicCMIRP notification profile.........................................................................3-17Table 3-22 Exceptions of getting BasicCMIRP notification profile..................................................................3-17Table 3-23 Parameters for finding managed objects (I).....................................................................................3-18Table 3-24 Values of finding managed objects (I).............................................................................................3-19Table 3-25 Exceptions of finding managed objects (I)......................................................................................3-20Table 3-26 Parameters for finding managed objects (II)....................................................................................3-20Table 3-27 Values of finding managed objects (II)............................................................................................3-21Table 3-28 Exceptions of finding managed objects (II).....................................................................................3-21Table 3-29 Exceptions of finding managed objects (III)....................................................................................3-22Table 3-30 Steps used for the event flow of querying MOs...............................................................................3-22Table 4-1 Values of getting AlarmIRP versions..................................................................................................4-2Table 4-2 Exceptions of getting AlarmIRP versions............................................................................................4-3Table 4-3 Parameters for getting AlarmIRP operation profile.............................................................................4-3Table 4-4 Values of getting AlarmIRP operation profile.....................................................................................4-3Table 4-5 Exceptions of getting AlarmIRP operation profile..............................................................................4-4Table 4-6 Parameters for getting AlarmIRP notification profile..........................................................................4-4Table 4-7 Values of getting AlarmIRP notification profile..................................................................................4-4Table 4-8 Exceptions of getting AlarmIRP notification profile...........................................................................4-5Table 4-9 Parameters for getting alarm list (I).....................................................................................................4-5Table 4-10 Values of getting alarm list (I)...........................................................................................................4-6Table 4-11 Exceptions of getting alarm list (I).....................................................................................................4-6Table 4-12 Parameters for getting alarm list (II)..................................................................................................4-7Table 4-13 Values of getting alarm list (II)..........................................................................................................4-7Table 4-14 Exceptions of getting alarm list (II)...................................................................................................4-7Table 4-15 Exceptions of getting alarm list (III)..................................................................................................4-8Table 4-16 Unacknowledged and uncleared alarms.............................................................................................4-9Table 4-17 Acknowledged but uncleared alarms...............................................................................................4-12Table 4-18 Unacknowledged but cleared alarms................................................................................................4-16Table 4-19 Parameters for getting alarm count..................................................................................................4-20Table 4-20 Values of getting alarm count..........................................................................................................4-20Table 4-21 Exceptions of getting alarm count....................................................................................................4-20Table 4-22 Parameters for acknowledging alarms.............................................................................................4-21Table 4-23 Values of acknowledging alarms.....................................................................................................4-22Table 4-24 Exceptions of acknowledging alarms...............................................................................................4-23

M2000Northbound CORBA Interface Developer Guide Tables


xv

Table 4-25 Parameters for unacknowledging alarms.........................................................................................4-23Table 4-26 Values of unacknowledging alarms.................................................................................................4-24Table 4-27 Exceptions of unacknowledging alarms...........................................................................................4-25Table 4-28 Parameters for clearing alarms.........................................................................................................4-25Table 4-29 Values of clearing alarms.................................................................................................................4-26Table 4-30 Exceptions of clearing alarms..........................................................................................................4-26Table 4-31 Parameters for adding comments to alarms.....................................................................................4-27Table 4-32 Values of adding comments to alarms.............................................................................................4-28Table 4-33 Exceptions of adding comments to alarms.......................................................................................4-28Table 4-34 notifyPotentialFaultyAlarmList....................................................................................................... 4-29Table 4-35 Notification of new alarms...............................................................................................................4-30Table 4-36 Notification of the change of the alarm acknowledgement status................................................... 4-34Table 4-37 Notification of alarm clearance........................................................................................................4-38Table 4-38 Format of adding alarm comment....................................................................................................4-41Table 4-39 Notification of alarm changes..........................................................................................................4-44Table 4-40 Description of the configuration item..............................................................................................4-48Table 5-1 Negotiated parameters..........................................................................................................................5-2Table 5-2 Usage of the CORBA interface............................................................................................................5-6Table 6-1 Troubleshooting...................................................................................................................................6-2Table 6-2 Information to be collected..................................................................................................................6-2Table 6-3 Possible Causes and Problem Localization .........................................................................................6-3

TablesM2000


xvi Huawei Proprietary and ConfidentialCopyright © Huawei Technologies Co., Ltd.

Issue 03 (2010-12-31)

1 Introduction to Northbound CORBAInterface

About This Chapter

This introduction defines the Northbound CORBA interface provided by the M2000 anddescribes the functions of the Northbound CORBA interface.

1.1 Definition of Northbound InterfaceThe northbound interface links the element management system (EMS) and the NMS.

1.2 Definition of Northbound CORBA InterfaceThe Northbound interface is an interface between the Element Management System (EMS) andthe Network Management System (NMS). The Northbound CORBA interface is one of theNorthbound interfaces. The Northbound CORBA interface conforms to the CORBA protocol,FTP protocol, and 3GPP specifications.

1.3 Function of Northbound CORBA InterfaceThis section describes the concepts related to CORBA interface management and integratedreference point (IRP).

1.4 Technical Specifications of Northbound CORBA InterfaceThis section describes the technical specifications related to the northbound CORBA interface.

M2000Northbound CORBA Interface Developer Guide 1 Introduction to Northbound CORBA Interface


1-1

1.1 Definition of Northbound InterfaceThe northbound interface links the element management system (EMS) and the NMS.

On the northbound interface, the NMS obtains information about the network elements (NEs)managed by the EMS and delivers operation commands. The NE information includes the alarm,configuration, performance and inventory data. The northbound interface is shown in Figure1-1.

Figure 1-1 Location of the northbound interface

In the communication network, the M2000 is an EMS. The M2000 reports the alarm,configuration, performance and inventory data to the NMS through the northbound interface.

1.2 Definition of Northbound CORBA InterfaceThe Northbound interface is an interface between the Element Management System (EMS) andthe Network Management System (NMS). The Northbound CORBA interface is one of theNorthbound interfaces. The Northbound CORBA interface conforms to the CORBA protocol,FTP protocol, and 3GPP specifications.

Interface ProtocolTable 1-1 describes the related information on interface protocol.

1 Introduction to Northbound CORBA InterfaceM2000


1-2 Huawei Proprietary and ConfidentialCopyright © Huawei Technologies Co., Ltd.

Issue 03 (2010-12-31)

Table 1-1 Interface protocol

Protocol Details

CORBA The design of network management interfaces adopts the CORBAtechnology for interface definition. The CORBA technology usesthe IDL language to define the interface information model and alsouses the IIOP communication protocol stack.The design of the network management interfaces complies with thefollowing CORBA standards:l OMG ORB 2.3 standardl OMG Notification Service 1.0 standardl TAO 1.3 VersionNOTEl OMG represents the Object Management Group.

l ORB represents the Object Request Broker.

FTP The file transfer mode in the management interface uses the FileTransfer Protocol (FTP) and the FTP protocol stack.



1-3

Protocol Details

3GPP The CORBA interface complies with the following 3GPP protocols:l 3GPP TS 32.111-1 v6.0.0 Fault Management; Part 1: 3G fault

management requirementsl 3GPP TS 32.111-2 v6.0.0 Fault Management; Part 2: Alarm

Integration Reference Point (IRP): Information Service (IS)l 3GPP TS 32.111-3 v6.0.0 Fault Management; Part 3: Alarm

Integration Reference Point (IRP): Common Object RequestBroker Architecture (CORBA) Solution Set (SS)

l 3GPP TS 32.352 v6.0.0 Telecommunication management;Communication Surveillance (CS) Integration Reference Point(IRP): Information Service (IS)

l 3GPP TS 32.411 v6.0.0 Telecommunication management;Performance Management (PM) Integration Reference Point(IRP): Requirements

l 3GPP TS 32.412 v6.0.0 Telecommunication management;Performance Management (PM) Integration Reference Point(IRP): Information Service (IS)

l 3GPP TS 32.413 v6.0.0 Telecommunication management;Performance Management (PM) Integration Reference Point(IRP): Common Object Request Broker Architecture (CORBA)Solution Set (SS)

l 3GPP TS 32.601 v6.0.0 Telecommunication management;Configuration Management (CM); Basic CM IntegrationReference Point (IRP): Requirements

l 3GPP TS 32.602 v6.0.0 Telecommunication management;Configuration Management (CM); Basic CM IntegrationReference Point (IRP): Information Service (IS)

l 3GPP TS 32.603 v6.0.0 Telecommunication management;Configuration Management (CM); Basic CM IntegrationReference Point (IRP): Common Object Request BrokerArchitecture (CORBA) Solution Set (SS)

l 3GPP TS 32.611 v6.0.0 Telecommunication management;Configuration Management (CM); Bulk CM IntegrationReference Point (IRP): Requirements

l 3GPP TS 32.612 v6.0.0 Telecommunication management;Configuration Management (CM); Bulk CM IntegrationReference Point (IRP): Information Service (IS)

l 3GPP TS 32.615 v6.0.0 Telecommunication management;Configuration Management (CM); Bulk CM IntegrationReference Point (IRP): eXtensible Markup Language (XML) fileformat definition

l 3GPP TS 32.613 v6.0.0 Telecommunication management;Configuration Management (CM); Bulk CM IntegrationReference Point (IRP): Common Object Request BrokerArchitecture (CORBA) Solution Set (SS)




Issue 03 (2010-12-31)

Protocol Details

l 3GPP TS 32.661 v6.0.0 Telecommunication management;Configuration Management (CM); Kernel CM: Requirements

l 3GPP TS 32.662 v6.0.0 Telecommunication management;Configuration Management (CM); Kernel CM InformationService (IS)

l 3GPP TS 32.663 v6.0.0 Telecommunication management;Configuration Management (CM); Kernel CM IntegrationReference Point (IRP): Common Object Request BrokerArchitecture (CORBA) Solution Set (SS)

1.3 Function of Northbound CORBA InterfaceThis section describes the concepts related to CORBA interface management and integratedreference point (IRP).

1.3.1 Interface Management of the CORBABased on the common management, configuration management, and fault management, the Itf-N consists of a cluster of management interfaces, such as common management interface,configuration management interface, and fault management interface.

1.3.2 About IRPThe integrated reference point (IRP) is the abstract name of the interface function. The relativelyindependent interface function provided by the Itf-N interface can be considered as an IRP andthen integrated in the network resource model as a managed object. For example, Entry PointIRP (EPIRP) and NotificationIRP.

1.3.1 Interface Management of the CORBABased on the common management, configuration management, and fault management, the Itf-N consists of a cluster of management interfaces, such as common management interface,configuration management interface, and fault management interface.

Figure 1-2 shows the interface management functions.

Figure 1-2 Interface management functions



1-5

1.3.2 About IRPThe integrated reference point (IRP) is the abstract name of the interface function. The relativelyindependent interface function provided by the Itf-N interface can be considered as an IRP andthen integrated in the network resource model as a managed object. For example, Entry PointIRP (EPIRP) and NotificationIRP.

IRPAgentIRPAgent is the agent of IRP. In the network resource model, IRPAgent is used as the subnodeof ManagementNode. IRPAgent includes each object class of IRPs on the Itf-N interface.Therefore, the Itf-N interface is considered as IRPAgent in the network resource model.

IRPAgent referred in the latter section is considered as the Itf-N interface system. The managedobject are called IRPs.

Figure 1-3 shows the relation between managed object by the management domain.

Figure 1-3 Relation between managed object by the management domain

Relations Between IRPsFigure 1-4 shows the function of entry points that can get object reference of other IRPs.




Issue 03 (2010-12-31)

Figure 1-4 Getting object reference of other IRPs by entry points

Figure 1-5 shows relations between IRPs.

Figure 1-5 Relations between IRPs

1.4 Technical Specifications of Northbound CORBAInterface

This section describes the technical specifications related to the northbound CORBA interface.

Specification Item Value

Maximum number of NMS users on the CORBA interface 5

Maximum number of notifications to be subscribed to onCORBA interfaces

8

Maximum delay in reporting a northbound alarm (unit: second) 15



1-7




Issue 03 (2010-12-31)

2 Common Management Function of theCORBA Interface

About This Chapter

The function of common management interface consists of a cluster of management functions.These functions are EPIRP, NotificationIRP and CSIRP.

2.1 Entry Point of the CORBA InterfaceThe entry point is the first object that IRPAgent accesses. The NMS can access the point at anytime according to your requirement and get CORBA reference of managed object in a managedsystem specified by IRPAgent. AlarmIRP is one example of the managed object.

2.2 Notification Management Function of the CORBA InterfaceThe notification Management function of the CORBA interface is used for event reporting tothe NMS and the management of order information. Function description and format are detailedin the introduction to the CORBA notification management function.

2.3 Communication Surveillance Function of the CORBA InterfaceThe communication surveillance interface function provides a mechanism to monitor the statusof communication channels between the NMS and IRPAgent. In this situation, exceptions canbe detected as soon as possible.

M2000Northbound CORBA Interface Developer Guide 2 Common Management Function of the CORBA Interface


2-1

2.1 Entry Point of the CORBA InterfaceThe entry point is the first object that IRPAgent accesses. The NMS can access the point at anytime according to your requirement and get CORBA reference of managed object in a managedsystem specified by IRPAgent. AlarmIRP is one example of the managed object.

The interoperable object reference (IOR), that is, CORBA object reference of the entry point, isreleased as a file. In addition, IOR is permanent, that is, the IP address of the server whereIRPAgent is located is fixed and IOR is permanently effective.

Object references of other IRPs are variable. When IRPAgent is rebooted, these object referencesmust be obtained again.

2.1.1 Interface Description of the Entry Point of the CORBA InterfaceThis describes the functions of CORBA entry point. These functions consist of getting EPIRPversions, getting EPIRP operation profile, getting EPIRP notification profile, getting IRPoutline, getting IRP reference, and releasing IRP reference.

2.1.2 Notification Description of the Entry Point of the CORBA InterfaceWhen changes happen to the IRP information (for the EPIRP instance itself or other EPIRPinstances that the EPIRP instance knows) saved in the entry point, send a notification of entrypoint register information change to the NMS according to requirement.

2.1.1 Interface Description of the Entry Point of the CORBAInterface

This describes the functions of CORBA entry point. These functions consist of getting EPIRPversions, getting EPIRP operation profile, getting EPIRP notification profile, getting IRPoutline, getting IRP reference, and releasing IRP reference.

Getting EPIRP Versionsl Function description

The NMS invokes get_EP_IRP_versions to get EPIRP versions.

l Function formatManagedGenericIRPConstDefs::VersionNumberSet get_EP_IRP_versions ()raises (GetEPIRPVersions);

There is no parameter in getting EPIRP versions.

Table 2-1 Values of getting EPIRP versions

Returned Value Description Support(Y/N)

VersionNumberSet Indicates a set of versions that the EPIRP supports.The value of VersionNumberSet is a set of strings.Huawei supports only one of the EPIRP versions.

Y

2 Common Management Function of the CORBA InterfaceM2000



Issue 03 (2010-12-31)

Table 2-2 Exceptions of getting EPIRP version

Exception Description Support(Y/N)

GetEPIRPVersions Indicates the exceptions caused by unknownreasons.

Y

Getting EP IRP Operation Profilel Function description

NMS invokes get_EP_IRP_operations_profile to get the profile of operations supportedby EPIRP.

l Function formatManagedGenericIRPConstDefs::MethodList get_EP_IRP_operations_profile ( in ManagedGenericIRPConstDefs::VersionNumber iRPVersion)raises ( GetEPIRPOperationsProfile, ManagedGenericIRPSystem::OperationNotSupported, ManagedGenericIRPSystem::InvalidParameter);

Table 2-3 Parameters for getting EPIRP operation profile

Parameter In/Out Description Support(Y/N)

iRPVersion In Indicates the version ID of EPIRP in theEPIRP profile obtained by the NMS. Theversion ID should be consistent with theversion ID returned by Getting EPIRPVersions.

Y

Table 2-4 Values of getting EPIRP operation profile


MethodList Indicates the information list of operationsthe EPIRP supports.The information list contains the followingitems:l Names of operationsl Parameter lists

Y



2-3

Table 2-5 Exceptions of getting EPIRP operation profile


InvalidParameter Indicates that the given iRPVersion isinvalid or null.

Y

OperationNotSupported Indicates that this operation is notsupported.

N

GetEPIRPOperationsProfile Indicates the exceptions caused byunknown reasons.

Y

Getting EP IRP Notification Profilel Function description

The NMS invokes get_EP_IRP_notification_profile to get the profile of the notificationsupported by EPIRP.

l Function formatManagedGenericIRPConstDefs::MethodList get_EP_IRP_notification_profile ( in ManagedGenericIRPConstDefs::VersionNumber iRPVersion)raises ( GetEPIRPNotificationProfile, ManagedGenericIRPSystem::OperationNotSupported, ManagedGenericIRPSystem::InvalidParameter);

Table 2-6 Parameters for getting EPIRP notification profile


iRPVersion In Indicates the version information aboutEPIRP in the EPIRP outline gotten by theNMS. The version ID should be consistentwith the version ID returned by GettingEPIRP Versions.

Y

Table 2-7 Values of getting EPIRP notification profile


MethodList Indicates the profile list of notifications that anEPIRP supports.The profile list contains the following items:l Names of notifications supported by the EPIRPl Names of fields in the notification (including

the names of filterable_data andremainder_of_body fields)

Y




Issue 03 (2010-12-31)

Table 2-8 Exceptions of getting EPIRP notification profile


InvalidIRPVersion Indicates that the given iRPVersion isinvalid or null.

Y


N

GetEPIRPNotificationProfile Indicates the exceptions caused byunknown reasons.

Y

Getting IRP Outlinel Function description

The NMS invokes get_IRP_outline to get the outline of the management domain ManagedObject.

l Function formatEPIRPConstDefs::ResultType get_IRP_outline ( in ManagedGenericIRPConstDefs::VersionNumber iRPVersion, out EPIRPConstDefs::SupportedIRPListType supportedIRPList)raises (GetIRPOutline,InvalidIRPVersion);

Table 2-9 Parameters for getting IRP outline


iRPVersion In Indicates the version informationabout EPIRP in the EPIRP outlinegotten by the NMS.The parameter has the following twosituations:l If this parameter is null, the Agent

returns the outline of all EPIRPs,including this EPIRP instanceitself.

l If this parameter is not null, theentered value is the complete IRPinformation.If you plan to query the generalinformation about the CS IRP, theinput parameter is CS IRP V1.2.0.

Y



2-5


supportedIRPList Out Indicates the returned list of the IRPprofile according to input parameterconditions.The list contains all IRP informationin systemDn and IRPAgent. The IRPinformation contains:l irpIdl irpVersionl irpClassNamel irpManagementScopeThe value of the parameter is of multi-nested structure.

Y

Table 2-10 Values of getting IRP outline


OK Indicates that the operation succeeds. Y

FAILURE Indicates that the operation fails. Y

Table 2-11 Exceptions of getting IRP outline


InvalidIRPVersion Indicates that the given IRPVersion isinvalid.

Y

GetIRPOutline Indicates the exceptions caused by unknownreasons.

Y

Getting IRP Referencel Function description

The NMS invokes get_IRP_reference to get the CORBA object reference specified inIRPAgent or the object reference of EPIRP.

l Function formatEPIRPConstDefs::ResultType get_IRP_reference ( in EPIRPConstDefs::ManagerIdentifierType managerIdentifier, in EPIRPConstDefs::DNType systemDn, in EPIRPConstDefs::IRPIdType irpId, in EPIRPConstDefs::IRPClassNameType irpClassName, out string iRPReference




Issue 03 (2010-12-31)

)raises ( GetIRPReference, ManagedGenericIRPSystem::InvalidParameter);

Table 2-12 Parameters for getting IRP reference


managerIdentifier In Indicates a character string identifyingManager (NMS). The character stringis given by the NMS and is unique.You can provide different values formanagerIdentifier to invoke thisoperation. If the number of differentvalues reaches five, an exceptionoccurs.Huawei recommends that you use aunique value for the parameter in anNMS.

Y

systemDN In Indicates the DN value of IRPAgentobtained from the Agent system.The value of this parameter should beconsistent with the value ofsystemDn returned by Getting IRPOutline.

Y

irpId In Indicates irpId of IRP obtained by theNMS.The value of this parameter should beconsistent with the value of irpIdreturned by Getting IRP Outline.

Y

irpClassName In Indicates the class name of IRPobtained by the NMS.The value of this parameter should beconsistent with the class name of IRPreturned by Getting IRP Outline.

Y

iRPReference Out Indicates the CORBA object referenceof IRP needed by the NMS.When you use a differentmanagerIdentifier to get the sameobject of IRP, the reference isdifferent.

Y



2-7

Table 2-13 Values of getting IRP reference



Failure Indicates that the operation fails. Y

Table 2-14 Exceptions of getting IRP reference


InvalidParameter Indicates that the following parameters ortheir combination are invalid:l systemDNl irpIdl irpClassNamel managerIdentifier

Y

GetIRPReference Indicates the exceptions caused by unknownreasons.

Y

Releasing IRP Referencel Function description

The NMS invokes release_IRP_reference to release the reference of a specified IRP thatis not in use.

l Function formatEPIRPConstDefs::ResultType release_IRP_reference( in EPIRPConstDefs::ManagerIdentifierType managerIdentifier, in string iRPReference)raises ( ReleaseIRPReference, UnknownIRPReference);

Table 2-15 Parameters for releasing IRP reference


managerIdentifier In Indicates a character stringidentifying the NMS.The parameter should be consistentwith managerIdentifier specified inGetting IRP Reference.

Y




Issue 03 (2010-12-31)


iRPReference In Indicates the CORBA objectreference, that is, IOR of IRP to bereleased by the NMS.The parameter should be consistentwith iRPReference returned byGetting IRP Reference throughrelevant managerIdentifier.

Y

Table 2-16 Values of releasing IRP reference



Failure Indicates that the operation fails. Y

Table 2-17 Exceptions of releasing IRP reference


UnknownIRPReference Indicates that the specified iRPReference isinvalid or the specified managerIdentifierdoes not match iRPReference.The reason is that iRPReference is notobtained by managerIdentifier through theoperation Getting IRP Reference.

Y

ReleaseIRPReference Indicates the exceptions caused by unknownreasons.

Y

2.1.2 Notification Description of the Entry Point of the CORBAInterface

When changes happen to the IRP information (for the EPIRP instance itself or other EPIRPinstances that the EPIRP instance knows) saved in the entry point, send a notification of entrypoint register information change to the NMS according to requirement.

Triggering Conditionsl When the newly obtained object reference is successful through the Getting IRP

Reference interface.

l When the object is released successfully through the Releasing IRP Reference interface.



2-9

l When the IRPAgent system starts or stops.

Notification FormatTable 2-18 lists the format of the notification of entry point register information change.

Table 2-18 Format of the notification of entry point register information change

Attribute Name Type Domain Description

domain_name string header.fixed_header.event_type

Indicates the name of a manageddomain. This parameter shows theversion number of the associated IRPinformation model.

type_name string header.fixed_header.event_type

Indicates the type of the reportednotification.The value of this parameter is definedbyEPIRPNotifications::notifyIRPInfoChanges::ET_IRPINFO_CHANGES.

event_name string header.fixed_header

Indicates the name of an event. (Thisparameter is null.)

e string filterable_data Indicates the instances of MO thatsends the notification, that is, the IRPobject instance.

a long remainder_of_body

Indicates the notification identifierand is used to exclusively identify anotification.

b TimeBase::UtcT

filterable_data Indicates the time when an eventoccurs.

c string filterable_data Indicates the identifier of theIRPAgent that generatesnotifications.

IRP_DN string remainder_of_body

Indicates the DN value of the IRPwhen the information about the EPchanges.




Issue 03 (2010-12-31)


CHANGE_MODE enumChangeModeType{REGISTER,DEREGISTER,MODIFY};

remainder_of_body

Indicates that the change modes of theEPIRP information.The change modes are as follows:l REGISTER

A new object reference value isobtained.

l DEREGISTERThe IRPAgent system stops orreleases an object reference.

l MODIFYThe IRPAgent system starts theobject reference value.

ADDITIONAL_TEXT

string remainder_of_body

Indicates the additional descriptiontext added to the notification.

NOTE

CosNotification::PropertySeq is the value type of remainder_of_body.

2.2 Notification Management Function of the CORBAInterface

The notification Management function of the CORBA interface is used for event reporting tothe NMS and the management of order information. Function description and format are detailedin the introduction to the CORBA notification management function.

2.2.1 Introduction to Notification Management Function of the CORBAThe notification management function of the CORBA interface is used for event reporting tothe NMS, order management, and order limitation.

2.2.2 Interface Description of the CORBA Notification ManagementThis describes the CORBA notification management function that involves gettingnotificationIRP versions, getting notificationIRP operation profile, getting notificationIRPnotification profile, getting notification categories, subscribing specified notifications, detachingnotification subscription, changing subscription filter conditions, querying subscription IDs, andquerying parameters of specified subscription.

2.2.1 Introduction to Notification Management Function of theCORBA

The notification management function of the CORBA interface is used for event reporting tothe NMS, order management, and order limitation.

Table 2-19 describes the notification management function of the CORBA interface.



2-11

Table 2-19 Notification management function of the CORBA interface

Scenario Description

Enabling IRPAgent to reportevents to the NMS

The NMS invokes the notification management interface toenable the NMS to receive the notification ofCosNotifyComm::SequencePushConsumer that is definedby the CORBA specification IOR and the notification ofintegrating the CORBA specification. The notification issent to the NMS through the notification channel.

Managing subscribednotifications

The management includes the subscription period,notification class, and filter condition.To ensure that all the subscribed notifications are valid,IRPAgen check whether the currently subscribedCosNotifyComm::SequencePushConsumer object is valid.IRPAgen can determine the validity by using the methodof _non_existent provided by CORBA. If an object isinvalid, IRPAgent automatically cancels the subscriptionof the object.If the CosNotifyComm::SequencePushConsumer object isinvalid and need be subscribed again, the NMS isrecommended to actively invoke an interface to cancel thesubscription before the CosNotifyComm::SequencePush-Consumer is invalid.

Subscribing a maximum ofeight notifications

If the actual subscription number exceeds the maximumsubscription number, an exception occurs.The NMS is recommended to actively cancel unneededsubscription.

2.2.2 Interface Description of the CORBA NotificationManagement

This describes the CORBA notification management function that involves gettingnotificationIRP versions, getting notificationIRP operation profile, getting notificationIRPnotification profile, getting notification categories, subscribing specified notifications, detachingnotification subscription, changing subscription filter conditions, querying subscription IDs, andquerying parameters of specified subscription.

Getting Notification IRP Versionsl Function description

The NMS invokes get_notification_IRP_versions to get the NotificationIRP versioninformation.

l Function formatManagedGenericIRPConstDefs::VersionNumberSet get_notification_IRP_versions ()raises (GetNotificationIRPVersions);

Obtain the parameters irrelevant to the NotificationIRP version.




Issue 03 (2010-12-31)

Table 2-20 Values of getting notificationIRP versions

Returned Value Description Support (Y/N)

VersionNumberSet Indicates a set of versions that theNotificationIRP supports. The value ofVersionNumberSet is a set of strings.Huawei supports only one of theNotificationIRP versions.

Y

Table 2-21 Exceptions of getting notificationIRP versions

Exception Description Support (Y/N)

GetNotificationIRPVersions Indicates the exceptions causedby unknown reasons.

Y

Getting Notification IRP Operation Profilel Function description

The NMS invokes get_notification_IRP_operations_profile to get the profile ofoperations supported by a specified version of NotificationIRP.

l Function formatManagedGenericIRPConstDefs::MethodList get_notification_IRP_operations_profile ( in ManagedGenericIRPConstDefs::VersionNumber notification_irp_version)raises ( GetNotificationIRPOperationsProfile, ManagedGenericIRPSystem::OperationNotSupported, ManagedGenericIRPSystem::InvalidParameter);

Table 2-22 Parameters for getting notificationIRP operation profile

Parameter In/Out Description Support (Y/N)

notification_irp_version In Indicates the NotificationIRPversion ID in theNotificationIRP profileobtained by the NMS.The version ID should beconsistent with the version IDreturned by GettingNotification IRP Versions.

Y



2-13

Table 2-23 Values of getting notificationIRP operation profile


MethodList Indicates the information list of operations theNotificationIRP supports.The information list contains the following items:l Names of operationsl Parameter lists

Y

Table 2-24 Exceptions of getting notificationIRP operation profile


InvalidParameter Indicates that the givennotification_irp_version is invalid ornull.

Y


N

GetEPIRPOperationsProfile Indicates the exceptions caused byunknown reasons.

Y

Getting Notification IRP Notification Profilel Function description

The NMS invokes get_notification_IRP_notification_profile to get the profile of thenotification supported by NotificationIRP.

l Function formatManagedGenericIRPConstDefs::MethodList get_notification_IRP_notification_profile ( in ManagedGenericIRPConstDefs::VersionNumber notification_irp_version)raises ( GetNotificationIRPNotificationProfile, ManagedGenericIRPSystem::OperationNotSupported, ManagedGenericIRPSystem::InvalidParameter);

Table 2-25 Parameters for getting notificationIRP notification profile


notification_irp_version In Indicates the NotificationIRPversion ID in the NotificationIRPprofile obtained by the NMS.The version ID should beconsistent with the version IDreturned by GettingNotification IRP Versions.

Y




Issue 03 (2010-12-31)

Table 2-26 Values of getting notificationIRP notification profile


MethodList Indicates the profile list of notifications that anNotificationIRP supports.The profile list contains the following items:l Names of notifications supported by the

NotificationIRPl Names of fields in the notification (including the

names of filterable_data andremainder_of_body fields)

Y

NOTE

Notifications are not defined in the NotificationIRP.

Table 2-27 Exceptions of getting notificationIRP notification profile


InvalidIRPVersion Indicates that the givennotification_irp_version is invalid or null.

Y

OperationNotSupported Indicates that this operation is not supported. N

GetNotificationIRPNotifi-cationProfile

Indicates the exceptions caused by unknownreasons.

Y

Getting Notification Categoriesl Function description

The NMS invokes get_notification_categories to query the notification categoriessupported by IRPAgent and the mapping notification types.

l Function formatNotificationIRPConstDefs::NotificationCategorySet get_notification_categories ( out NotificationIRPConstDefs::NotificationTypesSet notification_type_list)raises ( GetNotificationCategories, ManagedGenericIRPSystem::OperationNotSupported);

Table 2-28 Parameters for getting notification categories


notification_type_list Out Indicates the list of notificationtypes that map to notificationcategories.

Y



2-15

Table 2-29 Values of getting notification categories


NotificationCategorySet Indicates the set of notification categoriessupported by IRPAgent. Each element in thisset specifies a notification category.

Y

Table 2-30 Exceptions of getting notification categories



GetNotificationCategories Indicates the exceptions caused by unknownreasons.

Y

Subscribing Specified Notificationsl Function description

The NMS invokes attach_push to subscribe notifications of specified categories.l Function format

NotificationIRPConstDefs::SubscriptionId attach_push ( in string manager_reference, in unsigned long time_tick, in NotificationIRPConstDefs::NotificationCategorySet notification_categories, in ManagedGenericIRPConstDefs::StringTypeOpt filter)raises ( Attach, ManagedGenericIRPSystem::ParameterNotSupported, ManagedGenericIRPSystem::InvalidParameter, AlreadySubscribed, AtLeastOneNotificationCategoryNotSupported);




Issue 03 (2010-12-31)

Table 2-31 Parameters for subscribing specified notifications


manager_reference In Identifies the event receiver at the NMSside. For IOR, the parameter valueshould be CosNotifyComm::Sequence-PushConsumer.The IRPAgent uses the event channelto transfer the NMS an eventinformation, that is, manager_refer-ence invokes the push operation.When the subscribed number exceedseight, no new subscriptions arereceived.

Y

time_tick In Indicates a timer.After this timer expires, the subscribednotification is detached to release thenotification channel resources.Normally, the NMS invokes QueryingParameters of SpecifiedSubscription periodically to refreshthe timer to ensure that the relevantchannel is not released.The unit for this parameter is minute.Set the value of the timer according tothe following two situations:l If you enter a value between 1 and

15, the timer is set to 15.

l If you enter a value more than 15(included), the timer is set to theentered value.

l If you enter null or 0, the timer neverexpires.

Y



2-17


notification_catego-ries

In Defines the set of notifications to befiltered. Each element in the set shouldbe an element of the notificationcategory returned by GettingNotification Categories.If the set is null, infer that all thenotification categories supported byIRPAgent are subscribed.For the repeated subscription ofmanager_reference, there must be anotification class that is not subscribedin the parameter-defined set. If all thenotification classes are subscribed inthe set, an AlreadySubscribedexception is displayed.l If notification_categories is null,

infer that all the notification classesunsubscribed by manager_refer-ence need be subscribed.

l If all the notification classes aresubscribed, an AlreadySubscri-bed exception is displayed.

Y

filter In Defines the filter condition for thenotification subscription.The parameter is set based on allnotification categories defined bynotification_categories.If this parameter is valued null, inferthat conditions defined bynotification_categories have no extrarestrictions.For details of the syntax, refer to 7.1.1Notification filter Description.

Y

Table 2-32 Values of subscribing specified notifications


SubscriptionId Identifies the notification subscription.The NMS can uniquely identify a subscriptionrecord by using this value.

Y




Issue 03 (2010-12-31)

Table 2-33 Exceptions of subscribing specified notifications


AlreadySubscribed Indicates that the notifications defined bynotification_categories are alreadysubscribed by the manager_referencereceiver.

Y

ParameterNotSuppor-ted

Indicates that this parameter is not supported. N

InvalidParameter Indicates that this parameter is incorrect orthat its format is incorrect.

Y

AtLeastOneNotifica-tionCategoryNotSup-ported

Indicates that this parameter is incorrect orthat the parameter notification_categories isinvalid.

Y

Attach Indicates the exceptions caused by unknownreasons.

Y

Detaching Notification Subscriptionl Function description

The NMS invokes detach to detach the notification subscription.l Function format

void detach ( in string manager_reference, in NotificationIRPConstDefs::SubscriptionId subscription_id)raises ( DetachException, ManagedGenericIRPSystem::ParameterNotSupported, ManagedGenericIRPSystem::InvalidParameter);

Table 2-34 Parameters for detaching notification subscription


manager_reference In Indicates the identifier of the eventreceiver at the home NMS that isgoing to detach the notificationsubscription. The parameter shouldbe consistent with manager_refer-ence specified in SubscribingSpecified Notifications.

Y

subscription_id In Indicates the unique identifier of thenotification subscription.If this parameter is null, infer that allnotifications earlier subscribed bymanager_reference are detached.

Y



2-19

Retract the subscription of the parameters having no values.

Table 2-35 Exceptions of detaching notification subscription


InvalidParameter Indicates that the specified parametermanager_reference, subscription_id ortheir combination is invalid. Alternatively,the notification subscription identified bysubscription_id is not subscribed bymanager_reference.

Y

ParameterNotSupported Indicates that this parameter is not supported. N

DetachException Indicates the exceptions caused by unknownreasons.

Y

Changing Subscription Filter Conditionsl Function description

The NMS invokes change_subscription_filter to change the subscription filter conditions.l Function format

void change_subscription_filter ( in NotificationIRPConstDefs::SubscriptionId subscription_id, in string filter)raises ( ChangeSubscriptionFilter, ManagedGenericIRPSystem::OperationNotSupported, ManagedGenericIRPSystem::InvalidParameter);

Table 2-36 Parameters for changing subscription filter conditions


subscription_id In Indicates the unique identifier ofthe notification subscription.

Y

filter In Indicates the subscription offilter conditions.

Y

NOTE

For details of the syntax of filter, refer to 7.1.1 Notification filter Description.

Table 2-37 Values of changing subscription filter conditions


- - -




Issue 03 (2010-12-31)

Table 2-38 Exceptions of changing subscription filter conditions


InvalidParameter Indicates that the subscription_id orfilter is invalid or null.

Y


N

ChangeSubscriptionFilter Indicates the exceptions caused byunknown reasons.

Y

Querying Subscription IDsl Function description

The NMS invokes get_subscription_ids to query all subscription IDs related to a specifiedmanager_reference.

l Function formatNotificationIRPConstDefs::SubscriptionIdSet get_subscription_ids ( in string manager_reference)raises ( GetSubscriptionIds, ManagedGenericIRPSystem::OperationNotSupported, ManagedGenericIRPSystem::InvalidParameter);

Table 2-39 Parameters for querying subscription IDs


manager_reference In Indicates the identifier of the eventreceiver to be queried at the NMSside.The parameter should be consistentwith the specified manager_refer-ence given by SubscribingSpecified Notifications.

Y

Table 2-40 Values of querying subscription IDs


SubscriptionIdSet Indicates the set of all subscription IDs relatedto manager_reference.If a specified manager_reference is valid butnot subscribed, the returned list is null.

Y



2-21

Table 2-41 Exceptions of querying subscription IDs


InvalidParameter Indicates that the manager_reference isinvalid.

Y


GetSubscriptionIds Indicates the exceptions caused by unknownreasons.

Y

Querying Parameters of Specified Subscriptionl Function description

The NMS invokes get_subscription_status to query parameters of a specifiedsubscription, including subscription parameters and subscription statuses.

l Function formatNotificationIRPConstDefs::NotificationCategorySet get_subscription_status ( in NotificationIRPConstDefs::SubscriptionId subscription_id, out ManagedGenericIRPConstDefs::StringTypeOpt filter_in_effect, out NotificationIRPConstDefs::SubscriptionState subscription_state, out unsigned long time_tick)raises ( GetSubscriptionStatus, ManagedGenericIRPSystem::OperationNotSupported, ManagedGenericIRPSystem::InvalidParameter);

Table 2-42 Parameters for querying specified subscription parameters


subscription_id In Indicates the unique identifier ofthe notification subscription.

Y

time_tick Out Indicates the value for invokingattach_push.

Y

filter_in_effect Out Indicates the filter condition usedby the current subscription.

Y

subscription_state Out Indicates the status of the currentsubscription, including:l Activel SuspendedBecause the Suspended statusis not supported, only theActive status exists.

Y




Issue 03 (2010-12-31)

Table 2-43 Values of querying specified subscription parameters


NotificationCategorySet Indicates the set of notification categoriessupported by the current subscription.

Y

Table 2-44 Exceptions of querying specified subscription parameters


InvalidParameter Indicates that the subscription_id isinvalid.

Y

OperationNotSupported Indicates that the operation is not supported. N

GetSubscriptionStatus Indicates the exceptions caused by unknownreasons.

Y

2.3 Communication Surveillance Function of the CORBAInterface

The communication surveillance interface function provides a mechanism to monitor the statusof communication channels between the NMS and IRPAgent. In this situation, exceptions canbe detected as soon as possible.

The NMS monitors communication channels using the following two ways:l By setting a heartbeat interval, the NMS can receive heartbeat notifications to monitor the

status of communication channels between the NMS and IRPAgent.l The NMS actively invoke IRPAgent to trigger the heartbeat interface to query the status

of communication channels.

2.3.1 Interface Description of the CORBA Communication SurveillanceThe CORBA communication surveillance involves getting CSIRP versions, getting CSIRPoperation profile, getting CSIRP notification profile, getting heartbeat period, setting heartbeatperiod, and triggering heartbeat notifications.

2.3.2 Heartbeat Notification of the CORBA Communication SurveillanceWhen the heartbeat period is up, IRPAgent sends a heartbeat notification accordingly to theNMS.

2.3.1 Interface Description of the CORBA CommunicationSurveillance

The CORBA communication surveillance involves getting CSIRP versions, getting CSIRPoperation profile, getting CSIRP notification profile, getting heartbeat period, setting heartbeatperiod, and triggering heartbeat notifications.



2-23

Getting CSIRP Versionsl Function description

The NMS invokes get_CS_IRP_versions to get the CSIRP version information.l Function format

ManagedGenericIRPConstDefs::VersionNumberSet get_CS_IRP_versions ()raises (GetCSIRPVersions);There is no parameter in getting CSIRP versions.

Table 2-45 Values of getting CSIRP versions


VersionNumberSet Indicates a set of versions that theEPIRP supports. The value ofVersionNumberSet is a set of strings.Huawei supports only one of the EPIRPversions.

Y

Table 2-46 Exceptions of getting CSIRP versions


GetCSIRPVersions Indicates the exceptions caused byunknown reasons.

Y

Getting CSIRP Operation Profilel Function description

The NMS invokes get_CS_IRP_operations_profile to get the profile of operationssupported by a specified version of CSIRP.

l Function formatManagedGenericIRPConstDefs::MethodList get_CS_IRP_operations_profile ( in ManagedGenericIRPConstDefs::VersionNumber iRPVersion)raises ( GetCSIRPOperationsProfile, ManagedGenericIRPSystem::OperationNotSupported, ManagedGenericIRPSystem::InvalidParameter);

Table 2-47 Parameters for getting CSIRP operation profile


iRPVersion In Indicates the version ID of CSIRP in theprofile obtained by the NMS. Theversion ID should be consistent with theversion ID returned by Getting CSIRPVersions.

Y




Issue 03 (2010-12-31)

Table 2-48 Values of getting CSIRP operation profile


MethodList Indicates the information list of operations theCSIRP supports.The information list contains the following items:l Names of operationsl Parameter lists

Y

Table 2-49 Exceptions of getting CSIRP operation profile


InvalidParameter Indicates that iRPVersion is invalid ornull.

Y


N

GetCSIRPOperationsProfile Indicates the exceptions caused byunknown reasons.

Y

Getting CSIRP Notification Profilel Function description

The NMS invokes get_CS_IRP_notification_profile to get the profile of notificationssupported by a specified version of CSIRP.

l Function formatManagedGenericIRPConstDefs::MethodList get_CS_IRP_notification_profile ( in ManagedGenericIRPConstDefs::VersionNumber iRPVersion)raises ( GetCSIRPNotificationProfile, ManagedGenericIRPSystem::OperationNotSupported, ManagedGenericIRPSystem::InvalidParameter);

Table 2-50 Parameters for getting CSIRP notification profile


iRPVersion In Indicates the version ID of CSIRP in theprofile obtained by the NMS.The version ID should be consistent withthe version ID returned by GettingCSIRP Versions.

Y



2-25

Table 2-51 Values of getting CSIRP notification profile


MethodList Indicates the profile list of notifications that aCSIRP supports.The profile list contains the following items:l Names of notifications supported by the CSIRPl Names of fields in the notification (including

the names of filterable_data andremainder_of_body fields)

Y

Table 2-52 Exceptions of getting CSIRP notification profile


InvalidIRPVersion Indicates that the iRPVersion is invalid ornull.

Y


GetCSIRPNotification-Profile

Indicates the exceptions caused by unknownreasons.

Y

Getting Heartbeat Periodl Function description

The NMS invokes get_heartbeat_period to get the interval for sending heartbeatnotifications, that is, the heartbeat period.

l Function formatCSIRPConstDefs::ResultType get_heartbeat_period( out CSIRPConstDefs::HeartbeatPeriodType heartbeatPeriod)raises (GetHeartbeatPeriod);

Table 2-53 Parameters for getting heartbeat period


heartbeatPeriod Out Indicates the interval for whichIRPAgent reports heartbeatnotifications periodically to the NMS(unit: minute).Value range: 5 to 60The default value is 5.

The value 0 is also valid and 0 meansthat the interval for sending heartbeatnotifications is not set.

Y




Issue 03 (2010-12-31)

Table 2-54 Values of getting heartbeat period


Success Indicates that this operation succeeds. Y

Failure Indicates that this operation fails. Y

Table 2-55 Exceptions of getting heartbeat period


GetHeartbeatPeriod Indicates the exceptions caused by unknownreasons.

Y

Setting Heartbeat Periodl Function description

The NMS invokes set_heartbeat_period to set the interval for Agent to send heartbeatnotifications. Whenever the heartbeatPeriod attribute changes, the Agent sends aheartbeat notification with the new heartbeat period immediately to all the NMS that havesubscribed this notification.If the changed heartbeat period is the same in value as the old one, failure is returned forthis operation.If the heartbeat period is changed to 0, the Agent sends a notification informing about thechange and sends no more heartbeat notifications later unless this value is changed toanother different value.

l Function formatCSIRPConstDefs::ResultType set_heartbeat_period( in CSIRPConstDefs::HeartbeatPeriodType heartbeatPeriod)raises ( SetHeartbeatPeriod, ConflictingHeartbeatPeriod, InvalidHeartbeatPeriod, ManagedGenericIRPSystem::ValueNotSupported, ManagedGenericIRPSystem::OperationNotSupported);

Table 2-56 Parameters for setting heartbeat period


heartbeatPeriod In Indicates the heartbeat period. Thechanged heartbeat period (unit: minute).Value range: 5 to 60The value 0 is also valid.

Y



2-27

Table 2-57 Values of setting heartbeat period




Table 2-58 Exceptions of setting heartbeat period


InvalidHeartbeatPeriod Indicates that the specified heartbeatperiod is invalid.

Y

ConflictingHeartbeatPeriod Indicates that the specified heartbeatperiod is the same as the current value.

Y

ValueNotSupported Indicates that the specified parameter isnot supported.

N


N

SetHeartbeatPeriod Indicates the exceptions caused byunknown reasons.

Y

Triggering Heartbeat Notificationsl Function description

The NMS invokes trigger_heartbeat to trigger a heartbeat notification. When receivingthis operation, IRPAgent sends immediately a heartbeat notification and indicates in thenotification that this notification is triggered by the NMS. The NMS can perform thisoperation to actively query the communication state with IRPAgent.This does not affect the normal heartbeat notifications sent periodically by IRPAgent.

l Function formatCSIRPConstDefs::ResultType trigger_heartbeat( in CSIRPConstDefs::ManagerIdentifierType managerIdentifier)raises (TriggerHeartbeat, InvalidManagerIdentifier);




Issue 03 (2010-12-31)

Table 2-59 Parameters for triggering heartbeat notifications


managerIdentifi-er

In Indicates the identifier of theNMS triggering the heartbeatnotification.The parameter is a characterstring. In addition, the parametermust get the object reference ofCSIRP through the Getting IRPReference interface.

Y

Table 2-60 Values of triggering heartbeat notifications




Table 2-61 Exceptions of triggering heartbeat notifications


InvalidManagerIdentifier Indicates that managerIdentifier isinvalid.

Y

TriggerHeartbeat Indicates the exceptions caused byunknown reasons.

Y

2.3.2 Heartbeat Notification of the CORBA CommunicationSurveillance

When the heartbeat period is up, IRPAgent sends a heartbeat notification accordingly to theNMS.

When the sent heartbeat notification is triggered by the NMS, it does not affect the originalheartbeat period. If the NMS expects a heartbeat notification, the NMS should be active tosubscribe the heartbeat notification.

Triggering Conditionsl The heartbeat interval set by the NMS is not 0 and the interval time is up.l The NMS successfully resets the heartbeat by performing the Setting Heartbeat Period

operation.



2-29

l The NMS successfully passes the Triggering Heartbeat Notifications operation.

NOTE

After sending a heartbeat notification, IRPAgent begins to count the heartbeat period again.

Notification FormatTable 2-62 lists the format of the heartbeat notification.

Table 2-62 Format of the heartbeat notification



Indicates the name of a manageddomain.This parameter shows the versionnumber of the associated IRPinformation model.


Indicates the type of the reportedheartbeat notificationnotifyHeartbeat.The value of this parameter is definedbyCSIRPNotifications::notifyHeartbeat::EVENT_TYPE.



e string filterable_data Indicates the instances of MO thatsends the notification, that is, theCSIRP object instance.



b TimeBase::UtcT

filterable_data Indicates the time when the eventoccurs.


HEARTBEAT_PERIOD

unsignedshort

remainder_of_body

Indicates the heartbeat interval.Because the NMS may modify theheartbeat interval, the attribute isused to indicate the currently definedinterval.




Issue 03 (2010-12-31)


TRIGGER_FLAG

ENUM{IRPManager,IRPAgent}

remainder_of_body

Indicates whether the notification isnormal or triggered byIRPManager.The attribute is valued as ENUM{IRPManager, IRPAgent}.

MANAGER_IDENTIFIER

string remainder_of_body

l If triggerFlag is IRPManager,the value of the parameter is thesame as that for thetriggerHeartbeat operation.

l If triggerFlag is IRPAgent, thevalue of the parameter is null.

CHANNEL_ID string remainder_of_body

The channel identifier of the OMGnotification service.

NOTE




2-31

3 Configuration Management Function of theCORBA Interface

About This Chapter

The configuration management interface has the following three functions: BasicCMIRP,KernelCMIRP, and BulkCMIRP.

3.1 Getting to Know Configuration Management of the CORBA InterfaceThis describes the concepts of the managed object (MO), network resource model (NRM),distinguished name (DN), and relative distinguished name (RDN).

3.2 Common Configuration Management of the CORBACommon configuration has the function of actively reporting the change of a configurationobject. When a configuration object needs to be created, deleted, or modified, or requests theNMS to synchronize the configuration, KernelCMIRP actively sends a notification to the NMSfor managing configuration objects.

3.3 Function and Interface of Basic Configuration Management of the CORBABasicCMIRP provides interface operations for configuration managed objects. You can query,create, delete, and modify the interfaces of configuration managed objects. The NMS can usethe interfaces to manage configuration managed objects. Huawei only supports the interface ofquerying configuration managed objects.

M2000Northbound CORBA Interface Developer Guide

3 Configuration Management Function of the CORBAInterface


3-1

3.1 Getting to Know Configuration Management of theCORBA Interface

This describes the concepts of the managed object (MO), network resource model (NRM),distinguished name (DN), and relative distinguished name (RDN).

Managed Object (MO)An MO is an abstract entity that can be accessed through an open interface in two or moresystems. An MO is also a network resource that can be managed. It is an instance of a managedobject class (MOC) that is defined in the network resource.

Network Resource Model (NRM)An NRM, which is provided by IRPAgent, is a model of the actual network resource that ismanaged. It includes MOCs and their relevant attributes and operations.

DN and RDNA DN is the unique identification of an MO, which consists of a prefix and a set of RDNs.

For details about the DN syntax, see 7.2 Description of DN String.




Issue 03 (2010-12-31)

NOTE

When an NMS manages a network through multiple M2000s, you can perform the following steps to modifySubNetworkId of a DN to identify the data reported by each M2000.

1. Run the following command to navigate to the installation directory of the M2000 server.

The default installation directory of the M2000 server is /opt/OMC.

By default, run the following command:

# cd /opt/OMC

2. Run the environment variable script.

# . ./svc_profile.sh

3. Run the following command to modify SubNetworkId.

This part takes changing SubNetworkId to 2 for example.

# modify_SubNetworkId.sh 2

If the system displays the following information, you can infer that SubNetworkId is changed to 2successfully. Begin to modify the value of subNetworkId in the itf_n_config.xml ...Current Corba Interface is CorbaNBI NBIV1.2.0 Begin to modify the value of subNetworkId in the CvtDef_Omc.xml ... Modify success! Please Restart IRPService!

4. Run the following command to restart IRPService:

# svc_adm -cmd restartsvc IRPService

After the service is restarted, run the following command to view the running status of the service andensure that it is running properly:

# svc_adm -cmd status | grep IRPService

If the system displays the following information, you can infer that IRPService is running properly.IRPService [running ]

5. Run the following command to check the modification result:

# cat /export/home/omc/var/etc/IRPService/itf_n_config.xml

If the following information is displayed in the beginning of the file, you can infer thatSubNetworkId is already changed to 2.<SubNetwork xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="Schema/ServiceConfig.xsd" subNetworkId="2" dnPrefix="www.huawei.com">

3.2 Common Configuration Management of the CORBACommon configuration has the function of actively reporting the change of a configurationobject. When a configuration object needs to be created, deleted, or modified, or requests theNMS to synchronize the configuration, KernelCMIRP actively sends a notification to the NMSfor managing configuration objects.

3.2.1 Interface Description of the Common Configuration Management of the CORBAThis describes the common configuration management of the CORBA interface. The commonconfiguration management involves getting KernelCMIRP versions, getting KernelCMIRPoperation profile, getting KernelCMIRP notification profile, and getting NRM versions.

3.2.2 Notification Description of the Common Configuration Management of the CORBAThe part describes the notifyObjectCreation, notifyObjectDeletion,notifyAttributeValueChange, notifyCMSynchronizationRecommended in the commonconfiguration management of the CORBA interface.




3-3

3.2.1 Interface Description of the Common ConfigurationManagement of the CORBA

This describes the common configuration management of the CORBA interface. The commonconfiguration management involves getting KernelCMIRP versions, getting KernelCMIRPoperation profile, getting KernelCMIRP notification profile, and getting NRM versions.

Getting KernelCMIRP Versionsl Function description

The NMS invokes get_kernel_CM_IRP_versions to get the KernelCMIRP versioninformation.

l Function formatManagedGenericIRPConstDefs::VersionNumberSet get_kernel_CM_IRP_versions ()raises (GetKernelCMIRPVersionsException);

There is no parameter in getting KernelCMIRP versions.

Table 3-1 Values of getting KernelCMIRP versions


VersionNumberSet Indicates a set of versions that the KernelCMIRPsupports. The value of VersionNumberSet is aset of strings.Huawei supports only one of the KernelCMIRPversions.

Y

Table 3-2 Exceptions of getting KernelCMIRP versions


GetKernelCMIRPVersionsExcep-tion

Indicates the exceptions caused byunknown reasons.

Y

Getting KernelCMIRP Operation Profilel Function description

The NMS invokes get_kernel_CM_IRP_operation_profile to get the profile ofoperations supported by a specified version of KernelCMIRP.

l Function formatManagedGenericIRPConstDefs::MethodList get_kernel_CM_IRP_operation_profile( in ManagedGenericIRPConstDefs::VersionNumber kernel_CM_IRP_version)raises ( GetKernelCMIRPOperationProfileException, ManagedGenericIRPSystem::OperationNotSupported, ManagedGenericIRPSystem::InvalidParameter);




Issue 03 (2010-12-31)

Table 3-3 Parameters for getting KernelCMIRP operation profile


kernel_CM_IRP_version In Indicates the KernelCMIRPversion information in the IRPprofile obtained by the NMS.The version ID should beconsistent with the version IDreturned by Getting kernelCMIRP Versions.

Y

Table 3-4 Values of getting KernelCMIRP operation profile


MethodList Indicates the information list of operations that theFileTransferIRP supports.The information list contains the following items:l Names of operationsl Parameter lists

Y

Table 3-5 Exceptions of getting KernelCMIRP operation profile


InvalidParameter Indicates that thekernel_CM_IRP_version is invalidor null.

Y

OperationNotSupported Indicates that the operation is notsupported.

N

GetKernelCMIRPOperationProfi-leException


Y

Getting KernelCMIRP Notification Profilel Function description

The NMS invokes get_kernel_CM_IRP_notification_profile to get the profile ofnotifications supported by KernelCMIRP.

l Function formatManagedGenericIRPConstDefs::MethodList get_kernel_CM_IRP_notification_profile ( in ManagedGenericIRPConstDefs::VersionNumber kernel_CM_IRP_version)raises (




3-5

GetKernelCMIRPNotificationProfileException, ManagedGenericIRPSystem::OperationNotSupported, ManagedGenericIRPSystem::InvalidParameter);

Table 3-6 Parameters for getting KernelCMIRP notification profile


kernel_CM_IRP_version In Indicates the KernelCMIRPversion information in the IRPprofile obtained by the NMS.The version ID should beconsistent with the version IDreturned by Getting kernelCMIRP Versions.

Y

Table 3-7 Values of getting KernelCMIRP notification profile


MethodList Indicates the profile list of notifications that anKernelCMIRP supports.The profile list contains the following items:l Names of notifications supported by the

KernelCMIRPl Names of fields in the notification (including the


Y

Table 3-8 Exceptions of getting KernelCMIRP notification profile


InvalidIRPVersion Indicates that the givenkernel_CM_IRP_version isinvalid or null.

Y


N

GetKernelCMIRPNotificationProfi-leException


Y

Getting NRMIRP Versionsl Function description




Issue 03 (2010-12-31)

The NMS invokes get_NRM_IRP_version to get the version of NRM supported byIRPAgent.

l Function formatvoid get_NRM_IRP_version ( out ManagedGenericIRPConstDefs::VersionNumberSet versionNumberList, out ManagedGenericIRPConstDefs::VersionNumberSet vSEVersionNumberList)raises (GetNRMIRPVersion);

Table 3-9 Parameters for getting NRMIRP versions


versionNumberList Out Indicates the version of the NRMssupported by Agent.The NRM has the following types:l Common NRMl Wireless access NRMl Core network NRM

Y

vSEVersionNum-berList

Out Indicates the unique version of theextended NRM supported by Agent.This NRM is the extension on existingspecifications. In this situation, theparameter versionNumberList lists theversion information about standardspecifications that work as the extensionbasis. Accordingly, the parameterversionNumberList lists informationabout the extended version.The version information has the followingthree parts:l Version information about standard

specifications which work as the basisl Unique ID of the manufacturerl Version information about the

extended NRM of this manufacturer

Y

There is no value in getting NRMIRP versions.

Table 3-10 Exceptions of getting NRMIRP versions


GetNRMIRPVersion Indicates the exceptions caused byunknown reasons.

Y




3-7

3.2.2 Notification Description of the Common ConfigurationManagement of the CORBA

The part describes the notifyObjectCreation, notifyObjectDeletion,notifyAttributeValueChange, notifyCMSynchronizationRecommended in the commonconfiguration management of the CORBA interface.

notifyObjectCreation

When a configuration managed object is added, send the notifyObjectCreation notification.

After the NMS receives the notification, add an MO at the NMS side according to e andATTRIBUTE_LIST in the notification. You need to not query configuration managed objectsby querying an interface.

l Triggering conditions

– An NE adds a configuration managed object.

– The OMC adds a management NE.

l Notification format

Table 3-11 lists the format of the notifyObjectCreation notification.

Table 3-11 Notification of notifyObjectCreation



Indicates the name of amanaged domain. Thisparameter shows the versionnumber of the associated IRPinformation model.


Indicates the type of thereported notification, that is,the notifyObjectCreationnotification.The value is defined byKernelCmNotifications::MOCreation::EVENT_TYPE.


Indicates the name of an event.(This parameter is null.)

e string filterable_data Indicates the instances of MOthat sends the notification, thatis, the DN of the new MOinstances.


Indicates the notificationidentifier and is used toexclusively identify anotification.




Issue 03 (2010-12-31)


b TimeBase::UtcT

filterable_data Indicates the time when theevent occurs.


ADD_TEXT string remainder_of_body

Indicates the additional textrelated to the notification.

SOURCE string remainder_of_body

Indicates the indicator of thesource operation that triggersthis notification.The value of the attribute maybe one of the following values:l Resource_operation

This notification istriggered by an operationon the managed resources.

l Management_operationThe notification istriggered by an NMSoperation delivered fromManager.

l UnknownThe cause for triggeringthe notification isunknown.

ATTRIBUTE_LIST KernelCmNotifications::MOCreation::InitialAttributeValues

remainder_of_body

Indicates the attribute list of anew object. The list includes:l Attribute namel Value

NOTE


notifyObjectDeletionThe notifyObjectDeletion notification is sent when an MO is deleted.

After the NMS receives the notification, delete the corresponding object or its sub-object at theNMS side according to the e field in the notification.




3-9

NOTE

The e field in the notification is the base object of the object to be deleted. The sub-object does not sendthe notifyObjectDeletion notification.

l Triggering condition– A configuration object of an NE is deleted.– The OMC deletes the configuration of an NE.

l Notification formatTable 3-12 lists the format of the notifyObjectDeletion notification.

Table 3-12 Notification of notifyObjectDeletion

AttributeName

Type Domain Description


Indicates the name of a manageddomain. This parameter shows theversion number of the associatedIRP information model.


Indicates the type of the reportednotification, that is, thenotifyObjectDeletion notification.The value is defined byKernelCmNotifications::MODeletion::EVENT_TYPE.


Indicates the name of an event.(This parameter is null.)

e string filterable_data Indicates the instances of MO thatsends the notification, that is, theDN of the deleted MO instances.



b TimeBase::UtcT




Indicates the additional text relatedto the notification.




Issue 03 (2010-12-31)

AttributeName



Indicates the indicator of the sourceoperation that triggers thisnotification.The value of the attribute may beone of the following values:l Resource_operation

This notification is triggered byan operation on the managedresources.

l Management_operationThe notification is triggered byan NMS operation deliveredfrom Manager.

l UnknownThe cause for triggering thenotification is unknown.

ATTRIBUTE_LIST

KernelCmNotifications::MODeletion::AttributeValues

remainder_of_body

Indicates the attribute list of anobject to be deleted. The listincludes:l Attribute namel Value

NOTE


notifyAttributeValueChangeThe notifyAttributeValueChange notification is sent when an MO is modified.

After the NMS receives the notification, modify the MO in the NMS according to e andATTRIBUTE_LIST in the notification.

l Triggering condition– Attributes of a configuration object at an NE side are modified.– Attribute values of an NE managed by the OMC are changed.

l Notification formatTable 3-13 lists the format of the notifyAttributeValueChange notification.




3-11

Table 3-13 Notification of notifyAttributeValueChange

AttributeName





Indicates the type of the reportednotification, that is, the notifyAttribute-ValueChange notification.The value if defined byKernelCmNotifications::AttributeValueChange::EVENT_TYPE.



e string filterable_data

Indicates the instances of MO that sendsthe notification, that is, the DN of themodified MO.


Indicates the notification identifier andis used to exclusively identify anotification.

b TimeBase::UtcT

filterable_data

Indicates the time when the eventoccurs.

c string filterable_data

Indicates the identifier of the IRPAgentthat generates notifications.


Indicates the additional text related tothe notification.


Indicates the indicator of the sourceoperation that triggers this notification.The value of the attribute may be one ofthe following values:l Resource_operation

This notification is triggered by anoperation on the managed resources.

l Management_operationThe notification is triggered by anNMS operation from Manager.

l UnknownThe cause for triggering thenotification is unknown.




Issue 03 (2010-12-31)

AttributeName


MODIFIED_ATTRIBUTE_SET

KernelCmNotifications::AttributeValueChange::ModifiedAttributeSet

remainder_of_body

Indicates the list of the changed objectattributes. The list includes:l Attribute name.l Attribute values before the change

(optional).l Attribute values after the change.

notifyCMSynchronizationRecommended

When configuration information is modified greatly, the notification is sent.

After the NMS receives the notification, the NMS can synchronize configuration data ofIRPAgent according to the BASE_MOI field and the SCOPE field in the notification.

l Triggering condition

– The OMC adds a management NE.

– The OMC timing mechanism sends synchronization information to an NE.

For example, start a timing task to synchronize at 00:00 every day.

NOTE

Both the notification of creating the ManagedElement object and the notification of synchronizingconfiguration information are sent.


Table 3-14 lists the format of the notifyCMSynchronizationRecommended notification.

Table 3-14 Notification of notifyCMSynchronizationRecommended

AttributeName





Indicates the type of the reportednotification, that is, thenotifyCMSynchronizationRecom-mended notification.The value is defined byKernelCmNotifications::CMSynchronizationRecommended::EVENT_TYPE.






3-13

AttributeName


e string filterable_data Indicates the instances of MO thatsends the notification, that is, theconfigured MO instances.



b TimeBase::UtcT




Indicates the additional text relatedto the notification.

BASE_MOC string remainder_of_body

Indicates the class of the base MO ofa subtree specified to besynchronized.This field is not supported.

BASE_MOI string remainder_of_body

Indicates the instance identifier ofthe base MO of a subtree specified tobe synchronized.

SCOPE KernelCmConstDefs::ScopePara

remainder_of_body

Indicates the scope specified forsynchronization.The attribute value may be:l Base MOl Whole subtreel From the base MO to the layer N

subtreel Objects in layer NThe default value is the wholesubtree.The value is defined as follows:enum ScopeType{ BASE_ONLY, BASE_NTH_LEVEL, BASE_SUBTREE, BASE_ALL};struct ScopePara{ ScopeType type; Unsigned long level;};




Issue 03 (2010-12-31)

NOTE


3.3 Function and Interface of Basic ConfigurationManagement of the CORBA

BasicCMIRP provides interface operations for configuration managed objects. You can query,create, delete, and modify the interfaces of configuration managed objects. The NMS can usethe interfaces to manage configuration managed objects. Huawei only supports the interface ofquerying configuration managed objects.

Getting BasicCMIRP Versionsl Function description

The NMS invokes get_basicCm_IRP_version to get the BasicCMIRP versioninformation.

l Function formatManagedGenericIRPConstDefs::VersionNumberSet get_basicCm_IRP_version()raises (GetBasicCmIRPVersion);There is no parameter in getting BasicCMIRP versions.

Table 3-15 Values of getting BasicCMIRP versions


VersionNumberSet Indicates a set of versions that theBasicCMIRP supports. The value ofVersionNumberSet is a set of strings.Huawei supports only one of theBasicCMIRP versions.

Y

Table 3-16 Exceptions of getting BasicCMIRP versions


GetBasicCmIRPVer-sion


Y

Getting BasicCMIRP Operation Profilel Function description

The NMS invokes get_basicCm_IRP_operation_profile to get the profile of operationssupported by a specified version of BasicCMIRP.

l Function formatManagedGenericIRPConstDefs::MethodList get_basicCm_IRP_operation_profile ( in ManagedGenericIRPConstDefs::VersionNumber basicCm_IRP_version)raises (




3-15

GetBasicCmIRPOperationProfile, ManagedGenericIRPSystem::OperationNotSupported, ManagedGenericIRPSystem::InvalidParameter);

Table 3-17 Parameters for getting BasicCMIRP operation profile


basicCm_IRP_version In Indicates the BasicCMIRPversion information in the IRPprofile obtained by the NMS.The version ID should beconsistent with the version IDreturned by GettingBasicCMIRP Versions.

Y

Table 3-18 Values of getting BasicCMIRP operation profile


MethodList Indicates the information list of operationsthat the BasicCMIRP supports.The information list contains the followingitems:l Names of operationsl Parameter lists

Y

Table 3-19 Exceptions of getting BasicCMIRP operation profile


InvalidParameter Indicates that the givenbasicCm_IRP_version is invalid ornull.

Y


N

GetBasicCmIRPOperation-Profile


Y

Getting BasicCMIRP Notification Profilel Function description

The NMS invokes get_basicCm_IRP_notification_profile to get the profile ofnotifications supported by BasicCMIRP.




Issue 03 (2010-12-31)

l Function formatManagedGenericIRPConstDefs::MethodList get_basicCm_IRP_notification_profile ( in ManagedGenericIRPConstDefs::VersionNumber basicCm_IRP_version)raises ( GetBasicCmIRPNotificationProfile, ManagedGenericIRPSystem::OperationNotSupported, ManagedGenericIRPSystem::InvalidParameter);

Table 3-20 Parameters for getting BasicCMIRP notification profile


basicCm_IRP_ver-sion

In Indicates the BasicCMIRP versioninformation in the BasicCMIRPprofile obtained by the NMS.The version ID should be consistentwith the version ID returned byGetting BasicCMIRP Versions.

Y

Table 3-21 Values of getting BasicCMIRP notification profile


MethodList Indicates the profile list of notifications that anBasicCMIRP supports.The profile list contains the following items:l Names of notifications supported by the

BasicCMIRPl Names of fields in the notification (including the


Y

NOTE

Notifications are not defined in the BasicCMIRP.

Table 3-22 Exceptions of getting BasicCMIRP notification profile


InvalidParameter Indicates that the givenbasicCm_IRP_version is invalid ornull.

Y


N




3-17


GetBasicCmIRPNotification-Profile


Y

Finding Managed Objectsl Function description

The NMS invokes find_managed_objects to query MOs in a specified condition and theirattribute values.

l Function format(1)BasicCmInformationIterator find_managed_objects ( in BasicCMIRPConstDefs::DN baseObject, in BasicCMIRPConstDefs::SearchControl searchControl, in BasicCMIRPConstDefs::AttributeNameSet requestedAttributes)raises ( FindManagedObjects, ManagedGenericIRPSystem::ParameterNotSupported, ManagedGenericIRPSystem::InvalidParameter, ManagedGenericIRPSystem::ValueNotSupported, ManagedGenericIRPSystem::OperationNotSupported, UndefinedMOException, IllegalDNFormatException, UndefinedScopeException, IllegalScopeTypeException, IllegalScopeLevelException, IllegalFilterFormatException, FilterComplexityLimit);

Table 3-23 Parameters for finding managed objects (I)


baseObject In Indicates the ID of the base objectinstance. The parameter identifiesexclusively the base object of an MOsubtree.

Y




Issue 03 (2010-12-31)


searchControl In Defines query conditions. Thestructure of the parameter is asfollows:struct SearchControl { ScopeType type; unsigned long level; FilterType filter; ResultContents contents; };The type field defines a query rangeand is used in combination with thelevel field.l If type is BASE_ONLY and level

is null, a base object is returned.l If type is BASE_NTH_LEVEL, all

the objects at the level layer arereturned. If level is 0, the baseobject is returned.

l If type is BASE_SUBTREE, allthe objects between base objectsand objects at the level layer arereturned.

l If type is BASE_ALL and level isnull, base objects and all theobjects under the base objects arereturned.

l The filter field is not supported.l If contents is NAMES, only the

DNs of required MOs arereturned and attributes of theMOs are not returned.

l If contents is NAMES_AND_AT-TRIBUTES, the DNs andattributes of required MOs arereturned.

Y

requestedAttributes in Defines a name list of attributes to bequeried.

Y

Table 3-24 Values of finding managed objects (I)


BasicCmInformationIter-ator

Indicates that the returned value is the CORBAobject of BasicCmInformationIterator.

Y




3-19

Table 3-25 Exceptions of finding managed objects (I)


IllegalDNFormatException Indicates an illegal DN. Y

UndefinedScopeException Indicates that the filter scope is undefined. Y

IllegalScopeTypeException Indicates an illegal filter scope type. N

IllegalScopeLevelException Indicates an illegal filter scope level. Y

IllegalFilterFormatException Indicates an illegal filter condition. N

FilterComplexityLimit Indicates a complex filter condition thatcannot be parsed.

N

ParameterNotSupported Indicates that the given parameters are notsupported.

Y

InvalidParameter Indicates that the given parameter is invalid. Y

UndefinedMOException Indicates that baseObjectInstance is invalid. N

ValueNotSupported Indicates the value is not supported. N


FindManagedObjects Indicates the exceptions caused by unknownreasons.

Y

l Function format(2)

boolean next_basicCmInformations ( in unsigned short how_many, out BasicCMIRPConstDefs::ResultSet fetchedElements)raises ( NextBasicCmInformations, ManagedGenericIRPSystem::InvalidParameter, ManagedGenericIRPSystem::OperationNotSupported);

Table 3-26 Parameters for finding managed objects (II)

Parameter In/Out

Description Support(Y/N)

how_many In Indicates the number of objects that the NMSexpects.The value of the parameter must be greaterthan 0.

Y




Issue 03 (2010-12-31)

Parameter In/Out


fetchedElements Out Returns an information list of configurationobjects. The list includes DNs and attributelists. The list includes the following sub-items:l mo: the object class name of each returned

attribute valuel attributes: the list of queried attribute

names and valuesNOTEl If the current configuration object number is

more than the value of how_many, the lengthof the parameter is equal to how_many.

l If the current configuration object number isless than or equal to the value of how_many,the parameter is the information about currentconfiguration objects.

Y

Table 3-27 Values of finding managed objects (II)


boolean Indicates that the returned value is of the Bool type.l TRUE indicates that some object information is

not returned.l FALSE indicates that all object information is

returned and iterator objects are released.

Y

Table 3-28 Exceptions of finding managed objects (II)


NextBasicCmInforma-tions

Indicates operation failure caused by someunknown causes.

Y

InvalidParameter Indicates an invalid parameter, for example thevalue of InvalidParameter is 0.

Y


l Function format(3)

void destroy ()raises ( DestroyException, ManagedGenericIRPSystem::OperationNotSupported);




3-21

Table 3-29 Exceptions of finding managed objects (III)


DestroyException Indicates the exceptions caused by unknownreasons.

Y

OperationNotSup-ported

Indicates that the operation is not supported. N

l Event flow

The process of querying the event flow of MOs is shown in Figure 3-1.

Figure 3-1 Querying the event flow of MOs

Table 3-30 lists the steps used for querying the event flow of MOs.

Table 3-30 Steps used for the event flow of querying MOs

No. Step

1 The NMS uses the find_managed_objects interface to query MOs in aspecified condition.

2 IRPAgent queries MOs according to conditions provided by the NMSand creates the BasicCmInformationIterator object.




Issue 03 (2010-12-31)

No. Step

3 The NMS invokes the next_basicCmInformation interface ofBasicCmInformationIterator to query qualified MOs.l If the returned value is false, infer that the information list of MOs is

null and IRPAgent automatically releases the BasicCmInformationIt-erator object.

l If the returned value is true, infer that the information list of MOs isnot null.

4 When the NMS does not select all the MO information, invoke destroyto release the BasicCmInformationIterator object.




3-23

4 Alarm Management Function of the CORBAInterface

About This Chapter

The AlarmIRP interface is the only interface used in alarm management. The alarm managementhas the following functions: querying alarms, clearing alarms, acknowledging alarms,unacknowledging alarms, and reporting alarms in real time.

4.1 Introduction to the CORBA Alarm ManagementWith alarm management function, you can query, clear, acknowledge, counter-acknowledgealarms, and add comments to alarms. In addition, alarms can be reported in real time.

4.2 Alarm Management of the CORBAThe alarm management of the CORBA interface describes the CORBA alarm management andits functions.

M2000Northbound CORBA Interface Developer Guide 4 Alarm Management Function of the CORBA Interface


4-1

4.1 Introduction to the CORBA Alarm ManagementWith alarm management function, you can query, clear, acknowledge, counter-acknowledgealarms, and add comments to alarms. In addition, alarms can be reported in real time.

Through the alarm query interface, the NMS collects alarm statistics and synchronizes alarms,while the NMS manages alarms through the alarm operation interface. The real-time report ofalarms enables the NMS to handle alarms in real time.

4.2 Alarm Management of the CORBAThe alarm management of the CORBA interface describes the CORBA alarm management andits functions.

4.2.1 Interface Description of the CORBA Alarm ManagementThe CORBA alarm management involves getting AlarmIRP versions, getting AlarmIRPoperation profile, getting AlarmIRP notification profile, getting alarm list, alarm contents,getting alarm count, acknowledging alarms, unacknowledging alarms, and clearing alarms.4.2.2 Notification Description of the CORBA Alarm ManagementThe description of the CORBA alarm management notification contains the triggeringconditions and formats of the potential faulty alarm list notification, new alarm notification,alarm acknowledgement status change notification, alarm clearance notification, alarm commentnotification, and alarm change notification.4.2.3 Mechanism for Forwarding Common AlarmsIn a multi-mode base station (MBTS), common alarms can be generated on certain commondevices. You can differentiate normal mode alarms from common alarms by viewing alarminformation.

4.2.1 Interface Description of the CORBA Alarm ManagementThe CORBA alarm management involves getting AlarmIRP versions, getting AlarmIRPoperation profile, getting AlarmIRP notification profile, getting alarm list, alarm contents,getting alarm count, acknowledging alarms, unacknowledging alarms, and clearing alarms.

Getting AlarmIRP Versionsl Function description

The NMS invokes get_alarm_IRP_versions to get information about AlarmIRP versions.l Function format

ManagedGenericIRPConstDefs::VersionNumberSet get_alarm_IRP_versions () raises (GetAlarmIRPVersions);There is no parameter in getting AlarmIRP versions.

Table 4-1 Values of getting AlarmIRP versions


VersionNumberSet Indicates a set of versions that AlarmIRPsupports. The value of VersionNumberSetis a set of strings.Huawei supports only one of the AlarmIRPversions.

Y

4 Alarm Management Function of the CORBA InterfaceM2000



Issue 03 (2010-12-31)

Table 4-2 Exceptions of getting AlarmIRP versions


GetAlarmIRPVersions Indicates the exceptions caused byunknown reasons.

Y

Getting AlarmIRP Operation Profilel Function description

The NMS invokes get_alarm_IRP_operations_profile to get the profile of operationssupported by AlarmIRP.

l Function formatManagedGenericIRPConstDefs::MethodList get_alarm_IRP_operations_profile ( in ManagedGenericIRPConstDefs::VersionNumber alarm_irp_version ) raises ( GetAlarmIRPOperationsProfile, ManagedGenericIRPSystem::OperationNotSupported, ManagedGenericIRPSystem::InvalidParameter);

Table 4-3 Parameters for getting AlarmIRP operation profile


alarm_irp_version in Indicates the version of managedobjects in the AlarmIRP manageddomain.The value of this parameter shouldbe consistent with the versionnumber displayed in GettingAlarmIRP Versions.

Y

Table 4-4 Values of getting AlarmIRP operation profile


MethodList Indicates the information list of operations thatAlarmIRP supports.The information list contains the followingitems:l Names of operationsl Parameter lists

Y



4-3

Table 4-5 Exceptions of getting AlarmIRP operation profile


InvalidParameter Indicates that the given alarm_irp_ver-sion is invalid or null.

Y


N

GetAlarmIRPOperationsPro-file


Y

Getting AlarmIRP Notification Profilel Function description

The NMS invokes get_alarm_IRP_notification_profile to get the profile of notificationssupported by AlarmIRP.

l Function formatManagedGenericIRPConstDefs::MethodList get_alarm_IRP_notification_profile ( in ManagedGenericIRPConstDefs::VersionNumber alarm_irp_version ) raises ( GetAlarmIRPNotificationProfile, ManagedGenericIRPSystem::OperationNotSupported, ManagedGenericIRPSystem::InvalidParameter);

Table 4-6 Parameters for getting AlarmIRP notification profile


alarm_irp_version in Indicates the AlarmIRP version inthe AlarmIRP profile obtained bythe NMS.The value of this parameter shouldbe consistent with the versionnumber displayed in GettingAlarmIRP Versions.

Y

Table 4-7 Values of getting AlarmIRP notification profile


MethodList Indicates the profile list of notifications that anAlarmIRP supports.The profile list contains the following items:l Names of notifications supported by AlarmIRPl Names of fields in the notification (including the


Y




Issue 03 (2010-12-31)

Table 4-8 Exceptions of getting AlarmIRP notification profile


InvalidParameter Indicates that the given alarm_irp_ver-sion is invalid or null.

Y


N

GetAlarmIRPNotificationPro-file


Y

Getting Alarm Listl Function description

The NMS invokes get_alarm_list to get an alarm list of the current operations that meetcertain requirements.

l Function format (1)AlarmIRPConstDefs::AlarmInformationSeq get_alarm_list ( in ManagedGenericIRPConstDefs::StringTypeOpt filter, in AlarmIRPConstDefs::DNTypeOpt base_object, out boolean flag, out AlarmInformationIterator iter ) raises ( GetAlarmList, ManagedGenericIRPSystem::ParameterNotSupported, ManagedGenericIRPSystem::InvalidParameter);

Table 4-9 Parameters for getting alarm list (I)


base_object in Either null or a certain object.If this parameter is null, all the alarminformation in the current alarm list isdisplayed.If this parameter is a certain object, only thealarm information related to the specifiedobjects or the child objects in the currentalarm list is displayed.

Y

filter in Defines the filtering conditions for the alarminformation to be obtained by the NMS. Forthe Union type, if this parameter is null, nofiltering conditions are set.NOTE

For details about the filtering restrictions, referto 7.1.2 Description of filter in get_alarm_list.

Y



4-5


flag out l If flag is true, the Returned Valueshows alarm information.

l If flag is false, the iter shows thealarm information while the ReturnedValue list is null.

Y

iter out Indicates that the alarm information isobtained through iter when flag is false.

This parameter is the CORBA object ofAlarmInformationIterator.

Y

Table 4-10 Values of getting alarm list (I)


AlarmInformationSeq l If flag is true, the Returned Value shows thealarms that meet certain requirements.

l If flag is false, the Returned Value is null.

Y

Table 4-11 Exceptions of getting alarm list (I)


InvalidParameter Indicates that the parameter is invalid. Y


Indicates that this operation is not supported. N

GetAlarmList Indicates the exceptions caused by unknownreasons.

Y

l Function format (2)

boolean next_alarmInformations ( in unsigned short how_many, out AlarmIRPConstDefs::AlarmInformationSeq alarm_informations ) raises ( NextAlarmInformations, ManagedGenericIRPSystem::InvalidParameter);




Issue 03 (2010-12-31)

Table 4-12 Parameters for getting alarm list (II)


how_many in Indicates the number of alarms that theNMS expects.The value of this parameter must be greaterthan 0 and less than or equal to 2000.

Y

alarm_informations out Indicates the displayed alarm informationlist.l If the number of current alarms exceeds

the value of how_many, the sequencelength of alarm_informations is equalto that of how_many.

l If the number of current alarms is lessthan or equal to how_many,alarm_informations indicates thealarm information list.

Y

Table 4-13 Values of getting alarm list (II)


boolean Indicates that the returned value is ofboolean.l TRUE indicates that some alarm

information is not returned.l FALSE indicates that all alarm

information is returned and iteratorobjects are released.

Y

Table 4-14 Exceptions of getting alarm list (II)


InvalidParameter Indicates that the parameter is invalid.For instance, if the value ofhow_many is 0, infer that thisparameter is invalid.

Y

NextAlarmInforma-tions

Indicates that this operation is notsupported.

Y

l Function format (3)

void destroy ()raises( CORBA::SystemException);



4-7

Table 4-15 Exceptions of getting alarm list (III)


SystemException Indicates the exceptions caused by unknownreasons.

Y

l Event flow

Figure 4-1 shows the event flow of alarm information.

Figure 4-1 Event flow of alarm information

1. Get alarm lists.

2. Query alarms.

3. The AlarmInformationIterator is displayed when the value of flag is false. Allalarms are displayed when the value of flag is true.

4. In case the value of flag is false, the next_alarmInformations is invoked.

5. The system displays alarms. If the value false is displayed, objects are released.

6. If the value true is displayed, the system continue to query alarms.

7. Release objects directly.

Alarm Contentsl Unacknowledged and uncleared alarms

Table 4-16 lists the format of the Unacknowledged and uncleared alarms.




Issue 03 (2010-12-31)

Table 4-16 Unacknowledged and uncleared alarms

AttributeName



Indicates the version number of theassociated IRP information model.


Reports the name of a new alarm.The value of this parameter is asfollows: AlarmIRPConstDefs::No-tificationType ::NOTIFY_FM_NEW_ALARM.


Indicates the name of an event anddefines communication alarms,internal error-handling alarms,QoS alarms, and equipment alarms.The value of this parameter maps toAlarmIRPConstDefs::AlarmType.

e string filterable_data Indicates the object instances of analarm.

b TimeBase::UtcT

filterable_data Indicates the time when an alarmoccurs.

c string filterable_data Indicates the identifier of theIRPAgent.

g short filterable_data Indicates the possible reasons foran alarm and has more detailedcategorizations compared withAlarmType.The value range and informationabout this parameter are defined inProbableCause.

h short filterable_data Indicates the severity of an alarm.The following lists severities ofalarms:l INDETERMINATEl CRITICALl MAJORl MINORl WARNINGl CLEAREDNOTE

Currently, INDETERMINATE is notsupported.



4-9

AttributeName


jj long filterable_data Vendor-customized alarm type1: Fault alarm

nn long filterable_data The maintenance-mode alarmstatuses are as follows:l 0: Normall 1: Creationl 2: Expansionl 3: Upgradel 4: CommissioningNo default value of this attribute isprovided. The filterable_data areain alarm messages contains thisattribute only after this attribute isactivated.By default, the maintenance-modealarm function is inactive. TheNMS receives maintenance-modealarms only after this function isactivated. For details about how toactivate the maintenance-modealarm function and the attribute, seeReporting maintenance-modealarms.

f string remainder_of_body

Indicates the serial number ofalarms and is used to be the onlyidentifier for an alarm.

i string remainder_of_body

Indicates the detailed reasons for analarm.This parameter records theHuawei alarm private information.




Issue 03 (2010-12-31)

AttributeName


j string remainder_of_body

Indicates the detailed locationinformation about an alarm.The information consists of thefollowing items:l NE locationl Vendorl NE namel Alarm namel Detailed alarm location

informationThe format for locationinformation is as follows:NeType: NodeB| NeLocation:ShangHai | vendor: Huawei |neName: N91003| alarmName: RFUnit Maintenance Link Failure|alarmLocation: Cabinet No.=1,Subrack No.=4, Slot No.=0, Boardtype=WRFU| appendInfo:

NOTE

AlarmIRPConstDefs::AttributeSetType is the value type of remainder_of_body.

To set the maintenance-mode alarm function, perform the following steps:

1. Run the following command as user root or omcuser on the M2000 server to activate themaintenance-mode alarm function:

SettingTool -cmd setparam -path "/imap/ifms/specialAlarmStatus/nbenable" -value"true"

2. Run the following command to restart the FaultService service:

svc_adm -cmd restartsvc FaultService3. Check whether the CORBA V1.2.0 interface is installed by referring to the

iManagerM2000V200R010C00 Guide to Query and Change Northbound CORBAInterface. If the installed interface is not the CORBA V1.2.0 interface, replace it with theCORBA V1.2.0 interface.

4. Open the /opt/OMC/etc/IRPService/itf_n_config.xml file, and then setenableSpecialAlarmStatusID to true.<AlarmIRP irpId="4" Turner="synch" FileCategory="IM" ThreadNum="2" enableSpecialAlarmStatusID="false">

5. Run the following command to restart the IRPService service:

svc_adm -cmd restartsvc IRPService

l Alarms that are already acknowledged but not clearedTable 4-17 lists the format of the acknowledged but uncleared alarms.



4-11

Table 4-17 Acknowledged but uncleared alarms

AttributeName



Indicates the versionnumber of the associatedIRP information model.


Indicates the state of analarm. This parameter refersto the acknowledgementstate of an alarm.The value of this parametermaps toAlarmIRPConstDefs::NotificationType ::NOTIFY_FM_ACK_STATE_CHANGED.

event_name string header.fixed_header Indicates the name of anevent and definescommunication alarms,internal error-handlingalarms, QoS alarms, andequipment alarms.The value of this parametermaps toAlarmIRPConstDefs::AlarmType.

e string filterable_data Indicates the MO instancesin the alarm notification.That is, this parametershows the object instancesof alarms occurred.

b TimeBase::UtcT

filterable_data Indicates the time when analarm occurs.


g short filterable_data Indicates the possiblereasons for an alarm and hasmore detailedcategorizations comparedwith AlarmType.The value range andinformation about thisparameter are defined inProbableCause.




Issue 03 (2010-12-31)

AttributeName


h short filterable_data Indicates the severity of analarm.The following lists theseverities of alarms:l INDETERMINATEl CRITICALl MAJORl MINORl WARNINGl CLEAREDNOTE

Currently,INDETERMINATE is notsupported.

k TimeBase::UtcT

filterable_data Indicates the time when analarm is acknowledged.

jj long filterable_data Vendor-customized alarmtype1: Fault alarm



4-13

AttributeName


nn long filterable_data The maintenance-modealarm statuses are asfollows:l 0: Normall 1: Creationl 2: Expansionl 3: Upgradel 4: CommissioningNo default value of thisattribute is provided. Thefilterable_data area in alarmmessages contains thisattribute only after thisattribute is activated.By default, themaintenance-mode alarmfunction is inactive. TheNMS receives maintenance-mode alarms only after thisfunction is activated. Fordetails about how to activatethe maintenance-modealarm function and theattribute, see Reportingmaintenance-modealarms.

f string remainder_of_body Indicates the serial numberof alarms and is used to bethe only identifier for analarm.

l string remainder_of_body Indicates an identifier for auser that acknowledges analarm.The NMSacknowledgement alarmsshould be acknowledged byusers whose ids are in therange of ack_user_id.The OMCacknowledgement alarmsshould be performed only byOMC authorized users.




Issue 03 (2010-12-31)

AttributeName


n short remainder_of_body Indicates the current state ofalarm acknowledgement.The value 1 indicates thatthe alarm inAcknowledge state.

i string remainder_of_body Indicates the detailedreasons for an alarm.This parameter records theHuawei alarm privateinformation.

j string remainder_of_body Indicates the detailedlocation information aboutan alarm.The information consists ofthe following items:l NE locationl Vendorl NE namel Alarm namel Detailed alarm location

informationThe format for locationinformation is as follows:NeType: NodeB|NeLocation: ShangHai |vendor: Huawei | neName:N91003| alarmName: RFUnit Maintenance LinkFailure| alarmLocation:Cabinet No.=1, SubrackNo.=4, Slot No.=0, Boardtype=WRFU| appendInfo:

NOTE


l Unacknowledged but cleared alarmsTable 4-18 lists the format of the unacknowledged but cleared alarms.



4-15

Table 4-18 Unacknowledged but cleared alarms

AttributeName



Indicates the version numberof the associated IRPinformation model.


Indicates the state of analarm. Here this parameterrefers to the alarms inClear state.

The value of this parametermaps toAlarmIRPConstDefs::Noti-ficationType :NOTIFY_FM_CLEARED_ALARM.

event_name string header.fixed_header Indicates the name of anevent and definescommunication alarms,internal error-handlingalarms, QoS alarms, andequipment alarms.The value of this parametermaps toAlarmIRPConstDefs::AlarmType.

e string filterable_data Indicates the objectinstances in the alarmnotification.

b TimeBase::UtcT



g short filterable_data Indicates the possiblereasons for an alarm and hasmore detailedcategorizations comparedwith AlarmType.The value range andinformation about thisparameter are defined inProbableCause.




Issue 03 (2010-12-31)

AttributeName


h short filterable_data Indicates the severity of analarm. The following liststhe severities of alarms:l INDETERMINATEl CRITICALl MAJORl MINORl WARNINGl CLEAREDNOTE



nn long filterable_data The maintenance-modealarm statuses are asfollows:l 0: Normall 1: Creationl 2: Expansionl 3: Upgradel 4: CommissioningNo default value of thisattribute is provided. Thefilterable_data area in alarmmessages contains thisattribute only after thisattribute is activated.By default, the maintenance-mode alarm function isinactive. The NMS receivesmaintenance-mode alarmsonly after this function isactivated. For details abouthow to activate themaintenance-mode alarmfunction and the attribute,see Reportingmaintenance-modealarms.



4-17

AttributeName


f string remainder_of_body Indicates the serial numberof alarms and is used to bethe only identifier for analarm.

y string remainder_of_body Indicates an identifier for auser that clears an alarm.For the NMS, alarms can becleared by users whose IDsare in the range ofclear_user_id.For the OMC, alarms can becleared only by OMCauthorized users.In case of automatic alarmclearance, the authorizeduser is NE.

ll TimeBase::UtcT

remainder_of_body Indicates the time when analarm is cleared.

i string remainder_of_body Indicates the detailedreasons for an alarm.This parameter records theHuawei alarm privateinformation.




Issue 03 (2010-12-31)

AttributeName


j string remainder_of_body Indicates the detailedlocation information aboutan alarm.The information consists ofthe following items:l NE locationl Vendorl NE namel Alarm namel Detailed alarm location

informationThe format for locationinformation is as follows:NeType: NodeB|NeLocation: ShangHai |vendor: Huawei | neName:N91003| alarmName: RFUnit Maintenance LinkFailure| alarmLocation:Cabinet No.=1, SubrackNo.=4, Slot No.=0, Boardtype=WRFU| appendInfo:

NOTE


Getting Alarm Countl Function description

The NMS invokes get_alarm_count to get the count of all the current alarms differentseverities. The alarm count is consistent with the alarm information returned by GettingAlarm List. You can query the count of alarms in different severities before Getting AlarmList.

l Function formatvoid get_alarm_count ( in ManagedGenericIRPConstDefs::StringTypeOpt filter, out unsigned long critical_count, out unsigned long major_count, out unsigned long minor_count, out unsigned long warning_count, out unsigned long indeterminate_count, out unsigned long cleared_count ) raises ( GetAlarmCount, ManagedGenericIRPSystem::OperationNotSupported, ManagedGenericIRPSystem::ParameterNotSupported, ManagedGenericIRPSystem::InvalidParameter);



4-19

Table 4-19 Parameters for getting alarm count

Parameter In/Out


filter in Indicates the filtering conditions for thealarm count that the NMS wants to get.NOTE

For details about the filtering format, refer to7.1.3 Description of filter inget_alarm_count.

Y

critical_count out Displays the count of alarms in critical. Y

major_count out Displays the count of alarms in major. Y

minor_count out Displays the count of alarms in minor. Y

warning_count out Displays the count of alarms in warning. Y

indeterminate_count

out Displays the count of alarms inindeterminate.

Y

cleared_count out Displays the count of alarms in cleared. Y

Table 4-20 Values of getting alarm count


- - -

Table 4-21 Exceptions of getting alarm count


InvalidParameter Indicates that the given parameters areinvalid.

Y


Indicates that this parameter is notsupported.

N

OperationNotSuppor-ted

Indicates that the operation is notsupported.

N

GetAlarmCount Indicates the exceptions caused byunknown reasons.

Y

Acknowledging Alarmsl Function description

The NMS invokes acknowledge_alarms to acknowledge one or more alarms.




Issue 03 (2010-12-31)

l Function formatManagedGenericIRPConstDefs::Signal acknowledge_alarms ( in AlarmIRPConstDefs::AlarmInformationIdAndSevSeq alarm_information_id_and_sev_list, in string ack_user_id, in ManagedGenericIRPConstDefs::StringTypeOpt ack_system_id, out AlarmIRPConstDefs::BadAcknowledgeAlarmInfoSeq bad_ack_alarm_info_list ) raises ( AcknowledgeAlarms, ManagedGenericIRPSystem::ParameterNotSupported, ManagedGenericIRPSystem::InvalidParameter);

Table 4-22 Parameters for acknowledging alarms


alarm_information_id_and_sev_list in

Defines the identifier of alarmsto be acknowledged and the setof alarm severities.The ALARM_ID field in thealarm information indicates thealarm identifier.NOTE

Alarm severity is a parameter thatmust be entered. Currently,however, the M2000 does nothandle this parameter.

Y

ack_user_id in Defines the identifier of an NMSuser who acknowledges alarms.The parameter is defined by theNMS.

Y

ack_system_id in Defines the information aboutthe system where the NMS islocated.

N



4-21


bad_ack_alarm_info_list out Indicates errors in the alarmacknowledgement.If all the alarms areacknowledged correctly, thereturned value is OK and thisparameter is null.The displayed informationcontains the alarm identifiersand the reasons for the errors.The following lists the reasonsfor errors:l If the alarm ID does not exist,

the reason for the errors canbe classified asUNKNOWNALARMID.

l If the acknowledgeinformation does not displaythe wanted modification, thereason for the errors can beclassified asACKNOWLEDGMENT-FAILED, although the alarmID exists.

l If an alarm is alreadyacknowledged, the reason forthe errors can be classified asACKNOWLEDGMENT-FAILED, although the alarmID exists.

Y

Table 4-23 Values of acknowledging alarms


OK Indicates that all the alarms that requireacknowledgements are acknowledged.

Y

PartialFailure Indicates that only some of the alarms thatrequire acknowledgements are acknowledged.

Y

Failure Indicates that all the alarms that requireacknowledgements fail in acknowledgement.

Y




Issue 03 (2010-12-31)

Table 4-24 Exceptions of acknowledging alarms


InvalidParameter Indicates that at least one group of parameters isinvalid.

Y

AcknowledgeAlarms Indicates the exceptions caused by unknownreasons.

Y


Indicates the parameter is not supported. Y

Unacknowledging Alarmsl Function description

The NMS invokes unacknowledge_alarms to unacknowledge one or more alarms.l Function format

ManagedGenericIRPConstDefs::Signal unacknowledge_alarms ( in AlarmIRPConstDefs::AlarmInformationIdSeq alarm_information_id_list, in string ack_user_id, in ManagedGenericIRPConstDefs::StringTypeOpt ack_system_id, out AlarmIRPConstDefs::BadAlarmInformationIdSeq bad_alarm_information_id_list ) raises ( UnacknowledgeAlarms, ManagedGenericIRPSystem::OperationNotSupported, ManagedGenericIRPSystem::ParameterNotSupported, ManagedGenericIRPSystem::InvalidParameter);

Table 4-25 Parameters for unacknowledging alarms


alarm_information_id_list in Defines the identifier ofalarms to beunacknowledged.The ALARM_ID field in thealarm information indicatesthe alarm identifier.

Y

ack_user_id in Defines the identifier of anNMS user whounacknowledges alarms. Theparameter is defined by theNMS and should be consistentwith ack_user_id.

Y

ack_system_id in Defines the information aboutthe system where the NMS islocated.

N



4-23


bad_alarm_information_id_list

out Indicates errors in the alarmunacknowledgement.If all the alarms to beunacknowledged areunacknowledged, thereturned value is OK and thisparameter is null.The displayed informationcontains the alarm identifiersand the reasons for the errors.The following lists thereasons for the errors:l If the alarm ID specified in

the input parameter doesnot exist, the errorinformation is couldnot find thealarm.

l If the alarm ID specified inthe input parameter existsbut the actual alarm statusis "unacknowledged", theerror information is thealarm isunacknowledgedstate.

Y

Table 4-26 Values of unacknowledging alarms


OK Indicates that all the alarms that requireunacknowledgement are unacknowledged.

Y

PartialFailure Indicates that only some of that alarms thatrequire unacknowledgements areunacknowledged.

Y

Failure Indicates the cancel of theacknowledgements fails.

Y




Issue 03 (2010-12-31)

Table 4-27 Exceptions of unacknowledging alarms


InvalidParameter Indicates that all the groups ofparameters or at least one group ofparameters is invalid.

Y

ParameterNotSupported Indicates that the given parameters arenot supported.

Y


N

UnacknowledgeAlarms Indicates the exceptions caused byunknown reasons.

Y

Clearing Alarmsl Function description

The NMS invokes clear_alarms to clear one or more alarms.l Function format

ManagedGenericIRPConstDefs::Signal clear_alarms ( in AlarmIRPConstDefs::AlarmInformationIdSeq alarm_information_id_list, in string clear_user_id, in ManagedGenericIRPConstDefs::StringTypeOpt clear_system_id, out AlarmIRPConstDefs::BadAlarmInformationIdSeq bad_alarm_information_id_list ) raises ( ClearAlarms, ManagedGenericIRPSystem::ParameterNotSupported, ManagedGenericIRPSystem::InvalidParameter);

Table 4-28 Parameters for clearing alarms


alarm_information_id_list in Defines the identifier list ofthe alarms that the NMSwould clear.

Y

clear_user_id in Defines the identifier of anNMS user who clearsalarms.

Y

clear_system_id in Defines the informationabout the system where theNMS is located.

N



4-25



out Indicates errors in the alarmclearance.The displayed informationcontains the alarmidentifiers and reasons forthe errors.If all the alarms to be clearedare cleared, the returnedvalue is OK and thisparameter is null.The following lists thereasons for the errors:l The alarm ID does not

exist.l The NE does not support

manual alarm clearance.l The OMC disconnects

with the NE.

Y

Table 4-29 Values of clearing alarms


OK Indicates that all the alarms that require clearance arecleared.

Y

PartialFailure Indicates that only some of the alarms that requireclearance are cleared.

Y

Failure Indicates the clearance of alarms fails. Y

Table 4-30 Exceptions of clearing alarms


InvalidParameter Indicates that at least one group of parametersis invalid.

Y

ParameterNotSupported Indicates that the given parameters are notsupported.

Y

ClearAlarms Indicates the exceptions caused by unknownreasons.

Y




Issue 03 (2010-12-31)

Adding Comments to Alarmsl Function description

The NMS invokes this function to add comments to one or more alarms.l Function format

ManagedGenericIRPConstDefs::Signal comment_alarms ( in AlarmIRPConstDefs::AlarmInformationIdSeq alarm_information_id_list, in string comment_user_id, in ManagedGenericIRPConstDefs::StringTypeOpt comment_system_id, in string comment_text, out AlarmIRPConstDefs::BadAlarmInformationIdSeq bad_alarm_information_id_list)raises ( CommentAlarms, ManagedGenericIRPSystem::OperationNotSupported, ManagedGenericIRPSystem::ParameterNotSupported, ManagedGenericIRPSystem::InvalidParameter);

Table 4-31 Parameters for adding comments to alarms

Parameter In/Out

Description Supported (Y/N)

alarm_information_id_list in Refers to the list of theidentifiers indicating the alarmsto which the NMS will addcomments.

Y

comment_user_id in Refers to the identifier of theNMS user who will addcomments to alarms.

Y

comment_system_id in Refers to the information aboutthe NMS system that will addcomments to alarms.

N

comment_text in Refers to the comments to beadded to alarms.

Y



4-27

Parameter In/Out

Description Supported (Y/N)


out Refers to the alarm informationindicating the failure to addcomments to alarms.If comments are successfullyadded to all the specifiedalarms, the returned value is OKand this parameter is empty.The system output containsalarm identifiers and errorcauses. The error information isas follows:l If the alarm identifier

specified in the typedparameter does not exist, thesystem displays couldnot find the alarm.

l If the alarm identifierspecified in the typedparameter exists but addingcomments to this alarm isnot supported, the systemdisplays commentingthe alarm is notsupported.

Y

Table 4-32 Values of adding comments to alarms

Returned Value Description Supported (Y/N)

OK Indicates that comments are successfully added to allthe specified alarms.

Y

PartialFailure Indicates that comments are added to some of thespecified alarms.

Y

Failure Indicates that adding comments to the specifiedalarms fails.

Y

Table 4-33 Exceptions of adding comments to alarms

Exception Description Supported (Y/N)

OperationNotSupported Indicates that adding comments to a certainalarm is not supported.

N




Issue 03 (2010-12-31)

Exception Description Supported (Y/N)

ParameterNotSupported Indicates that one or more typed parameters arenot supported.

Y

InvalidParameter Indicates that at least one group of the typedparameters are invalid.

Y

4.2.2 Notification Description of the CORBA Alarm ManagementThe description of the CORBA alarm management notification contains the triggeringconditions and formats of the potential faulty alarm list notification, new alarm notification,alarm acknowledgement status change notification, alarm clearance notification, alarm commentnotification, and alarm change notification.

Notification of Potential Faulty Alarm ListThe IRPAgent may find that the current alarm list is inconsistent with the actual networkresources, or is not sure about the current alarm list. In such a situation, the IRPAgent sends thenotifyPotentialFaultyAlarmList to inform the NMS that the current alarm list may be inaccurate.

l Triggering conditionThe connection between the NE and the OMC become disconnected.

l Notification formatTable 4-34 lists the format of the notifyPotentialFaultyAlarmList notification.

Table 4-34 notifyPotentialFaultyAlarmList

AttributeName





Indicates the type of thereported notification, that is,notifyPotentialFaultyAlarm-List.The value of this parameter isdefined byAlarmIRPConstDefs::NotificationType::NOTIFY_FM_POTENTIAL_FAULTY_ALARM_LIST.



4-29

AttributeName



Indicates the name of anevent. (This parameter isnull.)

e string filterable_data Indicates the instances ofMO that sends thenotification, that is, theobject instance of AlarmIRP.



b TimeBase::UtcT

filterable_data Indicates the time when anevent occurs.


x string remainder_of_body

Indicates the reasons forreconstruction of alarm list.

NOTE

AlarmIRPConstDefs::AttributeSetType is the value type of the remainder_of_body.

Notification of New AlarmsWhen new alarms occur on NEs or on the OMC, the NMS sends the new alarm notification.

l Triggering conditionNew alarms occur on NEs or on the OMC.

l Notification formatTable 4-35 lists the format of the new alarm notification.

Table 4-35 Notification of new alarms



Indicates the version numberof the associated IRPinformation model.




Issue 03 (2010-12-31)



Indicates the type of thereported alarm, that is, thenew alarm.The value of this parameter isas follows:AlarmIRPConstDefs::Notifi-cationType ::NOTIFY_FM_NEW_ALARM.


Indicates the name of anevent and definescommunication alarms,internal error-handlingalarms, QoS alarms, andequipment alarms.The value of this parameter isthat ofAlarmIRPConstDefs::AlarmType.

e string filterable_data Indicates the instances of MOthat sends the notification,that is, the object instance ofthe alarm.



b TimeBase::UtcT



g short filterable_data Indicates the possible reasonsfor an alarm and has moredetailed categorizationscompared with AlarmType.The value range andinformation about thisparameter are defined inProbableCause of the IDL.



4-31


h short filterable_data Indicates the severity of analarm.The following lists severitiesof alarms:l INDETERMINATEl CRITICALl MAJORl MINORl WARNINGl CLEAREDNOTE

Currently, INDETERMINATEis not supported.


nn long filterable_data The maintenance-modealarm statuses are as follows:l 0: Normall 1: Creationl 2: Expansionl 3: Upgradel 4: CommissioningNo default value of thisattribute is provided. Thefilterable_data area in alarmmessages contains thisattribute only after thisattribute is activated.By default, the maintenance-mode alarm function isinactive. The NMS receivesmaintenance-mode alarmsonly after this function isactivated. For details abouthow to activate themaintenance-mode alarmfunction and the attribute, seeReporting maintenance-mode alarms.


Indicates the serial number ofalarms and is used to be theonly identifier for an alarm.




Issue 03 (2010-12-31)



Indicates the detailed reasonsfor an alarm.This parameter records theHuawei alarm privateinformation.


Indicates the detailedlocation information about analarm.The information consists ofthe following items:l NE locationl Vendorl NE namel Alarm namel Detailed alarm location

informationThe format of locationinformation is as follows:NeType: NodeB|NeLocation: ShangHai |vendor: Huawei | neName:N91003| alarmName: RFUnit Maintenance LinkFailure| alarmLocation:Cabinet No.=1, SubrackNo.=4, Slot No.=0, Boardtype=WRFU| appendInfo:

NOTE


Notification of the Change of Alarm Acknowledgement Status

If the acknowledgement status of an alarm is changed, the NMS sends the alarmacknowledgement notification.


– The NMS successfully acknowledges or unacknowledges alarms throughAcknowledging Alarms or Unacknowledging Alarms.

– The OMC successfully acknowledges or unacknowledges alarms.


Table 4-36 lists the format of the alarm acknowledgement notification.



4-33

Table 4-36 Notification of the change of the alarm acknowledgement status





Indicates the type of thereported alarm, that is, thenotification of the change ofthe alarm acknowledgementstatus.The value of this parameter isas follows:AlarmIRPConstDefs::Notifi-cationType ::NOTIFY_FM_ACK_STATE_CHANGED.


Indicates the name of an eventand defines communicationalarms, internal error-handlingalarms, QoS alarms, andequipment alarms.The value of this parameter isthat ofAlarmIRPConstDefs::Alarm-Type.

e string filterable_data Indicates the MO instances inthe alarm notification. That is,this parameter shows the objectinstances of alarms occurred.



b TimeBase::UtcT






Issue 03 (2010-12-31)


g short filterable_data Indicates the possible reasonsfor an alarm and has moredetailed categorizationscompared with AlarmType.The value range andinformation about thisparameter are defined inProbableCause in the IDL.

h short filterable_data Indicates the severity of analarm.The following lists theseverities of alarms:l INDETERMINATEl CRITICALl MAJORl MINORl WARNINGl CLEAREDNOTE

Currently, INDETERMINATE isnot supported.

k TimeBase::UtcT

filterable_data Indicates the time when analarm is acknowledged orunacknowledged.

jj long filterable_data Vendor-customized alarm type1: Fault alarm



4-35


nn long filterable_data The maintenance-mode alarmstatuses are as follows:l 0: Normall 1: Creationl 2: Expansionl 3: Upgradel 4: CommissioningNo default value of thisattribute is provided. Thefilterable_data area in alarmmessages contains thisattribute only after thisattribute is activated.By default, the maintenance-mode alarm function isinactive. The NMS receivesmaintenance-mode alarmsonly after this function isactivated. For details abouthow to activate themaintenance-mode alarmfunction and the attribute, seeReporting maintenance-mode alarms.


Indicates the serial number ofalarms and is used to be theonly identifier for an alarm.

l string remainder_of_body

Indicates an identifier for a userthat acknowledges orunacknowledges an alarm.l The NMS

acknowledgement alarmsshould be acknowledged orunacknowledged by userswhose ids are in the rangeof ack_user_id.

l The OMCacknowledgement orunacknowledgementalarms should be performedonly by OMC authorizedusers.

l In case of automaticacknowledgement, theauthorized user is system.




Issue 03 (2010-12-31)


n short remainder_of_body

Indicates the currentacknowledgement state of analarm.l The value 1 indicates that

the alarm in Acknowledgestate.

l The value 2 indicates thatthe alarm inUnacknowledge state.

For details, refer to thedefinition ofAlarmIRPConstDefs::Ac-kState.


Indicates the detailed reasonsfor an alarm.This parameter records theprivate information of Huaweialarms.



informationThe format of locationinformation is as follows:NeType: NodeB| NeLocation:ShangHai | vendor: Huawei |neName: N91003|alarmName: RF UnitMaintenance Link Failure|alarmLocation: CabinetNo.=1, Subrack No.=4, SlotNo.=0, Board type=WRFU|appendInfo:

NOTE




4-37

Notification of Alarm Clearance

When an alarm is cleared, the NMS sends the alarm clearance notification.


– The notification of alarm clearance shows that the NMS successfully clears alarmsthrough Notification of Alarm Clearance.

– The OMC successfully clears alarms.

– The NEs automatically clear alarms.


Table 4-37 lists the format of the alarm clearance notification.

Table 4-37 Notification of alarm clearance



Indicates the name of a manageddomain. This parameter showsthe version number of theassociated IRP informationmodel.


Indicates the type of the reportednotification, that is, notificationof alarm clearance.The value of this parameter is asfollows:AlarmIRPConstDefs::Notifica-tionType ::NOTIFY_FM_CLEARED_ALARM.


Indicates the name of an eventand defines communicationalarms, internal error-handlingalarms, QoS alarms, andequipment alarms.The value of this parameter isthat ofAlarmIRPConstDefs::Alarm-Type.

e string filterable_data

Indicates the object instances inthe alarm notification.



b TimeBase::UtcT

filterable_data

Indicates the time when an alarmis cleared.




Issue 03 (2010-12-31)


c string filterable_data

Indicates the identifier of theIRPAgent.

g short filterable_data

Indicates the possible reasons foran alarm and has more detailedcategorizations compared withAlarmType.The value range and informationabout this parameter are definedin ProbableCause.

h short filterable_data

Indicates the severity of analarm.The following lists the severitiesof alarms:l INDETERMINATEl CRITICALl MAJORl MINORl WARNINGl CLEAREDNOTE

Currently, INDETERMINATE isnot supported.

jj long filterable_data

Vendor-customized alarm type1: Fault alarm



4-39


nn long filterable_data

The maintenance-mode alarmstatuses are as follows:l 0: Normall 1: Creationl 2: Expansionl 3: Upgradel 4: CommissioningNo default value of this attributeis provided. The filterable_dataarea in alarm messages containsthis attribute only after thisattribute is activated.By default, the maintenance-mode alarm function is inactive.The NMS receives maintenance-mode alarms only after thisfunction is activated. For detailsabout how to activate themaintenance-mode alarmfunction and the attribute, seeReporting maintenance-modealarms.


Indicates the serial number ofalarms and is used to be the onlyidentifier for an alarm.

y string remainder_of_body

Indicates an identifier for a userthat clears an alarm.l For the NMS, alarms can be

cleared by users whose IDsare in the range ofclear_user_id.

l For the OMC, alarms can becleared only by OMCauthorized users.

l In case of automatic alarmclearance, the authorized useris NE.


Indicates the detailed reasons foran alarm.This parameter records theHuawei alarm privateinformation.




Issue 03 (2010-12-31)




informationThe format of locationinformation is as follows:NeType: NodeB| NeLocation:ShangHai | vendor: Huawei |neName: N91003| alarmName:RF Unit Maintenance LinkFailure| alarmLocation: CabinetNo.=1, Subrack No.=4, SlotNo.=0, Board type=WRFU|appendInfo:

NOTE


Notification of Adding Alarm CommentWhen the alarm comment is added through the Northbound interface, the notification is sent.

l Trigger conditionThe NMS successfully adds alarm comment.

l Notification formatTable 4-38 the notification format of adding alarm comment.

Table 4-38 Format of adding alarm comment



Indicates themanagement domainname. It is the versionnumber of correspondingIRP information model.



4-41



Indicates the type ofreported notification,that is, notification ofadding alarm comment.The value isAlarmIRPConstDefs::NotificationType ::.NOTIFY_FM_COMMENT_ADDED.

event_name string header.fixed_header Indicates the event name.Its value is alarm type. Itdefines notificationalarm, internal error-handling alarm, QoSalarm, and equipmentalarm. The value isdefined byAlarmIRPConstDefs::AlarmType.

e string filterable_data Indicates the instances ofMO that sends thenotification, that is, theobject instance of alarm.

b TimeBase::UtcT

filterable_data Indicates the time whenthe notification of addingalarm comment occurs.

c string filterable_data Indicates the identifier ofthe managed system(IRPAgent) thatgenerates thenotification.

g short filterable_data Indicates the possiblereasons for an alarm andhas more detailedcategorizationscompared withalarmType. The valuerange and informationabout this parameter aredefined inProbableCause of IDL.




Issue 03 (2010-12-31)


h short filterable_data Indicates the followingalarm severity:l INDETERMINATEl CRITICALl MAJORl MINORl WARNINGl CLEAREDNOTE


jj long filterable_data Vendor-customizedalarm type1: Fault alarm

nn long filterable_data The maintenance-modealarm statuses are asfollows:l 0: Normall 1: Creationl 2: Expansionl 3: Upgradel 4: CommissioningNo default value of thisattribute is provided. Thefilterable_data area inalarm messages containsthis attribute only afterthis attribute is activated.By default, themaintenance-modealarm function isinactive. The NMSreceives maintenance-mode alarms only afterthis function is activated.For details about how toactivate themaintenance-modealarm function and theattribute, see Reportingmaintenance-modealarms.



4-43


a long remainder_of_body Indicates the notificationidentifier and is used toexclusively identify anotification.

f string remainder_of_body Indicates the serialnumber of alarms and isused to be the onlyidentifier for an alarm.

o sequence remainder_of_body Indicates the added alarmcomment informationAlarmIRPConstDefs::CommentSet.

NOTE

The value type of remainder_of_body domain is AlarmIRPConstDefs::AttributeSetType.

Notification of Alarm ChangesThe alarm notification is delivered when the NE alarm changes.

l Trigger conditionThe NE alarm changes.

l Notification formatTable 4-39 describes the notification format of alarm changes.

Table 4-39 Notification of alarm changes



Indicates themanagement domainname. It is the versionnumber of correspondingIRP information model.


Indicates the type of thereported notification,that is, the notification ofnew alarm. The value isAlarmIRPConstDefs::NotificationType ::.NOTIFY_FM_CHANGED_ALARM.




Issue 03 (2010-12-31)


event_name string header.fixed_header Indicates the event name.Its value is alarm type. Itdefines notificationalarm, internal error-handling alarm, QoSalarm, and equipmentalarm. The value isdefined byAlarmIRPConstDefs::AlarmType.

e string filterable_data Indicates the instances ofMO that sends thenotification, that is, theobject instance of alarm.

b TimeBase::UtcT

filterable_data Indicates the time whenalarm changes.

c string filterable_data Indicates the identifier ofthe managed system(IRPAgent) thatgenerates thenotification.

g short filterable_data Indicates the possiblereasons for an alarm andhas more detailedcategorizationscompared withalarmType. The valuerange and informationabout this parameter aredefined inProbableCause of IDL.

h short filterable_data Indicates the followingalarm severity:l INDETERMINATEl CRITICALl MAJORl MINORl WARNINGl CLEAREDNOTE




4-45


jj long filterable_data Vendor-customizedalarm type1: Fault alarm

nn long filterable_data The maintenance-modealarm statuses are asfollows:l 0: Normall 1: Creationl 2: Expansionl 3: Upgradel 4: CommissioningNo default value of thisattribute is provided. Thefilterable_data area inalarm messages containsthis attribute only afterthis attribute is activated.By default, themaintenance-modealarm function isinactive. The NMSreceives maintenance-mode alarms only afterthis function is activated.For details about how toactivate themaintenance-modealarm function and theattribute, see Reportingmaintenance-modealarms.

a long remainder_of_body Indicates the notificationidentifier and is used toexclusively identify anotification.

f string remainder_of_body Indicates the serialnumber of alarms and isused to be the onlyidentifier for an alarm.

i string remainder_of_body Indicates the detailedreasons for an alarm.This field records theHuawei alarm privateinformation.




Issue 03 (2010-12-31)


j string remainder_of_body Indicates the detailedlocation informationabout an alarm.Theinformation consists ofNE location, vendor, NEname, alarm name, anddetailed alarm locationinformation.The format is as follows:NeType: NodeB|NeLocation: ShangHai |vendor: Huawei |neName: N91003|alarmName: RF UnitMaintenance LinkFailure| alarmLocation:Cabinet No.=1, SubrackNo.=4, Slot No.=0,Board type=WRFU|appendInfo:

NOTE

The value type of remainder_of_body domain is AlarmIRPConstDefs::AttributeSetType.

4.2.3 Mechanism for Forwarding Common AlarmsIn a multi-mode base station (MBTS), common alarms can be generated on certain commondevices. You can differentiate normal mode alarms from common alarms by viewing alarminformation.

Common alarms are generated on some common devices in an MBTS. On the M2000 client,choose Monitor > Browse Alarm List and then choose Advanced > Properties > CommonAlarm Indentifier. You can then determine whether the generated alarms are normal modealarms or common alarms by viewing values in the Common Alarm Identifier column. Thevalue of Common Alarm Identifier can be NA, GSM, UMTS, or LTE, where NA indicatesa normal mode alarm.

A common alarm can be reported repeatedly to the NMS through northbound interfaces. Toavoid this problem, you can determine the method to be used for reporting common alarmsthrough the northbound interfaces by setting a configuration item.

The directory for this configuration item is /imap/ifms/mbtsfilter, and the value range is 0-7.The default value is 0, indicating that the common alarms whose Common Alarm Identifiervalues are GSM, UMTS, or LTE are to be reported. For details about this configuration item,see Table 4-40.

You can run the SettingTool command to set the configuration item.l Run the following commands to set the configuration item:

# . /opt/OMC/svc_profile.sh



4-47

# SettingTool -cmd setparam -path "/imap/ifms/mbtsfilter" -value 1If the directory of the configuration item, that is, /imap/ifms/mbtsfilter, is set to 1, onlythe common alarm whose Common Alarm Identifier value is GSM is to be reported.

l Run the following command to restart FaultService:# svc_adm -cmd restartsvc FaultService

l Run the following command to check whether FaultService is started:# svc_adm -cmd status | grep FaultServiceIf the system displays the following information, it indicates that FaultService is started:FaultService [running ]

Run the SettingTool command to view the value of the configuration item:

SettingTool -cmd getparam -path "/imap/ifms/mbtsfilter"

Table 4-40 Description of the configuration item

Value Meaning

0 The common alarms whose Common Alarm Identifier values areGSM, UMTS, or LTE are to be reported through the northboundinterfaces.In an MBTS GU, two common alarms with the same information areto be reported. One alarm is generated by the MBTS GSM and the otheris generated by the MBTS UMTS. All the information contained in thealarms is the same except that they have different network serialnumbers (SNs).

1 Only the common alarm whose Common Alarm Identifier value isGSM is to be reported through the northbound interfaces.In an MBTS GU, only the common alarm whose Common AlarmIdentifier value is GSM is to be reported.

2 Only the common alarm whose Common Alarm Identifier value isUMTS is to be reported through the northbound interfaces.l In an MBTS UL or GU, only the common alarm whose Common

Alarm Identifier value is UMTS is to be reported.l In an MBTS GL, no common alarm is to be reported.

3 Only the common alarms whose Common Alarm Identifier values areGSM or UMTS are to be reported through the northbound interfaces.l In an MBTS GU, two alarms generated by the MBTS GSM and

MBTS UMTS are to be reported.l In an MBTS GL, only the common alarm whose Common Alarm

Identifier value is GSM is to be reported.l In an MBTS UL, only the common alarm whose Common Alarm

Identifier value is UMTS is to be reported.




Issue 03 (2010-12-31)

Value Meaning

4 Only the common alarm whose Common Alarm Identifier value isLTE is to be reported through the northbound interfaces.l In an MBTS GL, only the common alarm generated by the MBTS

LTE is to be reported.l In an MBTS UL, only the common alarm whose Common Alarm

Identifier value is LTE is to be reported.l In an MBTS GU, no common alarm is to be reported.

5 Only the common alarms whose Common Alarm Identifier values areGSM or LTE are to be reported through the northbound interfaces.l In an MBTS GL, two common alarms generated by the MBTS GSM

and MBTS LTE are to be reported.l In an MBTS UL, only the common alarm whose Common Alarm

Identifier value is LTE is to be reported.l In an MBTS GU, only the common alarm whose Common Alarm

Identifier value is GSM is to be reported.

6 Only the common alarms whose Common Alarm Identifier values areUMTS or LTE are to be reported through the northbound interfaces.l In an MBTS UL, two common alarms generated by the MBTS

UMTS and MBTS LTE are to be reported.l In an MBTS GL, only the common alarm whose Common Alarm

Identifier value is LTE is to be reported.l In an MBTS GU, only the common alarm whose Common Alarm

Identifier value is UMTS is to be reported.

7 The common alarms whose Common Alarm Identifier values areGSM, UMTS, or LTE are not to be reported through the northboundinterfaces.No common alarm is to be reported, regardless of the type of the MBTS.



4-49

5 Preparations for InterconnectionCommissioning of the Northbound CORBA

Interface

About This Chapter

Before interconnecting the NMS to the M2000, you need to make certain preparations. If youcomplete the preparations, you can infer that the northbound CORBA interface meets theconditions for the interconnection.

5.1 Negotiating the Interconnection Parameters of the Northbound CORBA InterfaceBefore connecting the M2000 to the NMS, make sure that the NMS is licensed to use thenorthbound CORBA interface and has the negotiated interconnection parameters.

5.2 Obtaining the IDL FileThis describes how to obtain the IDL file. The NMS interconnects to the M2000 by invokingthe IDL file. Before the interconnection, the IDL file of the M2000 needs to be provided to theNMS.

5.3 Checking the CORBA VersionBefore interconnecting the M2000 to the NMS, make sure that the northbound CORBA versionon the M2000 server is valid.

5.4 Obtaining the Reference of the Entry Point ObjectThis describes how to obtain the reference of the entry point object, that is, the1.ior file. Thereference of the entry point object is the prerequisite for the M2000 to invoke the northboundCORBA interface.

5.5 Modifying the hosts File of the ServerThis section describes how to enable the NMS host and the M2000 server to communicate witheach other through their host names. After you modify the hosts files of the M2000 server andthe NMS host, they communicate with each other, subscribe to notifications, and receivenotifications by using their host names.

5.6 Using the CORBA InterfaceThis section describes how to use the northbound CORBA interface when the M2000 systemadopts different networking modes.


5 Preparations for Interconnection Commissioning of theNorthbound CORBA Interface


5-1

5.1 Negotiating the Interconnection Parameters of theNorthbound CORBA Interface

Before connecting the M2000 to the NMS, make sure that the NMS is licensed to use thenorthbound CORBA interface and has the negotiated interconnection parameters.

Checking LicenseBefore the interconnection, make sure that the NMS has the required license. Do as follows tocheck whether the NMS has the required license.

1. Log in to the M2000 client.2. Choose License > OMC License Management > License Information. The License

Information window is displayed.3. Click the Resource Control Item tab. If Resource contains Alarm CORBA Interface or

Basic Configuration CORBA Interface, you can infer that the NMS is authorized to usethe CORBA interface.

Negotiating the Interconnection ParametersThe negotiated parameters include the parameters that the M2000 should provide to the NMSand the parameters that the NMS should provide to the M2000. For details, see Table 5-1.

Table 5-1 Negotiated parameters

Parameter Type Parameter Parameter Value Description

Parameters providedto the NMS by theM2000

FTP user name The FTP user can beany user that has thepermission to readthe 1.ior file.

For example, ftpuser.

FTP password The actual passwordof the FTP user.

For example, ftpuser.

Configuration model The value of thisparameter dependson the actualcondition.

If the RNC is used onsite, theconfiguration modelof this NE needs to beprovided for theNMS.

IP address andhostname of theM2000 server

The value of thisparameter dependson the actualcondition.

The M2000 providesthe IP address andhostname of theserver for theinterconnection.




Issue 03 (2010-12-31)

Parameter Type Parameter Parameter Value Description

Parameters providedto the M2000 by theNMS

IP address andhostname of theNMS

The value of thisparameter dependson the actualcondition.

The NMS providesits IP address andhostname for theinterconnection.

5.2 Obtaining the IDL FileThis describes how to obtain the IDL file. The NMS interconnects to the M2000 by invokingthe IDL file. Before the interconnection, the IDL file of the M2000 needs to be provided to theNMS.

After the package of release documents is decompressed, the path of the IDL file is as followsENG\07.Northbound File\Corba interface\<Installed Corba version>\IDL.

CAUTIONThe northbound CORBA interface of the M2000 supports only the IDL file delivered with theversion. To use the other IDL files, you need to consult Huawei R&D engineers.

5.3 Checking the CORBA VersionBefore interconnecting the M2000 to the NMS, make sure that the northbound CORBA versionon the M2000 server is valid.

PrerequisiteLog in to the M2000 server.

Procedure

Step 1 Run the following commands to check the CORBA version.

# cd /opt/OMC


# displayCorbaNBI

The following message is displayed:

-------Current Version--------CorbaNBI NBIV×.×.×

If the version is V1.2.0, you can infer that this version is valid. If the version is not V1.2.0,change the version to V1.2.0 according to the iManagerM2000V200R010C00 Guide to Queryand Change Northbound CORBA Interface.




5-3

NOTE

The iManagerM2000V200R010C00 Guide to Query and Change Northbound CORBA Interface documentis decompressed to the doc\ENG\07.Northbound File\Corba interface directory. In addition, you candownload the document from the website:http://support.huawei.com.

----End

5.4 Obtaining the Reference of the Entry Point ObjectThis describes how to obtain the reference of the entry point object, that is, the1.ior file. Thereference of the entry point object is the prerequisite for the M2000 to invoke the northboundCORBA interface.

PrerequisiteLog in to the M2000 server as user root or omcuser.

ContextFor more information about the reference of the entry point object, see 2.1 Entry Point of theCORBA Interface.

Procedure

Step 1 Run the following commands to view the reference of the entry point object.

NOTE

The reference of the entry point object is dynamically generated by the northbound interface and is writtento the /opt/OMC/var/itf_n/EPIRP/1.ior file.

# cd /opt/OMC


# cd var/itf_n/EPIRP

# ls

Check whether the 1.ior file exists. If the file does not exist, see 6 Troubleshooting theNorthbound CORBA Interface.

Step 2 The NMS obtains the 1.ior file from the /opt/OMC/var/itf_n/EPIRP directory on the M2000server to the specified local path through the FTP. The NMS obtains the common functions,alarm functions, and configuration functions by invoking the 1.ior file of the M2000.

CAUTIONWhen the FTP mode is used, the 1.ior file must be transferred in ASCII mode.

----End




Issue 03 (2010-12-31)

5.5 Modifying the hosts File of the ServerThis section describes how to enable the NMS host and the M2000 server to communicate witheach other through their host names. After you modify the hosts files of the M2000 server andthe NMS host, they communicate with each other, subscribe to notifications, and receivenotifications by using their host names.

Procedure

Step 1 Log in to the M2000 server as user root or omcuser.

Step 2 Run the following command to open the /etc/hosts file on the M2000 server.

# vi /etc/hosts

Step 3 Add the IP address and hostname of the interconnected NMS server at the end of the file.

For example, if the IP address and hostname of the NMS server are 10.71.224.100 andnms_01, respectively, add the following information to the end of the /etc/hosts file:

10.71.224.100 nms_01

Press Esc and run the :wq! command. Save the file and exit the vi editor.

Step 4 Optional: When the NMS accesses the M2000 through the hostname of the M2000, the hostsfile of the NMS server needs to be modified.

Add the IP address and hostname of the M2000 server in the hosts file of the NMS.

l If the NMS server uses the Microsoft Win32 operating system, add the IP address andhostname of the M2000 server to the hosts file saved in the system32\drivers\etc\hostsdirectory through the text editor.

l If the NMS uses the UNIX operating system, log in to the system as user root. Then, add theIP address and hostname of the M2000 server to the /etc/hosts file through the vi editor.

# vi /etc/hosts

For example, if the IP address and hostname of the M2000 server are 10.71.224.103 andM2000_BAM03, respectively, add the following information to the end of the /etc/hosts file.

10.71.224.103 M2000_BAM03

Press Esc and run the :wq! command. Save the file and exit the vi editor.

----End

5.6 Using the CORBA InterfaceThis section describes how to use the northbound CORBA interface when the M2000 systemadopts different networking modes.

The M2000 system can adopt the following networking modes: single-server system, HAsystem, remote HA system, SLS system, and emergency system. For details about how to usethe northbound CORBA interface in different networking modes, see Table 5-2.




5-5

Table 5-2 Usage of the CORBA interface

M2000 System Type Usage Reference

Single-server system See this document.

HA system See this document.

Remote HA system See this document and M2000 SolutionDescription (Remote HA System) provided in theproduct documentation.

SLS system See this document.

Emergency system See this document and M2000 SemergencySystem User Guide provided in the productdocumentation.




Issue 03 (2010-12-31)

6 Troubleshooting the Northbound CORBAInterface

About This Chapter

The NMS interconnects with the M2000 through the northbound CORBA interface. If a faultoccurs when the NMS is obtaining the data, refer to relevant troubleshooting methods in thischapter.

6.1 Common Troubleshooting and Information Collection (CORBA Interface)If a fault occurs when the NMS attempts to obtain data through the northbound CORBAinterface, rectify the fault according to common troubleshooting methods. If it is not possible torectify the fault by using common troubleshooting methods, collect the fault information andcontact Huawei engineers for assistance.

6.2 Troubleshooting Failure to Obtain DataThis section describes how to troubleshoot the issue when data obtaining fails due to thefollowing causes: 1. Certain key attribute of the MO is null; 2. The DN is repeated; 3. The MOdata conversion fails; 4. The service is not started; 5. NEs are disconnected; 6. Free disk spaceis unavailable on the M2000 server.

6.3 Operations Required When the IP Address or Hostname of the M2000 Server ChangesThis describes the operations that should be performed for the M2000 and the NMS when theIP address or hostname of the M2000 server is changed.

M2000Northbound CORBA Interface Developer Guide 6 Troubleshooting the Northbound CORBA Interface


6-1

6.1 Common Troubleshooting and Information Collection(CORBA Interface)

If a fault occurs when the NMS attempts to obtain data through the northbound CORBAinterface, rectify the fault according to common troubleshooting methods. If it is not possible torectify the fault by using common troubleshooting methods, collect the fault information andcontact Huawei engineers for assistance.

TroubleshootingFor the methods of handling common faults that may occur during the process for obtainingrelevant data for the NMS, see Table 6-1.

Table 6-1 Troubleshooting

Common Fault Troubleshooting Method

Obtaining data failed. See 6.2 Troubleshooting Failure to Obtain Data.

The IP address of the M2000 serveris changed.

See 6.3 Operations Required When the IP Addressor Hostname of the M2000 Server Changes.

Information CollectionIf a fault not included in Table 6-1 occurs when the NMS is obtaining the data, you need tocollect relevant information for fault localization. Table 6-2 lists the information that needs tobe collected and the collection methods.

Table 6-2 Information to be collected

Related Information Description

Operation information Records the operations performed before a fault occursand the troubleshooting measures taken later.

Version information Indicates the information about the M2000 version, NEmediation version, and NE version.

IP address information Indicates the IP address of the M2000 server.

Log information You can obtain logs from the /opt/OMC/var/logsdirectory on the M2000 server. The .trace file forIRPService is iMAP.irp_agent.trace.

6.2 Troubleshooting Failure to Obtain DataThis section describes how to troubleshoot the issue when data obtaining fails due to thefollowing causes: 1. Certain key attribute of the MO is null; 2. The DN is repeated; 3. The MO

6 Troubleshooting the Northbound CORBA InterfaceM2000



Issue 03 (2010-12-31)

data conversion fails; 4. The service is not started; 5. NEs are disconnected; 6. Free disk spaceis unavailable on the M2000 server.

Problem Description

The NMS cannot obtain relevant data of the NE.

Troubleshooting

Obtaining data fails possibly due to the following causes:

l Certain key attribute of the MO is null.

l The DN is repeated.

l Conversion of the MO data fails.

l IRPService is not started.

l NEs are disconnected.

l Free disk space is unavailable on the M2000 server.

Handling the Fault of obtaining the configuration data failed

The NMS invokes the northbound CORBA interface to obtain the configuration data. Thenorthbound CORBA interface fails to obtain the configuration data. As a result, the NMS cannotobtain the required configuration data.

NOTE

This is a typical problem of the northbound CORBA interface.

Table 6-3 lists the possible causes of the problem and methods for locating the problem.

Table 6-3 Possible Causes and Problem Localization

Cause Description Localization

Certain key attribute of theMO is null.

In the northbound CORBAinterface, a DN is used touniquely identify an MO. Forexample,DC=www.huawei.com,SubNetwork=1,ManagedElement=37, andSignallingPoint=0. This DNindicates the MO object of asignaling point.SignallingPoint is the keyattribute of the MO. If thevalue of SignallingPoint isNULL, data of the MOcannot be obtained.

Log in to the M2000 server.Check theiMAP.irp_agent.trace fileunder the /opt/OMC/var/logs directory.If the file includes thefollowing information, youcan infer that the key attributesignallingPointId is null.T-ER:TagID 0001:08-02 11:20:58.118: (25382|59) Svr.GFace: attribute signallingPointId not exist!



6-3

Cause Description Localization

The DN is repeated. In the northbound CORBAinterface, a DN is used touniquely identify an MO. Ifmultiple MOs obtained sharea DN, the DN cannotuniquely identify an MO. Inthis case, the interfaceindicates the exception.

Log in to the M2000 server.Check theiMAP.irp_agent.trace fileunder the /opt/OMC/var/logs directory.If the file includes thefollowing information, youcan infer that The DN isrepeated.DuplicateRdnInfo , keyValue[220_0]

Conversion of the MO datafails.

The northbound CORBAinterface needs to convert thetype of data (such as int,string, long, unsigned int, andunsigned long) obtained fromthe M2000 to the specifiedtype of data (such as enum,string, sequence, struct, long,and their combinations).Conversion of the data typemay fail. In this case, thenorthbound CORBAinterface indicates theexception.

Log in to the M2000 server.Check theiMAP.irp_agent.trace fileunder the /opt/OMC/var/logs directory.If the file includes thefollowing information, youcan infer that an exceptionrelated to NetIdListTypeoccurs during the conversionof the data type.while convertor to any where type is NetIdListType,gv moi number is more than the metaInfo length!

Handling the Fault of Service UnactivationCheck whether IRPService is started. If the service is not started, run the relevant commands tostart it.

1. Log in to the M2000 server as user root or omcuser.2. Check the status of IRPService.

# cd /opt/OMC# . ./svc_profile.sh# svc_adm -cmd statusIf the following message is displayed, you can infer that the service is started.IRPService [running ]

3. If IRPService is not started, run the following command:# svc_adm -cmd startsvc IRPServiceCheck whether the 1.ior file exists after the service is started. If the file exists, you can inferthat the service process is successfully started. If the file does not exist, you can infer thatthe service process fails to be started.




Issue 03 (2010-12-31)

NOTE

For details on how to check whether the 1.ior file exists or not, see 5.4 Obtaining the Reference ofthe Entry Point Object.

Handling NE Disconnection Faults1. On the M2000 client, choose Topology > Main Topology. In the Main Topology window,

right-click the disconnected NE and then choose Reconnect NE.2. Verify the network and rectify the network fault.3. Rectify the fault on the NE mediation. To reinstall the NE mediation, see the Commissioning

Guide of the corresponding M2000 networking mode.

Handling Insufficient Disk Space Faults on the M2000 ServerClear the disk space on the M2000 server.

CAUTIONConfirm the files can be deleted before clearing the disk space. Deleting a file by mistake canresult in incorrect system operation. You are advised to clear the disk space by referring to theAdministrator Guide of the corresponding M2000 networking mode.

SolutionContact Huawei technical support.

6.3 Operations Required When the IP Address or Hostnameof the M2000 Server Changes

This describes the operations that should be performed for the M2000 and the NMS when theIP address or hostname of the M2000 server is changed.

QuestionThe NMS obtains common data, alarm data, and configuration data through obtaining the1.ior file. After the M2000 is interconnected to the NMS, if the IP address or hostname of theM2000 server needs to be changed, what operations should be performed for the M2000 and theNMS?

AnswerIf the IP address or hostname of the M2000 server needs to be changed, settings of the northboundCORBA interface need not be changed. In this case, the interface needs to instruct the NMS toobtain the new 1.ior file and to modify the hosts file.

After the IP address of the M2000 server is changed, you need to restart the northbound serviceprocess. After the northbound service process is restarted, a new 1.ior file is generated. The new1.ior file contains different information from the original 1.ior file. In this case, the northbound



6-5

interface needs to instruct the NMS to obtain the new 1.ior file. Otherwise, the NMS cannotinvoke the CORBA interface.

The 1.ior file is saved in the /opt/OMC/var/itf_n/EPIRP/ directory. For details on how to obtainthe 1.ior file, see 5.4 Obtaining the Reference of the Entry Point Object. For details on howto modify the hosts file of the NMS server, see 5.5 Modifying the hosts File of the Server.




Issue 03 (2010-12-31)

7 Appendix

About This Chapter

A collection of supplementary material.

7.1 Description of filterThis describes the supporting fields, syntax description, and conventions of the filter. The filtersin the get_alarm_list and get_alarm_count are also described.

7.2 Description of DN StringA DN string is used to represent each object.

7.3 Description of Alarm Location Detailed InformationAnalyze and locate alarms through Alarm Location Detailed Information.

M2000Northbound CORBA Interface Developer Guide 7 Appendix


7-1

7.1 Description of filterThis describes the supporting fields, syntax description, and conventions of the filter. The filtersin the get_alarm_list and get_alarm_count are also described.

7.1.1 Notification filter DescriptionThis describes the supporting field, syntax description, and conventions of the filter.

7.1.2 Description of filter in get_alarm_listThis describes the supporting fields, syntax description, and conventions of theget_alarm_list.

7.1.3 Description of filter in get_alarm_countThis describes the supporting field of the get_alarm_count.

7.1.1 Notification filter DescriptionThis describes the supporting field, syntax description, and conventions of the filter.

Fields Supporting filterl type_namel event_namel e

Description of Supported Syntax<ConstraintExpr>:= [ <Expr> ]<Expr> := <Expr> <ExprOp> <Expr>| "(" <Expr> ")"| "not" <Expr>| <SetExpr> <SetOp> <SetExpr>| <StrExpr> <StrOp> <StrExpr>| <NumExpr> <NumOp> <NumExpr>

<NumOp> := "==" | "!=" | "<" | "<=" | ">" | ">="<SetOp> := "==" | "!="<StrOp> := "==" | "!="<ExprOp>:="and"|"or"

<NumExpr> := <NumTerm>| <NumExpr> "+" <NumTerm>| <NumExpr> "-" <NumTerm>

<NumTerm> := <NumFactor>| <NumTerm> "*" <NumFactor>| <NumTerm> "/" <NumFactor>

<NumFactor> := <Identifier>| <Number>| "(" <NumExpr> ")"| "-" <NumFactor>

<StrExpr> := "$"<Identifier>| <String>| "(" <StrExpr> ")"

<SetExpr> := "$"<Identifier>| <Set>

7 AppendixM2000



Issue 03 (2010-12-31)

<Identifier> := <Letter> { <AlphaNum> }*

<Number> := <Integer>| <Float>| "-" <Number>

<Integer> := { <Digit> }+

<Float> := <Integer> [ "." [ <Integer> ] ]

<AlphaNum> := <Letter>| <Digit>| "_"

<String> := "'" { <Char> }* "'"

<Char> := <Letter>| <Digit>| <Other>

<Set> := "{" <Elements> "}"

<Elements> := [ <Element> { <Sp>+ <Element> }* ]

<Element> := <Number>| "$"<Identifier>| <String>

<Letter> := a | b | c | d | e | f | g | h | i | j | k| l | m | n | o | p | q | r | s | t | u | v| w | x | y | z | A | B | C | D | E | F | G| H | I | J | K | L | M | N | O | P | Q | R| S | T | U | V | W | X | Y | Z

<Digit> := 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9

<Other> := <Sp> | ~ | ! | @ | # | $ | % | ^ | & | * | (| ) | - | _ | = | + | [ | { | } | ] | ; | :| " | \ | | | < | . | > | / | ? | ,

<Sp> := " "

Conventionl <Identifier> supports the following fields:

– type_name– event_name– e

NOTE

These field names correspond to associated fields in the notification.

l The symbol $ must be added before <Identifier>.If $ is not added, filter can pass the syntax check. The notification, however, cannot bereceived.

Instance$type_name == 'x1'



7-3

7.1.2 Description of filter in get_alarm_listThis describes the supporting fields, syntax description, and conventions of theget_alarm_list.

Fields Supporting filterThe following fields in get_alarm_list support filter:l type_namel event_namel bl h

Syntax Descriptionl <SingleExpr> := "$"<Identifier><separator><ExprOp> <separator><Expr>l <OrExpr> ::= <SingleExpr><separator>"or"<separator><SingleExpr>l <AndExpr> : "("<OrExpr>")"<separator>"and"<separator>"("<OrExpr>")"l <separator>::= " "l <ExprOp>::= "==" | "<=" | ">="l <Expr>:= <StrExpr> | <NumExpr>l <StrExpr> := "'" { <Char> }* "'"l <NumExpr>:= <Integer>l <Identifier>::= "type_name" | "event_name" | "b" | "h"

ConventionThe conventions are as follows:

l <Identifier> supports the following fields:– type_name– event_name– b– h

l In <SingleExpr> preceding and following the keyword "or", <Identifier> must be the same.l In <SingleExpr> preceding and following the keyword "and", <Identifier> must be

different except that for the field name b.l <Integer> is data of a decimal integer.l The field names type_name, event_name, and h support only the operator "==".l The operators that the field name b supports are only ">=" and "<=".l The field name type_name supports the following values:

– x1– x3– x5

l The field name event_name supports the following values:

7 AppendixM2000



Issue 03 (2010-12-31)

– x1– x2– x3– x4– x5

l The field name h supports the following values:– 2– 3– 4– 5

l The field name b is used to filter alarm time. The time format for alarms is the one definedin time of TimeBase::UtcT.

Instancel $type_name == 'x1'l $type_name == 'x1' or $type_name == 'x2'l ($type_name == 'x1' or $type_name == 'x2') and ($event_name == 'x1') and ($b ==

133459954540000000)l ($b >= 133459954540000000) and ($b <= 133459955540000000)

7.1.3 Description of filter in get_alarm_countThis describes the supporting field of the get_alarm_count.

Supporting Field and Formatl The supporting field is e.l The supporting format is $e == 'DN'.

DN refers to the alarm to be filtered.

Instance$e == 'DC=www.huawei.com, SubNetwork=1 , ManagementNode=1'

7.2 Description of DN StringA DN string is used to represent each object.

Figure 7-1 shows the expression of a DN string.



7-5

Figure 7-1 DN string

Figure 7-1 shows the RDN of each object. Each object shown Figure 7-1 is numbered and theDN of each object can be obtained.

The DN of a specific object is follows:l DN for Object 5: subnetwork=subnetwork_A, managedElement= ME_1,

mscFunction=MSCF_1l DN for Object 9: subnetwork= subnetwork_A, managedElement=ME_2,

rncFunction=RNCF_1, utranCell=UCL_1l DN for Object 11: subnetwork=subnetwork_A, managedElement= ME_1,

mscFunction=MSCF_1, signallingPoint=SP_1, signallingLinkSetTP=SLSTP_2l DN for Object 12: subnetwork=subnetwork_A, managedElement=ME_1,

mscFunction=MSCF_1, signallingPoint=SP_1, signallingLinkSetTP=SLSTP_1,signallingLinkTP=SLTP_1

7.3 Description of Alarm Location Detailed InformationAnalyze and locate alarms through Alarm Location Detailed Information.

7 AppendixM2000



Issue 03 (2010-12-31)

The Alarm Location Detailed Information is shown in the field j in the notification.

The Alarm Location Detailed Information contains the following items:l NeTypel NeLocationl Vendorl neNamel Alarm namel Alarm location

The format for the Alarm Location Detailed Information is as follows:

NeType: NodeB| NeLocation: ShangHai | vendor: Huawei | neName: N91003| alarmName: RFUnit Maintenance Link Failure| alarmLocation: Cabinet No.=1, Subrack No.=4, Slot No.=0,Board type=WRFU| appendInfo:

where,

l NeType: indicates the type of the NE that has alarms.l NeLocation: indicates the location of the NE in which the alarm occurs.l vendor: indicates the manufacture of alarm devices.l neName: indicates the name of the NE where the alarm occurs.l alarmName: indicates the name of an alarm.l alarmLocation: indicates the location information about an alarm.

NOTE

l The fields NeType give the information about the type of the NE that has alarms.

l The fields NeLocation, Vendor, and neName give the information about the NE where the alarmoccurs. The information can be also traced on the OMC.

l The fields alarmName and alarmLocation are used to locate alarms.

Thus, the NMS can analyze and locate alarms through Alarm Location Detailed Information.



7-7

M2000 Northbound CORBA Interface Developer Guide

Documents

primary mouse

detailed categorizations

eventty pe

additional

network resource

free disk

remote ha

optomcvar