6 IRP Information Service

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

Name

Qualifier

Purpose

managerReference

Input, M

It specifies the reference of IRPManager to which IRPAgent shall send events.

timeTick

Input, O

It specifies the value of a timer hold by IRPAgent for the subject IRPManager. This value defines a time window within which IRPManager intends to invoke getSubscriptionStatus (or subscribe) operation. IRPAgent shall reset the timer, with timeTick, when it receives the getSubscriptionStatus (or subscribe) operation from the subject IRPManager. If the timer expires, IRPAgent may delete its resources allocated to the IRPManager and consider IRPManager as if it has invoked unsubscribe operation. In such case, IRPManager will not receive further notification. IRPManager needs to invoke subscribe operation again.

The value is in unit of whole minute.

If the value is between 1 and 15, IRPAgent considers it to be 15.

If the parameter is absent or if the parameter is present but its value is negative or 0, IRPAgent shall treat timeTick value as infinite, i.e., timer will never expire and IRPAgent needs other means to decide when to delete resources allocated to the IRPManager.

notification Categories

Input, O

It identifies one or more Notification Categories (see also definition in subclause 3.1).

If the parameter is absent, IRPAgent shall consider IRPManager is subscribing to all notification categories supported by IRPAgent.

filter

Input, O

It specifies a filter constraint that IRPAgent shall use to filter notification of the category specified in notificationCategory parameter. IRPAgent shall notify IRPManagers if the event satisfies the filter constraint.

If this parameter is absent, then no filter constraint shall be applied. Valid filter constraint grammars are specified by individual notification IRP SS, e.g. Notification IRP: CORBA SS.

subscriptionId

Output, M

It holds an unambiguous identity of this subscription. IRPManager can invoke operations (e.g., suspendSubscription) using this identity. In normal usage, IRPManager shall not provide this identity to another IRPManager such that the second IRPManager can invoke operations using it.

status

Output, M

(a) Operation succeeded in that the requested subscription has been established successfully AND that IRPAgent is emitting categories of notification specified by IRPManager via the notificationCategory parameter AND that the filter, if present, contains a valid filter constraint.

(b) Operation failed because IRPManager is already in subscription, i.e., IRPAgent detects that there is an existing subscription carrying the same managerReference and in subscription for the same notificationCategory.

(c) Operation failed because of other specified or unspecified reason.

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

Name

Qualifier

Purpose

manager Reference

Input, M

It specifies the reference of IRPManager. IRPManager shall supply its valid managerReference. This is the necessary requirement for the operation to be successful.

subscriptionId

Input, O

It carries the subscriptionId carried as the OUT parameter in the subscribe operation. IRPManager shall supply a specific subscriptionId if IRPManager wants to unsubscribe that particular subscription. IRPManager shall not supply subscriptionId (the parameter is absent) if it wants to unsubscribe all subscriptions established between IRPAgent and this managerReference.

status

Output, M

(a) Operation succeeded in that subscription is cancelled successfully.

(b) Operation failed because of specified or unspecified reason.

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

Name

Qualifier

Purpose

versionNumberList

Output, M

It indicates one or more SS version numbers supported by the IRPAgent. In Release 99, it shall contain only one version number.

status

Output, M

(a) Operation succeeded in that versionNumberList contains valid result.

(b) Operation failed. Output parameter versionNumberList may contain invalid result.

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

Name

Qualifier

Purpose

subscriptionId

Input, M

It carries the subscriptionId carried as the output parameter in the subscribe operation.

notification CategoryList

Output, M

It identifies the notificationCategory or notificationCategories supported in this subscription.

filterInEffect

Output, O

It contains the filter constraint currently active. If it is absent, IRPManager shall not apply any filter constraint to notifications emitted towards the subject IRPManager.

subscription State

Output, O

It indicates if the subscription is in “suspended” or “not-suspended”.

timeTick

Output, O

It carries the same value as the one in subscribe operation.

status

Output, M
  1. Operation is successful and IRPAgent has valid values for all output parameters.
  2. Operation is unsuccessful in that IRPAgent has no knowledge of the subscription.

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

Name

Qualifier

Purpose

managerReference

Input, M

It specifies the reference of IRPManager that requests the list of identifiers of active subscriptions related to this IRPManager.

subscriptionIdList

Output, M

It carries a list of the subscriptionId, each assigned as OUT parameter in previous subscribe operations invoked by the current IRPManager. This value should contain no information if the IRPManager did not yet subscribed to that System or System lost all subscription related information.

status

Output, M

(a) Operation succeeded in that the value contained in OUT parameter is valid.

(b) Operation failed because subscription information is lost or IRPAgent cannot complete the operation for other reasons. In this case, the OUT parameter shall contain no information.

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

Name

Qualifier

Purpose

subscriptionId

Input, M

It carries the subscriptionId carried as the OUT parameter in the subscribe operation.

filter

Input, M

See description of Table 1: Parameters of subscribe.

status

Output, M
  1. Operation succeeded in that IRPAgent is now producing events based on the new filter constraint.
  2. Operation failed in that, for unspecified reason, the new filter constraint cannot be installed. The old filter constraint, if present before this operation, is still in effect.

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

Name

Qualifier

Purpose

subscriptionId

Input, M

It carries the subscriptionId carried as the OUT parameter in the subscribe operation.

status

Output, M
  1. Operation succeeded in that IRPAgent has suspended emission of notifications.
  2. Operation failed in that, for unspecified reason, IRPAgent has not suspended emission of events.

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

Name

Qualifier

Purpose

subscriptionId

Input, M

It carries the subscriptionId carried as the OUT parameter in the subscribe operation.

status

Output, M
  1. Operation succeeded in that IRPAgent is has resumed emission of events.
  2. Operation failed in that, for unspecified reason, IRPAgent cannot resume emission of events.

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

Name

Qualifier

Purpose

notification CategoryList

Output, M

It identifies the list of notification categories supported by IRPAgent (see also definition in subclause 3.1).

If this parameter value contain no information, then the meaning is that IRPAgent does not support any notification category at the moment.

eventTypeList

Output, O

It contains a list of elements. Each element is a list of eventType. The number of element shall be identical to that of output parameter notificationCategoryList.

The n-th element of this list relates to the n-th element of the notificationCategoryList.

IRPAgent shall not use arbitrarily any eventType(s) in this n-th element. IRPAgent shall use the same list of eventType(s) specified in the IRP document identified by the n-th element of the notificationCategoryList.

If the n-th element contains no information, it implies IRPAgent is not providing explicit identification of eventType(s) of the corresponding notificationCategory.

If this parameter is absent or contains no information, it implies that IRPAgent is not providing explicit identification of eventType(s).

extendedEvent TypeList

Output, O

It contains a list of element. Each element is a list of extendedEventType. The number of element shall be identical to that of output parameter notificationCategoryList.

The n-th element of this list relates to the n-th element of the notificationCategoryList.

IRPAgent shall not use arbitrarily any extendedEventType in this n-th element. IRPAgent shall use the same list of extendedEventType specified in the IRP document identified by the n-th element of the notificationCategoryList.

If the n-th element contains no information, it implies IRPAgent is not providing explicit identification of extendedEventType(s) of the corresponding notificationCategory.

If this parameter is absent or contains no information, it implies that IRPAgent is not providing explicit identification of extendedEventType(s).

status

Output, M
  1. Operation succeeded in that the output parameter contains valid information.
  2. Operation failed in that the output parameter does not contain valid information.

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

Change history

Date

TSG #

TSG Doc.

CR

Rev

Subject/Comment

Old

New

Mar 2000

S_07

SP-000012

–

Approved at TSG SA #7 and placed under Change Control

2.0.0

3.0.0

Mar 2000

–

cosmetic

3.0.0

3.0.1

Jun 2000

S_08

SP-000242

002

Split of TS – Part 2: Notification Integration Reference Point (IRP): Information Service (IS)

3.0.1

3.1.0

Sep 2000

S_9

SP-000518

001

Consistent description of Event types and Extended event types

3.1.0

3.2.0

Sep 2000

S_9

SP-000518

002

Correction of parameter inconsistency in operation unsubscribe

3.1.0

3.2.0

Mar 2001

S_11

SP-010027

003

Add Information Service QOS specification

3.2.0

3.3.0

Mar 2001

S_11

SP-010027

004

Remove the reference to Relationship Change Notifications (ITU-T X.732)

3.2.0

3.3.0