Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 32.302  Word version:  17.0.0

Top   Top   None   None   Next
0…   2…

 

0  Introductionp. 5

The present document is part of a TS-family covering the 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Telecommunication management; as identified below:
  • 32.301: Configuration Management (CM); Notification Integration Reference Point (IRP): Requirements
  • 32.302: Configuration Management (CM); Notification Integration Reference Point (IRP): Information Service (IS)
  • 32.303: Configuration Management (CM); Notification Integration Reference Point (IRP): Common Object Request Broker Architecture (CORBA) Solution Set (SS)
  • 32.305: Configuration Management (CM); Notification Integration Reference Point (IRP): eXtensible Markup Language (XML) definition
  • 32.307: Configuration Management (CM); Notification Integration Reference Point (IRP): Simple Object Access Protocol (SOAP) Solution Set (SS)
The Itf-N interface is built up by a number of Integration Reference Points (IRPs) and a related Name Convention, which realise the functional capabilities over this interface. The basic structure of the IRPs is defined in TS 32.101 and TS 32.102.
Network Elements (NEs) under management and element managers generate notifications of events about occurrences within the network. Different kinds of events carry different kinds of information. For instance a new alarm as specified in Alarm IRP: Information Service [1], is one possible kind of event, an object creation as specified in Basic CM IRP: Information Service [8] is another possible kind of event.
Information of an event is carried in notification. An IRPAgent (typically an EM or a NE) emits notifications. IRPManager (typically a network management system) receives notifications. The purpose of Notification IRP is to define an interface through which an IRPManager can subscribe to IRPAgent for receiving notifications.
This IRP bases its design on work captured in ITU-T Recommendation X.734 [2], OMG Notification Service [4]. The central design ideas are:
  • Separation of notification Consumers (IRPManagers) from Producers (IRPAgents);
  • Notifications are sent to IRPManagers without the need for IRPManagers to periodically check for new notifications.
Common characteristics related to notifications in all other IRPs are gathered in one IRP.
Up

1  Scopep. 7

The purpose of Notification IRP is to define an interface through which an IRPManager can subscribe to an IRPAgent for receiving notifications. The present document is the "Information Service" of Notification IRP. It defines, for the purpose of subscribing to an IRPAgent for receiving notifications, the information observable and controlled by management system's client and it also specifies the semantics of the interactions used to carry this information. It also defines the information common to all notifications which is called the notificationHeader.
An IRPAgent supporting this IRP IS may emit one or multiple categories of notifications, such as alarms (as specified in Alarm IRP: Information Service [1]) and others. This IRP IS defines a mechanism that IRPManager can use to determine the categories of notifications supported by an IRPAgent. It also defines a mechanism (subscribe and unsubscribe operations) that IRPManager can use to specify the categories of notifications IRPAgent should emit to IRPManager during subscription. It also defines a mechanism (getSubscriptionIds operation) that IRPManager can use to check which categories of notifications it has subscribed to. IRPManager can set and change filter criteria applicable during the life-cycle of a subscription. IRPManager can also exercise flow-control on IRPAgent's emission of notifications (suspendSubscription and resumeSubscription operations).
Using different managerReference, an IRPManager can subscribe several times. It will result in multiple subscriptions. As far as IRPAgent is concerned, notifications are sent to multiple "places".
Using the same managerReference, an IRPManager can subscribe several times specifying different categories of notifications.
This IRP IS does not specify information that is carried in some but not all notifications. That kind of information is specified in other IRP ISs involved. For example, perceivedSeverity is a piece of information specific for notifications carrying alarm information. This information is not defined in the present document but in Alarm IRP: Information Service [1].
How IRPManager discovers the IRPAgent's address or reference (so that IRPManager can invoke an operation) is outside the scope of the present document.
This IRP IS is aligned with ITU-T M.3702 [13] in terms of the definitions of operations for Notification management.
Up

Up   Top   ToC