IBM Support

Generic 3GPP probe keep starting the Resync

Technical Blog Post


Abstract

Generic 3GPP probe keep starting the Resync

Body

Issue:

Probe keep resynchronizing causing high number of duplicate events and wasting resource.

Problem:

Alarm IRP 3GPP TS 32.111 notification category define x6 notification type as NOTIFY_FM_ALARM_LIST_REBUILT notification. This notification type will trigger resynch on probe.

However other notification categories also have x6 notification type and the bad part is they were defined for different notification. Example:-

  1. Kernel CM IRP 3GPP TS 32.663 define x6 notification type as MO created notification.
  2. Bulk CM IRP 3GPP TS 32.613 define x6 notification type as ACTIVATION_PARTLY_REALISED notification.

The probe is design only to handle Fault Management (Alarm IRP). Thus, when the target system notification service hosting multiple notification categories (i.e. Alarm IRP, Kernel CM IRP and Bulk CM IRP), it will trigger false resync when the x6 notification come from Kernel CM IRP and Bulk CM IRP notification categories.

Within probe log, user can see “Received a NOTIFY_FM_ALARM_LIST_REBUILT Event” debug message prior probe start resynch.

Further check will confirm the x6 notification type is coming from which notification type. Example below shows that the x6 notification type is coming from Kernel CM IRP which is a normal MO created notification. This notification should not trigger resynch.

2012-10-09T12:04:49: Debug: D-UNK-000-000: [Event Processor] domain_name: 32.663 V6.3
2012-10-09T12:04:49: Debug: D-UNK-000-000: [Event Processor] EVENT_TYPE: x6
2012-10-09T12:04:49: Debug: D-UNK-000-000: [Event Processor] EVENT_NAME: ""

Solution:

Probe does not design to handle other notification categories than Alarm IRP 3GPP TS 32.111. To filter out other notification categories, user can use NotificationCategories property.

The notification category identifier might be different between deployments base on EMS configuration. To configure the NotificationCategories property, follow these steps:-

1) Run probe once without configuring the NotificationCategories. The probe will connect to notification service on EMS and list down all the hosted notification categories as below:-

2012-10-01T15:54:36: Debug: D-JPR-000-000: NetcoolIRPManager: Supported Notification IRP Category : 32.613 V6.2
2012-10-01T15:54:36: Debug: D-JPR-000-000: NetcoolIRPManager: Supported Notification IRP Category : 32.663 V6.3
2012-10-01T15:54:36: Debug: D-JPR-000-000: NetcoolIRPManager: Supported Notification IRP Category : 32.363 V6.1
2012-10-01T15:54:36: Debug: D-JPR-000-000: NetcoolIRPManager: Supported Notification IRP Category : 32.353 V6.0
2012-10-01T15:54:36: Debug: D-JPR-000-000: NetcoolIRPManager: Supported Notification IRP Category : 32.343 V6.2
2012-10-01T15:54:36: Debug: D-JPR-000-000: NetcoolIRPManager: Supported Notification IRP Category : 32.111 V6.2
2012-10-01T15:54:36: Debug: D-JPR-000-000: NetcoolIRPManager: Supported Notification IRP Category : 32.413 V6.4

2) Configure the notification category identifier for Alarm IRP to NotificationCategories property and restart the probe. For above sample, the value for NotificationCategories property is “32.111 V6.2”.

Note:

There is issue identified for Nokia NetAct OSS 5.4 which it does not honor the selected notification categories. This was fixed in PCD5039 released on 21.11.2012 to deploy on top of OSS5.4 CD2 P8.

 

Abbreviation:

 

3GPP: 3rd Generation Partnership Project
CM: Configuration Management
EMS: Event Management System
FM: Fault Management
IRP: Integration Reference Point
MO: Managed Object
OSS: Operation Support System

[{"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Product":{"code":"","label":""},"Component":"","Platform":[{"code":"","label":""}],"Version":"","Edition":"","Line of Business":{"code":"","label":""}}]

UID

ibm11082055