WO2001095572A2

WO2001095572A2 - Method, system, and agent for processing a network resource alarm update in a telecommunication management network

Info

Publication number: WO2001095572A2
Application number: PCT/SE2001/001270
Authority: WO
Inventors: Edwin Tse; Nicolas Gosselin; André GODIN
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2000-06-05
Filing date: 2001-06-05
Publication date: 2001-12-13
Also published as: AU2001262884A1; WO2001095572A3

Abstract

In an Event Management System (EMS) (11), a method, system and agent (19) for processing an alarm update, wherein an agent receives from an alarmed network resource (14i) a first update alarm notification (50) with an alarm attribute, such as a severity attribute, set to CLEARED, followed by a second alarm update notification (60) comprising a new value of the attribute. Upon receipt of the first update (50), the agent (19) starts a timer for monitoring if the second update is received within a pre-determined period of time. If so, the agent discards the first update notification (50), and updates its active alarm list with the new alarm attribute, and further informs a manager (32') of the alarm change. If not, i.e. the pre-determined period of time expires and no second update is received at the agent (19), the agent (19) updates its original alarm (16) in its active alarm list with the attribute set to the CLEARED, and further informs the manager (32') of the attribute updated with the CLEARED state.

Description

Method, System, and Agent for Processing a Network Resource Alarm Update in a Telecommunication Management Network

Priority Statement Under 35 U.S.C S.119(e) & 37 C.F.R. S.1.78

This non-provisional patent application claims priority based upon the prior U. S provisional patent application entitled "Method, System, and Agent for Processing a Network Resource Alarm Update in a Telecommunication Management Network", application number 60/209521, filed June 05, 2000, in the names of TSE Edwin, GODrN Andre, and GOSSELIN Nicolas.

BACKGROUND OF THE INVENTION

Field of the Invention

The present invention relates to Telecommunication Management Systems, and in particular to the processing of alarm updates by an agent of the Telecommunication Management System.

Description of the Related Art

Networks are widely employed nowadays in various areas of activity. Local Area Networks (LANs), Wide Area Networks (WANs), Public Local Mobile Networks (PLMN) are just a few examples of the uses made of networks for providing new or improved services to users and subscribers. In order to insure its proper operation, each such network is typically monitored by a co-operating Telecommunication Management Network or Event Management System (EMS), which acquires and processes data related to the activity and/or faults that occur in the monitored network. The nodes of the monitored network typically issue event notifications for various events taking place in the network, such as for example call set-ups, radio cell selections, or hand-off failures in a PLMN. The events are further collected by the EMS and processed in a manner defined by the network operator for providing indications of the level of service quality given by the monitored network.

It is a particular function of the EMS to collect, process and display event- related information concerning the events/alarms issued by various elements of the monitored network. Such alarms can be issued upon detection or assumption of an error in the monitored network, such as for example the failure of a Base Station (BS) transceiver in the PLMN. In such a case, the BS issues an alarm notification which is further sent to the EMS. The EMS may comprise one or more Agents that receives, processes and stores the incoming events, such as the alarm notification. For example, the Agent may receive the alarm notification from the monitored network, process it by assigning an alarm identifier to the received notification and store the identified alarm in an Active Alarm List (AAL). Thereafter, the agent can send a notification to one or more Managers, which is another type of entity of the EMS that may be dedicated to further processing the alarm notifications, such as for example by performing alarm correlation. Alternatively, Managers may perform, for example, the actual management of the alarms, i.e. displaying the alarms to network administrators, thus allowing some remedial actions to be taken for dealing with the original problem that triggered the alarm notification.

Independently of the type of tasks assigned to a Manager node in the EMS, the Agent is typically linked to a Manager and notifies the Manager upon receipt of an alarm notification, by sending the alarm information along with its identifier. If, for example, the severity level of the alarm subsequently changes, such as for example because it has been detected that the radio quality of the current call improved, an update of the alarm must be issued in order to reflect the change. In the current implementations, as suggested by the International Telecommunication Union -

Telecommunication sector (ITU-T) Recommendation Q.821 - Specifications of Signaling System no 7 (SS7) Q3 Interface, the alarm update is performed in two separate steps. First, the alarmed resource that originally issued the alarm issues another alarm with the severity level set to CLEARED. Upon receipt of this notification, the Agent sets the alarm severity level to CLEARED in its Active Alarm

List (AAL), and then further sends the alarm notification to the Manager, which also sets the alarm severity level to CLEARED in its own alarm list. Thereafter, the alarmed resource sends yet another alarm notification along with the new severity level to the Agent. Upon receipt of the new alarm notification, the Agent changes again the alarm severity level in its AAL, and notifies yet again the Manager of the new alarm severity.

In general, there are other alarm attributes than the alarm severity attribute that, in various network implementation, necessitate the two-step update, wherein a first update notification comprises a transitional attribute value, such as a cleared state, and a second alarm update notification that comprises the actual new attribute value.

Therefore, since there are various attributes of the alarm that require two update signals to be sent and processed for their update, the use of the two-step alarm update creates double load on the agent processing means, i.e. the agent must process two alarm notifications for one single actual alarm update. Furthermore, the bandwidth of the link between the Agent and the Manager is also double-used since two notifications (and the potential corresponding message receive acknowledgment) are sent for one single alarm update. Although there is no prior art solution as the one proposed hereinafter for solving the above-mentioned deficiencies, the US patent 5,933,604 bears some relation with the present invention. In the US Patent 5,933,604, Inakoshi teaches a method and system for monitoring the activity of a network that allows a user to send a request for monitoring an information resource of that network. The management system further notifies the user of the update information using a notifying interface corresponding to each user. However, Inakoshi is limited to a method and system for notifying a user of an information change, and does not disclose, teach or suggest a method and system for simplifying the treatment of alarm update notification as proposed in the present invention.

There is a need for a simplified scheme for performing alarm update notification received at an EMS Agent from an alarmed resources, and further transmitted to an EMS Manager. It would be particularly advantageous to have a flexible method allowing one-step alarm update notification in the majority of cases wherein the attribute value is transmitted shortly after the alarm attribute set to cleared

(transitional value), while still allowing alarm attribute to be set to cleared by an Agent of the EMS when the new attribute value is not received during a pre-determined time interval.

Summary of the Invention

It is therefore an object of the present invention to provide a new method, system and agent that allow the simplified treatment of alarm update.

It is a particular object of the present invention to provide a new method, system and agent that reduce the processing load on the agent as well as the agent-to- manager signaling, by discarding a first alarm update notification comprising the alarm attribute set to a CLEARED value in case the first alarm update notification is followed, within a pre-determined period of time, by a second update alarm notification comprising a new actual alarm attribute value.

Therefore, in accordance with a preferred embodiment of the invention there is provided, in an Event Management System (EMS), a method for updating an alarm attribute of a particular alarm, the method comprising the steps of: receiving in an agent of the EMS a first update alarm notification comprising an alarm attribute value set to cleared, for the particular alarm; starting a timer set to expire after a pre-determined period of time upon receipt of said first update alarm notification in the agent; and if a second update alarm notification comprising a second alarm attribute value is received in the agent for the particular alarm before an expiry of the pre-determined period of time: discarding the first update alarm notification; and updating the alarm attribute of the particular alarm with the second alarm attribute value. It is another object of the invention to provide an Event Management System (EMS) comprising: an Alarmed Network Resource (ANR); an agent connected to the ANR for acquiring alarms and alarms updates from the ANR, the agent comprising an Active Alarm List (AAL) for storing active alarms; wherein when a change in a state of the ANR occurs, the ANR sends a first update alarm notification comprising an alarm attribute value set to CLEARED to the agent, the notification being directed to update a particular alarm; upon receipt of the first update notification, the Agent starts a timer set to expire after a pre-determined period of time; and if a second update alarm notification directed to the particular alarm and comprising a second alarm attribute value is received in the agent before an expiry of the pre-determined period of time: the agent discards the first update alarm notification; and the agent updates the alarm attribute of the particular with the second alarm attribute value. It is yet another object of the invention to provide an agent of an Even Management System (EMS), comprising: an Active Alarm List (AAL) for storing alarms received from at least one Alarmed

Network Resource (ANR) connected to the agent; a timer set to expire after a pre-determined period of time; an alarm processor connected to the timer for starting the timer upon receipt from the ANR of a first update alarm notification directed to a particular alarm and comprising an alarm attribute value set to CLEARED, and for determining if a second update alarm notification directed to the particular alarm and comprising a second alarm attribute value is received at the agent before an expiry of the pre-determined period of time; wherein, if the second update alarm notification is received in the agent before the expiry of the pre-determined period of time: the agent discards the first update alarm notification; and the agent updates the particular alarm with the second alarm attribute value.

Brief Description of the Drawings For a more detailed understanding of the invention, for further objects and advantages thereof, reference can now be made to the following description, taken in conjunction with the accompanying drawings, in which:

Figure 1 (Prior Art) is a high-level block diagram of an Event Management System (EMS) and also includes a high-level flowchart diagram of the prior art method for treating an update alarm notification;

Figure 2 is an exemplary high-level block diagram of an EMS network according to a preferred embodiment of the invention, and also includes a high-level flowchart diagram of the invented method for treating an alarm update;

Figure 3. a (Prior Art) is an exemplary illustration of an alarm notification; Figure 3.b (Prior Art) is an exemplary illustration of the severity attribute of an alarm notification;

Figure 3.c (prior Art) is yet another exemplary illustration of a series of attributes of an alarm notification; and

Figure 4 is an exemplary high-level block diagram of an EMS agent according to a preferred embodiment of the invention.

Detailed Description of the Preferred Embodiments

Reference is now made to Figure 1 , wherein there is shown a high-level block diagram of a known prior art Event Management System (EMS) 10 (also called hereinafter alarm management system or telecommunication management network) that monitors a network 12, such as for example a Public Local Mobile Network (PLMN) 12. From the point of view of the EMS 10, the monitored network 12 may appear as a set of components, or nodes, also having a series of sub-components. Every such node and/or sub-component may issue events and/or alarms. For the purpose of describing the present invention with greater simplicity, the nodes and subcomponents are depicted as Alarmed Network Resources (ANR) 14_;. It is to be understood that the monitored network 12 may be practically any kind of network, and that the ANRs 14_; can be any kind of nodes, sub-components, or logical entities in communication or not with each other. The monitored network 12 is linked with the EMS 10 by at least one connection 15, and the EMS 10 comprises at least one Agent 18 further connected to at least one Manager 32, such as for example through a network 34 that may be a Local Area network (LAN) or a Wide Area network (WAN). The Agent 18 further comprises an internal or external Active Alarm List (AAL) 26 for storing the active alarms issued by at least some portions of the monitored network 12.

In Figure 1 it is assumed that the ANR 14_α first issues an original alarm notification 16 and sends it to the Agent 18. The Agent 18 receives the original alarm

16, action 20, assigns an identifier to the original alarm 16, action 22 and then stores the alarm along with the identifier, information 24, in its AAL 26, action 28. Once the information 24 is stored in the AAL 26, the Agent 18 sends a notification 30, comprising information 24 (the alarm with its identifier) to the Manager 32 over the network 34, action 36, thus allowing the Manager 32 to be also informed of the receipt of the original alarm 16.

An alarm notification, such as for example the original alarm 16 may include various alarm attributes (also called fields) having certain pre-defined values (also called states). With reference to Figure 3. a, an alarm notification such as for example the alarm notification 16 typically includes certain alarm attributes (fields) 40_i5 each such attribute comprising an alarm attribute value 40_;' (the actual content, or state, of the attribute). In the present scenario, it is assumed for example, that the alarm attribute 40₄ may be the "perceived severity attribute" and thus comprises the "perceived severity attribute value" 40₄'. However, as it will be readily apparent for those skilled in the art, the format of the alarm notification may vary from one communication protocol to another.

Figure 3.b illustrates an exemplary list of the possible values of an alarm attribute, such as for example of the alarm "perceived severity attribute" 40₄ of the alarm notification 16. Figure 3.c depicts an exemplary list of alarm attributes 40j used in various ITU-

T standards, such as for example in the XJ33, X.731 and Q821 standards. Besides the alarm attributes, it is understood that each alarm typically comprises an alarm identification which is used by the various EMS nodes for identifying, associating and correlating a particular alarm. With reference being made back to Figure 1, after an original alarm notification 16 is issued and processed in the EMS 10 as described hereinbefore, actions 20-36, an attribute value of the original alarm may have to be changed for various reasons. For example, the state of an ANR that issued the original alarm may vary, and thus an alarm attribute such as for example the severity attribute of the original alarm 16 may change. This may require an update notification to be sent by the ANR 14_j to the Agent 18. According to the common usage created by the known standards, such as for example as exemplified by the International Telecommunication Union - telecommunication Sector (ITU-T), Recommendation Q.821 - Specifications of Signaling System no 7 (SS7), Q3 Interface, when the value of an alarm attribute such as for example the perceived severity level (i.e severity attribute value) of the original alarm changes, first the ANR 14, sends a first update alarm notification with the severity attribute value set to CLEARED, message 50, to the Agent 18. The updated alarm notification 50 comprises the same alarm information as the original alarm notification 16, i.e. the alarm identification and all attributes that did not change, with the exception of the alarm severity attribute that changed from a first attribute value to another attribute value set to CLEARED. The Agent 18 receives the message 50, action 52, and sets the alarm severity attribute value 40₄' of the alarm listed in the

AAL 26 to the new value received in message 50, action 54, by sending an AAL update request 55 and finally informs the Manager 32, action 56, by sending the same information as in 30, except for the new severity attribute value now set to CLEARED, message 58. It is understood that the Agent 18 may use the alarm identification information for knowing which alarm from the AAL 26 the update alarm notification is addressed to.

After having sent the first update alarm notification 50 with the alarm severity attribute value set to CLEARED as described beforehand, according to the current standards, the ANR 14_x can send the new actual alarm severity attribute value. For this purpose, the ANR 14, sends yet another (second) update alarm notification, message

60, comprising the same information as the original alarm notification 16, with the exception of the new (second) alarm severity attribute value to the Agent 18. The Agent 18 receives the message 60, action 62, and stores in the AAL 26 the alarm information with the new severity level, action 63, by sending a message 65 comprising the alarm information with the new severity level. Thereafter, the manager

32 is informed of the alarm severity update by the message 64 comprising similar information as the prior message 58, with the exception of the new severity attribute value, action 66.

The prior art method for processing the alarm updates described in Figure 1 is laborious since it requires sending and processing a tandem update alarm notification comprising a first update alarm notification with an alarm attribute value set to CLEARED and a second update alarm notification having the actual (second) alarm severity attribute value. The same two-step approach is also used in the prior art systems for updating not only the alarm severity attribute, but also other types of alarm attributes.

Reference is now made to Figure 2, in which there is shown an exemplary high-level block diagram according to a preferred embodiment of the invention for solving the above-mentioned deficiencies. In Figure 2, elements similar to the ones described with reference to Figure 1 are described with similar numerals. A modified EMS 11 monitors the monitored network 12. The monitored network may be any kind of network, such as for example a Local Area Network (LAN), a Wide Area Network (WAN), a wired or wireless telephone network of any kind (GSM, ANSI-41 , GPRS,

CDMA, NMT, a Public Switched Telephone Network (PSTN), etc). The monitored network 12 is connected through at least one link 15, such as for example a wireline link, to one or more Agents 19, of the EMS 11. The Agents 19 (only one is shown for greater simplicity) may be nodes and/or logical entities of the EMS 11 responsible for example of the intermediate treatment of the information ranging between the information acquisition from the monitored network 12 to the final display of the treated information on the network administrators display (not shown). Typically, the tasks assigned to the Agents of an EMS include, but may not be limited to, information (events, alarms, etc) storage, primary information treatment such as some basic alarm correlation, basic information categorization, etc. In the exemplary preferred embodiment described in reference with Figure 2, only one Agent 19 is shown for simplification purposes and without any limitation, the Agent 19 shown being responsible for storing alarms issued by one or more Alarms Network Resources 14 for the alarm update processing and for forwarding the alarm-related information to the Manager 32'.

In Figure 2 it is assumed that the ANR 14, first issues an original alarm notification 16 and sends it to the Agent 19. The Agent 19 receives the alarm 16, action 20, creates and assigns an identifier to the original alarm 16, action 22 and then stores the information 24, i.e. the alarm along with the identifier, in its AAL 26', action 28. Once the information 24 is stored in the AAL 26', the Agent 19 sends a notification message 30, comprising the information 24 (the alarm with its identifier) to the Manager 32' over the network 34, action 36, thus allowing the Manager to be also informed of the original alarm.

As it was described hereinbefore, an alarm attribute value, such as the value of the alarm severity attribute, may change after a certain period of time such as for example because the status of the ANR 14, has changed (example: partial recovery of the ANR 14₁). When such a change occurs (example: alarm severity of a given alarm changes from a previous value of CRITICAL to a new value of MINOR) in the particular ANR 14₁ that issued the original alarm notification 16, and if the communications between the ANRs (the monitored network 12) and the EMS 11 are set up according to the common usage suggested by a standard such as for example the ITU-T X.821, the ANR 14, may be set to issue a first alarm notification comprising the same alarm information as the original alarm notification 16, with the exception of the alarm attribute value now being set to CLEARED, message 50, and to send it to the Agent 19.

According to a preferred embodiment of the invention, there is proposed a new method to simplify and to accelerate the processing and the transmission scenario for an alarm update with respect to the described prior art method. Instead of proceeding with the processing of two notifications in tandem for only one alarm update (such as a severity attribute having a cleared value followed by the actual alarm severity attribute value update) and to their respective transmissions from the Agent to the Manager(s), the invention proposes to receive a first update alarm notification having an attribute value set to cleared, hold this request for a pre-determined period of time without modifying the AAL entry of the given particular alarm, and without sending the further notification to the Manager. If a subsequent (second) update alarm notification is received for the particular alarm at the Agent during that pre-determined period of time, which is believed to happen in most situations, then the cleared request is dropped, the AAL is updated with the new attribute value comprised in the second notification of the given alarm and the alarm attribute value is further sent to the Manager. If not, i.e. if no further alarm update is received at the Agent during the predetermined period of time, the Agent updates the AAL alarm attribute by setting the given attribute value to CLEARED, and also informs the Managers that the given attribute value is set to CLEARED.

With particular reference to Figure 2, it is assumed that, for example, a change occurs in the ANR 14, and that this necessitates the transmission of an alarm update. Assuming that the communication between the ANR 14, and the Agent 19 is governed by a standard requiring a tandem update notification as described hereinbefore, when such a change occurs in the ANR 14„ the ANR first sends a first update alarm notification message 50 to the Agent 19 over the link 15, wherein the message 50 comprises the same alarm information as the original alarm 16 with the exception of the given alarm attribute that must be changed, which value is set to CLEARED. According to a preferred embodiment of the invention, the Agent 19 receives the message 50, action 80, and first starts a Timer, action 82, for measuring a time interval between the receipt of message 50, comprising the given attribute value set to CLEARED, and the second update alarm notification, message 60, comprising the second (actual) alarm attribute value. The Timer is set to expire at a pre-defined time period defined by a network administrator. The period of time may bear a relation with the average amount of time separating the receipt of the first update alarm notification 50 and the receipt of the second update alarm notification 60 for the given particular alarm (see Figure 1). This relation can be for example that the pre-defined time period is set to be: i) sensibly greater than, or, ii) twice the average amount of time separating the receipt of the first and the second update alarm notifications at the Agent.

Once the Timer is started (the first update alarm notification is received at the Agent), the Agent 19 does not actually perform the update of the given alarm attribute with the CLEARED state, as done in the prior art systems. Instead, the Agent monitors if a second update alarm notification message 60 (comprising a new alarm attribute value than the original alarm notification 16) is received before the expiration of the pre-determined time period, action 84. If yes, i.e. if the Agent 19 receives before the expiration of the pre-determined time period a second update alarm notification 60 with a new attribute value, the Agent 19 first discards the first alarm notification message 50, action 86, i.e. the Agent does not update the AAL 26' with the alarm attribute value set to CLEARED, and does not update the Manager 32' with the alarm attribute value set to CLEARED. Instead, the Agent 19 updates the alarm attribute of the given alarm in the AAL 26' with the new alarm severity attribute received in message 60, action 87, by sending an alarm update request 88 to the AAL 26', and further informs the Manager 32' of the alarm update by sending an update alarm notification message 90 over the network 34, action 92.

It is believed that this scenario, wherein the actual alarm update notification message 60 is received at the Agent 19 before the expiry of the pre-determined time period happens significantly often, such as for example in at least 80%-90% of cases. Therefore, with the present invention, it is contemplated that the actual unnecessary Agent-to-Manager alarm update signaling that exists in the prior art implementation with the two-step update notification, along with the corresponding duplicative message processing in the Agent regarding the AAL update, is avoided in most cases .

The invention further comprises provisions for dealing with exception cases wherein the second update alarm notification 60 is not received during the pre-determined time period. In such a case, the timer monitors for receipt of the actual alarm update notification 60, action 84; if the timer expires and no such notification is received, then the Agent 19 updates the given attribute of the particular alarm in the AAL 26' with the CLEARED value, action 100, by sending an alarm attribute update request 102 to the AAL 26', and further updates the Manager 32', action 103, by sending an alarm attribute update request message 104 over the network 34.

If later on, after the expiry of the pre-determined time interval, the Agent finally receives the second update alarm notification (comprising a new (second) attribute value for the given alarm) from the ANR 14„ the Agent 19 may update the AAL 26' with the new (second) alarm attribute and further update the Manager 32' as described beforehand for analogous actions (actions not shown).

It is to be noted that although the invention was exemplified hereinbefore especially with reference to the alarm severity attribute update, the invention is applicable and useful for updating various types of alarm attributes that according to certain standards require a first update with in intermediary value, such as the CLEARED value, and then only allow to proceed with the actual attribute update with an actual attribute value.

Reference is now made to Figure 4 wherein there is shown a high-level block diagram of an exemplary functional implementation according to yet another preferred embodiment of the present invention. The Agent 19 may comprise am input module 110, such as an I/O interface, for receiving the alarm notifications 16, 50, and 60 from the ANRs 14_i3 and possibly also for acknowledging receipt of the alarms (actions and acknowledging messages not shown). The input module 110 may be connected to an alarm processor 112 wherein alarms are identified and treated as described hereinbefore with reference to Figure 3. The alarm processor 112 is further connected to a Timer 114, which is responsible for measuring the time interval from the receipt of first update alarm notification with the attribute value set to CLEARED, message 50, to the receipt of the second update alarm notification 60 (see Figure 2). Also connected to the alarm processor 112 is: i) the alarm identifier builder 113 that is responsible for creating and assigning an identifier for each newly received alarm (original alarm 16) as described in connection to Figure 2 and ii) the AAL 26' that stores the list of the active alarms. The AAL 26' may be comprised in the Agent 19, as it is shown in Figure 4, or may be external to the Agent 19 but connected therewith, as shown in Figure 2.

The Agent 19 receives an original alarm notification 16 at the alarm input module 110, which forwards the notification 16 to the alarm processor 112. Upon detection that the notification 16 is a new alarm (action not shown), by for example consulting the AAL 26', the processor passes the original alarm notification 16 to the alarm identifier builder 113 that creates and assigns an identifier to the alarm 16. The identifier builder 113 further transmits the alarm and its identifier, information 24 to the AAL 26'.

The Agent 19 may later receive a first update alarm notification 50 from the ANR 14,. The notification 50 may be received in the same alarm input module 110 and further transmitted to the alarm processor 112. Since the first update alarm notification 50 contains the same alarm information as the notification 16, with the exception of the given attribute that must be updated which is set to the CLEARED value in the message 50, the alarm processor 112 detects that this is not an original alarm, but rather an update (CLEARED) for the original alarm given attribute. This action may be performed by the alarm processor 112 in collaboration with the AAL 26' that may be queried for detecting the presence of the original alarm 16 (with its identifier) in the AAL 26'. Once the processor 112 detects that the message 50 is an update alarm notification following and corresponding to an original alarm notification 16, the processor 112 instructs the timer 114 to start and run until reaching a predetermined time value. When the time value is attained, the timer 114 may send a timer expiry signal 115 to the alarm processor 112. Upon receipt of the time expiry signal 115, the alarm processor 112 updates the alarm attribute of the given particular alarm in the AAL 26' by setting it to the CLEARED value received in message 50. The alarm processor 112 may identify the particular alarm the update 50 is directed to by using the alarm identification comprised in the message 50. Further, the alarm processor 112 notifies the Manager (not shown) of the new alarm attribute value set to CLEARED through message 104.

However, if before the pre-determined time value expiry, i.e. before receipt at the alarm processor 112 of the time expiry signal 115 from the timer 114, the alarm processor 112 actually receives a second update alarm notification 60 comprising a new (second) attribute value than the original alarm notification 16, then the alarm processor 112, first discards the first update alarm notification 50, (action 86 in Figure

2), updates the alarm attribute if the given particular alarm in the AAL 26' by replacing the original alarm attribute value (received in the notification 16) by the second alarm attribute value (received in the second notification 60) as described in action 87 of Figure 2. Further, the alarm processor 112 notifies the Manager (not shown) of the alarm update through the message 90 (action 92 in Figure 2). In such a scenario, upon receipt of the second update alarm notification 60 comprising a new severity attribute, the alarm processor 112 may also instruct timer 114 to stop counting (action not shown) or simply ignore the time expiry signal received at the expiration of the pre-determined time period. Therefore, in the exemplary preferred embodiment described with reference to Figure 4, at least part of the intelligence of the Agent 19 is comprised in the alarm processor 112. Furthermore, the functional modules 110 - 114 may preferably be software modules forming a global alarm processing application, or a portion thereof. Alternatively, the functional modules 110 - 114 may be hardware modules, or a combination of software modules running over certain hardware devices. For example, the alarm processor 112 may be a code program functionality running over a hardware chip, while the AAL 26' may be a database management software application running over an operating system installed on a given server.

According to a preferred embodiment of the invention, although the invented method, system and Agent were described hereinbefore as being useful for dealing with a sequence comprising the receipt of an alarm update following the receipt of an original alarm 16 (see Figure 2), it is to be noted that the "original" alarm 16 may also be any kind of alarm notification, such as for example an update alarm notification. Therefore, the invention may also apply for processing not only a first alarm update for a given "original" alarm, but also further alarm updates of a given alarm, including a series of alarm updates (in that case the "original" alarm 16 becomes a "previous" alarm update). Therefore, the term "original" alarm notification as described hereinbefore should be interpreted in its larger sense, i.e. it represents an alarm that is received at the agent 19 previous to a subsequent alarm update.

In an alternative preferred embodiment of the invention, the same principle and simplified processing scheme described with reference to Figures 2 and 4 may be used and applied not only for processing any type of alarm update wherein an alarm attribute changes, provided that the alarm identity remains unchanged. The invention can therefore be applied to the processing any type of alarm attribute update that requires, according to a given standard (or other requirements), the transmission of an attribute set to a CLEARED state, or to an intermediate state, prior to the transmission of a new attribute indicating the actual update of that attribute. For example, but not limited to, the following alarm attributes may be used in accordance with the teachings of the present invention and as described hereinbefore, for simplifying the alarm update processing scheme: i ) the "correlated Notifications" alarm attribute that typically identifies a set of notifications to which the current notification is considered to be correlated; ii) the "trend Indication" alarm attribute that indicates if some observed condition is getting better, worse, or not changing. Legal values are "less severe", "no change" and "more severe"; and iii) the "proposed Repair Actions" alarm attribute that indicates proposed repair actions.

Although several preferred embodiments of the method and system of the present invention have been illustrated in the accompanying Drawings and described in the foregoing Detailed Description, it will be understood that the invention is not limited to the embodiments disclosed, but is capable of numerous rearrangements, modifications and substitutions without departing from the spirit of the invention as set forth and defined by the following claims.

Claims

What is claimed is:

1. In an Event Management System (EMS), a method for updating an alarm attribute of a particular alarm, the method comprising the steps of: receiving in an agent of the EMS a first update alarm notification comprising an alarm attribute value set to cleared, for the particular alarm; starting a timer set to expire after a pre-determined period of time upon receipt of said first update alarm notification in the agent; and if a second update alarm notification comprising a second alarm attribute value is received in the agent for the particular alarm before an expiry of the pre-determined period of time: discarding the first update alarm notification; and updating the alarm attribute of the particular alarm with the second alarm attribute value.

2. The method claimed in claim 1, wherein the step of updating comprises the steps of: updating the alarm attribute of the particular alarm with the second alarm attribute value in an Active Alarm List (AAL) of said agent; sending an update alarm notification request comprising the second alarm attribute value to a manager of the EMS, the manager being connected to the agent.

3. The method claimed in claim 1, further comprising, prior to the step of receiving, the steps of: receiving an original alarm comprising an original attribute value in the agent; creating and assigning an alarm identifier to the original alarm; storing the original alarm and the alarm identifier in an Active Alarm List

(AAL) of the agent; sending to the manager an original alarm notification message for informing the manager of the original alarm.

4. The method claimed in claim 1, wherein the agent receives the first update alarm notification and the second update alarm notification from an Alarmed Network Resource (ANR) of a monitored network.

5. The method claimed in claim 2, wherein the AAL is an alarm database connected to the agent.

6. The method claimed in claim 5, wherein the agent is a node of the EMS having a task of storing alarms received from at least one monitored node.

7. The method of claim 1, wherein the alarm attribute is an alarm attribute selected from the group consisting of the severity attribute, the proposed repair action attribute, the trend indication attribute and the correlated notifications attribute.

8. An Event Management System (EMS) comprising: an Alarmed Network Resource (ANR); an agent connected to the ANR for acquiring alarms and alarms updates from the ANR, the agent comprising an Active Alarm List (AAL) for storing active alarms; wherein when a change in a state of the ANR occurs, the ANR sends a first update alarm notification comprising an alarm attribute value set to CLEARED to the agent, the notification being directed to update a particular alarm; upon receipt of the first update notification, the Agent starts a timer set to expire after a pre-determined period of time; and if a second update alarm notification directed to the particular alarm and comprising a second alarm attribute value is received in the agent before an expiry of the pre-determined period of time: the agent discards the first update alarm notification; and the agent updates the alarm attribute of the particular with the second alarm attribute value.

9. The EMS claimed in claim 8, further comprising: a manager connected to the agent; wherein if the second update alarm notification is received in the agent before an expiry of the pre-determined period of time, the agent informs the manager of the second alarm attribute value of the particular alarm.

10. The EMS claimed in claim 8, wherein the alarm attribute is an alarm attribute selected from the group consisting of the severity attribute, the proposed repair action attribute, the trend indication attribute and the correlated notifications attribute.

11. The EMS claimed in claim 8, wherein the second alarm attribute value is different from the clear value of the alarm attribute comprised in the first update alarm notification.

12. The EMS claimed in claim 8, wherein the AAL is one of internal and external to the agent.

13. An agent of an Even Management System (EMS), comprising: an Active Alarm List (AAL) for storing alarms received from at least one Alarmed

14. The agent claimed in claim 13, wherein the AAL is one of internal and external to the agent.

15. The agent claimed in claim 13, wherein the second alarm attribute value is different from the clear value of the alarm attribute comprised in the first update alarm notification.

16. The agent claimed in claim 13, wherein the alarm attribute is an alarm attribute selected from the group consisting of the severity attribute, the proposed repair action attribute, the trend indication attribute and the correlated notifications attribute.

17. The alarm management system claimed in claim 13, wherein the second alarm attribute value is different from the clear value of the alarm attribute comprised in the first update alarm notification.