M2000 Northbound CORBA Interface Developer Guide

M2000 V200R010
Northbound CORBA Interface Developer Guide

Issue Date 03 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 written consent 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.
Notice
The purchased products, services and features are stipulated by the contract made between Huawei and the customer. All or part of the products, services and features described in this document may not be within the purchase 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 representations of any kind, either express or implied. The information in this document is subject to change without notice. Every effort has been made in the preparation of this document to ensure accuracy of the contents, but all statements, information, and recommendations in this document do not constitute the warranty of any kind, express or implied.
Huawei Technologies Co., Ltd.

Address: Huawei Industrial Base Bantian, Longgang Shenzhen 518129 People's Republic of China http://www.huawei.com support@huawei.com
Website: Email:
Issue 03 (2010-12-31)
Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.
M2000 Northbound CORBA Interface Developer Guide
About This Document
About This Document
Purpose
This document provides information about the M2000 northbound CORBA interface. The document also provides operation guidelines for connecting the network management system (NMS).
Related Versions
The following table lists product versions related to this document. Product Name M2000 Version V200R010
Intended Audience
This 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:
Issue 03 (2010-12-31)
iii
About This Document
Content 1.4 Technical Specifications of Northbound CORBA Interface
Modification Description 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 1.4 Technical Specifications of Northbound CORBA Interface Modification Description 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 and describes 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 management has 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
iv Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. Issue 03 (2010-12-31)
About This Document
Before interconnecting the NMS to the M2000, you need to make certain preparations. If you complete the preparations, you can infer that the northbound CORBA interface meets the conditions for the interconnection. 6 Troubleshooting the Northbound CORBA Interface The NMS interconnects with the M2000 through the northbound CORBA interface. If a fault occurs when the NMS is obtaining the data, refer to relevant troubleshooting methods in this chapter. 7 Appendix A collection of supplementary material.
Conventions
Symbol 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 not avoided, will result in death or serious injury. Indicates a hazard with a medium or low level of risk, which if not avoided, could result in minor or moderate injury. Indicates a potentially hazardous situation, which if not avoided, could result in equipment damage, data loss, performance degradation, or unexpected results. Indicates a tip that may help you solve a problem or save time. Provides additional information to emphasize or supplement important points of the main text.
General Conventions The general conventions that may be found in this document are defined as follows. Convention Times New Roman Boldface Italic Courier New Description Normal paragraphs are in Times New Roman. Names of files, directories, folders, and users are in boldface. For example, log in as user root. Book titles are in italics. Examples of information displayed on the screen are in Courier New.
Issue 03 (2010-12-31)
About This Document
Command Conventions The command conventions that may be found in this document are defined as follows. Convention Boldface Italic [] { x | y | ... } [ x | y | ... ] { x | y | ... }* Description The keywords of a command line are in boldface. Command arguments are in italics. Items (keywords or arguments) in brackets [ ] are optional. Optional items are grouped in braces and separated by vertical bars. One item is selected. Optional items are grouped in brackets and separated by vertical bars. One item is selected or no item is selected. Optional items are grouped in braces and separated by vertical bars. A minimum of one item or a maximum of all items can be selected. Optional items are grouped in brackets and separated by vertical bars. Several items or no item can be selected.
[ x | y | ... ]*
GUI Conventions The GUI conventions that may be found in this document are defined as follows. Convention Boldface > Description Buttons, menus, parameters, tabs, window, and dialog titles are 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 Key Key 1+Key 2 Key 1, Key 2 Description Press the key. For example, press Enter and press Tab. Press the keys concurrently. For example, pressing Ctrl+Alt +A means the three keys should be pressed concurrently. Press the keys in turn. For example, pressing Alt, A means the two keys should be pressed in turn.
Mouse Operations
vi Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. Issue 03 (2010-12-31)
About This Document
The mouse operations that may be found in this document are defined as follows. Action Click Double-click Drag Description Select and release the primary mouse button without moving the pointer. Press the primary mouse button twice continuously and quickly without moving the pointer. Press and hold the primary mouse button and move the pointer to a certain position.
Issue 03 (2010-12-31)
vii
Contents
Contents
About This Document...................................................................................................................iii 1 Introduction to Northbound CORBA Interface...................................................................1-1
1.1 Definition of Northbound Interface.................................................................................................................1-2 1.2 Definition of Northbound CORBA Interface..................................................................................................1-2 1.3 Function of Northbound CORBA Interface....................................................................................................1-5 1.3.1 Interface Management of the CORBA...................................................................................................1-5 1.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-1

2.1 Entry Point of the CORBA Interface.............................................................................................................. 2-2 2.1.1 Interface Description of the Entry Point of the CORBA Interface........................................................ 2-2 2.1.2 Notification Description of the Entry Point of the CORBA Interface...................................................2-9 2.2 Notification Management Function of the CORBA Interface......................................................................2-11 2.2.1 Introduction to Notification Management Function of the CORBA....................................................2-11 2.2.2 Interface Description of the CORBA Notification Management.........................................................2-12 2.3 Communication Surveillance Function of the CORBA Interface.................................................................2-23 2.3.1 Interface Description of the CORBA Communication Surveillance...................................................2-23 2.3.2 Heartbeat Notification of the CORBA Communication Surveillance.................................................2-29
3 Configuration Management Function of the CORBA Interface.......................................3-1

3.1 Getting to Know Configuration Management of the CORBA Interface.........................................................3-2 3.2 Common Configuration Management of the CORBA....................................................................................3-3 3.2.1 Interface Description of the Common Configuration Management of the CORBA..............................3-4 3.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-1

4.1 Introduction to the CORBA Alarm Management...........................................................................................4-2 4.2 Alarm Management of the CORBA................................................................................................................4-2 4.2.1 Interface Description of the CORBA Alarm Management....................................................................4-2 4.2.2 Notification Description of the CORBA Alarm Management.............................................................4-29 4.2.3 Mechanism for Forwarding Common Alarms.....................................................................................4-47
Issue 03 (2010-12-31)
ix
Contents
5 Preparations for Interconnection Commissioning of the Northbound CORBA Interface ...........................................................................................................................................................5-1

5.1 Negotiating the Interconnection Parameters of the Northbound CORBA Interface.......................................5-2 5.2 Obtaining the IDL File....................................................................................................................................5-3 5.3 Checking the CORBA Version.......................................................................................................................5-3 5.4 Obtaining the Reference of the Entry Point Object.........................................................................................5-4 5.5 Modifying the hosts File of the Server............................................................................................................5-5 5.6 Using the CORBA Interface...........................................................................................................................5-5
6 Troubleshooting the Northbound CORBA Interface.........................................................6-1

6.1 Common Troubleshooting and Information Collection (CORBA Interface).................................................6-2 6.2 Troubleshooting Failure to Obtain Data..........................................................................................................6-2 6.3 Operations Required When the IP Address or Hostname of the M2000 Server Changes..............................6-5
7 Appendix......................................................................................................................................7-1
7.1 Description of filter.........................................................................................................................................7-2 7.1.1 Notification filter Description................................................................................................................7-2 7.1.2 Description of filter in get_alarm_list....................................................................................................7-4 7.1.3 Description of filter in get_alarm_count................................................................................................7-5 7.2 Description of DN String................................................................................................................................7-5 7.3 Description of Alarm Location Detailed Information.....................................................................................7-6
Issue 03 (2010-12-31)
Figures
Figures
Figure 1-1 Location of the northbound interface................................................................................................. 1-2 Figure 1-2 Interface management functions.........................................................................................................1-5 Figure 1-3 Relation between managed object by the management domain.........................................................1-6 Figure 1-4 Getting object reference of other IRPs by entry points...................................................................... 1-7 Figure 1-5 Relations between IRPs......................................................................................................................1-7 Figure 3-1 Querying the event flow of MOs......................................................................................................3-22 Figure 4-1 Event flow of alarm information........................................................................................................4-8 Figure 7-1 DN string............................................................................................................................................ 7-6
Issue 03 (2010-12-31)
xi
Tables
Tables
Table 1-1 Interface protocol.................................................................................................................................1-3 Table 2-1 Values of getting EPIRP versions........................................................................................................2-2 Table 2-2 Exceptions of getting EPIRP version...................................................................................................2-3 Table 2-3 Parameters for getting EPIRP operation profile...................................................................................2-3 Table 2-4 Values of getting EPIRP operation profile...........................................................................................2-3 Table 2-5 Exceptions of getting EPIRP operation profile....................................................................................2-4 Table 2-6 Parameters for getting EPIRP notification profile...............................................................................2-4 Table 2-7 Values of getting EPIRP notification profile.......................................................................................2-4 Table 2-8 Exceptions of getting EPIRP notification profile.................................................................................2-5 Table 2-9 Parameters for getting IRP outline.......................................................................................................2-5 Table 2-10 Values of getting IRP outline.............................................................................................................2-6 Table 2-11 Exceptions of getting IRP outline......................................................................................................2-6 Table 2-12 Parameters for getting IRP reference.................................................................................................2-7 Table 2-13 Values of getting IRP reference.........................................................................................................2-8 Table 2-14 Exceptions of getting IRP reference...................................................................................................2-8 Table 2-15 Parameters for releasing IRP reference..............................................................................................2-8 Table 2-16 Values of releasing IRP reference......................................................................................................2-9 Table 2-17 Exceptions of releasing IRP reference...............................................................................................2-9 Table 2-18 Format of the notification of entry point register information change.............................................2-10 Table 2-19 Notification management function of the CORBA interface...........................................................2-12 Table 2-20 Values of getting notificationIRP versions......................................................................................2-13 Table 2-21 Exceptions of getting notificationIRP versions................................................................................2-13 Table 2-22 Parameters for getting notificationIRP operation profile.................................................................2-13 Table 2-23 Values of getting notificationIRP operation profile.........................................................................2-14 Table 2-24 Exceptions of getting notificationIRP operation profile..................................................................2-14 Table 2-25 Parameters for getting notificationIRP notification profile..............................................................2-14 Table 2-26 Values of getting notificationIRP notification profile.....................................................................2-15 Table 2-27 Exceptions of getting notificationIRP notification profile...............................................................2-15 Table 2-28 Parameters for getting notification categories..................................................................................2-15 Table 2-29 Values of getting notification categories..........................................................................................2-16 Table 2-30 Exceptions of getting notification categories...................................................................................2-16 Table 2-31 Parameters for subscribing specified notifications...........................................................................2-17 Table 2-32 Values of subscribing specified notifications..................................................................................2-18 Issue 03 (2010-12-31) Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. xiii
Tables
M2000 Northbound CORBA Interface Developer Guide Table 2-33 Exceptions of subscribing specified notifications............................................................................2-19 Table 2-34 Parameters for detaching notification subscription..........................................................................2-19 Table 2-35 Exceptions of detaching notification subscription...........................................................................2-20 Table 2-36 Parameters for changing subscription filter conditions....................................................................2-20 Table 2-37 Values of changing subscription filter conditions............................................................................2-20 Table 2-38 Exceptions of changing subscription filter conditions.....................................................................2-21 Table 2-39 Parameters for querying subscription IDs........................................................................................2-21 Table 2-40 Values of querying subscription IDs................................................................................................2-21 Table 2-41 Exceptions of querying subscription IDs.........................................................................................2-22 Table 2-42 Parameters for querying specified subscription parameters.............................................................2-22 Table 2-43 Values of querying specified subscription parameters.....................................................................2-23 Table 2-44 Exceptions of querying specified subscription parameters..............................................................2-23 Table 2-45 Values of getting CSIRP versions....................................................................................................2-24 Table 2-46 Exceptions of getting CSIRP versions.............................................................................................2-24 Table 2-47 Parameters for getting CSIRP operation profile.............................................................................. 2-24 Table 2-48 Values of getting CSIRP operation profile...................................................................................... 2-25 Table 2-49 Exceptions of getting CSIRP operation profile................................................................................2-25 Table 2-50 Parameters for getting CSIRP notification profile...........................................................................2-25 Table 2-51 Values of getting CSIRP notification profile...................................................................................2-26 Table 2-52 Exceptions of getting CSIRP notification profile............................................................................ 2-26 Table 2-53 Parameters for getting heartbeat period........................................................................................... 2-26 Table 2-54 Values of getting heartbeat period................................................................................................... 2-27 Table 2-55 Exceptions of getting heartbeat period.............................................................................................2-27 Table 2-56 Parameters for setting heartbeat period............................................................................................2-27 Table 2-57 Values of setting heartbeat period....................................................................................................2-28 Table 2-58 Exceptions of setting heartbeat period.............................................................................................2-28 Table 2-59 Parameters for triggering heartbeat notifications.............................................................................2-29 Table 2-60 Values of triggering heartbeat notifications.....................................................................................2-29 Table 2-61 Exceptions of triggering heartbeat notifications.............................................................................. 2-29 Table 2-62 Format of the heartbeat notification.................................................................................................2-30 Table 3-1 Values of getting KernelCMIRP versions............................................................................................3-4 Table 3-2 Exceptions of getting KernelCMIRP versions.....................................................................................3-4 Table 3-3 Parameters for getting KernelCMIRP operation profile......................................................................3-5 Table 3-4 Values of getting KernelCMIRP operation profile..............................................................................3-5 Table 3-5 Exceptions of getting KernelCMIRP operation profile.......................................................................3-5 Table 3-6 Parameters for getting KernelCMIRP notification profile...................................................................3-6 Table 3-7 Values of getting KernelCMIRP notification profile...........................................................................3-6 Table 3-8 Exceptions of getting KernelCMIRP notification profile....................................................................3-6 Table 3-9 Parameters for getting NRMIRP versions............................................................................................3-7 Table 3-10 Exceptions of getting NRMIRP versions...........................................................................................3-7 Table 3-11 Notification of notifyObjectCreation.................................................................................................3-8 Table 3-12 Notification of notifyObjectDeletion...............................................................................................3-10
xiv
Issue 03 (2010-12-31)
Tables
Table 3-13 Notification of notifyAttributeValueChange................................................................................... 3-12 Table 3-14 Notification of notifyCMSynchronizationRecommended...............................................................3-13 Table 3-15 Values of getting BasicCMIRP versions..........................................................................................3-15 Table 3-16 Exceptions of getting BasicCMIRP versions...................................................................................3-15 Table 3-17 Parameters for getting BasicCMIRP operation profile....................................................................3-16 Table 3-18 Values of getting BasicCMIRP operation profile............................................................................3-16 Table 3-19 Exceptions of getting BasicCMIRP operation profile.....................................................................3-16 Table 3-20 Parameters for getting BasicCMIRP notification profile.................................................................3-17 Table 3-21 Values of getting BasicCMIRP notification profile.........................................................................3-17 Table 3-22 Exceptions of getting BasicCMIRP notification profile..................................................................3-17 Table 3-23 Parameters for finding managed objects (I).....................................................................................3-18 Table 3-24 Values of finding managed objects (I).............................................................................................3-19 Table 3-25 Exceptions of finding managed objects (I)......................................................................................3-20 Table 3-26 Parameters for finding managed objects (II)....................................................................................3-20 Table 3-27 Values of finding managed objects (II)............................................................................................3-21 Table 3-28 Exceptions of finding managed objects (II).....................................................................................3-21 Table 3-29 Exceptions of finding managed objects (III)....................................................................................3-22 Table 3-30 Steps used for the event flow of querying MOs...............................................................................3-22 Table 4-1 Values of getting AlarmIRP versions..................................................................................................4-2 Table 4-2 Exceptions of getting AlarmIRP versions............................................................................................4-3 Table 4-3 Parameters for getting AlarmIRP operation profile.............................................................................4-3 Table 4-4 Values of getting AlarmIRP operation profile.....................................................................................4-3 Table 4-5 Exceptions of getting AlarmIRP operation profile..............................................................................4-4 Table 4-6 Parameters for getting AlarmIRP notification profile..........................................................................4-4 Table 4-7 Values of getting AlarmIRP notification profile..................................................................................4-4 Table 4-8 Exceptions of getting AlarmIRP notification profile...........................................................................4-5 Table 4-9 Parameters for getting alarm list (I).....................................................................................................4-5 Table 4-10 Values of getting alarm list (I)...........................................................................................................4-6 Table 4-11 Exceptions of getting alarm list (I).....................................................................................................4-6 Table 4-12 Parameters for getting alarm list (II)..................................................................................................4-7 Table 4-13 Values of getting alarm list (II)..........................................................................................................4-7 Table 4-14 Exceptions of getting alarm list (II)...................................................................................................4-7 Table 4-15 Exceptions of getting alarm list (III)..................................................................................................4-8 Table 4-16 Unacknowledged and uncleared alarms.............................................................................................4-9 Table 4-17 Acknowledged but uncleared alarms...............................................................................................4-12 Table 4-18 Unacknowledged but cleared alarms................................................................................................4-16 Table 4-19 Parameters for getting alarm count..................................................................................................4-20 Table 4-20 Values of getting alarm count..........................................................................................................4-20 Table 4-21 Exceptions of getting alarm count....................................................................................................4-20 Table 4-22 Parameters for acknowledging alarms.............................................................................................4-21 Table 4-23 Values of acknowledging alarms.....................................................................................................4-22 Table 4-24 Exceptions of acknowledging alarms...............................................................................................4-23 Issue 03 (2010-12-31) Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. xv
Tables
M2000 Northbound CORBA Interface Developer Guide Table 4-25 Parameters for unacknowledging alarms.........................................................................................4-23 Table 4-26 Values of unacknowledging alarms.................................................................................................4-24 Table 4-27 Exceptions of unacknowledging alarms...........................................................................................4-25 Table 4-28 Parameters for clearing alarms.........................................................................................................4-25 Table 4-29 Values of clearing alarms.................................................................................................................4-26 Table 4-30 Exceptions of clearing alarms..........................................................................................................4-26 Table 4-31 Parameters for adding comments to alarms.....................................................................................4-27 Table 4-32 Values of adding comments to alarms.............................................................................................4-28 Table 4-33 Exceptions of adding comments to alarms.......................................................................................4-28 Table 4-34 notifyPotentialFaultyAlarmList....................................................................................................... 4-29 Table 4-35 Notification of new alarms...............................................................................................................4-30 Table 4-36 Notification of the change of the alarm acknowledgement status................................................... 4-34 Table 4-37 Notification of alarm clearance........................................................................................................4-38 Table 4-38 Format of adding alarm comment....................................................................................................4-41 Table 4-39 Notification of alarm changes..........................................................................................................4-44 Table 4-40 Description of the configuration item..............................................................................................4-48 Table 5-1 Negotiated parameters..........................................................................................................................5-2 Table 5-2 Usage of the CORBA interface............................................................................................................5-6 Table 6-1 Troubleshooting...................................................................................................................................6-2 Table 6-2 Information to be collected..................................................................................................................6-2 Table 6-3 Possible Causes and Problem Localization .........................................................................................6-3
xvi
Issue 03 (2010-12-31)
1 Introduction to Northbound CORBA Interface
Introduction to Northbound CORBA Interface
About This Chapter

This introduction defines the Northbound CORBA interface provided by the M2000 and describes the functions of the Northbound CORBA interface. 1.1 Definition of Northbound Interface The northbound interface links the element management system (EMS) and the NMS. 1.2 Definition of Northbound CORBA Interface The Northbound interface is an interface between the Element Management System (EMS) and the Network Management System (NMS). The Northbound CORBA interface is one of the Northbound interfaces. The Northbound CORBA interface conforms to the CORBA protocol, FTP protocol, and 3GPP specifications. 1.3 Function of Northbound CORBA Interface This section describes the concepts related to CORBA interface management and integrated reference point (IRP). 1.4 Technical Specifications of Northbound CORBA Interface This section describes the technical specifications related to the northbound CORBA interface.
Issue 03 (2010-12-31)
1-1
1.1 Definition of Northbound Interface

The 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 Figure 1-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 Interface

The Northbound interface is an interface between the Element Management System (EMS) and the Network Management System (NMS). The Northbound CORBA interface is one of the Northbound interfaces. The Northbound CORBA interface conforms to the CORBA protocol, FTP protocol, and 3GPP specifications.
Interface Protocol
Table 1-1 describes the related information on interface protocol.
1-2
Issue 03 (2010-12-31)
Table 1-1 Interface protocol Protocol CORBA Details The design of network management interfaces adopts the CORBA technology for interface definition. The CORBA technology uses the IDL language to define the interface information model and also uses the IIOP communication protocol stack. The design of the network management interfaces complies with the following CORBA standards: l OMG ORB 2.3 standard l OMG Notification Service 1.0 standard l TAO 1.3 Version
NOTE l OMG represents the Object Management Group. l ORB represents the Object Request Broker.
FTP
The file transfer mode in the management interface uses the File Transfer Protocol (FTP) and the FTP protocol stack.
Issue 03 (2010-12-31)
1-3
Protocol 3GPP
Details 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 requirements l 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 Request Broker 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 Integration Reference Point (IRP): Requirements l 3GPP TS 32.602 v6.0.0 Telecommunication management; Configuration Management (CM); Basic CM Integration Reference Point (IRP): Information Service (IS) l 3GPP TS 32.603 v6.0.0 Telecommunication management; Configuration Management (CM); Basic CM Integration Reference Point (IRP): Common Object Request Broker Architecture (CORBA) Solution Set (SS) l 3GPP TS 32.611 v6.0.0 Telecommunication management; Configuration Management (CM); Bulk CM Integration Reference Point (IRP): Requirements l 3GPP TS 32.612 v6.0.0 Telecommunication management; Configuration Management (CM); Bulk CM Integration Reference Point (IRP): Information Service (IS) l 3GPP TS 32.615 v6.0.0 Telecommunication management; Configuration Management (CM); Bulk CM Integration Reference Point (IRP): eXtensible Markup Language (XML) file format definition l 3GPP TS 32.613 v6.0.0 Telecommunication management; Configuration Management (CM); Bulk CM Integration Reference Point (IRP): Common Object Request Broker Architecture (CORBA) Solution Set (SS)
1-4
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 Information Service (IS) l 3GPP TS 32.663 v6.0.0 Telecommunication management; Configuration Management (CM); Kernel CM Integration Reference Point (IRP): Common Object Request Broker Architecture (CORBA) Solution Set (SS)
1.3 Function of Northbound CORBA Interface

This section describes the concepts related to CORBA interface management and integrated reference point (IRP). 1.3.1 Interface Management of the CORBA Based on the common management, configuration management, and fault management, the ItfN consists of a cluster of management interfaces, such as common management interface, configuration management interface, and fault management interface. 1.3.2 About IRP The integrated reference point (IRP) is the abstract name of the interface function. The relatively independent interface function provided by the Itf-N interface can be considered as an IRP and then integrated in the network resource model as a managed object. For example, Entry Point IRP (EPIRP) and NotificationIRP.
1.3.1 Interface Management of the CORBA

Based on the common management, configuration management, and fault management, the ItfN 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
Issue 03 (2010-12-31)
1-5
1.3.2 About IRP

The integrated reference point (IRP) is the abstract name of the interface function. The relatively independent interface function provided by the Itf-N interface can be considered as an IRP and then integrated in the network resource model as a managed object. For example, Entry Point IRP (EPIRP) and NotificationIRP.
IRPAgent
IRPAgent is the agent of IRP. In the network resource model, IRPAgent is used as the subnode of 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 managed object 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 IRPs

Figure 1-4 shows the function of entry points that can get object reference of other IRPs.
1-6
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 CORBA Interface

This section describes the technical specifications related to the northbound CORBA interface. Specification Item Maximum number of NMS users on the CORBA interface Maximum number of notifications to be subscribed to on CORBA interfaces Maximum delay in reporting a northbound alarm (unit: second)
Issue 03 (2010-12-31) Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.
Value 5 8 15
1-7
1-8
Issue 03 (2010-12-31)
2 Common Management Function of the CORBA Interface
Common Management Function of the CORBA 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 Interface The entry point is the first object that IRPAgent accesses. The NMS can access the point at any time according to your requirement and get CORBA reference of managed object in a managed system specified by IRPAgent. AlarmIRP is one example of the managed object. 2.2 Notification Management Function of the CORBA Interface The notification Management function of the CORBA interface is used for event reporting to the NMS and the management of order information. Function description and format are detailed in the introduction to the CORBA notification management function. 2.3 Communication Surveillance Function of the CORBA Interface The communication surveillance interface function provides a mechanism to monitor the status of communication channels between the NMS and IRPAgent. In this situation, exceptions can be detected as soon as possible.
Issue 03 (2010-12-31)
2-1
2.1 Entry Point of the CORBA Interface

The entry point is the first object that IRPAgent accesses. The NMS can access the point at any time according to your requirement and get CORBA reference of managed object in a managed system 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, is released as a file. In addition, IOR is permanent, that is, the IP address of the server where IRPAgent is located is fixed and IOR is permanently effective. Object references of other IRPs are variable. When IRPAgent is rebooted, these object references must be obtained again. 2.1.1 Interface Description of the Entry Point of the CORBA Interface This describes the functions of CORBA entry point. These functions consist of getting EPIRP versions, getting EPIRP operation profile, getting EPIRP notification profile, getting IRP outline, getting IRP reference, and releasing IRP reference. 2.1.2 Notification Description of the Entry Point of the CORBA Interface When changes happen to the IRP information (for the EPIRP instance itself or other EPIRP instances that the EPIRP instance knows) saved in the entry point, send a notification of entry point register information change to the NMS according to requirement.
2.1.1 Interface Description of the Entry Point of the CORBA Interface

This describes the functions of CORBA entry point. These functions consist of getting EPIRP versions, getting EPIRP operation profile, getting EPIRP notification profile, getting IRP outline, getting IRP reference, and releasing IRP reference.
Getting EPIRP Versions

l l Function description The NMS invokes get_EP_IRP_versions to get EPIRP versions. Function format
ManagedGenericIRPConstDefs::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 VersionNumberSet Description 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. Support (Y/N) Y
2-2
Issue 03 (2010-12-31)
Table 2-2 Exceptions of getting EPIRP version Exception GetEPIRPVersions Description Indicates the exceptions caused by unknown reasons. Support (Y/N) Y
Getting EP IRP Operation Profile

l Function description NMS invokes get_EP_IRP_operations_profile to get the profile of operations supported by EPIRP. l Function format
ManagedGenericIRPConstDefs::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 iRPVersion In/Out In Description Indicates the version ID of EPIRP in the EPIRP profile obtained by the NMS. The version ID should be consistent with the version ID returned by Getting EPIRP Versions. Support (Y/N) Y
Table 2-4 Values of getting EPIRP operation profile Returned Value MethodList Description Indicates the information list of operations the EPIRP supports. The information list contains the following items: l Names of operations l Parameter lists Support (Y/N) Y
Issue 03 (2010-12-31)
2-3
Table 2-5 Exceptions of getting EPIRP operation profile Exception InvalidParameter OperationNotSupported GetEPIRPOperationsProfile Description Indicates that the given iRPVersion is invalid or null. Indicates that this operation is not supported. Indicates the exceptions caused by unknown reasons. Support (Y/N) Y N Y
Getting EP IRP Notification Profile

l Function description The NMS invokes get_EP_IRP_notification_profile to get the profile of the notification supported by EPIRP. l Function format
ManagedGenericIRPConstDefs::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 Parameter iRPVersion In/Out In Description Indicates the version information about EPIRP in the EPIRP outline gotten by the NMS. The version ID should be consistent with the version ID returned by Getting EPIRP Versions. Support (Y/N) Y
Table 2-7 Values of getting EPIRP notification profile Returned Value MethodList Description Indicates the profile list of notifications that an EPIRP supports. The profile list contains the following items: l Names of notifications supported by the EPIRP l Names of fields in the notification (including the names of filterable_data and remainder_of_body fields)
2-4 Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. Issue 03 (2010-12-31)
Support (Y/N) Y
Table 2-8 Exceptions of getting EPIRP notification profile Exception InvalidIRPVersion OperationNotSupported GetEPIRPNotificationProfile Description Indicates that the given iRPVersion is invalid or null. Indicates that this operation is not supported. Indicates the exceptions caused by unknown reasons. Support (Y/N) Y N Y
Getting IRP Outline

l Function description The NMS invokes get_IRP_outline to get the outline of the management domain Managed Object. l Function format
EPIRPConstDefs::ResultType get_IRP_outline ( in ManagedGenericIRPConstDefs::VersionNumber iRPVersion, out EPIRPConstDefs::SupportedIRPListType supportedIRPList ) raises (GetIRPOutline,InvalidIRPVersion);
Table 2-9 Parameters for getting IRP outline Parameter iRPVersion In/Out In Description Indicates the version information about EPIRP in the EPIRP outline gotten by the NMS. The parameter has the following two situations: l If this parameter is null, the Agent returns the outline of all EPIRPs, including this EPIRP instance itself. l If this parameter is not null, the entered value is the complete IRP information. If you plan to query the general information about the CS IRP, the input parameter is CS IRP V1.2.0. Support (Y/N) Y
Issue 03 (2010-12-31)
2-5
Parameter supportedIRPList
In/Out Out
Description Indicates the returned list of the IRP profile according to input parameter conditions. The list contains all IRP information in systemDn and IRPAgent. The IRP information contains: l irpId l irpVersion l irpClassName l irpManagementScope The value of the parameter is of multinested structure.
Support (Y/N) Y
Table 2-10 Values of getting IRP outline Returned Value OK FAILURE Description Indicates that the operation succeeds. Indicates that the operation fails. Support (Y/N) Y Y
Table 2-11 Exceptions of getting IRP outline Exception InvalidIRPVersion GetIRPOutline Description Indicates that the given IRPVersion is invalid. Indicates the exceptions caused by unknown reasons. Support (Y/N) Y Y
Getting IRP Reference

l Function description The NMS invokes get_IRP_reference to get the CORBA object reference specified in IRPAgent or the object reference of EPIRP. l Function format
EPIRPConstDefs::ResultType get_IRP_reference ( in EPIRPConstDefs::ManagerIdentifierType managerIdentifier, in EPIRPConstDefs::DNType systemDn, in EPIRPConstDefs::IRPIdType irpId, in EPIRPConstDefs::IRPClassNameType irpClassName, out string iRPReference
2-6
Issue 03 (2010-12-31)
) raises ( GetIRPReference, ManagedGenericIRPSystem::InvalidParameter);
Table 2-12 Parameters for getting IRP reference Parameter managerIdentifier In/Out In Description Indicates a character string identifying Manager (NMS). The character string is given by the NMS and is unique. You can provide different values for managerIdentifier to invoke this operation. If the number of different values reaches five, an exception occurs. Huawei recommends that you use a unique value for the parameter in an NMS. systemDN In Indicates the DN value of IRPAgent obtained from the Agent system. The value of this parameter should be consistent with the value of systemDn returned by Getting IRP Outline. irpId In Indicates irpId of IRP obtained by the NMS. The value of this parameter should be consistent with the value of irpId returned by Getting IRP Outline. irpClassName In Indicates the class name of IRP obtained by the NMS. The value of this parameter should be consistent with the class name of IRP returned by Getting IRP Outline. iRPReference Out Indicates the CORBA object reference of IRP needed by the NMS. When you use a different managerIdentifier to get the same object of IRP, the reference is different. Y Y Y Y Support (Y/N) Y
Issue 03 (2010-12-31)
2-7
Table 2-13 Values of getting IRP reference Returned Value OK Failure Description Indicates that the operation succeeds. Indicates that the operation fails. Support (Y/N) Y Y
Table 2-14 Exceptions of getting IRP reference Exception InvalidParameter Description Indicates that the following parameters or their combination are invalid: l systemDN l irpId l irpClassName l managerIdentifier GetIRPReference Indicates the exceptions caused by unknown reasons. Y Support (Y/N) Y
Releasing IRP Reference

l Function description The NMS invokes release_IRP_reference to release the reference of a specified IRP that is not in use. l Function format
EPIRPConstDefs::ResultType release_IRP_reference( in EPIRPConstDefs::ManagerIdentifierType managerIdentifier, in string iRPReference ) raises ( ReleaseIRPReference, UnknownIRPReference);
Table 2-15 Parameters for releasing IRP reference Parameter managerIdentifier In/Out In Description Indicates a character string identifying the NMS. The parameter should be consistent with managerIdentifier specified in Getting IRP Reference. Support (Y/N) Y
2-8
Issue 03 (2010-12-31)
Parameter iRPReference
In/Out In
Description Indicates the CORBA object reference, that is, IOR of IRP to be released by the NMS. The parameter should be consistent with iRPReference returned by Getting IRP Reference through relevant managerIdentifier.
Support (Y/N) Y
Table 2-16 Values of releasing IRP reference Returned Value OK Failure Description Indicates that the operation succeeds. Indicates that the operation fails. Support (Y/N) Y Y
Table 2-17 Exceptions of releasing IRP reference Exception UnknownIRPReference Description Indicates that the specified iRPReference is invalid or the specified managerIdentifier does not match iRPReference. The reason is that iRPReference is not obtained by managerIdentifier through the operation Getting IRP Reference. ReleaseIRPReference Indicates the exceptions caused by unknown reasons. Y Support (Y/N) Y
2.1.2 Notification Description of the Entry Point of the CORBA Interface

When changes happen to the IRP information (for the EPIRP instance itself or other EPIRP instances that the EPIRP instance knows) saved in the entry point, send a notification of entry point register information change to the NMS according to requirement.
Triggering Conditions
l l
Issue 03 (2010-12-31)
When the newly obtained object reference is successful through the Getting IRP Reference interface. When the object is released successfully through the Releasing IRP Reference interface.
Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. 2-9
When the IRPAgent system starts or stops.
Notification Format
Table 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 domain_name Type string Domain header.fixed_h eader.event_ty pe header.fixed_h eader.event_ty pe Description Indicates the name of a managed domain. This parameter shows the version number of the associated IRP information model. Indicates the type of the reported notification. The value of this parameter is defined by EPIRPNotifications::notifyIRPInfo Changes::ET_IRPINFO_CHANGE S. Indicates the name of an event. (This parameter is null.) Indicates the instances of MO that sends the notification, that is, the IRP object instance. Indicates the notification identifier and is used to exclusively identify a notification. Indicates the time when an event occurs. Indicates the identifier of the IRPAgent that generates notifications. Indicates the DN value of the IRP when the information about the EP changes.
type_name
string
event_name e
string string
header.fixed_h eader filterable_data
long
remainder_of_ body filterable_data filterable_data
b c
TimeBase:: UtcT string
IRP_DN
string
remainder_of_ body
2-10
Issue 03 (2010-12-31)
Attribute Name CHANGE_MODE
Type enum ChangeMod eType {REGISTE R, DEREGIST ER, MODIFY};
Domain remainder_of_ body
Description Indicates that the change modes of the EPIRP information. The change modes are as follows: l REGISTER A new object reference value is obtained. l DEREGISTER The IRPAgent system stops or releases an object reference. l MODIFY The IRPAgent system starts the object reference value.
ADDITIONAL_T EXT
string
remainder_of_ body
Indicates the additional description text added to the notification.
NOTE
CosNotification::PropertySeq is the value type of remainder_of_body.
2.2 Notification Management Function of the CORBA Interface

The notification Management function of the CORBA interface is used for event reporting to the NMS and the management of order information. Function description and format are detailed in the introduction to the CORBA notification management function. 2.2.1 Introduction to Notification Management Function of the CORBA The notification management function of the CORBA interface is used for event reporting to the NMS, order management, and order limitation. 2.2.2 Interface Description of the CORBA Notification Management This describes the CORBA notification management function that involves getting notificationIRP versions, getting notificationIRP operation profile, getting notificationIRP notification profile, getting notification categories, subscribing specified notifications, detaching notification subscription, changing subscription filter conditions, querying subscription IDs, and querying parameters of specified subscription.
2.2.1 Introduction to Notification Management Function of the CORBA

The notification management function of the CORBA interface is used for event reporting to the NMS, order management, and order limitation. Table 2-19 describes the notification management function of the CORBA interface.
Issue 03 (2010-12-31) Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. 2-11
Table 2-19 Notification management function of the CORBA interface Scenario Enabling IRPAgent to report events to the NMS Description The NMS invokes the notification management interface to enable the NMS to receive the notification of CosNotifyComm::SequencePushConsumer that is defined by the CORBA specification IOR and the notification of integrating the CORBA specification. The notification is sent to the NMS through the notification channel. 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 subscribed CosNotifyComm::SequencePushConsumer object is valid. IRPAgen can determine the validity by using the method of _non_existent provided by CORBA. If an object is invalid, IRPAgent automatically cancels the subscription of the object. If the CosNotifyComm::SequencePushConsumer object is invalid and need be subscribed again, the NMS is recommended to actively invoke an interface to cancel the subscription before the CosNotifyComm::SequencePushConsumer is invalid. Subscribing a maximum of eight notifications If the actual subscription number exceeds the maximum subscription number, an exception occurs. The NMS is recommended to actively cancel unneeded subscription.
Managing subscribed notifications
2.2.2 Interface Description of the CORBA Notification Management

This describes the CORBA notification management function that involves getting notificationIRP versions, getting notificationIRP operation profile, getting notificationIRP notification profile, getting notification categories, subscribing specified notifications, detaching notification subscription, changing subscription filter conditions, querying subscription IDs, and querying parameters of specified subscription.
Getting Notification IRP Versions

l Function description The NMS invokes get_notification_IRP_versions to get the NotificationIRP version information. l Function format
ManagedGenericIRPConstDefs::VersionNumberSet get_notification_IRP_versions () raises (GetNotificationIRPVersions);
Obtain the parameters irrelevant to the NotificationIRP version.

Table 2-20 Values of getting notificationIRP versions Returned Value VersionNumberSet Description Indicates a set of versions that the NotificationIRP supports. The value of VersionNumberSet is a set of strings. Huawei supports only one of the NotificationIRP versions. Support (Y/N) Y
Table 2-21 Exceptions of getting notificationIRP versions Exception GetNotificationIRPVersions Description Indicates the exceptions caused by unknown reasons. Support (Y/N) Y
Getting Notification IRP Operation Profile

l Function description The NMS invokes get_notification_IRP_operations_profile to get the profile of operations supported by a specified version of NotificationIRP. l Function format
ManagedGenericIRPConstDefs::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 notification_irp_version In/Out In Description Indicates the NotificationIRP version ID in the NotificationIRP profile obtained by the NMS. The version ID should be consistent with the version ID returned by Getting Notification IRP Versions. Suppor t (Y/N) Y
Issue 03 (2010-12-31)
2-13
Table 2-23 Values of getting notificationIRP operation profile Returned Value MethodList Description Indicates the information list of operations the NotificationIRP supports. The information list contains the following items: l Names of operations l Parameter lists Support (Y/N) Y
Table 2-24 Exceptions of getting notificationIRP operation profile Exception InvalidParameter Description Indicates that the given notification_irp_version is invalid or null. Indicates that this operation is not supported. Indicates the exceptions caused by unknown reasons. Support (Y/N) Y
OperationNotSupported GetEPIRPOperationsProfile
N Y
Getting Notification IRP Notification Profile

l Function description The NMS invokes get_notification_IRP_notification_profile to get the profile of the notification supported by NotificationIRP. l Function format
ManagedGenericIRPConstDefs::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 Parameter notification_irp_version In/Out In Description Indicates the NotificationIRP version ID in the NotificationIRP profile obtained by the NMS. The version ID should be consistent with the version ID returned by Getting Notification IRP Versions.
Support (Y/N) Y
Table 2-26 Values of getting notificationIRP notification profile Returned Value Description Suppo rt (Y/ N) Y
MethodList
Indicates the profile list of notifications that an NotificationIRP supports. The profile list contains the following items: l Names of notifications supported by the NotificationIRP l Names of fields in the notification (including the names of filterable_data and remainder_of_body fields)
NOTE
Notifications are not defined in the NotificationIRP.
Table 2-27 Exceptions of getting notificationIRP notification profile Exception InvalidIRPVersion OperationNotSupported GetNotificationIRPNotificationProfile Description Indicates that the given notification_irp_version is invalid or null. Indicates that this operation is not supported. Indicates the exceptions caused by unknown reasons. Support (Y/N) Y N Y
Getting Notification Categories

l Function description The NMS invokes get_notification_categories to query the notification categories supported by IRPAgent and the mapping notification types. Function format
NotificationIRPConstDefs::NotificationCategorySet get_notification_categories ( out NotificationIRPConstDefs::NotificationTypesSet notification_type_list ) raises ( GetNotificationCategories, ManagedGenericIRPSystem::OperationNotSupported);
Table 2-28 Parameters for getting notification categories Parameter notification_type_list In/Out Out Description Indicates the list of notification types that map to notification categories. Support (Y/N) Y
Issue 03 (2010-12-31)
2-15
Table 2-29 Values of getting notification categories Returned Value NotificationCategorySet Description Indicates the set of notification categories supported by IRPAgent. Each element in this set specifies a notification category. Suppor t (Y/N) Y
Table 2-30 Exceptions of getting notification categories Exception Description Suppo rt (Y/ N) N Y
OperationNotSupported GetNotificationCategories
Indicates that this operation is not supported. Indicates the exceptions caused by unknown reasons.
Subscribing Specified Notifications

l l Function description The NMS invokes attach_push to subscribe notifications of specified categories. 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);
2-16
Issue 03 (2010-12-31)
Table 2-31 Parameters for subscribing specified notifications Parameter manager_reference In/Out In Description Identifies the event receiver at the NMS side. For IOR, the parameter value should be CosNotifyComm::SequencePushConsumer. The IRPAgent uses the event channel to transfer the NMS an event information, that is, manager_reference invokes the push operation. When the subscribed number exceeds eight, no new subscriptions are received. time_tick In Indicates a timer. After this timer expires, the subscribed notification is detached to release the notification channel resources. Normally, the NMS invokes Querying Parameters of Specified Subscription periodically to refresh the timer to ensure that the relevant channel is not released. The unit for this parameter is minute. Set the value of the timer according to the 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 the entered value. l If you enter null or 0, the timer never expires. Y Suppor t (Y/N) Y
Issue 03 (2010-12-31)
2-17
Parameter notification_categories
In/Out In
Description Defines the set of notifications to be filtered. Each element in the set should be an element of the notification category returned by Getting Notification Categories. If the set is null, infer that all the notification categories supported by IRPAgent are subscribed. For the repeated subscription of manager_reference, there must be a notification class that is not subscribed in the parameter-defined set. If all the notification classes are subscribed in the set, an AlreadySubscribed exception is displayed. l If notification_categories is null, infer that all the notification classes unsubscribed by manager_reference need be subscribed. l If all the notification classes are subscribed, an AlreadySubscribed exception is displayed.
Suppor t (Y/N) Y
filter
In
Defines the filter condition for the notification subscription. The parameter is set based on all notification categories defined by notification_categories. If this parameter is valued null, infer that conditions defined by notification_categories have no extra restrictions. For details of the syntax, refer to 7.1.1 Notification filter Description.
Table 2-32 Values of subscribing specified notifications Returned Value SubscriptionId Description Identifies the notification subscription. The NMS can uniquely identify a subscription record by using this value. Support (Y/ N) Y
2-18
Issue 03 (2010-12-31)
Table 2-33 Exceptions of subscribing specified notifications Exception AlreadySubscribed Description Indicates that the notifications defined by notification_categories are already subscribed by the manager_reference receiver. Indicates that this parameter is not supported. Indicates that this parameter is incorrect or that its format is incorrect. Indicates that this parameter is incorrect or that the parameter notification_categories is invalid. Indicates the exceptions caused by unknown reasons. Support (Y/ N) Y
ParameterNotSupported InvalidParameter AtLeastOneNotificationCategoryNotSupported Attach
N Y Y
Detaching Notification Subscription

l l Function description The NMS invokes detach to detach the notification subscription. 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 Parameter manager_reference In/Out In Description Indicates the identifier of the event receiver at the home NMS that is going to detach the notification subscription. The parameter should be consistent with manager_reference specified in Subscribing Specified Notifications. Indicates the unique identifier of the notification subscription. If this parameter is null, infer that all notifications earlier subscribed by manager_reference are detached.
Support (Y/N) Y
subscription_id
In
Retract the subscription of the parameters having no values. Table 2-35 Exceptions of detaching notification subscription Exception InvalidParameter Description Indicates that the specified parameter manager_reference, subscription_id or their combination is invalid. Alternatively, the notification subscription identified by subscription_id is not subscribed by manager_reference. Indicates that this parameter is not supported. Indicates the exceptions caused by unknown reasons. Support (Y/N) Y
ParameterNotSupported DetachException
N Y
Changing Subscription Filter Conditions

l l Function description The NMS invokes change_subscription_filter to change the subscription filter conditions. 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 Parameter subscription_id filter In/Out In In Description Indicates the unique identifier of the notification subscription. Indicates the subscription of filter conditions. Suppor t (Y/N) Y 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 Returned Value 2-20
Description -
Suppor t (Y/N) Issue 03 (2010-12-31)
Table 2-38 Exceptions of changing subscription filter conditions Exception Description Suppo rt (Y/ N) Y N Y
InvalidParameter OperationNotSupported ChangeSubscriptionFilter
Indicates that the subscription_id or filter is invalid or null. Indicates that this operation is not supported. Indicates the exceptions caused by unknown reasons.
Querying Subscription IDs

l Function description The NMS invokes get_subscription_ids to query all subscription IDs related to a specified manager_reference. l Function format
NotificationIRPConstDefs::SubscriptionIdSet get_subscription_ids ( in string manager_reference ) raises ( GetSubscriptionIds, ManagedGenericIRPSystem::OperationNotSupported, ManagedGenericIRPSystem::InvalidParameter);
Table 2-39 Parameters for querying subscription IDs Parameter manager_reference In/Out In Description Indicates the identifier of the event receiver to be queried at the NMS side. The parameter should be consistent with the specified manager_reference given by Subscribing Specified Notifications. Support (Y/N) Y
Table 2-40 Values of querying subscription IDs Returned Value SubscriptionIdSet Description Indicates the set of all subscription IDs related to manager_reference. If a specified manager_reference is valid but not subscribed, the returned list is null.
Support (Y/N) Y
Table 2-41 Exceptions of querying subscription IDs Exception InvalidParameter OperationNotSupported GetSubscriptionIds Description Indicates that the manager_reference is invalid. Indicates that this operation is not supported. Indicates the exceptions caused by unknown reasons. Support (Y/N) Y N Y
Querying Parameters of Specified Subscription

l Function description The NMS invokes get_subscription_status to query parameters of a specified subscription, including subscription parameters and subscription statuses. l Function format
NotificationIRPConstDefs::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 Parameter subscription_id time_tick filter_in_effect subscription_state In/Out In Out Out Out Description Indicates the unique identifier of the notification subscription. Indicates the value for invoking attach_push. Indicates the filter condition used by the current subscription. Indicates the status of the current subscription, including: l Active l Suspended Because the Suspended status is not supported, only the Active status exists. Support (Y/N) Y Y Y Y
2-22
Issue 03 (2010-12-31)
Table 2-43 Values of querying specified subscription parameters Returned Value NotificationCategorySet Description Indicates the set of notification categories supported by the current subscription. Support (Y/N) Y
Table 2-44 Exceptions of querying specified subscription parameters Exception InvalidParameter OperationNotSupported GetSubscriptionStatus Description Indicates that the subscription_id is invalid. Indicates that the operation is not supported. Indicates the exceptions caused by unknown reasons. Support (Y/N) Y N Y
2.3 Communication Surveillance Function of the CORBA Interface

The communication surveillance interface function provides a mechanism to monitor the status of communication channels between the NMS and IRPAgent. In this situation, exceptions can be detected as soon as possible. The NMS monitors communication channels using the following two ways: l l By setting a heartbeat interval, the NMS can receive heartbeat notifications to monitor the status of communication channels between the NMS and IRPAgent. 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 Surveillance The CORBA communication surveillance involves getting CSIRP versions, getting CSIRP operation profile, getting CSIRP notification profile, getting heartbeat period, setting heartbeat period, and triggering heartbeat notifications. 2.3.2 Heartbeat Notification of the CORBA Communication Surveillance When the heartbeat period is up, IRPAgent sends a heartbeat notification accordingly to the NMS.
2.3.1 Interface Description of the CORBA Communication Surveillance

The CORBA communication surveillance involves getting CSIRP versions, getting CSIRP operation profile, getting CSIRP notification profile, getting heartbeat period, setting heartbeat period, and triggering heartbeat notifications.
Getting CSIRP Versions

l l Function description The NMS invokes get_CS_IRP_versions to get the CSIRP version information. 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 Returned Value VersionNumberSet Description Support (Y/N)
Indicates a set of versions that the Y EPIRP supports. The value of VersionNumberSet is a set of strings. Huawei supports only one of the EPIRP versions.
Table 2-46 Exceptions of getting CSIRP versions Exception GetCSIRPVersions Description Indicates the exceptions caused by unknown reasons. Support (Y/N) Y
Getting CSIRP Operation Profile

l Function description The NMS invokes get_CS_IRP_operations_profile to get the profile of operations supported by a specified version of CSIRP. l Function format
ManagedGenericIRPConstDefs::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 Parameter iRPVersion In/Out In Description Indicates the version ID of CSIRP in the profile obtained by the NMS. The version ID should be consistent with the version ID returned by Getting CSIRP Versions. Support (Y/N) Y
2-24
Issue 03 (2010-12-31)
Table 2-48 Values of getting CSIRP operation profile Returned Value MethodList Description Indicates the information list of operations the CSIRP supports. The information list contains the following items: l Names of operations l Parameter lists Support (Y/N) Y
Table 2-49 Exceptions of getting CSIRP operation profile Exception InvalidParameter OperationNotSupported GetCSIRPOperationsProfile Description Indicates that iRPVersion is invalid or null. Indicates that this operation is not supported. Indicates the exceptions caused by unknown reasons. Support (Y/N) Y N Y
Getting CSIRP Notification Profile

l Function description The NMS invokes get_CS_IRP_notification_profile to get the profile of notifications supported by a specified version of CSIRP. l Function format
ManagedGenericIRPConstDefs::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 Parameter iRPVersion In/Out In Description Indicates the version ID of CSIRP in the profile obtained by the NMS. The version ID should be consistent with the version ID returned by Getting CSIRP Versions. Support (Y/N) Y
Issue 03 (2010-12-31)
2-25
Table 2-51 Values of getting CSIRP notification profile Returned Value MethodList Description Indicates the profile list of notifications that a CSIRP supports. The profile list contains the following items: l Names of notifications supported by the CSIRP l Names of fields in the notification (including the names of filterable_data and remainder_of_body fields) Support (Y/N) Y
Table 2-52 Exceptions of getting CSIRP notification profile Exception InvalidIRPVersion OperationNotSupported GetCSIRPNotificationProfile Description Indicates that the iRPVersion is invalid or null. Indicates that this operation is not supported. Indicates the exceptions caused by unknown reasons. Support (Y/N) Y N Y
Getting Heartbeat Period

l Function description The NMS invokes get_heartbeat_period to get the interval for sending heartbeat notifications, that is, the heartbeat period. l Function format
CSIRPConstDefs::ResultType get_heartbeat_period( out CSIRPConstDefs::HeartbeatPeriodType heartbeatPeriod ) raises (GetHeartbeatPeriod);
Table 2-53 Parameters for getting heartbeat period Parameter heartbeatPeriod In/Out Out Description Indicates the interval for which IRPAgent reports heartbeat notifications periodically to the NMS (unit: minute). Value range: 5 to 60 The default value is 5. The value 0 is also valid and 0 means that the interval for sending heartbeat notifications is not set.
Support (Y/N) Y
Table 2-54 Values of getting heartbeat period Returned Value Success Failure Description Indicates that this operation succeeds. Indicates that this operation fails. Support (Y/N) Y Y
Table 2-55 Exceptions of getting heartbeat period Exception GetHeartbeatPeriod Description Indicates the exceptions caused by unknown reasons. Support (Y/N) Y
Setting Heartbeat Period

l Function description The NMS invokes set_heartbeat_period to set the interval for Agent to send heartbeat notifications. Whenever the heartbeatPeriod attribute changes, the Agent sends a heartbeat notification with the new heartbeat period immediately to all the NMS that have subscribed this notification. If the changed heartbeat period is the same in value as the old one, failure is returned for this operation. If the heartbeat period is changed to 0, the Agent sends a notification informing about the change and sends no more heartbeat notifications later unless this value is changed to another different value. l Function format
CSIRPConstDefs::ResultType set_heartbeat_period( in CSIRPConstDefs::HeartbeatPeriodType heartbeatPeriod ) raises ( SetHeartbeatPeriod, ConflictingHeartbeatPeriod, InvalidHeartbeatPeriod, ManagedGenericIRPSystem::ValueNotSupported, ManagedGenericIRPSystem::OperationNotSupported);
Table 2-56 Parameters for setting heartbeat period Parameter heartbeatPeriod In/Out In Description Indicates the heartbeat period. The changed heartbeat period (unit: minute). Value range: 5 to 60 The value 0 is also valid.
Support (Y/N) Y
Table 2-57 Values of setting heartbeat period Returned Value Success Failure Description Indicates that this operation succeeds. Indicates that this operation fails. Support (Y/N) Y Y
Table 2-58 Exceptions of setting heartbeat period Exception InvalidHeartbeatPeriod ConflictingHeartbeatPeriod ValueNotSupported OperationNotSupported SetHeartbeatPeriod Description Indicates that the specified heartbeat period is invalid. Indicates that the specified heartbeat period is the same as the current value. Indicates that the specified parameter is not supported. Indicates that this operation is not supported. Indicates the exceptions caused by unknown reasons. Support (Y/N) Y Y N N Y
Triggering Heartbeat Notifications

l Function description The NMS invokes trigger_heartbeat to trigger a heartbeat notification. When receiving this operation, IRPAgent sends immediately a heartbeat notification and indicates in the notification that this notification is triggered by the NMS. The NMS can perform this operation to actively query the communication state with IRPAgent. This does not affect the normal heartbeat notifications sent periodically by IRPAgent. l Function format
CSIRPConstDefs::ResultType trigger_heartbeat( in CSIRPConstDefs::ManagerIdentifierType managerIdentifier ) raises (TriggerHeartbeat, InvalidManagerIdentifier);
2-28
Issue 03 (2010-12-31)
Table 2-59 Parameters for triggering heartbeat notifications Parameter managerIdentifier In/Out In Description Indicates the identifier of the NMS triggering the heartbeat notification. The parameter is a character string. In addition, the parameter must get the object reference of CSIRP through the Getting IRP Reference interface. Suppor t (Y/N) Y
Table 2-60 Values of triggering heartbeat notifications Returned Value Success Failure Description Indicates that this operation succeeds. Indicates that this operation fails. Suppor t (Y/N) Y Y
Table 2-61 Exceptions of triggering heartbeat notifications Exception InvalidManagerIdentifier TriggerHeartbeat Description Indicates that managerIdentifier is invalid. Indicates the exceptions caused by unknown reasons. Suppor t (Y/N) Y Y
2.3.2 Heartbeat Notification of the CORBA Communication Surveillance

When the heartbeat period is up, IRPAgent sends a heartbeat notification accordingly to the NMS. When the sent heartbeat notification is triggered by the NMS, it does not affect the original heartbeat period. If the NMS expects a heartbeat notification, the NMS should be active to subscribe the heartbeat notification.
Triggering Conditions
l l The heartbeat interval set by the NMS is not 0 and the interval time is up. The NMS successfully resets the heartbeat by performing the Setting Heartbeat Period operation.
Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. 2-29
Issue 03 (2010-12-31)
The NMS successfully passes the Triggering Heartbeat Notifications operation.

NOTE
After sending a heartbeat notification, IRPAgent begins to count the heartbeat period again.
Notification Format
Table 2-62 lists the format of the heartbeat notification. Table 2-62 Format of the heartbeat notification Attribute Name domain_name Type string Domain header.fixed_he ader.event_type Description Indicates the name of a managed domain. This parameter shows the version number of the associated IRP information model. type_name string header.fixed_he ader.event_type Indicates the type of the reported heartbeat notification notifyHeartbeat. The value of this parameter is defined by CSIRPNotifications::notifyHeartbea t::EVENT_TYPE. event_name e string string header.fixed_he ader filterable_data Indicates the name of an event. (This parameter is null.) Indicates the instances of MO that sends the notification, that is, the CSIRP object instance. Indicates the notification identifier and is used to exclusively identify a notification. Indicates the time when the event occurs. Indicates the identifier of the IRPAgent that generates notifications. Indicates the heartbeat interval. Because the NMS may modify the heartbeat interval, the attribute is used to indicate the currently defined interval.
long
remainder_of_b ody filterable_data filterable_data
b c
HEARTBEAT_P ERIOD
unsigned short
remainder_of_b ody
2-30
Issue 03 (2010-12-31)
Attribute Name TRIGGER_FLA G
Type ENUM {IRPMana ger, IRPAgent } string
Domain remainder_of_b ody
Description Indicates whether the notification is normal or triggered by IRPManager. The attribute is valued as ENUM {IRPManager, IRPAgent}.
MANAGER_IDE NTIFIER
remainder_of_b ody
l If triggerFlag is IRPManager, the value of the parameter is the same as that for the triggerHeartbeat operation. l If triggerFlag is IRPAgent, the value of the parameter is null.
CHANNEL_ID
string
remainder_of_b ody
The channel identifier of the OMG notification service.
NOTE
Issue 03 (2010-12-31)
2-31
3 Configuration Management Function of the CORBA Interface
Configuration Management Function of the CORBA 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 Interface This 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 CORBA Common configuration has the function of actively reporting the change of a configuration object. When a configuration object needs to be created, deleted, or modified, or requests the NMS to synchronize the configuration, KernelCMIRP actively sends a notification to the NMS for managing configuration objects. 3.3 Function and Interface of Basic Configuration Management 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 use the interfaces to manage configuration managed objects. Huawei only supports the interface of querying configuration managed objects.
Issue 03 (2010-12-31)
3-1
3.1 Getting to Know Configuration Management of the CORBA 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 more systems. An MO is also a network resource that can be managed. It is an instance of a managed object 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 is managed. It includes MOCs and their relevant attributes and operations.
DN and RDN
A 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.
3-2
Issue 03 (2010-12-31)

NOTE
When an NMS manages a network through multiple M2000s, you can perform the following steps to modify SubNetworkId 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 2 successfully.
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 and ensure 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 that SubNetworkId 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 CORBA

Common configuration has the function of actively reporting the change of a configuration object. When a configuration object needs to be created, deleted, or modified, or requests the NMS to synchronize the configuration, KernelCMIRP actively sends a notification to the NMS for managing configuration objects. 3.2.1 Interface Description of the Common Configuration Management of the CORBA This describes the common configuration management of the CORBA interface. The common configuration management involves getting KernelCMIRP versions, getting KernelCMIRP operation profile, getting KernelCMIRP notification profile, and getting NRM versions. 3.2.2 Notification Description of the Common Configuration Management of the CORBA The part describes the notifyObjectCreation, notifyObjectDeletion, notifyAttributeValueChange, notifyCMSynchronizationRecommended in the common configuration management of the CORBA interface.
3.2.1 Interface Description of the Common Configuration Management of the CORBA

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

l Function description The NMS invokes get_kernel_CM_IRP_versions to get the KernelCMIRP version information. l Function format
ManagedGenericIRPConstDefs::VersionNumberSet get_kernel_CM_IRP_versions () raises (GetKernelCMIRPVersionsException);
There is no parameter in getting KernelCMIRP versions. Table 3-1 Values of getting KernelCMIRP versions Returned Value VersionNumberSet Description Indicates a set of versions that the KernelCMIRP supports. The value of VersionNumberSet is a set of strings. Huawei supports only one of the KernelCMIRP versions. Support (Y/N) Y
Table 3-2 Exceptions of getting KernelCMIRP versions Exception GetKernelCMIRPVersionsException Description Indicates the exceptions caused by unknown reasons. Support (Y/N) Y
Getting KernelCMIRP Operation Profile

l Function description The NMS invokes get_kernel_CM_IRP_operation_profile to get the profile of operations supported by a specified version of KernelCMIRP. l Function format
ManagedGenericIRPConstDefs::MethodList get_kernel_CM_IRP_operation_profile( in ManagedGenericIRPConstDefs::VersionNumber kernel_CM_IRP_version ) raises ( GetKernelCMIRPOperationProfileException, ManagedGenericIRPSystem::OperationNotSupported, ManagedGenericIRPSystem::InvalidParameter);
3-4
Issue 03 (2010-12-31)
Table 3-3 Parameters for getting KernelCMIRP operation profile Parameter kernel_CM_IRP_version In/Out In Description Indicates the KernelCMIRP version information in the IRP profile obtained by the NMS. The version ID should be consistent with the version ID returned by Getting kernel CMIRP Versions. Suppor t (Y/N) Y
Table 3-4 Values of getting KernelCMIRP operation profile Returned Value MethodList Description Indicates the information list of operations that the FileTransferIRP supports. The information list contains the following items: l Names of operations l Parameter lists Support (Y/N) Y
Table 3-5 Exceptions of getting KernelCMIRP operation profile Exception InvalidParameter Description Indicates that the kernel_CM_IRP_version is invalid or null. Indicates that the operation is not supported. Indicates the exceptions caused by unknown reasons. Support (Y/N) Y
OperationNotSupported GetKernelCMIRPOperationProfileException
N Y
Getting KernelCMIRP Notification Profile

l Function description The NMS invokes get_kernel_CM_IRP_notification_profile to get the profile of notifications supported by KernelCMIRP. l Function format
ManagedGenericIRPConstDefs::MethodList get_kernel_CM_IRP_notification_profile ( in ManagedGenericIRPConstDefs::VersionNumber kernel_CM_IRP_version ) raises (
Issue 03 (2010-12-31)
3-5
GetKernelCMIRPNotificationProfileException, ManagedGenericIRPSystem::OperationNotSupported, ManagedGenericIRPSystem::InvalidParameter);
Table 3-6 Parameters for getting KernelCMIRP notification profile Parameter kernel_CM_IRP_version In/Out In Description Indicates the KernelCMIRP version information in the IRP profile obtained by the NMS. The version ID should be consistent with the version ID returned by Getting kernel CMIRP Versions. Support (Y/N) Y
Table 3-7 Values of getting KernelCMIRP notification profile Returned Value MethodList Description Indicates the profile list of notifications that an KernelCMIRP supports. The profile list contains the following items: l Names of notifications supported by the KernelCMIRP l Names of fields in the notification (including the names of filterable_data and remainder_of_body fields) Suppor t (Y/N) Y
Table 3-8 Exceptions of getting KernelCMIRP notification profile Exception InvalidIRPVersion Description Indicates that the given kernel_CM_IRP_version is invalid or null. Indicates that the operation is not supported. Indicates the exceptions caused by unknown reasons. Support (Y/N) Y
OperationNotSupported GetKernelCMIRPNotificationProfileException
N Y
Getting NRMIRP Versions

l
3-6
Function description
Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. Issue 03 (2010-12-31)
The NMS invokes get_NRM_IRP_version to get the version of NRM supported by IRPAgent. l Function format
void get_NRM_IRP_version ( out ManagedGenericIRPConstDefs::VersionNumberSet versionNumberList, out ManagedGenericIRPConstDefs::VersionNumberSet vSEVersionNumberList ) raises (GetNRMIRPVersion);
Table 3-9 Parameters for getting NRMIRP versions Parameter versionNumberList In/Out Out Description Indicates the version of the NRMs supported by Agent. The NRM has the following types: l Common NRM l Wireless access NRM l Core network NRM vSEVersionNumberList Out Indicates the unique version of the extended NRM supported by Agent. This NRM is the extension on existing specifications. In this situation, the parameter versionNumberList lists the version information about standard specifications that work as the extension basis. Accordingly, the parameter versionNumberList lists information about the extended version. The version information has the following three parts: l Version information about standard specifications which work as the basis l Unique ID of the manufacturer l Version information about the extended NRM of this manufacturer Y Support (Y/N) Y
There is no value in getting NRMIRP versions. Table 3-10 Exceptions of getting NRMIRP versions Exception GetNRMIRPVersion Description Indicates the exceptions caused by unknown reasons. Support (Y/N) Y
Issue 03 (2010-12-31)
3-7
3.2.2 Notification Description of the Common Configuration Management of the CORBA

The part describes the notifyObjectCreation, notifyObjectDeletion, notifyAttributeValueChange, notifyCMSynchronizationRecommended in the common configuration 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 and ATTRIBUTE_LIST in the notification. You need to not query configuration managed objects by 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 Attribute Name domain_name Type string Domain header.fixed_he ader.event_type Description Indicates the name of a managed domain. This parameter shows the version number of the associated IRP information model. Indicates the type of the reported notification, that is, the notifyObjectCreation notification. The value is defined by KernelCmNotifications::MO Creation::EVENT_TYPE. event_name e string string header.fixed_he ader filterable_data Indicates the name of an event. (This parameter is null.) Indicates the instances of MO that sends the notification, that is, the DN of the new MO instances. Indicates the notification identifier and is used to exclusively identify a notification.
type_name
string
header.fixed_he ader.event_type
long
remainder_of_b ody
3-8
Issue 03 (2010-12-31)
Attribute Name b c
Type TimeBase: :UtcT string
Domain filterable_data filterable_data
Description Indicates the time when the event occurs. Indicates the identifier of the IRPAgent that generates notifications. Indicates the additional text related to the notification. Indicates the indicator of the source operation that triggers this notification. The value of the attribute may be one of the following values: l Resource_operation This notification is triggered by an operation on the managed resources. l Management_operation The notification is triggered by an NMS operation delivered from Manager. l Unknown The cause for triggering the notification is unknown.
ADD_TEXT SOURCE
string string
remainder_of_b ody remainder_of_b ody
ATTRIBUTE_LIST
KernelCm Notificatio ns::MOCre ation::Initi alAttribute Values
remainder_of_b ody
Indicates the attribute list of a new object. The list includes: l Attribute name l Value
NOTE
notifyObjectDeletion
The notifyObjectDeletion notification is sent when an MO is deleted. After the NMS receives the notification, delete the corresponding object or its sub-object at the NMS side according to the e field in the notification.
Issue 03 (2010-12-31)
3-9

NOTE
The e field in the notification is the base object of the object to be deleted. The sub-object does not send the notifyObjectDeletion notification.
Triggering condition A configuration object of an NE is deleted. The OMC deletes the configuration of an NE.
Notification format Table 3-12 lists the format of the notifyObjectDeletion notification. Table 3-12 Notification of notifyObjectDeletion Attribute Name domain_name Type string Domain header.fixed_h eader.event_ty pe header.fixed_h eader.event_ty pe Description Indicates the name of a managed domain. This parameter shows the version number of the associated IRP information model. Indicates the type of the reported notification, that is, the notifyObjectDeletion notification. The value is defined by KernelCmNotifications::MODeleti on::EVENT_TYPE. event_name e string string header.fixed_h eader filterable_data Indicates the name of an event. (This parameter is null.) Indicates the instances of MO that sends the notification, that is, the DN of the deleted MO instances. Indicates the notification identifier and is used to exclusively identify a notification. Indicates the time when the event occurs. Indicates the identifier of the IRPAgent that generates notifications. Indicates the additional text related to the notification.
type_name
string
long
remainder_of_ body filterable_data filterable_data
b c
ADD_TEXT
string
remainder_of_ body
3-10
Issue 03 (2010-12-31)
Attribute Name SOURCE
Type string
Domain remainder_of_ body
Description Indicates the indicator of the source operation that triggers this notification. The value of the attribute may be one of the following values: l Resource_operation This notification is triggered by an operation on the managed resources. l Management_operation The notification is triggered by an NMS operation delivered from Manager. l Unknown The cause for triggering the notification is unknown.
ATTRIBUTE_ LIST
KernelCmN otifications:: MODeletion ::AttributeV alues
remainder_of_ body
Indicates the attribute list of an object to be deleted. The list includes: l Attribute name l Value
NOTE
notifyAttributeValueChange
The notifyAttributeValueChange notification is sent when an MO is modified. After the NMS receives the notification, modify the MO in the NMS according to e and ATTRIBUTE_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 format Table 3-13 lists the format of the notifyAttributeValueChange notification.
Issue 03 (2010-12-31)
3-11
Table 3-13 Notification of notifyAttributeValueChange Attribute Name domain_name Type string Domain header.fixe d_header.e vent_type header.fixe d_header.e vent_type Description Indicates the name of a managed domain. This parameter shows the version number of the associated IRP information model. Indicates the type of the reported notification, that is, the notifyAttributeValueChange notification. The value if defined by KernelCmNotifications::AttributeValu eChange::EVENT_TYPE. event_name e string string header.fixe d_header filterable_d ata remainder_ of_body filterable_d ata filterable_d ata remainder_ of_body remainder_ of_body Indicates the name of an event. (This parameter is null.) Indicates the instances of MO that sends the notification, that is, the DN of the modified MO. Indicates the notification identifier and is used to exclusively identify a notification. Indicates the time when the event occurs. Indicates the identifier of the IRPAgent that generates notifications. Indicates the additional text related to the notification. Indicates the indicator of the source operation that triggers this notification. The value of the attribute may be one of the following values: l Resource_operation This notification is triggered by an operation on the managed resources. l Management_operation The notification is triggered by an NMS operation from Manager. l Unknown The cause for triggering the notification is unknown.
type_name
string
long
b c ADD_TEXT SOURCE
TimeBase:: UtcT string string string
3-12
Issue 03 (2010-12-31)
Attribute Name MODIFIED_A TTRIBUTE_S ET
Type KernelCm Notificatio ns::Attribut eValueCha nge::Modif iedAttribut eSet
Domain remainder_ of_body
Description Indicates the list of the changed object attributes. 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 of IRPAgent 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 synchronizing configuration information are sent.
Notification format Table 3-14 lists the format of the notifyCMSynchronizationRecommended notification. Table 3-14 Notification of notifyCMSynchronizationRecommended Attribute Name domain_name Type string Domain header.fixed_he ader.event_type Description Indicates the name of a managed domain. This parameter shows the version number of the associated IRP information model. Indicates the type of the reported notification, that is, the notifyCMSynchronizationRecommended notification. The value is defined by KernelCmNotifications::CMSynchr onizationRecommended::EVENT_ TYPE. event_name string header.fixed_he ader Indicates the name of an event. (This parameter is null.)
3-13
type_name
string
Issue 03 (2010-12-31)
Attribute Name e
Type string
Domain filterable_data
Description Indicates the instances of MO that sends the notification, that is, the configured MO instances. Indicates the notification identifier and is used to exclusively identify a notification. Indicates the time when the event occurs. Indicates the identifier of the IRPAgent that generates notifications. Indicates the additional text related to the notification. Indicates the class of the base MO of a subtree specified to be synchronized. This field is not supported.
long
remainder_of_b ody filterable_data filterable_data
b c
TimeBase ::UtcT string
ADD_TEXT BASE_MOC
string string
BASE_MOI
string
Indicates the instance identifier of the base MO of a subtree specified to be synchronized. Indicates the scope specified for synchronization. The attribute value may be: l Base MO l Whole subtree l From the base MO to the layer N subtree l Objects in layer N The default value is the whole subtree. The value is defined as follows:
enum ScopeType { BASE_ONLY, BASE_NTH_LEVEL, BASE_SUBTREE, BASE_ALL }; struct ScopePara { ScopeType type; Unsigned long level; };
SCOPE
KernelCm ConstDefs ::ScopePa ra
3-14
Issue 03 (2010-12-31)

NOTE
3.3 Function and Interface of Basic Configuration Management 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 use the interfaces to manage configuration managed objects. Huawei only supports the interface of querying configuration managed objects.
Getting BasicCMIRP Versions

l Function description The NMS invokes get_basicCm_IRP_version to get the BasicCMIRP version information. l Function format
ManagedGenericIRPConstDefs::VersionNumberSet get_basicCm_IRP_version() raises (GetBasicCmIRPVersion);
There is no parameter in getting BasicCMIRP versions. Table 3-15 Values of getting BasicCMIRP versions Returned Value VersionNumberSet Description Indicates a set of versions that the BasicCMIRP supports. The value of VersionNumberSet is a set of strings. Huawei supports only one of the BasicCMIRP versions. Support (Y/N) Y
Table 3-16 Exceptions of getting BasicCMIRP versions Exception GetBasicCmIRPVersion Description Indicates the exceptions caused by unknown reasons. Support (Y/N) Y
Getting BasicCMIRP Operation Profile

l Function description The NMS invokes get_basicCm_IRP_operation_profile to get the profile of operations supported by a specified version of BasicCMIRP. l Function format
ManagedGenericIRPConstDefs::MethodList get_basicCm_IRP_operation_profile ( in ManagedGenericIRPConstDefs::VersionNumber basicCm_IRP_version ) raises (
Issue 03 (2010-12-31)
3-15
GetBasicCmIRPOperationProfile, ManagedGenericIRPSystem::OperationNotSupported, ManagedGenericIRPSystem::InvalidParameter);
Table 3-17 Parameters for getting BasicCMIRP operation profile Parameter basicCm_IRP_version In/Out In Description Indicates the BasicCMIRP version information in the IRP profile obtained by the NMS. The version ID should be consistent with the version ID returned by Getting BasicCMIRP Versions. Support (Y/N) Y
Table 3-18 Values of getting BasicCMIRP operation profile Returned Value MethodList Description Indicates the information list of operations that the BasicCMIRP supports. The information list contains the following items: l Names of operations l Parameter lists Support (Y/N) Y
Table 3-19 Exceptions of getting BasicCMIRP operation profile Exception InvalidParameter Description Indicates that the given basicCm_IRP_version is invalid or null. Indicates that the operation is not supported. Indicates the exceptions caused by unknown reasons. Support (Y/ N) Y
OperationNotSupported GetBasicCmIRPOperationProfile
N Y
Getting BasicCMIRP Notification Profile

l Function description The NMS invokes get_basicCm_IRP_notification_profile to get the profile of notifications supported by BasicCMIRP.
Function format
ManagedGenericIRPConstDefs::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 Parameter basicCm_IRP_version In/Out In Description Indicates the BasicCMIRP version information in the BasicCMIRP profile obtained by the NMS. The version ID should be consistent with the version ID returned by Getting BasicCMIRP Versions. Support (Y/N) Y
Table 3-21 Values of getting BasicCMIRP notification profile Returned Value MethodList Description Indicates the profile list of notifications that an BasicCMIRP supports. The profile list contains the following items: l Names of notifications supported by the BasicCMIRP l Names of fields in the notification (including the names of filterable_data and remainder_of_body fields) Support (Y/N) Y
NOTE
Notifications are not defined in the BasicCMIRP.
Table 3-22 Exceptions of getting BasicCMIRP notification profile Exception InvalidParameter Description Indicates that the given basicCm_IRP_version is invalid or null. Indicates that the operation is not supported. Support (Y/ N) Y
OperationNotSupported
Issue 03 (2010-12-31)
3-17
Exception GetBasicCmIRPNotificationProfile
Description Indicates the exceptions caused by unknown reasons.
Support (Y/ N) Y
Finding Managed Objects

l Function description The NMS invokes find_managed_objects to query MOs in a specified condition and their attribute 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) Parameter baseObject In/Out In Description Indicates the ID of the base object instance. The parameter identifies exclusively the base object of an MO subtree. Support (Y/N) Y
3-18
Issue 03 (2010-12-31)
Parameter searchControl
In/Out In
Description Defines query conditions. The structure of the parameter is as follows:

struct SearchControl { ScopeType type; unsigned long level; FilterType filter; ResultContents contents; };
Support (Y/N) Y
The type field defines a query range and is used in combination with the level 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 are returned. If level is 0, the base object is returned. l If type is BASE_SUBTREE, all the objects between base objects and objects at the level layer are returned. l If type is BASE_ALL and level is null, base objects and all the objects under the base objects are returned. l The filter field is not supported. l If contents is NAMES, only the DNs of required MOs are returned and attributes of the MOs are not returned. l If contents is NAMES_AND_ATTRIBUTES, the DNs and attributes of required MOs are returned. requestedAttributes in Defines a name list of attributes to be queried. Y
Table 3-24 Values of finding managed objects (I) Returned Value BasicCmInformationIterator Description Indicates that the returned value is the CORBA object of BasicCmInformationIterator. Support (Y/N) Y
Issue 03 (2010-12-31)
3-19
Table 3-25 Exceptions of finding managed objects (I) Exception Description Suppo rt (Y/ N) Y Y N Y N N Y Y N N N Y
IllegalDNFormatException UndefinedScopeException IllegalScopeTypeException IllegalScopeLevelException IllegalFilterFormatException FilterComplexityLimit ParameterNotSupported InvalidParameter UndefinedMOException ValueNotSupported OperationNotSupported FindManagedObjects
Indicates an illegal DN. Indicates that the filter scope is undefined. Indicates an illegal filter scope type. Indicates an illegal filter scope level. Indicates an illegal filter condition. Indicates a complex filter condition that cannot be parsed. Indicates that the given parameters are not supported. Indicates that the given parameter is invalid. Indicates that baseObjectInstance is invalid. Indicates the value is not supported. Indicates that the operation is not supported. Indicates the exceptions caused by unknown reasons.
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 how_many In/ Out In Description Indicates the number of objects that the NMS expects. The value of the parameter must be greater than 0. Support (Y/N) Y
3-20
Issue 03 (2010-12-31)
Parameter fetchedElements
In/ Out Out
Description Returns an information list of configuration objects. The list includes DNs and attribute lists. The list includes the following subitems: l mo: the object class name of each returned attribute value l attributes: the list of queried attribute names and values
NOTE l If the current configuration object number is more than the value of how_many, the length of the parameter is equal to how_many. l If the current configuration object number is less than or equal to the value of how_many, the parameter is the information about current configuration objects.
Support (Y/N) Y
Table 3-27 Values of finding managed objects (II) Returned Value boolean Description 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. Support (Y/N) Y
Table 3-28 Exceptions of finding managed objects (II) Exception NextBasicCmInformations InvalidParameter OperationNotSupported l Function format(3)
void destroy () raises ( DestroyException, ManagedGenericIRPSystem::OperationNotSupported);
Description Indicates operation failure caused by some unknown causes. Indicates an invalid parameter, for example the value of InvalidParameter is 0. Indicates that the operation is not supported.
Support (Y/N) Y Y N
Issue 03 (2010-12-31)
3-21
Table 3-29 Exceptions of finding managed objects (III) Exception DestroyException OperationNotSupported 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 Description Indicates the exceptions caused by unknown reasons. Indicates that the operation is not supported. Support (Y/N) Y N
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. 1 2 Step The NMS uses the find_managed_objects interface to query MOs in a specified condition. IRPAgent queries MOs according to conditions provided by the NMS and creates the BasicCmInformationIterator object.
3-22
No. 3
Step The NMS invokes the next_basicCmInformation interface of BasicCmInformationIterator 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 BasicCmInformationIterator object. l If the returned value is true, infer that the information list of MOs is not null.
When the NMS does not select all the MO information, invoke destroy to release the BasicCmInformationIterator object.
Issue 03 (2010-12-31)
3-23
4 Alarm Management Function of the CORBA Interface
Alarm Management Function of the CORBA Interface
About This Chapter

The AlarmIRP interface is the only interface used in alarm management. The alarm management has the following functions: querying alarms, clearing alarms, acknowledging alarms, unacknowledging alarms, and reporting alarms in real time. 4.1 Introduction to the CORBA Alarm Management With alarm management function, you can query, clear, acknowledge, counter-acknowledge alarms, and add comments to alarms. In addition, alarms can be reported in real time. 4.2 Alarm Management of the CORBA The alarm management of the CORBA interface describes the CORBA alarm management and its functions.
Issue 03 (2010-12-31)
4-1
4.1 Introduction to the CORBA Alarm Management

With alarm management function, you can query, clear, acknowledge, counter-acknowledge alarms, 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 of alarms enables the NMS to handle alarms in real time.
4.2 Alarm Management of the CORBA

The alarm management of the CORBA interface describes the CORBA alarm management and its functions. 4.2.1 Interface Description of the CORBA Alarm Management The CORBA alarm management involves getting AlarmIRP versions, getting AlarmIRP operation 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 Management The description of the CORBA alarm management notification contains the triggering conditions and formats of the potential faulty alarm list notification, new alarm notification, alarm acknowledgement status change notification, alarm clearance notification, alarm comment notification, and alarm change notification. 4.2.3 Mechanism for Forwarding Common Alarms In a multi-mode base station (MBTS), common alarms can be generated on certain common devices. You can differentiate normal mode alarms from common alarms by viewing alarm information.
4.2.1 Interface Description of the CORBA Alarm Management

The CORBA alarm management involves getting AlarmIRP versions, getting AlarmIRP operation profile, getting AlarmIRP notification profile, getting alarm list, alarm contents, getting alarm count, acknowledging alarms, unacknowledging alarms, and clearing alarms.
Getting AlarmIRP Versions

l l Function description The NMS invokes get_alarm_IRP_versions to get information about AlarmIRP versions. 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 Returned Value VersionNumberSet Description Indicates a set of versions that AlarmIRP supports. The value of VersionNumberSet is a set of strings. Huawei supports only one of the AlarmIRP versions.
Support (Y/N) Y
Table 4-2 Exceptions of getting AlarmIRP versions Exception GetAlarmIRPVersions Description Indicates the exceptions caused by unknown reasons. Support (Y/N) Y
Getting AlarmIRP Operation Profile

l Function description The NMS invokes get_alarm_IRP_operations_profile to get the profile of operations supported by AlarmIRP. l Function format
ManagedGenericIRPConstDefs::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 Parameter alarm_irp_version In/Out in Description Indicates the version of managed objects in the AlarmIRP managed domain. The value of this parameter should be consistent with the version number displayed in Getting AlarmIRP Versions. Suppor t (Y/N) Y
Table 4-4 Values of getting AlarmIRP operation profile Returned Value MethodList Description Indicates the information list of operations that AlarmIRP supports. The information list contains the following items: l Names of operations l Parameter lists Suppor t (Y/N) Y
Issue 03 (2010-12-31)
4-3
Table 4-5 Exceptions of getting AlarmIRP operation profile Exception InvalidParameter OperationNotSupported GetAlarmIRPOperationsProfile Description Indicates that the given alarm_irp_version is invalid or null. Indicates that this operation is not supported. Indicates the exceptions caused by unknown reasons. Suppor t (Y/N) Y N Y
Getting AlarmIRP Notification Profile

l Function description The NMS invokes get_alarm_IRP_notification_profile to get the profile of notifications supported by AlarmIRP. l Function format
ManagedGenericIRPConstDefs::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 Parameter alarm_irp_version In/Out in Description Indicates the AlarmIRP version in the AlarmIRP profile obtained by the NMS. The value of this parameter should be consistent with the version number displayed in Getting AlarmIRP Versions. Support (Y/N) Y
Table 4-7 Values of getting AlarmIRP notification profile Returned Value MethodList Description Indicates the profile list of notifications that an AlarmIRP supports. The profile list contains the following items: l Names of notifications supported by AlarmIRP l Names of fields in the notification (including the names of filterable_data and remainder_of_body fields)
Support (Y/N) Y
Table 4-8 Exceptions of getting AlarmIRP notification profile Exception InvalidParameter OperationNotSupported GetAlarmIRPNotificationProfile Description Indicates that the given alarm_irp_version is invalid or null. Indicates that this operation is not supported. Indicates the exceptions caused by unknown reasons. Suppor t (Y/N) Y N Y
Getting Alarm List

l Function description The NMS invokes get_alarm_list to get an alarm list of the current operations that meet certain 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) Parameter base_object In/Out in Description Either null or a certain object. If this parameter is null, all the alarm information in the current alarm list is displayed. If this parameter is a certain object, only the alarm information related to the specified objects or the child objects in the current alarm list is displayed. filter in Defines the filtering conditions for the alarm information to be obtained by the NMS. For the Union type, if this parameter is null, no filtering conditions are set.
NOTE For details about the filtering restrictions, refer to 7.1.2 Description of filter in get_alarm_list.
Suppor t (Y/N) Y
Issue 03 (2010-12-31)
4-5
Parameter flag
In/Out out
Description l If flag is true, the Returned Value shows alarm information. l If flag is false, the iter shows the alarm information while the Returned Value list is null.
Suppor t (Y/N) Y
iter
out
Indicates that the alarm information is obtained through iter when flag is false. This parameter is the CORBA object of AlarmInformationIterator.
Table 4-10 Values of getting alarm list (I) Returned Value AlarmInformationSeq Description l If flag is true, the Returned Value shows the alarms that meet certain requirements. l If flag is false, the Returned Value is null. Support (Y/N) Y
Table 4-11 Exceptions of getting alarm list (I) Exception InvalidParameter ParameterNotSupported GetAlarmList Description Indicates that the parameter is invalid. Indicates that this operation is not supported. Indicates the exceptions caused by unknown reasons. Support (Y/N) Y N Y
Function format (2)

boolean next_alarmInformations ( in unsigned short how_many, out AlarmIRPConstDefs::AlarmInformationSeq alarm_informations ) raises ( NextAlarmInformations, ManagedGenericIRPSystem::InvalidParameter);
4-6
Issue 03 (2010-12-31)
Table 4-12 Parameters for getting alarm list (II) Parameter how_many In/Out in Description Indicates the number of alarms that the NMS expects. The value of this parameter must be greater than 0 and less than or equal to 2000. alarm_informations out Indicates the displayed alarm information list. l If the number of current alarms exceeds the value of how_many, the sequence length of alarm_informations is equal to that of how_many. l If the number of current alarms is less than or equal to how_many, alarm_informations indicates the alarm information list. Y Suppo rt (Y/N) Y
Table 4-13 Values of getting alarm list (II) Returned Value boolean Description Indicates that the returned value is of boolean. l TRUE indicates that some alarm information is not returned. l FALSE indicates that all alarm information is returned and iterator objects are released. Support (Y/N) Y
Table 4-14 Exceptions of getting alarm list (II) Exception InvalidParameter Description Indicates that the parameter is invalid. For instance, if the value of how_many is 0, infer that this parameter is invalid. NextAlarmInformations l Function format (3)
void destroy () raises( CORBA::SystemException);
Support (Y/N) Y
Indicates that this operation is not supported.
Issue 03 (2010-12-31)
4-7
Table 4-15 Exceptions of getting alarm list (III) Exception SystemException Description Indicates the exceptions caused by unknown reasons. Support (Y/N) Y
Event flow Figure 4-1 shows the event flow of alarm information. Figure 4-1 Event flow of alarm information
1. 2. 3. 4. 5. 6. 7.
Get alarm lists. Query alarms. The AlarmInformationIterator is displayed when the value of flag is false. All alarms are displayed when the value of flag is true. In case the value of flag is false, the next_alarmInformations is invoked. The system displays alarms. If the value false is displayed, objects are released. If the value true is displayed, the system continue to query alarms. Release objects directly.
Alarm Contents
l Unacknowledged and uncleared alarms Table 4-16 lists the format of the Unacknowledged and uncleared alarms.
4-8
Issue 03 (2010-12-31)
Table 4-16 Unacknowledged and uncleared alarms Attribute Name domain_name type_name Type string string Domain header.fixed_hea der.event_type header.fixed_hea der.event_type Description Indicates the version number of the associated IRP information model. Reports the name of a new alarm. The value of this parameter is as follows: AlarmIRPConstDefs::NotificationType :: NOTIFY_FM_NEW_ALARM. Indicates the name of an event and defines communication alarms, internal error-handling alarms, QoS alarms, and equipment alarms. The value of this parameter maps to AlarmIRPConstDefs::AlarmType. e b c g string TimeBase: :UtcT string short filterable_data filterable_data filterable_data filterable_data Indicates the object instances of an alarm. Indicates the time when an alarm occurs. Indicates the identifier of the IRPAgent. Indicates the possible reasons for an alarm and has more detailed categorizations compared with AlarmType. The value range and information about this parameter are defined in ProbableCause. h short filterable_data Indicates the severity of an alarm. The following lists severities of alarms: l INDETERMINATE l CRITICAL l MAJOR l MINOR l WARNING l CLEARED
NOTE Currently, INDETERMINATE is not supported.
event_name
string
header.fixed_hea der
Issue 03 (2010-12-31)
4-9
Attribute Name jj
Type long
Description Vendor-customized alarm type 1: Fault alarm
nn
long
filterable_data
The maintenance-mode alarm statuses are as follows: l 0: Normal l 1: Creation l 2: Expansion l 3: Upgrade l 4: Commissioning No default value of this attribute is provided. The filterable_data area in alarm messages contains this attribute only after this attribute is activated. By default, the maintenance-mode alarm function is inactive. The NMS receives maintenance-mode alarms only after this function is activated. For details about how to activate the maintenance-mode alarm function and the attribute, see Reporting maintenance-mode alarms.
string
Indicates the serial number of alarms and is used to be the only identifier for an alarm. Indicates the detailed reasons for an alarm. This parameter records the Huawei alarm private information.
string
4-10
Issue 03 (2010-12-31)
Attribute Name j
Type string
Description Indicates the detailed location information about an alarm. The information consists of the following items: l NE location l Vendor l NE name l Alarm name l Detailed alarm location information The format for location information is as follows: NeType: NodeB| NeLocation: ShangHai | vendor: Huawei | neName: N91003| alarmName: RF Unit Maintenance Link Failure| alarmLocation: Cabinet No.=1, Subrack No.=4, Slot No.=0, Board type=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 the maintenance-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 FaultService 3. Check whether the CORBA V1.2.0 interface is installed by referring to the iManagerM2000V200R010C00 Guide to Query and Change Northbound CORBA Interface. If the installed interface is not the CORBA V1.2.0 interface, replace it with the CORBA V1.2.0 interface. 4. Open the /opt/OMC/etc/IRPService/itf_n_config.xml file, and then set enableSpecialAlarmStatusID 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
Alarms that are already acknowledged but not cleared Table 4-17 lists the format of the acknowledged but uncleared alarms.
Issue 03 (2010-12-31)
4-11
Table 4-17 Acknowledged but uncleared alarms Attribute Name domain_name Type string Domain header.fixed_header.ev ent_type header.fixed_header.ev ent_type Description Indicates the version number of the associated IRP information model. Indicates the state of an alarm. This parameter refers to the acknowledgement state of an alarm. The value of this parameter maps to AlarmIRPConstDefs::Notif icationType ::NOTIFY_FM _ACK_STATE_CHANGE D. event_name string header.fixed_header Indicates the name of an event and defines communication alarms, internal error-handling alarms, QoS alarms, and equipment alarms. The value of this parameter maps to AlarmIRPConstDefs::Alar mType. e string filterable_data Indicates the MO instances in the alarm notification. That is, this parameter shows the object instances of alarms occurred. Indicates the time when an alarm occurs. Indicates the identifier of the IRPAgent. Indicates the possible reasons for an alarm and has more detailed categorizations compared with AlarmType. The value range and information about this parameter are defined in ProbableCause.
type_name
string
b c g
TimeBase: :UtcT string short
filterable_data filterable_data filterable_data
4-12
Issue 03 (2010-12-31)
Attribute Name h
Type short
Description Indicates the severity of an alarm. The following lists the severities of alarms: l INDETERMINATE l CRITICAL l MAJOR l MINOR l WARNING l CLEARED
k jj
TimeBase: :UtcT long
filterable_data filterable_data
Indicates the time when an alarm is acknowledged. Vendor-customized alarm type 1: Fault alarm
Issue 03 (2010-12-31)
4-13
Attribute Name nn
Type long
Description The maintenance-mode alarm statuses are as follows: l 0: Normal l 1: Creation l 2: Expansion l 3: Upgrade l 4: Commissioning No default value of this attribute is provided. The filterable_data area in alarm messages contains this attribute only after this attribute is activated. By default, the maintenance-mode alarm function is inactive. The NMS receives maintenancemode alarms only after this function is activated. For details about how to activate the maintenance-mode alarm function and the attribute, see Reporting maintenance-mode alarms.
string
remainder_of_body
Indicates the serial number of alarms and is used to be the only identifier for an alarm. Indicates an identifier for a user that acknowledges an alarm. The NMS acknowledgement alarms should be acknowledged by users whose ids are in the range of ack_user_id. The OMC acknowledgement alarms should be performed only by OMC authorized users.
string
remainder_of_body
4-14
Issue 03 (2010-12-31)
Attribute Name n
Type short
Domain remainder_of_body
Description Indicates the current state of alarm acknowledgement. The value 1 indicates that the alarm in Acknowledge state.
string
remainder_of_body
Indicates the detailed reasons for an alarm. This parameter records the Huawei alarm private information.
string
remainder_of_body
Indicates the detailed location information about an alarm. The information consists of the following items: l NE location l Vendor l NE name l Alarm name l Detailed alarm location information The format for location information is as follows: NeType: NodeB| NeLocation: ShangHai | vendor: Huawei | neName: N91003| alarmName: RF Unit Maintenance Link Failure| alarmLocation: Cabinet No.=1, Subrack No.=4, Slot No.=0, Board type=WRFU| appendInfo:
NOTE
AlarmIRPConstDefs::AttributeSetType is the value type of remainder_of_body.
Unacknowledged but cleared alarms Table 4-18 lists the format of the unacknowledged but cleared alarms.
Issue 03 (2010-12-31)
4-15
Table 4-18 Unacknowledged but cleared alarms Attribute Name domain_name Type string Domain header.fixed_header.eve nt_type header.fixed_header.eve nt_type Description Indicates the version number of the associated IRP information model. Indicates the state of an alarm. Here this parameter refers to the alarms in Clear state. The value of this parameter maps to AlarmIRPConstDefs::NotificationType : NOTIFY_FM_CLEARED_ ALARM. event_name string header.fixed_header Indicates the name of an event and defines communication alarms, internal error-handling alarms, QoS alarms, and equipment alarms. The value of this parameter maps to AlarmIRPConstDefs::Alar mType. e string filterable_data Indicates the object instances in the alarm notification. Indicates the time when an alarm occurs. Indicates the identifier of the IRPAgent. Indicates the possible reasons for an alarm and has more detailed categorizations compared with AlarmType. The value range and information about this parameter are defined in ProbableCause.
type_name
string
b c g
TimeBase ::UtcT string short
4-16
Issue 03 (2010-12-31)
Attribute Name h
Type short
Description Indicates the severity of an alarm. The following lists the severities of alarms: l INDETERMINATE l CRITICAL l MAJOR l MINOR l WARNING l CLEARED
jj
long
filterable_data
Vendor-customized alarm type 1: Fault alarm
nn
long
filterable_data
The maintenance-mode alarm statuses are as follows: l 0: Normal l 1: Creation l 2: Expansion l 3: Upgrade l 4: Commissioning No default value of this attribute is provided. The filterable_data area in alarm messages contains this attribute only after this attribute is activated. By default, the maintenancemode alarm function is inactive. The NMS receives maintenance-mode alarms only after this function is activated. For details about how to activate the maintenance-mode alarm function and the attribute, see Reporting maintenance-mode alarms.
Issue 03 (2010-12-31)
4-17
Attribute Name f
Type string
Description Indicates the serial number of alarms and is used to be the only identifier for an alarm. Indicates an identifier for a user that clears an alarm. For the NMS, alarms can be cleared by users whose IDs are in the range of clear_user_id. For the OMC, alarms can be cleared only by OMC authorized users. In case of automatic alarm clearance, the authorized user is NE.
string
remainder_of_body
ll i
TimeBase ::UtcT string
remainder_of_body remainder_of_body
Indicates the time when an alarm is cleared. Indicates the detailed reasons for an alarm. This parameter records the Huawei alarm private information.
4-18
Issue 03 (2010-12-31)
Attribute Name j
Type string
Description Indicates the detailed location information about an alarm. The information consists of the following items: l NE location l Vendor l NE name l Alarm name l Detailed alarm location information The format for location information is as follows: NeType: NodeB| NeLocation: ShangHai | vendor: Huawei | neName: N91003| alarmName: RF Unit Maintenance Link Failure| alarmLocation: Cabinet No.=1, Subrack No.=4, Slot No.=0, Board type=WRFU| appendInfo:
NOTE
Getting Alarm Count

l Function description The NMS invokes get_alarm_count to get the count of all the current alarms different severities. The alarm count is consistent with the alarm information returned by Getting Alarm List. You can query the count of alarms in different severities before Getting Alarm List. l Function format
void 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);
Issue 03 (2010-12-31)
4-19
Table 4-19 Parameters for getting alarm count Parameter filter In/ Out in Description Indicates the filtering conditions for the alarm count that the NMS wants to get.
NOTE For details about the filtering format, refer to 7.1.3 Description of filter in get_alarm_count.
Support (Y/N) Y
critical_count major_count minor_count warning_count indeterminate_cou nt cleared_count
out out out out out out
Displays the count of alarms in critical. Displays the count of alarms in major. Displays the count of alarms in minor. Displays the count of alarms in warning. Displays the count of alarms in indeterminate. Displays the count of alarms in cleared.
Y Y Y Y Y Y
Table 4-20 Values of getting alarm count Returned Value Description Support (Y/N) -
Table 4-21 Exceptions of getting alarm count Exception InvalidParameter ParameterNotSupported OperationNotSupported GetAlarmCount Description Indicates that the given parameters are invalid. Indicates that this parameter is not supported. Indicates that the operation is not supported. Indicates the exceptions caused by unknown reasons. Support (Y/N) Y N N Y
Acknowledging Alarms
l Function description The NMS invokes acknowledge_alarms to acknowledge one or more alarms.
Function format
ManagedGenericIRPConstDefs::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 Parameter In/Out Description Supp ort (Y/ N) Y
alarm_information_id_and_se v_list
in
Defines the identifier of alarms to be acknowledged and the set of alarm severities. The ALARM_ID field in the alarm information indicates the alarm identifier.
NOTE Alarm severity is a parameter that must be entered. Currently, however, the M2000 does not handle this parameter.
ack_user_id
in
Defines the identifier of an NMS user who acknowledges alarms. The parameter is defined by the NMS. Defines the information about the system where the NMS is located.
ack_system_id
in
Issue 03 (2010-12-31)
4-21
Parameter
In/Out
Description
Supp ort (Y/ N) Y
bad_ack_alarm_info_list
out
Indicates errors in the alarm acknowledgement. If all the alarms are acknowledged correctly, the returned value is OK and this parameter is null. The displayed information contains the alarm identifiers and the reasons for the errors. The following lists the reasons for errors: l If the alarm ID does not exist, the reason for the errors can be classified as UNKNOWNALARMID. l If the acknowledge information does not display the wanted modification, the reason for the errors can be classified as ACKNOWLEDGMENTFAILED, although the alarm ID exists. l If an alarm is already acknowledged, the reason for the errors can be classified as ACKNOWLEDGMENTFAILED, although the alarm ID exists.
Table 4-23 Values of acknowledging alarms Returned Value OK PartialFailure Failure Description Indicates that all the alarms that require acknowledgements are acknowledged. Indicates that only some of the alarms that require acknowledgements are acknowledged. Indicates that all the alarms that require acknowledgements fail in acknowledgement. Support (Y/N) Y Y Y
4-22
Issue 03 (2010-12-31)
Table 4-24 Exceptions of acknowledging alarms Exception InvalidParameter AcknowledgeAlarms ParameterNotSupported Description Indicates that at least one group of parameters is invalid. Indicates the exceptions caused by unknown reasons. Indicates the parameter is not supported. Support (Y/N) Y Y Y
Unacknowledging Alarms
l l Function description The NMS invokes unacknowledge_alarms to unacknowledge one or more alarms. 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 Parameter alarm_information_id_list In/Out in Description Defines the identifier of alarms to be unacknowledged. The ALARM_ID field in the alarm information indicates the alarm identifier. ack_user_id in Defines the identifier of an NMS user who unacknowledges alarms. The parameter is defined by the NMS and should be consistent with ack_user_id. Defines the information about the system where the NMS is located. Y Support (Y/N) Y
ack_system_id
in
Issue 03 (2010-12-31)
4-23
Parameter bad_alarm_information_id_li st
In/Out out
Description Indicates errors in the alarm unacknowledgement. If all the alarms to be unacknowledged are unacknowledged, the returned value is OK and this parameter is null. The displayed information contains the alarm identifiers and the reasons for the errors. The following lists the reasons for the errors: l If the alarm ID specified in the input parameter does not exist, the error information is could not find the alarm. l If the alarm ID specified in the input parameter exists but the actual alarm status is "unacknowledged", the error information is the alarm is unacknowledged state.
Support (Y/N) Y
Table 4-26 Values of unacknowledging alarms Returned Value OK PartialFailure Description Indicates that all the alarms that require unacknowledgement are unacknowledged. Indicates that only some of that alarms that require unacknowledgements are unacknowledged. Indicates the cancel of the acknowledgements fails. Support (Y/N) Y Y
Failure
4-24
Issue 03 (2010-12-31)
Table 4-27 Exceptions of unacknowledging alarms Exception InvalidParameter Description Indicates that all the groups of parameters or at least one group of parameters is invalid. Indicates that the given parameters are not supported. Indicates that the operation is not supported. Indicates the exceptions caused by unknown reasons. Support (Y/ N) Y
ParameterNotSupported OperationNotSupported UnacknowledgeAlarms
Y N Y
Clearing Alarms
l l Function description The NMS invokes clear_alarms to clear one or more alarms. 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 Parameter alarm_information_id_list In/Out in Description Defines the identifier list of the alarms that the NMS would clear. Defines the identifier of an NMS user who clears alarms. Defines the information about the system where the NMS is located. Suppor t (Y/N) Y
clear_user_id
in
clear_system_id
in
Issue 03 (2010-12-31)
4-25
Parameter bad_alarm_information_id _list
In/Out out
Description Indicates errors in the alarm clearance. The displayed information contains the alarm identifiers and reasons for the errors. If all the alarms to be cleared are cleared, the returned value is OK and this parameter is null. The following lists the reasons 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.
Suppor t (Y/N) Y
Table 4-29 Values of clearing alarms Returned Value OK PartialFailure Failure Description Indicates that all the alarms that require clearance are cleared. Indicates that only some of the alarms that require clearance are cleared. Indicates the clearance of alarms fails. Support (Y/N) Y Y Y
Table 4-30 Exceptions of clearing alarms Exception InvalidParameter ParameterNotSupported ClearAlarms Description Indicates that at least one group of parameters is invalid. Indicates that the given parameters are not supported. Indicates the exceptions caused by unknown reasons. Support (Y/N) Y Y Y
4-26
Issue 03 (2010-12-31)
Adding Comments to Alarms

l l Function description The NMS invokes this function to add comments to one or more alarms. 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 alarm_information_id_list In/ Out in Description Refers to the list of the identifiers indicating the alarms to which the NMS will add comments. Refers to the identifier of the NMS user who will add comments to alarms. Refers to the information about the NMS system that will add comments to alarms. Refers to the comments to be added to alarms. Support ed (Y/N) Y
comment_user_id
in
comment_system_id
in
comment_text
in
Issue 03 (2010-12-31)
4-27
Parameter bad_alarm_information_id_lis t
In/ Out out
Description Refers to the alarm information indicating the failure to add comments to alarms. If comments are successfully added to all the specified alarms, the returned value is OK and this parameter is empty. The system output contains alarm identifiers and error causes. The error information is as follows: l If the alarm identifier specified in the typed parameter does not exist, the system displays could not find the alarm. l If the alarm identifier specified in the typed parameter exists but adding comments to this alarm is not supported, the system displays commenting the alarm is not supported.
Support ed (Y/N) Y
Table 4-32 Values of adding comments to alarms Returned Value OK PartialFailure Failure Description Indicates that comments are successfully added to all the specified alarms. Indicates that comments are added to some of the specified alarms. Indicates that adding comments to the specified alarms fails. Support ed (Y/N) Y Y Y
Table 4-33 Exceptions of adding comments to alarms Exception OperationNotSupported Description Indicates that adding comments to a certain alarm is not supported. Support ed (Y/N) N
4-28
Issue 03 (2010-12-31)
Exception ParameterNotSupported InvalidParameter
Description Indicates that one or more typed parameters are not supported. Indicates that at least one group of the typed parameters are invalid.
Support ed (Y/N) Y Y
4.2.2 Notification Description of the CORBA Alarm Management

The description of the CORBA alarm management notification contains the triggering conditions and formats of the potential faulty alarm list notification, new alarm notification, alarm acknowledgement status change notification, alarm clearance notification, alarm comment notification, and alarm change notification.
Notification of Potential Faulty Alarm List

The IRPAgent may find that the current alarm list is inconsistent with the actual network resources, or is not sure about the current alarm list. In such a situation, the IRPAgent sends the notifyPotentialFaultyAlarmList to inform the NMS that the current alarm list may be inaccurate. l l Triggering condition The connection between the NE and the OMC become disconnected. Notification format Table 4-34 lists the format of the notifyPotentialFaultyAlarmList notification. Table 4-34 notifyPotentialFaultyAlarmList Attribute Name domain_name Type string Domain header.fixed_hea der.event_type Description Indicates the name of a managed domain. This parameter shows the version number of the associated IRP information model. Indicates the type of the reported notification, that is, notifyPotentialFaultyAlarmList. The value of this parameter is defined by AlarmIRPConstDefs::Notifi cationType::NOTIFY_FM_ POTENTIAL_FAULTY_A LARM_LIST.
type_name
string
header.fixed_hea der.event_type
Issue 03 (2010-12-31)
4-29
Attribute Name event_name
Type string
Domain header.fixed_hea der filterable_data
Description Indicates the name of an event. (This parameter is null.) Indicates the instances of MO that sends the notification, that is, the object instance of AlarmIRP. Indicates the notification identifier and is used to exclusively identify a notification. Indicates the time when an event occurs. Indicates the identifier of the IRPAgent that generates notifications. Indicates the reasons for reconstruction of alarm list.
string
long
remainder_of_bo dy
b c
TimeBase::Utc T string
string
remainder_of_bo dy
NOTE
AlarmIRPConstDefs::AttributeSetType is the value type of the remainder_of_body.
Notification of New Alarms

When new alarms occur on NEs or on the OMC, the NMS sends the new alarm notification. l l Triggering condition New alarms occur on NEs or on the OMC. Notification format Table 4-35 lists the format of the new alarm notification. Table 4-35 Notification of new alarms Attribute Name domain_name Type string Domain header.fixed_he ader.event_type Description Indicates the version number of the associated IRP information model.
4-30
Issue 03 (2010-12-31)
Attribute Name type_name
Type string
Domain header.fixed_he ader.event_type
Description Indicates the type of the reported alarm, that is, the new alarm. The value of this parameter is as follows: AlarmIRPConstDefs::NotificationType :: NOTIFY_FM_NEW_ALAR M.
event_name
string
header.fixed_he ader
Indicates the name of an event and defines communication alarms, internal error-handling alarms, QoS alarms, and equipment alarms. The value of this parameter is that of AlarmIRPConstDefs::Alarm Type.
string
filterable_data
Indicates the instances of MO that sends the notification, that is, the object instance of the alarm. Indicates the notification identifier and is used to exclusively identify a notification. Indicates the time when an alarm occurs. Indicates the identifier of the IRPAgent. Indicates the possible reasons for an alarm and has more detailed categorizations compared with AlarmType. The value range and information about this parameter are defined in ProbableCause of the IDL.
long
remainder_of_b ody
b c g
TimeBase::Ut cT string short
Issue 03 (2010-12-31)
4-31
Attribute Name h
Type short
Description Indicates the severity of an alarm. The following lists severities of alarms: l INDETERMINATE l CRITICAL l MAJOR l MINOR l WARNING l CLEARED
jj
long
filterable_data
nn
long
filterable_data
The maintenance-mode alarm statuses are as follows: l 0: Normal l 1: Creation l 2: Expansion l 3: Upgrade l 4: Commissioning No default value of this attribute is provided. The filterable_data area in alarm messages contains this attribute only after this attribute is activated. By default, the maintenancemode alarm function is inactive. The NMS receives maintenance-mode alarms only after this function is activated. For details about how to activate the maintenance-mode alarm function and the attribute, see Reporting maintenancemode alarms.
string
remainder_of_b ody
Indicates the serial number of alarms and is used to be the only identifier for an alarm.
4-32
Issue 03 (2010-12-31)
Attribute Name i
Type string
Description Indicates the detailed reasons for an alarm. This parameter records the Huawei alarm private information.
string
remainder_of_b ody
Indicates the detailed location information about an alarm. The information consists of the following items: l NE location l Vendor l NE name l Alarm name l Detailed alarm location information The format of location information is as follows: NeType: NodeB| NeLocation: ShangHai | vendor: Huawei | neName: N91003| alarmName: RF Unit Maintenance Link Failure| alarmLocation: Cabinet No.=1, Subrack No.=4, Slot No.=0, Board type=WRFU| appendInfo:
NOTE
Notification of the Change of Alarm Acknowledgement Status

If the acknowledgement status of an alarm is changed, the NMS sends the alarm acknowledgement notification. l Triggering condition The NMS successfully acknowledges or unacknowledges alarms through Acknowledging Alarms or Unacknowledging Alarms. The OMC successfully acknowledges or unacknowledges alarms. l Notification format Table 4-36 lists the format of the alarm acknowledgement notification.
Issue 03 (2010-12-31)
4-33
Table 4-36 Notification of the change of the alarm acknowledgement status Attribute Name domain_name Type string Domain header.fixed_he ader.event_type Description Indicates the name of a managed domain. This parameter shows the version number of the associated IRP information model. Indicates the type of the reported alarm, that is, the notification of the change of the alarm acknowledgement status. The value of this parameter is as follows: AlarmIRPConstDefs::NotificationType :: NOTIFY_FM_ACK_STATE _CHANGED. event_name string header.fixed_he ader Indicates the name of an event and defines communication alarms, internal error-handling alarms, QoS alarms, and equipment alarms. The value of this parameter is that of AlarmIRPConstDefs::AlarmType. e string filterable_data Indicates the MO instances in the alarm notification. That is, this parameter shows the object instances of alarms occurred. Indicates the notification identifier and is used to exclusively identify a notification. Indicates the time when an alarm occurs. Indicates the identifier of the IRPAgent.
type_name
string
long
remainder_of_b ody
b c
TimeBase: :UtcT string
4-34
Issue 03 (2010-12-31)
Attribute Name g
Type short
Description Indicates the possible reasons for an alarm and has more detailed categorizations compared with AlarmType. The value range and information about this parameter are defined in ProbableCause in the IDL.
short
filterable_data
Indicates the severity of an alarm. The following lists the severities of alarms: l INDETERMINATE l CRITICAL l MAJOR l MINOR l WARNING l CLEARED
TimeBase: :UtcT long
filterable_data
Indicates the time when an alarm is acknowledged or unacknowledged. Vendor-customized alarm type 1: Fault alarm
jj
filterable_data
Issue 03 (2010-12-31)
4-35
Attribute Name nn
Type long
Description The maintenance-mode alarm statuses are as follows: l 0: Normal l 1: Creation l 2: Expansion l 3: Upgrade l 4: Commissioning No default value of this attribute is provided. The filterable_data area in alarm messages contains this attribute only after this attribute is activated. By default, the maintenancemode alarm function is inactive. The NMS receives maintenance-mode alarms only after this function is activated. For details about how to activate the maintenance-mode alarm function and the attribute, see Reporting maintenancemode alarms.
string
Indicates the serial number of alarms and is used to be the only identifier for an alarm. Indicates an identifier for a user that acknowledges or unacknowledges an alarm. l The NMS acknowledgement alarms should be acknowledged or unacknowledged by users whose ids are in the range of ack_user_id. l The OMC acknowledgement or unacknowledgement alarms should be performed only by OMC authorized users. l In case of automatic acknowledgement, the authorized user is system.
string
4-36
Issue 03 (2010-12-31)
Attribute Name n
Type short
Description Indicates the current acknowledgement state of an alarm. l The value 1 indicates that the alarm in Acknowledge state. l The value 2 indicates that the alarm in Unacknowledge state. For details, refer to the definition of AlarmIRPConstDefs::AckState.
string
remainder_of_b ody
Indicates the detailed reasons for an alarm. This parameter records the private information of Huawei alarms.
string
remainder_of_b ody
Indicates the detailed location information about an alarm. The information consists of the following items: l NE location l Vendor l NE name l Alarm name l Detailed alarm location information The format of location information is as follows: NeType: NodeB| NeLocation: ShangHai | vendor: Huawei | neName: N91003| alarmName: RF Unit Maintenance Link Failure| alarmLocation: Cabinet No.=1, Subrack No.=4, Slot No.=0, Board type=WRFU| appendInfo:
NOTE
Issue 03 (2010-12-31)
4-37
Notification of Alarm Clearance

When an alarm is cleared, the NMS sends the alarm clearance notification. l Triggering condition The notification of alarm clearance shows that the NMS successfully clears alarms through Notification of Alarm Clearance. The OMC successfully clears alarms. The NEs automatically clear alarms. l Notification format Table 4-37 lists the format of the alarm clearance notification. Table 4-37 Notification of alarm clearance Attribute Name domain_name Type string Domain header.fixed_ header.event_ type Description Indicates the name of a managed domain. This parameter shows the version number of the associated IRP information model. Indicates the type of the reported notification, that is, notification of alarm clearance. The value of this parameter is as follows: AlarmIRPConstDefs::NotificationType :: NOTIFY_FM_CLEARED_AL ARM. event_name string header.fixed_ header Indicates the name of an event and defines communication alarms, internal error-handling alarms, QoS alarms, and equipment alarms. The value of this parameter is that of AlarmIRPConstDefs::AlarmType. e a string long filterable_dat a remainder_of _body Indicates the object instances in the alarm notification. Indicates the notification identifier and is used to exclusively identify a notification. Indicates the time when an alarm is cleared.
Issue 03 (2010-12-31)
type_name
string
header.fixed_ header.event_ type
TimeBase:: UtcT
filterable_dat a
4-38
Attribute Name c g
Type string short
Domain filterable_dat a filterable_dat a
Description Indicates the identifier of the IRPAgent. Indicates the possible reasons for an alarm and has more detailed categorizations compared with AlarmType. The value range and information about this parameter are defined in ProbableCause.
short
filterable_dat a
Indicates the severity of an alarm. The following lists the severities of alarms: l INDETERMINATE l CRITICAL l MAJOR l MINOR l WARNING l CLEARED
jj
long
filterable_dat a
Issue 03 (2010-12-31)
4-39
Attribute Name nn
Type long
Domain filterable_dat a
Description The maintenance-mode alarm statuses are as follows: l 0: Normal l 1: Creation l 2: Expansion l 3: Upgrade l 4: Commissioning No default value of this attribute is provided. The filterable_data area in alarm messages contains this attribute only after this attribute is activated. By default, the maintenancemode alarm function is inactive. The NMS receives maintenancemode alarms only after this function is activated. For details about how to activate the maintenance-mode alarm function and the attribute, see Reporting maintenance-mode alarms.
string
remainder_of _body remainder_of _body
Indicates the serial number of alarms and is used to be the only identifier for an alarm. Indicates an identifier for a user that clears an alarm. l For the NMS, alarms can be cleared by users whose IDs are in the range of clear_user_id. l For the OMC, alarms can be cleared only by OMC authorized users. l In case of automatic alarm clearance, the authorized user is NE.
string
string
remainder_of _body
Indicates the detailed reasons for an alarm. This parameter records the Huawei alarm private information.
4-40
Issue 03 (2010-12-31)
Attribute Name j
Type string
Domain remainder_of _body
Description Indicates the detailed location information about an alarm. The information consists of the following items: l NE location l Vendor l NE name l Alarm name l Detailed alarm location information The format of location information is as follows: NeType: NodeB| NeLocation: ShangHai | vendor: Huawei | neName: N91003| alarmName: RF Unit Maintenance Link Failure| alarmLocation: Cabinet No.=1, Subrack No.=4, Slot No.=0, Board type=WRFU| appendInfo:
NOTE
Notification of Adding Alarm Comment

When the alarm comment is added through the Northbound interface, the notification is sent. l l Trigger condition The NMS successfully adds alarm comment. Notification format Table 4-38 the notification format of adding alarm comment. Table 4-38 Format of adding alarm comment Attribute Name domain_name Type string Domain header.fixed_header. event_type Description Indicates the management domain name. It is the version number of corresponding IRP information model.
Issue 03 (2010-12-31)
4-41
Attribute Name type_name
Type string
Domain header.fixed_header. event_type
Description Indicates the type of reported notification, that is, notification of adding alarm comment. The value is AlarmIRPConstDefs::N otificationType ::. NOTIFY_FM_COMME NT_ADDED. Indicates the event name. Its value is alarm type. It defines notification alarm, internal errorhandling alarm, QoS alarm, and equipment alarm. The value is defined by AlarmIRPConstDefs::Al armType. Indicates the instances of MO that sends the notification, that is, the object instance of alarm. Indicates the time when the notification of adding alarm comment occurs. Indicates the identifier of the managed system (IRPAgent) that generates the notification. Indicates the possible reasons for an alarm and has more detailed categorizations compared with alarmType. The value range and information about this parameter are defined in ProbableCause of IDL.
event_name
string
header.fixed_header
string
filterable_data
filterable_data
filterable_data
short
filterable_data
4-42
Issue 03 (2010-12-31)
Attribute Name h
Type short
Description Indicates the following alarm severity: l INDETERMINATE l CRITICAL l MAJOR l MINOR l WARNING l CLEARED
jj
long
filterable_data
nn
long
filterable_data
The maintenance-mode alarm statuses are as follows: l 0: Normal l 1: Creation l 2: Expansion l 3: Upgrade l 4: Commissioning No default value of this attribute is provided. The filterable_data area in alarm messages contains this attribute only after this attribute is activated. By default, the maintenance-mode alarm function is inactive. The NMS receives maintenancemode alarms only after this function is activated. For details about how to activate the maintenance-mode alarm function and the attribute, see Reporting maintenance-mode alarms.
Issue 03 (2010-12-31)
4-43
Attribute Name a
Type long
Description Indicates the notification identifier and is used to exclusively identify a notification. Indicates the serial number of alarms and is used to be the only identifier for an alarm. Indicates the added alarm comment information AlarmIRPConstDefs::C ommentSet.
string
remainder_of_body
sequence
remainder_of_body
NOTE
The value type of remainder_of_body domain is AlarmIRPConstDefs::AttributeSetType.
Notification of Alarm Changes

The alarm notification is delivered when the NE alarm changes. l l Trigger condition The NE alarm changes. Notification format Table 4-39 describes the notification format of alarm changes. Table 4-39 Notification of alarm changes Attribute Name domain_name Type string Domain header.fixed_header. event_type Description Indicates the management domain name. It is the version number of corresponding IRP information model. Indicates the type of the reported notification, that is, the notification of new alarm. The value is AlarmIRPConstDefs::N otificationType ::. NOTIFY_FM_CHANG ED_ALARM.
type_name
string
header.fixed_header. event_type
4-44
Issue 03 (2010-12-31)
Attribute Name event_name
Type string
Domain header.fixed_header
Description Indicates the event name. Its value is alarm type. It defines notification alarm, internal errorhandling alarm, QoS alarm, and equipment alarm. The value is defined by AlarmIRPConstDefs::Al armType. Indicates the instances of MO that sends the notification, that is, the object instance of alarm. Indicates the time when alarm changes. Indicates the identifier of the managed system (IRPAgent) that generates the notification. Indicates the possible reasons for an alarm and has more detailed categorizations compared with alarmType. The value range and information about this parameter are defined in ProbableCause of IDL. Indicates the following alarm severity: l INDETERMINATE l CRITICAL l MAJOR l MINOR l WARNING l CLEARED
string
filterable_data
b c
short
filterable_data
short
filterable_data
Issue 03 (2010-12-31)
4-45
Attribute Name jj
Type long
Description Vendor-customized alarm type 1: Fault alarm
nn
long
filterable_data
The maintenance-mode alarm statuses are as follows: l 0: Normal l 1: Creation l 2: Expansion l 3: Upgrade l 4: Commissioning No default value of this attribute is provided. The filterable_data area in alarm messages contains this attribute only after this attribute is activated. By default, the maintenance-mode alarm function is inactive. The NMS receives maintenancemode alarms only after this function is activated. For details about how to activate the maintenance-mode alarm function and the attribute, see Reporting maintenance-mode alarms.
long
remainder_of_body
Indicates the notification identifier and is used to exclusively identify a notification. Indicates the serial number of alarms and is used to be the only identifier for an alarm. Indicates the detailed reasons for an alarm. This field records the Huawei alarm private information.
string
remainder_of_body
string
remainder_of_body
4-46
Issue 03 (2010-12-31)
Attribute Name j
Type string
Description Indicates the detailed location information about an alarm.The information consists of NE location, vendor, NE name, alarm name, and detailed alarm location information. The format is as follows: NeType: NodeB| NeLocation: ShangHai | vendor: Huawei | neName: N91003| alarmName: RF Unit Maintenance Link Failure| alarmLocation: Cabinet No.=1, Subrack No.=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 Alarms

In a multi-mode base station (MBTS), common alarms can be generated on certain common devices. You can differentiate normal mode alarms from common alarms by viewing alarm information. 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 > Common Alarm Indentifier. You can then determine whether the generated alarms are normal mode alarms or common alarms by viewing values in the Common Alarm Identifier column. The value of Common Alarm Identifier can be NA, GSM, UMTS, or LTE, where NA indicates a normal mode alarm. A common alarm can be reported repeatedly to the NMS through northbound interfaces. To avoid this problem, you can determine the method to be used for reporting common alarms through 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 Identifier values 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
# SettingTool -cmd setparam -path "/imap/ifms/mbtsfilter" -value 1 If the directory of the configuration item, that is, /imap/ifms/mbtsfilter, is set to 1, only the common alarm whose Common Alarm Identifier value is GSM is to be reported. l l Run the following command to restart FaultService: # svc_adm -cmd restartsvc FaultService Run the following command to check whether FaultService is started: # svc_adm -cmd status | grep FaultService If 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 0 Meaning The common alarms whose Common Alarm Identifier values are GSM, UMTS, or LTE are to be reported through the northbound interfaces. In an MBTS GU, two common alarms with the same information are to be reported. One alarm is generated by the MBTS GSM and the other is generated by the MBTS UMTS. All the information contained in the alarms is the same except that they have different network serial numbers (SNs). 1 Only the common alarm whose Common Alarm Identifier value is GSM is to be reported through the northbound interfaces. In an MBTS GU, only the common alarm whose Common Alarm Identifier value is GSM is to be reported. 2 Only the common alarm whose Common Alarm Identifier value is UMTS 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 are GSM 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.
4-48
Issue 03 (2010-12-31)
Value 4
Meaning Only the common alarm whose Common Alarm Identifier value is LTE 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.
Only the common alarms whose Common Alarm Identifier values are GSM 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.
Only the common alarms whose Common Alarm Identifier values are UMTS 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.
The common alarms whose Common Alarm Identifier values are GSM, UMTS, or LTE are not to be reported through the northbound interfaces. No common alarm is to be reported, regardless of the type of the MBTS.
Issue 03 (2010-12-31)
4-49
5 Preparations for Interconnection Commissioning of the Northbound CORBA Interface
Commissioning of the Northbound CORBA Interface

About This Chapter
Before interconnecting the NMS to the M2000, you need to make certain preparations. If you complete the preparations, you can infer that the northbound CORBA interface meets the conditions for the interconnection. 5.1 Negotiating the Interconnection Parameters of the Northbound CORBA Interface Before connecting the M2000 to the NMS, make sure that the NMS is licensed to use the northbound CORBA interface and has the negotiated interconnection parameters. 5.2 Obtaining the IDL File This describes how to obtain the IDL file. The NMS interconnects to the M2000 by invoking the IDL file. Before the interconnection, the IDL file of the M2000 needs to be provided to the NMS. 5.3 Checking the CORBA Version Before interconnecting the M2000 to the NMS, make sure that the northbound CORBA version on the M2000 server is valid. 5.4 Obtaining the Reference of the Entry Point Object This describes how to obtain the reference of the entry point object, that is, the1.ior file. The reference of the entry point object is the prerequisite for the M2000 to invoke the northbound CORBA interface. 5.5 Modifying the hosts File of the Server This section describes how to enable the NMS host and the M2000 server to communicate with each other through their host names. After you modify the hosts files of the M2000 server and the NMS host, they communicate with each other, subscribe to notifications, and receive notifications by using their host names. 5.6 Using the CORBA Interface This section describes how to use the northbound CORBA interface when the M2000 system adopts different networking modes.
Preparations for Interconnection
5.1 Negotiating the Interconnection Parameters of the Northbound CORBA Interface

Before connecting the M2000 to the NMS, make sure that the NMS is licensed to use the northbound CORBA interface and has the negotiated interconnection parameters.
Checking License
Before the interconnection, make sure that the NMS has the required license. Do as follows to check whether the NMS has the required license. 1. 2. 3. Log in to the M2000 client. Choose License > OMC License Management > License Information. The License Information window is displayed. 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 use the CORBA interface.
Negotiating the Interconnection Parameters

The negotiated parameters include the parameters that the M2000 should provide to the NMS and the parameters that the NMS should provide to the M2000. For details, see Table 5-1. Table 5-1 Negotiated parameters Parameter Type Parameters provided to the NMS by the M2000 Parameter FTP user name Parameter Value The FTP user can be any user that has the permission to read the 1.ior file. The actual password of the FTP user. The value of this parameter depends on the actual condition. Description For example, ftpuser.
FTP password Configuration model
For example, ftpuser. If the RNC is used on site, the configuration model of this NE needs to be provided for the NMS. The M2000 provides the IP address and hostname of the server for the interconnection.
IP address and hostname of the M2000 server
The value of this parameter depends on the actual condition.
5-2
Issue 03 (2010-12-31)
Parameter Type Parameters provided to the M2000 by the NMS
Parameter IP address and hostname of the NMS
Parameter Value The value of this parameter depends on the actual condition.
Description The NMS provides its IP address and hostname for the interconnection.
5.2 Obtaining the IDL File

This describes how to obtain the IDL file. The NMS interconnects to the M2000 by invoking the IDL file. Before the interconnection, the IDL file of the M2000 needs to be provided to the NMS. After the package of release documents is decompressed, the path of the IDL file is as follows ENG\07.Northbound File\Corba interface\<Installed Corba version>\IDL.
CAUTION
The northbound CORBA interface of the M2000 supports only the IDL file delivered with the version. To use the other IDL files, you need to consult Huawei R&D engineers.
5.3 Checking the CORBA Version

Before interconnecting the M2000 to the NMS, make sure that the northbound CORBA version on the M2000 server is valid.
Prerequisite
Log in to the M2000 server.
Procedure
Step 1 Run the following commands to check the CORBA version. # cd /opt/OMC # . ./svc_profile.sh # 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 Query and Change Northbound CORBA Interface.

NOTE
The iManagerM2000V200R010C00 Guide to Query and Change Northbound CORBA Interface document is decompressed to the doc\ENG\07.Northbound File\Corba interface directory. In addition, you can download the document from the website:http://support.huawei.com.
----End
5.4 Obtaining the Reference of the Entry Point Object

This describes how to obtain the reference of the entry point object, that is, the1.ior file. The reference of the entry point object is the prerequisite for the M2000 to invoke the northbound CORBA interface.
Prerequisite
Log in to the M2000 server as user root or omcuser.
Context
For more information about the reference of the entry point object, see 2.1 Entry Point of the CORBA 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 written to the /opt/OMC/var/itf_n/EPIRP/1.ior file.
# cd /opt/OMC # . ./svc_profile.sh # cd var/itf_n/EPIRP # ls Check whether the 1.ior file exists. If the file does not exist, see 6 Troubleshooting the Northbound CORBA Interface. Step 2 The NMS obtains the 1.ior file from the /opt/OMC/var/itf_n/EPIRP directory on the M2000 server 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.
CAUTION
When the FTP mode is used, the 1.ior file must be transferred in ASCII mode. ----End
5.5 Modifying the hosts File of the Server

This section describes how to enable the NMS host and the M2000 server to communicate with each other through their host names. After you modify the hosts files of the M2000 server and the NMS host, they communicate with each other, subscribe to notifications, and receive notifications 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 and nms_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 hosts file 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 and hostname of the M2000 server to the hosts file saved in the system32\drivers\etc\hosts directory through the text editor. l If the NMS uses the UNIX operating system, log in to the system as user root. Then, add the IP 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 and M2000_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 Interface

This section describes how to use the northbound CORBA interface when the M2000 system adopts different networking modes. The M2000 system can adopt the following networking modes: single-server system, HA system, remote HA system, SLS system, and emergency system. For details about how to use the northbound CORBA interface in different networking modes, see Table 5-2.
Table 5-2 Usage of the CORBA interface M2000 System Type Single-server system HA system Remote HA system Usage Reference See this document. See this document. See this document and M2000 Solution Description (Remote HA System) provided in the product documentation. See this document. See this document and M2000 Semergency System User Guide provided in the product documentation.
SLS system Emergency system
5-6
Issue 03 (2010-12-31)
6 Troubleshooting the Northbound CORBA Interface
Troubleshooting the Northbound CORBA Interface
About This Chapter

The NMS interconnects with the M2000 through the northbound CORBA interface. If a fault occurs when the NMS is obtaining the data, refer to relevant troubleshooting methods in this chapter. 6.1 Common Troubleshooting and Information Collection (CORBA Interface) If a fault occurs when the NMS attempts to obtain data through the northbound CORBA interface, rectify the fault according to common troubleshooting methods. If it is not possible to rectify the fault by using common troubleshooting methods, collect the fault information and contact Huawei engineers for assistance. 6.2 Troubleshooting Failure to Obtain Data This section describes how to troubleshoot the issue when data obtaining fails due to the following causes: 1. Certain key attribute of the MO is null; 2. The DN is repeated; 3. The MO data conversion fails; 4. The service is not started; 5. NEs are disconnected; 6. Free disk space is unavailable on the M2000 server. 6.3 Operations Required When the IP Address or Hostname of the M2000 Server Changes This describes the operations that should be performed for the M2000 and the NMS when the IP address or hostname of the M2000 server is changed.
Issue 03 (2010-12-31)
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 CORBA interface, rectify the fault according to common troubleshooting methods. If it is not possible to rectify the fault by using common troubleshooting methods, collect the fault information and contact Huawei engineers for assistance.
Troubleshooting
For the methods of handling common faults that may occur during the process for obtaining relevant data for the NMS, see Table 6-1. Table 6-1 Troubleshooting Common Fault Obtaining data failed. The IP address of the M2000 server is changed. Troubleshooting Method See 6.2 Troubleshooting Failure to Obtain Data. See 6.3 Operations Required When the IP Address or Hostname of the M2000 Server Changes.
Information Collection
If a fault not included in Table 6-1 occurs when the NMS is obtaining the data, you need to collect relevant information for fault localization. Table 6-2 lists the information that needs to be collected and the collection methods. Table 6-2 Information to be collected Related Information Operation information Version information IP address information Log information Description Records the operations performed before a fault occurs and the troubleshooting measures taken later. Indicates the information about the M2000 version, NE mediation version, and NE version. Indicates the IP address of the M2000 server. You can obtain logs from the /opt/OMC/var/logs directory on the M2000 server. The .trace file for IRPService is iMAP.irp_agent.trace.
6.2 Troubleshooting Failure to Obtain Data

This section describes how to troubleshoot the issue when data obtaining fails due to the following causes: 1. Certain key attribute of the MO is null; 2. The DN is repeated; 3. The MO
data conversion fails; 4. The service is not started; 5. NEs are disconnected; 6. Free disk space is 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 l l l l l Certain key attribute of the MO is null. The DN is repeated. Conversion of the MO data fails. IRPService is not started. NEs are disconnected. 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. The northbound CORBA interface fails to obtain the configuration data. As a result, the NMS cannot obtain 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 Certain key attribute of the MO is null. Description In the northbound CORBA interface, a DN is used to uniquely identify an MO. For example, DC=www.huawei.com, SubNetwork=1, ManagedElement=37, and SignallingPoint=0. This DN indicates the MO object of a signaling point. SignallingPoint is the key attribute of the MO. If the value of SignallingPoint is NULL, data of the MO cannot be obtained. Localization Log in to the M2000 server. Check the iMAP.irp_agent.trace file under the /opt/OMC/var/ logs directory. If the file includes the following information, you can infer that the key attribute signallingPointId is null.
T-ER:TagID 0001:08-02 11:20:58.118: (25382|59) Svr.GFace: attribute signallingPointId not exist!
Issue 03 (2010-12-31)
6-3
Cause The DN is repeated.
Description In the northbound CORBA interface, a DN is used to uniquely identify an MO. If multiple MOs obtained share a DN, the DN cannot uniquely identify an MO. In this case, the interface indicates the exception.
Localization Log in to the M2000 server. Check the iMAP.irp_agent.trace file under the /opt/OMC/var/ logs directory. If the file includes the following information, you can infer that The DN is repeated.
DuplicateRdnInfo , keyValue[220_0]
Conversion of the MO data fails.
The northbound CORBA interface needs to convert the type of data (such as int, string, long, unsigned int, and unsigned long) obtained from the M2000 to the specified type of data (such as enum, string, sequence, struct, long, and their combinations). Conversion of the data type may fail. In this case, the northbound CORBA interface indicates the exception.
Log in to the M2000 server. Check the iMAP.irp_agent.trace file under the /opt/OMC/var/ logs directory. If the file includes the following information, you can infer that an exception related to NetIdListType occurs during the conversion of 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 Unactivation

Check whether IRPService is started. If the service is not started, run the relevant commands to start it. 1. 2. Log in to the M2000 server as user root or omcuser. Check the status of IRPService. # cd /opt/OMC # . ./svc_profile.sh # svc_adm -cmd status If 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 IRPService Check whether the 1.ior file exists after the service is started. If the file exists, you can infer that the service process is successfully started. If the file does not exist, you can infer that the service process fails to be started.
6-4
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 of the Entry Point Object.
Handling NE Disconnection Faults

1. 2. 3. On the M2000 client, choose Topology > Main Topology. In the Main Topology window, right-click the disconnected NE and then choose Reconnect NE. Verify the network and rectify the network fault. 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 Server

Clear the disk space on the M2000 server.
CAUTION
Confirm the files can be deleted before clearing the disk space. Deleting a file by mistake can result in incorrect system operation. You are advised to clear the disk space by referring to the Administrator Guide of the corresponding M2000 networking mode.
Solution
Contact Huawei technical support.
6.3 Operations Required When the IP Address or Hostname of the M2000 Server Changes
This describes the operations that should be performed for the M2000 and the NMS when the IP address or hostname of the M2000 server is changed.
Question
The NMS obtains common data, alarm data, and configuration data through obtaining the 1.ior file. After the M2000 is interconnected to the NMS, if the IP address or hostname of the M2000 server needs to be changed, what operations should be performed for the M2000 and the NMS?
Answer
If the IP address or hostname of the M2000 server needs to be changed, settings of the northbound CORBA interface need not be changed. In this case, the interface needs to instruct the NMS to obtain 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 service process. After the northbound service process is restarted, a new 1.ior file is generated. The new 1.ior file contains different information from the original 1.ior file. In this case, the northbound
interface needs to instruct the NMS to obtain the new 1.ior file. Otherwise, the NMS cannot invoke the CORBA interface. The 1.ior file is saved in the /opt/OMC/var/itf_n/EPIRP/ directory. For details on how to obtain the 1.ior file, see 5.4 Obtaining the Reference of the Entry Point Object. For details on how to modify the hosts file of the NMS server, see 5.5 Modifying the hosts File of the Server.
6-6
Issue 03 (2010-12-31)
7 Appendix
7
About This Chapter
A collection of supplementary material. 7.2 Description of DN String A DN string is used to represent each object.
Appendix
7.1 Description of filter This describes the supporting fields, syntax description, and conventions of the filter. The filters in the get_alarm_list and get_alarm_count are also described.
7.3 Description of Alarm Location Detailed Information Analyze and locate alarms through Alarm Location Detailed Information.
Issue 03 (2010-12-31)
7-1
7 Appendix
7.1 Description of filter

This describes the supporting fields, syntax description, and conventions of the filter. The filters in the get_alarm_list and get_alarm_count are also described. 7.1.1 Notification filter Description This describes the supporting field, syntax description, and conventions of the filter. 7.1.2 Description of filter in get_alarm_list This describes the supporting fields, syntax description, and conventions of the get_alarm_list. 7.1.3 Description of filter in get_alarm_count This describes the supporting field of the get_alarm_count.
7.1.1 Notification filter Description

This describes the supporting field, syntax description, and conventions of the filter.
Fields Supporting filter

l l l type_name event_name 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-2
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> := | l | m | n | w | x | y | H | I | J | S | T | U a | | | | | o z K V b | | | | | p A L W c | | | | | q B M X d | | | | | r C N Y e | | | | | s D O Z f | | | | t E P g | | | | u F Q h | | | | i | j | k v G R
7 Appendix
<Digit> := 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 <Other> := <Sp> | ~ | ! | @ | # | $ | % | ^ | & | * | ( | ) | - | _ | = | + | [ | { | } | ] | ; | : | " | \ | | | < | . | > | / | ? | , <Sp> := " "
Convention
l <Identifier> supports the following fields: type_name event_name e
NOTE
These field names correspond to associated fields in the notification.
The symbol $ must be added before <Identifier>. If $ is not added, filter can pass the syntax check. The notification, however, cannot be received.
Instance
$type_name == 'x1'
Issue 03 (2010-12-31)
7-3
7 Appendix
7.1.2 Description of filter in get_alarm_list

This describes the supporting fields, syntax description, and conventions of the get_alarm_list.
Fields Supporting filter

The following fields in get_alarm_list support filter: l l l l type_name event_name b h
Syntax Description
l l l l l l l l l <SingleExpr> := "$"<Identifier><separator><ExprOp> <separator><Expr> <OrExpr> ::= <SingleExpr><separator>"or"<separator><SingleExpr> <AndExpr> : "("<OrExpr>")"<separator>"and"<separator>"("<OrExpr>")" <separator>::= " " <ExprOp>::= "==" | "<=" | ">=" <Expr>:= <StrExpr> | <NumExpr> <StrExpr> := "'" { <Char> }* "'" <NumExpr>:= <Integer> <Identifier>::= "type_name" | "event_name" | "b" | "h"
Convention
The conventions are as follows: l <Identifier> supports the following fields: type_name event_name b h l l l l l l In <SingleExpr> preceding and following the keyword "or", <Identifier> must be the same. In <SingleExpr> preceding and following the keyword "and", <Identifier> must be different except that for the field name b. <Integer> is data of a decimal integer. The field names type_name, event_name, and h support only the operator "==". The operators that the field name b supports are only ">=" and "<=". The field name type_name supports the following values: x1 x3 x5 l
7-4
The field name event_name supports the following values:

7 Appendix
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 defined in time of TimeBase::UtcT.
Instance
l l l l $type_name == 'x1' $type_name == 'x1' or $type_name == 'x2' ($type_name == 'x1' or $type_name == 'x2') and ($event_name == 'x1') and ($b == 133459954540000000) ($b >= 133459954540000000) and ($b <= 133459955540000000)
7.1.3 Description of filter in get_alarm_count

This describes the supporting field of the get_alarm_count.
Supporting Field and Format

l l The supporting field is e. 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 String

A DN string is used to represent each object. Figure 7-1 shows the expression of a DN string.
Issue 03 (2010-12-31)
7-5
7 Appendix
Figure 7-1 DN string
Figure 7-1 shows the RDN of each object. Each object shown Figure 7-1 is numbered and the DN of each object can be obtained. The DN of a specific object is follows: l l l l DN for Object 5: subnetwork=subnetwork_A, managedElement= ME_1, mscFunction=MSCF_1 DN for Object 9: subnetwork= subnetwork_A, managedElement=ME_2, rncFunction=RNCF_1, utranCell=UCL_1 DN for Object 11: subnetwork=subnetwork_A, managedElement= ME_1, mscFunction=MSCF_1, signallingPoint=SP_1, signallingLinkSetTP=SLSTP_2 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 Information

Analyze and locate alarms through Alarm Location Detailed Information.
7 Appendix
The Alarm Location Detailed Information is shown in the field j in the notification. The Alarm Location Detailed Information contains the following items: l l l l l l NeType NeLocation Vendor neName Alarm name Alarm location
The format for the Alarm Location Detailed Information is as follows: NeType: NodeB| NeLocation: ShangHai | vendor: Huawei | neName: N91003| alarmName: RF Unit Maintenance Link Failure| alarmLocation: Cabinet No.=1, Subrack No.=4, Slot No.=0, Board type=WRFU| appendInfo: where, l l l l l l NeType: indicates the type of the NE that has alarms. NeLocation: indicates the location of the NE in which the alarm occurs. vendor: indicates the manufacture of alarm devices. neName: indicates the name of the NE where the alarm occurs. alarmName: indicates the name of an alarm. alarmLocation: indicates the location information about an alarm.
NOTE
l l l
The fields NeType give the information about the type of the NE that has alarms. The fields NeLocation, Vendor, and neName give the information about the NE where the alarm occurs. The information can be also traced on the OMC. The fields alarmName and alarmLocation are used to locate alarms.
Thus, the NMS can analyze and locate alarms through Alarm Location Detailed Information.
Issue 03 (2010-12-31)
7-7

M2000 Northbound CORBA Interface Developer Guide

Diunggah oleh

Informasi Dokumen

Deskripsi Asli:

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

M2000 Northbound CORBA Interface Developer Guide

Diunggah oleh

Hak Cipta:

Format Tersedia

M2000 V200R010

Northbound CORBA Interface Developer Guide

HUAWEI TECHNOLOGIES CO., LTD.

Trademarks and Permissions

Huawei Technologies Co., Ltd.

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.