32.106-23GPPConfiguration Management (CM)Part 2: Notification Integration Reference Point (IRP): Information Service (IS)Telecommunication managementTS

6.1 Interfaces

Figure 3 illustrates the operations and notifications defined as interfaces implemented and used by IRPAgent and IRPManager. Parameters and return status are not indicated. Interface in IRP Information Service is identical to concept conveyed by stereotype <<interface>> of UML.

One interface, called NotificationIRPOperations, is defined. This interface defines operations implemented by IRPAgent and used (or called by) IRPManager.

Figure 3: Protocol Independent Interface

6.1.1 NotificationIRPOperation Interface

6.1.1.1 Operation subscribe (M)

IRPManager invokes this operation to establish subscription to receive network events via notifications, under the filter constraint specified in this operation. How IRPManager discovers the IRPAgent’s address or reference (so that IRPManager can invoke this operation) is outside the scope of the present document.

Table 1: Parameters of subscribe

6.1.1.2 Operation unsubscribe (M)

The IRPManager invokes this operation to cancel subscriptions. The IRPManager can cancel one subscription by providing the corresponding subscriptionId or all subscriptions by leaving the subscriptionId parameter absent.

Table 2: Parameters for unsubscribe

6.1.1.3 Operation getNotificationIRPVersion (M)

IRPManager wishes to find out the Notification IRP SS versions supported by IRPAgent. IRPAgent shall respond with a list of Notification IRP SS version(s).

Table 3: Parameters for getNotificationIRPVersion

6.1.1.4 Operation getSubscriptionStatus (O)

IRPManager invokes this operation to query the subscription status of a particular subscription.

IRPManager can get similar service by invoking subscribe operation. However, the following differences are noted.

• Operation subscribe uses managerReference and this operation uses subscriptionId.
• If IRPAgent has lost IRPManager’s reference, IRPManager use of subscribe operation may result in establishment of another subscription. Using this operation does not establish another subscription.
• IRPManager can use getSubscriptionStatus operation to know about the filter constraint in effect, the state of subscription (i.e., if subscription is suspended/inactive or resumed/active), the timeTick value that may be set at subscribe invocation time and the notificationCategory currently in used in the subscription.

Table 4: Parameters for getSubscriptionStatus

6.1.1.5 Operation getSubscriptionIds (O)

IRPManager invokes this operation to get the values of all still valid subscriptionIds assigned by IRPAgent as result of previously subscribe operations performed by this IRPManager.

Table 5: Parameters for getSubscriptionIds

6.1.1.6 Operation changeSubscriptionFilter (O)

IRPManager invokes this operation to replace the present filter constraint with a new one.

Table 6: Parameters for changeSubscriptionFilter

6.1.1.7 Operation suspendSubscription (O)

IRPManager invokes this operation to request IRPAgent to stop emission of notifications. IRPAgent may lose notification(s) if subscription is suspended.

Table 7: Parameters for suspendSubscription

6.1.1.8 Operation resumeSubscription (O)

IRPManager invokes this operation to request IRPAgent to resume emission of notifications. If the Subscription State is “not-suspended”, IRPAgent shall return status successful and ignore this invocation. If Subscription State is “suspended”, IRPAgent shall return status successful, change the Subscription State to “not-suspended” and resume emission of notifications.

Table 8: Parameters for resumeSubscription

6.1.1.9 Operation getNotificationCategories (O)

IRPManager invokes this operation to query the categories of notification supported by IRPAgent. IRPManager does not need to be in subscription to invoke this operation.

Table 9: Parameters for getNotificationCategories

6.1.2 NotificationIRPNotification Interface

6.1.2.1 Notification notify

IRPAgent notifies the subscribed IRPManager that an event has occurred and that the event has satisfies the filter constraints used for this subscription. One event example is the notification defined in Alarm IRP: IS (3GPP TS 32.111‑2 [1]).

The present document does not further specify this notify. Other IRPs using the Notification IRP, such as Alarm IRP: IS (3GPP TS 32.111‑2 [1]), shall specify this notify, in particular, the specific parameters carried in notification, for use in their context.

The present document shall specify, in subclause 6.1.2.2, attributes commonly carried in parameters of all notifications.

6.1.2.2 Notification Attributes

Information about network events is carried in notification containing parameters of multiple attributes. This IRP specifies attributes that are commonly found in notifications defined by other IRPs. Collectively, they are called Notification Header. Other IRPs using the Notification IRP, such as Alarm IRP: IS (3GPP TS 32.111‑2 [1]), shall specify the attributes used in the notification including:

• Identification and qualification of notification Header attributes for their use;
• Specification and qualification of other attributes relevant for their use.

6.1.2.2.1 managedObjectClass (M)

This parameter specifies the class of the Managed Object (MO) in which the network event occurred. This attribute is filterable.

6.1.2.2.2 managedObjectInstance (M)

This parameter specifies the instance of the MO in which the network event occurred. This attribute is filterable.

6.1.2.2.3 notificationId (O)

This parameter provides an identifier for the notification, which may be carried in the correlatedNotifications parameter (see below) of future notifications. Attribute notificationId shall be chosen to be unique across all notifications of a particular managed object throughout the time that correlation is significant.

It uniquely identifies this notification from other notifications generated by the subject MO.

If IRPManager receives notifications from one IRPAgent, IRPManager shall use notificationId and managedObjectInstance to uniquely identify all received notifications.

If IRPManager receives notifications from multiple IRPAgents and notifications of each MO are reported at most through one IRPAgent, IRPManager shall use notificationId and managedObjectInstance to uniquely identify all received notifications.

If IRPManager receives notifications from multiple IRPAgents and notifications of one or more MOs are reported through two or more IRPAgents, IRPManager shall use notificationId, together with managedObjectInstance and the identity of IRPAgent, to uniquely identify all received notifications. Attribute systemDN, if present, carries IRPAgent’s identify. If systemDN is absent, IRPManager needs other means, which are outside the scope of this IRP, to determine the identity of IRPAgent.

If and when the value of this can be re-used is specified in SSs.

This attribute is filterable.

6.1.2.2.4 eventTime (M)

It indicates the event occurrence time. The semantics of Generalised Time specified by ITU-T shall be used here.

This attribute is filterable.

6.1.2.2.5 systemDN (C)

It carries the Distinguished Name (DN) of IRPAgent that detects the network event and generates the notification. See 3GPP TS 32.106-8 [4] for name convention regarding DN.

This attribute is filterable.

6.1.2.2.6 eventType (M)

It carries identification of the type of event reported by the notification. Allowed event types are ITU-T TMN defined event types. Examples of ITU-T TMN event types are:

• Object Creation (ITU-T Recommendation X.730 [10])
• Object Deletion (ITU-T Recommendation X.730 [10])
• Attribute Value Change (ITU-T Recommendation X.731 [11])
• State Change (ITU-T Recommendation X.731 [11])
• Communications Alarm (ITU-T Recommendation X.733 [13])
• Processing Error Alarm (ITU-T Recommendation X.733 [13])
• Environmental Alarm (ITU-T Recommendation X.733 [13])
• Quality of Service Alarm (ITU-T Recommendation X.733 [13])
• Equipment Alarm (ITU-T Recommendation X.733 [13])
• Integrity Violation (ITU-T Recommendation X.736 [14])
• Security Violation (ITU-T Recommendation X.736 [14])
• Time Domain Violation (ITU-T Recommendation X.736 [14])
• Operational Violation (ITU-T Recommendation X.736 [14])
• Physical Violation (ITU-T Recommendation X.736 [14])

Each IRP document using the Notification IRP, such as Alarm IRP: IS (3GPP TS 32.111-2 [1]), identifies which eventType shall be used for that IRP.

This attribute is filterable.

6.1.2.2.7 extendedEventType (M)

IRPAgent, in certain situations, may generate notifications of types whose semantics are extended beyond those defined by ITU-T event types. Examples are:

• Indicate alarm acknowledgement state changes
• Indicate Alarm List of AlarmIRPAgent has rebuilt successfully.

This attribute carries the required extension.

Each IRP document using the Notification IRP, such as Alarm IRP: IS (3GPP TS 32.111-2 [1]), defines the extended event types required.

This attribute is filterable.

6.1.3 Behaviour

6.1.3.1 IRPAgent supports multiple subscriptions with one IRPManager

An IRPManager can have multiple managerReferences. IRPManager can invoke subscribe operations using different managerReferences resulting in multiple subscriptions. As far as IRPAgent is concerned, the IRPAgent is sending alarms to multiple "places".

If IRPManager invokes multiple subscriptions with identical managerReference and notificationCategory combination, all but one subscription shall fail with exception indicating that the IRPManager is already in subscription.

If IRPManager has established subscription by invoking subscribe with notificationCategory parameter absent, subsequent subscribe, either with notificationCatgory absent or present, using the same managerReference, shall fail. IRPAgent shall throw exception indicating that the IRPManager is already in subscription.

IRPManager controls the filter constraint via subscribe and changeSubscriptionFilter operations.

6.1.3.2 Support of packing multiple notifications

It should be possible to pack multiple notifications together for sending to NM. This provides more efficient use of data communication resources. In order to pack multiple notifications, an EM/NE configurable parameter defines the maximum number of notifications to be packed together. Additionally an EM/NE configurable parameter defines the maximum time delay before the notifications have to be sent.

6.1.3.3 IRPAgent supports emission of multiple Notification categories

IRPAgent supporting this IRP may emit multiple categories of notifications. For example, it may emit notification defined in Alarm IRP 3GPP TS 32.111-2 [1]. IRPAgent supports mechanism that IRPManager can use to determine the categories of notifications supported by IRPAgent. IRPAgent also supports mechanism that IRPManager can use to specify the categories of notifications IRPAgent should emit to IRPManager during subscription.

6.1.3.4 Subscription list loss

IRPAgent can lose the list of managerReference that identifies current IRPManagers under subscription. Under this condition, IRPAgent is incapable of sending events to the affected subscriber(s).

This Notification IRP recommends that IRPManager should invoke the getSubscriptionStatus operation periodically to confirm that IRPAgent still has the IRPManager’s reference in its list. In case IRPManager does not obtain a positive confirmation, IRPManager should assume that IRPAgent has lost the IRPManager’s reference. In this case, IRPManager should invoke unsubscribe and then subscribe operation again.

This IRP does not recommend the frequency IRPManager should use to invoke getSubscriptionStatus operation.

6.1.3.5 Notification ordering

Under normal operations, an IRPAgent shall send, to each IRPManager, notifications in the same order they were generated, i.e. in the First-In, First-Out order. Notifications of one Event Type and/or Extended Event Type shall not be given priority over other Event Types and/or Extended Event Types.

Annex A (informative):
Change history