EP1299973A1

EP1299973A1 - Technique for monitoring a network using dynamic rule-based logic

Info

Publication number: EP1299973A1
Application number: EP01950189A
Authority: EP
Inventors: Gary Gubbins; Michael Kelly; Robert Thomas Lambert; Patricia Murphy; Barry O'driscoll
Original assignee: Telefonaktiebolaget LM Ericsson AB
Current assignee: Telefonaktiebolaget LM Ericsson AB
Priority date: 2000-07-13
Filing date: 2001-07-13
Publication date: 2003-04-09
Also published as: AU2001271214A1; WO2002007386A1

Abstract

A technique for reporting alarms and other notifications from a network element module to a monitoring module uses a dynamic rule-based technique for weighting the relevancy of network events. The technique includes broadcasting a priority threshold value from the monitoring module to the network element module. Upon receiving the priority threshold value, the network element module weights the relevancy associated with one or more events occurring within the network element module by at least one weighting component to produce a final severity value. The network element module then determines whether to transmit a notification from the network element module to the monitoring module based on a comparison between the priority threshold value and the final severity value. In alternative embodiments, the priority threshold value is also computed based on a weighting procedure. The weighting components used by the weighting procedure in the monitoring module and/or network element module generally pertain to conditions currently prevailing in the network element module and to other attributes of the network element module, such as the status of the network element module within the network. Accordingly, the relevancy assigned to events automatically and dynamically varies with changing conditions in the network. The use of intelligent filtering within the network element module quickly provides the user with the most relevant alarms occurring within the network at any given time.

Description

TECHNIQUE FOR MONTTORTNG A NETWORK USING DYNAMIC RULE-BASED LOGTC

BACKGROUND The present invention relates to a system, network element, and method for monitoring network activities, and more particularly, to a system, network element, and method for monitoring network activities using dynamic rule-based logic.

The efficient management of a network requires tools for monitoring alarms and other events within the network. For instance, Fig. 1 shows a well-known architecture for monitoring and managing a communication network 102 comprising one or more managed systems (e.g., managed systems 110 and 112). The management system shown there includes a communication management network 100 comprising one or more operations systems (e.g., operations systems 106 and 108). The operations systems are connected to the managed communication network 102 via a data communication network 104 (which may comprise, for example, a network governed by the SNMP or CORBA protocols). Alarms (and other notifications) are transferred to the operations systems via the data communication network 104. The operations systems may include devices and/or systems for storing, analyzing, and displaying the alarms and other notifications. Further, the operations systems typically include devices and/or systems for talcing corrective action based on the alarms and other notifications.

Several standards have been developed for the management of networked systems. For telecommunication networks, the ITU (International Telecommunication Union) provides exemplary guidelines for the definition of the Telecommunication Management Network (TMN), such as the ITU M.3010 standard, "Principals for a Telecommunications Management Network," October 1992, which is incorporated by reference here in its entirety. Object-oriented protocols such as those set forth in the ITU conceptualize the managed network as including one or more network elements (NE). With reference to Fig. 2, a network element 202 is divided into a management layer 204 and a resource layer 206. The management layer 204 consists of a collection of managed objects (e.g., objects 210, 211, 212). A managed object includes attributes and, as shown, can also have a relation to other managed objects. Associative relationships are specified as attributes. The resource layer comprises a number of resource objects RO (e.g., objects 214, 216) represented by the managed objects of the management layer. The resource objects represent the real implementation of the network element. For example, resources objects may represent circuit boards used in a radio communications base station. Interested readers are referred to commonly assigned U.S. Patent No. 5,799,153 for more details on the exemplary characteristics of a network element in an object-oriented protocol.

Changes within the network elements generate "events." The transport of events from any event producer to a "consumer" is referred to as a "notification." In the context of Fig. 2, a managed object sends a notification to the operations system 200 over the Q3 interface (e.g., in the context of the SNMP or CORB A network protocols) to thereby inform operations system 200 that an event has occurred in the network element. An alarm condition is an example of a notification. An alarm represents an abnormal network element condition.

A typical communications network can generate a large number of alarms and other notifications. This raises the risk of potentially overwhelming the analysis capacity of an operations system. For instance, a system using an automatic analysis tool may lack sufficient processing capacity to process the notifications. A system which relies on human analysis of notifications may be subject to human limitations. That is, the human operator may be deluged with an enormous number of notifications, making it difficult for the operator to recognize and act on the most critical alarms in a timely manner. This problem may be compounded when the operations system is restarted after a period of inactivity. In this circumstance, the operator may loose all knowledge of prevailing conditions in the network elements. Upon restart, the operator may be confronted with a particularly large number of notifications, making it difficult to extract and act on the most critical alarms. Prior art systems have addressed this problem by restricting the amount of information forwarded to the operator for his or her review. Such restriction can be accomplished using filters (or "discriminators"). A typical filter extracts and forwards information which matches predefined criteria. The criteria is specified by filter parameters which define the alarms and notifications that are particularly of interest to the operator. For instance, if deluged with a large number of low-level alarms emanating from a particular network element, the system operator could define filter parameters which exclude those low-level alarms.

However, the use of conventional filters is not fully satisfactory. The alarm- generating characteristics of networks vary over time depending on a number of factors. For instance, the traffic load in a communications network (and the alarms associated therewith) will typically vary both in nature and amount over time. Further, different network elements may have different alarm-generating characteristics. Thus, a filter may be suitable for one set of network conditions and/or network elements, but not others. It is possible to define filter parameters in an ad hoc manner to suit prevailing conditions in a network. However, this solution requires the operator to assess prevailing network conditions and then select appropriate filter parameters to match those conditions. An operator may find it difficult to perform this task in a timely manner, especially when the operations system is restarted after a period of inactivity.

SUMMARY

These and other problems are addressed by the present invention through the use of a dynamic rule-based technique for weighting the relevancy of network events. The technique includes broadcasting a priority threshold value from a monitoring module to a network element module. Upon receiving the priority threshold value, the network element module weights the relevancy associated with one or more events occurring within the network element module by at least one weighting component to produce a final severity value. The network element module then determines whether to transmit a notification from the network element module to the monitoring module based on a comparison between the priority threshold value and the final severity value. In alternative embodiments, the priority threshold value is also computed based on a weighting procedure.

The weighting components used in the weighting procedure of the monitoring module and/or network element module can include a number of components relating to the variable conditions prevailing in the network at the time of operator inquiry, including load on the network element module (e.g., related to CPU usage percentage), bit error rate on a link between the monitoring module and the network element module, time of day when the event occurred, day of week when the event occurred, and whether the network element module is currently using back-up resources (such as a back-up power supply). The weighting components can also include a number of components relating to the attributes of the network element module or its status within the network (which also may vary), such as the relative importance assigned to the network element module, classification of data handled by the network element module (e.g., emergency or non-emergency traffic), geographic location of the network element module, size of the network element module (which may be related to the number of subscribers it can handle, for example), whether the network element module handles subscriber traffic or predominantly provides support for other network element modules, and the classification of users of the network (e.g., commercial versus domestic users). The use of intelligent and real-time weighting within the monitoring module and/or network element module automatically applies filtering criteria which are appropriate to the prevailing conditions within the network and the status of the network elements in the network. Accordingly, the operator need not independently analyze the conditions within the network or the characteristics of the network to assess what filtering criteria to apply to the notifications. The operator is thus placed in a good position to quickly receive and act on the most relevant alarms generated by the network at any given time. BRTEF DESCRIPTION OE THE DRAWINGS

The foregoing, and other, objects, features and advantages of the present invention will be more readily understood upon reading the following detailed description in conjunction with the drawings in which: Figure 1 shows the architecture of a prior art communication management system;

Figure 2 shows the conceptualization of an operating system and a network element according to object-oriented standards;

Figure 3 shows an exemplary monitoring module and a network element module constructed according to the present invention; and

Figure 4 shows an exemplary protocol for reporting notifications to the monitoring module according to the present invention.

PET ATT, ED DESCRIPTION

In the following description, for purposes of explanation and not limitation, specific details are set forth in order to provide a thorough understanding of the invention. However it will be apparent to one skilled in the art that the present invention may be practiced in other embodiments that depart from these specific details. In other instances, detailed descriptions of well-known methods, devices, and circuits are omitted so as not to obscure the description of the present invention with unnecessary detail. In the drawings, like numerals represent like features.

1. Overview

Fig. 3 shows an exemplary implementation of the present invention. The system includes a monitoring module 300 for receiving and monitoring notifications produced by a network element module (NE) 302. The monitoring module 300 can comprise any component, device, system, or software module for monitoring notifications. For instance, the momtoring module 300 can comprise an operations system used to monitor the operation of a communications network (such as a wireless or wired communications network). It may, for example, take the form a general purpose computer (e.g., a personal computer) programmed with appropriate software. However, the invention is not restricted to communications environments. The monitoring module 300 preferably includes a display 308 for presenting notification information to a human operator, memory (not shown) for storing notifications for later review, and processing logic (not shown) for formatting and analyzing notifications.

The term "notifications" generally refers to the communication of any network event from any event producer to any "consumer." The term encompasses alarms generated by the network element module 302. In the communications environment, the alarms include communication alarms associated with the procedure and/or process required to convey information from one point to another. Other communications alarms include equipment alarms, processing error alarms, quality of service alarms, various security alarms, etc. Other notifications may pertain to non-alarm conditions. For instance, notifications can include call traffic information which does not represent an out-of-tolerance condition.

The term "network element module" encompasses any entity capable of generating notifications in the context of any network. For example, the module may represent a base station (or some part thereof) in a radio communication network. The network element module 302 can be exemplarily defined with reference to any object-oriented network management standard, and may include a collection of managed objects (not shown) representing a number of resource objects (not shown). (Only one network element module is illustrated, although, in practice, many may be included.)

The network element module 302 includes one or more event producers 318. The event producers 318 generate notifications based on changes occurring within the network or prevailing conditions within the network. The network element module 302 can also be cascaded with additional network element modules (not shown), and may receive and forward notifications generated by those other network element modules. In one exemplary embodiment, alarms and other notifications can be stored in an alarm list 314. The alarm list 314 contains a list of alarm records. The network element module 302 creates a new entry in the alarm list 314 whenever an alarm is emitted (internally within network element module 302) that does not match any alarm in the alarm list 314. When an alarm is cleared, its corresponding entry in this list is removed. Each alarm is represented by an alarm ID which uniquely identifies this alarm from all other alarms generated by the network element module 302.

In a first embodiment, momtoring module (MM) weighting logic 305, broadcast logic 306, network element module (NE) weighting logic 310, and reporting logic 312 provide a dynamic mechanism for determining which notifications are forwarded to the monitoring module 300. The function of these modules is best explained within reference to the flowchart shown in Fig. 4. The flowchart begins in step 400 by determining whether the operator wishes to interrogate the network element module 302 to extract alarms and other notifications stored therein, e..g., in the alarm list 314. For instance, an operator can instruct the monitoring module 300 to interrogate the network element module 302 after the monitoring module 300 has remained inactive for a length of time.

If the "report notifications now" inquiry is answered affirmatively in step 400, the monitoring module 300 assigns priority thresholds to events occurring within the managed communications network in step 402. To perform this task, the MM weighting logic 305 modifies one or more default threshold values (T_def) by one or more weighting components (WC) to produce weighted priority threshold values (T_w). Then, in step 404, the broadcast logic 306 broadcasts the weighted threshold values to the network element module 302.

In step 406, the network element module 302 receives the priority threshold values. Then the NE weighting logic 310 calculates a final severity value (S_final).

Broadly stated, the final severity value represents a multi-factored assessment of the importance of events occurring within the network element module 302. The NE weighting logic 310 derives the final severity value using a technique similar to that employed by the monitoring module 300 in its calculation of the weighted threshold values. Namely, the NE weighting logic 310 derives the final severity value (S_final) by modifying a default severity value (S_def) by one or more weighting components (WC). The default severity value (S_def), in turn, is a default value characterizing the seriousness of events occurring within the network element module 302, which may depend, for instance, on the class to which an alarm belongs. The network element module 302 may store the default severity values in the alarm list 314 upon the occurrence of events within the event producers 318. In step 408, the reporting logic 312 compares the final severity value (S_final) with the weighted priority threshold value (T_w) broadcast by the monitoring module 300. If the final severity value exceeds the priority threshold value (i.e., S_final > T_w), the network element module 302 broadcasts a notification to the monitoring module 300 in step 410. Alternatively, the reporting logic 312 can forward a notification if the final severity value is greater than or equal to the priority threshold value (i.e., S_fiπal __ T_w).

The weighting components used by the NE weighting logic 310 generally pertain to conditions currently prevailing in the network element module 302 and/or to other attributes of the network element module 302 (such as the status of the network element module within the network). Accordingly, the relevancy assigned to events occurring within the network element module automatically varies with changing conditions in the network. This is a notable improvement over the methods described in the Background section. The prior art approach required the operator to manually assess the prevailing conditions in a network and then select an appropriate filter to extract the most relevant information. In the present approach, the network element module 302 automatically assesses the conditions and attributes of the network element modules and automatically adjusts the relevancy of events produced in the network element modules. Hence, the use of intelligence in the network element modules reduces the analysis required by the human operator and enables the operator to make more timely decisions. However, the operator still retains control over the nature and quantity of notifications transmitted by the network element module by setting and broadcasting the priority threshold values. The momtoring module's (MM) weighting logic 305 can use the same types of weighting components as the NE weighting logic 310, or some subset thereof. For example, both the MM weighting logic 305 and NE weighting logic 310 can include a weighting component which dynamically varies depending on time of day (however, the MM weighting logic 305 and the NE weighting logic 310 can vary their respective default values by differing amounts based on the time of day). In other embodiments, the MM weighting logic 305 may can include additional types of weighting components not used by the NE weighting logic 310. The combination of the MM weighting logic 305 and the NE weighting logic 310 provides a highly flexible mechanism for filtering notifications and alarms to suit different investigatory scenarios. In the method described in Fig. 4, the transmission of alarm notifications to the monitoring module 300 is prompted by the operator broadcasting priority threshold values to the network element modules (in steps 400, 402, and 404). Other protocols are envisioned. For instance, the broadcast logic 306 of the momtoring module 300 can download its priority threshold values in advance. The network element modules can then, at a later time, independently calculate final severity values. For instance, the network element module 302 can automatically calculate final severity values when triggered by events/alarms occurring within the network. Alternatively, the network element module 302 can automatically calculate final severity values at preselected reporting times. Still alternatively, the network element module 302 can calculate final severity values when the network element module 302 independently assesses that it should report its alarms (e.g., based on its own analysis of the nature and quantity of alarms). In any event, the final severity values can then be compared with the previously broadcast priority threshold values, and relevant alarms and notifications can then be reported to the monitoring module 300.

In still another alternative embodiment, the system can omit the MM weighting logic 305. Thus, the dynamic filtering is performed using solely the NE weighting logic 310. In this case, the broadcast priority thresholds are constant or can be manually modified by a systems operator. In still another alternative embodiment, the system can omit the NE weighting logic 310. Thus, the dynamic filtering is performed using solely the MM weighting logic 305. In this case, the reporting logic compares the default severity values with the broadcast priority thresholds.

2. First Example 5 According to a first exemplary implementation, the final severity value (S_final

) can be calculated using the NE weighting logic 310 by modifying a default severity value (S_de£) by a total weighting element (W_totaI). The total weighting element, in turn, is composed of one or more dynamic weighting components (i.e., W_total = WC₁ + WC_{2 +} . . . WC_n ). Hence, the final severity value (S_finaI) may be represented by:

i o s_final = W_total ^• S_def - (WC, + WC₂ + . . . WC_n) ^• s_def .

The NE weighting logic 310 can use the following exemplary components (WC). a. relative importance. A first weighting component (i.e., W ) pertains to the importance ascribed to the network element module in the network. One

15 example of a module with relatively high importance is a radio network controller which monitors a set of radio base stations, hi another more general example, plural network element modules may be cascaded such that a fault condition in one network element module propagates to others. The network element module which originated the fault may therefore be regarded as having an "important role." The

20 effect of this weighting component can be to enhance the severity of events produced by important network element modules (relative to other, less important network element modules). This, in turn, makes it more likely that an important network element module will forward its alarms to the monitoring module 300 (relative to other, less important network element modules).

25 b. load on the network element module. A second weighting component pertains to the load on the network element module. For example, in a communications network, a heavy load may indicate that many subscribers are using and relying on a network element module. An example of such a load-dependent module is a radio base station in a densely populated region. The effect of this weighting component can be to enhance the severity of events produced by heavily-used network element modules (relative to other, less heavily-loaded network element modules). This may ensure that heavily-used resources are preferentially serviced by the operator. c. power supply status. A third weighting component pertains to whether or not the module is cunently using back-up communications resources, such as a back-up power supply (e.g., a battery power supply). The effect of this weighting component can be to enhance the severity of events produced by network element modules using back-up resources (relative to other modules using standard resources). This may ensure that the modules closest to cessation of operation are serviced before others. d. error rate on link from the monitoring module to the network element module.

A fourth weighting relates to the bit enor rate on the link from the monitoring module 300 to the network element module. For example, in a communications network, a high bit error rate may indicate that the network element module associated with the high bit enor rate is providing substandard performance to subscribers or is on the verge of a more serious failure. The effect of this weighting component can be to enhance the severity of events produced by network element modules with high enor rates (relative to other modules with normal enor rates). This will help ensure that serious problems associated with the modules are addressed in a timely manner. e. type of data the network element module handles. A fifth weighting component pertains to the type of data that the network element module handles. For instance, some network element modules may routinely handle more emergency calls than other network element modules. The effect of this weighting component can be to enhance the severity of events produced by network element modules that handle higher priority calls and data (relative to other modules with more ordinary traffic). This will help ensure that critical communication services are not compromised before more routine subscriber traffic. Also, some network element modules may handle more voice information than data (e.g., facsimile information, etc.), or vice versa. Accordingly, these two different types of modules may have different alarm reporting requirements. The fifth weighting component can be used to provide selective weighting based on this consideration. f. geographic location of the network element module. A sixth weighting component pertains to the geographic location of the network element module. Certain geographic locations may have a history of serving more critical calls than others. For example, a network element module may serve a region including a law enforcement agency or hospital. The effect of this weighting component can be to enhance the severity of events produced by network element modules with such geographic-based importance, compared to, for instance, rural settings. g. time-based components. A seventh weighting component pertains to the time of day and/or day of week that an event occurs. Communications traffic predictably varies during the course of a day, and also varies from day to day. For instance, the communications network may routinely experience heavy loads at rush hour, but only light loads in night-time hours. Further, the communications network may routinely experience heavier loads during weekdays compared to weekends. Holiday communications traffic may present another predictable variance. The effect of this weighting component can vary depending on the precise communication environment and the policy objectives of the system operator. For example, it may be preferable to relatively diminish the severity of events occurring within the network during times of high data load so as not to inundate the operator with mid-level alarm notifications, allowing only the most serious alarms to reach the operator. h. size of the network element module. An eighth weighting component pertains to the size of the network element module. The effect of this weighting component can be used to relatively enhance or diminish the severity of module events depending on the communications environment and policy objectives of the network operator. For example, it might be preferable to enhance the relevancy of events generated by large network elements based on the assumption that it serves a more important role relative to other modules and may also serve more subscribers. i. type of service supported by the network element module. A ninth weighting component pertains to the role of the network element module, such as whether the module handles subscriber traffic or if the module functions primarily as support for other network elements. This criterion can be used to positively or negatively weight module event severity depending on the communications environment and policy objectives of the network operator. j. type of users. A tenth exemplary weighting component pertains to the type of users associated with a network element module. Again, the effect of weighting component can be used to positively or negatively weight module event severity depending on the communications environment and policy objectives of the network operator. For example, it might be preferable to weight the event severity associated with a module which predominately serves commercial users, as opposed to domestic users, or vice versa, depending on the contractual relationships that the operator has with these two respective groups of users and other policy-based components.

Different techniques may be appropriate for calculating different weighting components. For instance, the weighting component associated with load experienced by the network element module can be formed by multiplying a weighting factor (w_load) and a variable (Pι_oad) representing the actual load experienced by the network element. That is, WC_load = w_load ^• p_Ioad. The weighting component associated with power supply status can be calculated in a similar manner. However, in this case, the variable (p_power) representing the power supply status has discrete values of "0" or "1" depending on whether or not the network element module is using a backup power supply or not. In any case, the weighting components (WC) represent dynamically varying quantities. This is because the ■ variables (p) may change. Also, the weighting factors (w) vary. It follows that the total weighting element (W_total) is a dynamic quantity which changes depending on changing conditions in the network. In exemplary embodiments, the total weighting element (W_t0(aj) can be out of 100 points.

As indicated in the equation above, the total weighting element (W_total) is applied to the default severity value (S_def). The default severity value, in turn, reflects a severity level assigned to events reported by the event producers 318 (e.g., an integer-value severity level). The network element module 302 can assign the default severity level based on predefined scales or a look-up table depending on the class to which the alarm or notification belongs.

The above-described NE weighting logic 310 can be modified in a number of ways. For instance, all notifications with a default severity level over a prescribed threshold can be reported regardless of the weighting applied to the default severity level. For instance, the network element module 302 can report a default severity level having a level of 5 (out of 5) regardless of the weighting assigned by the NE weighting logic 310. Furthermore, the network element module 302 may be programmed to report a notifications if the total weighting element "W_total" exceeds a predefined threshold, for example, 50/100.

As yet a further modification, the network element module 302 can apply a feedback paradigm to adjust the values of the weighting components. For instance, an operator may expect a network element module 302 to forward notifications at a prescribed rate. If this rate is exceeded, the network element module 302 can adjust the values of its weighting components to reduce the number of notifications. Thus, whereas the "load" weighting component assesses the number of events occurring within network element module 302 (e.g., relating to the traffic load placed on the network element module 302), the feedback mechanism assesses the number of alarms and other notifications actually forwarded to the monitoring module 300.

Further, the operator may adjust the weighting component based on his or her independent analysis of their appropriateness in a given circumstance, or can entirely deactivate and reactivate the weighting components.

The above-identified list of weighting components is exemplary. A system operator may decide to include only a subset of the components or to include different components. Further, the MM weighting logic 305 of the monitoring module 300 can use the same types of components in calculating its priority thresholds which it downloads to the network element modules. In alternative embodiments, the system can omit either the MM weighting logic 305 or the NE weighting logic 310. In these embodiments, the dynamic weighting would be performed exclusively by either the NE weighting logic 310 or the MM weighting logic 305, respectively.

3. Second Example

The above-described first example modified the relevance of events in a network element module using a total weighting element (W_total) formed by adding multiple weighting components together. However, there are other ways of implementing the general principles discussed in Section No. 1. For instance, as a second example, the NE weighting logic 310 can use the following algorithm, expressed in pseudo-code, to calculate the final weighting (in the exemplary specific case ofa radio communication system) :

SHORTFALL = REQUIRED_FOR_TRAFFIC - AVAILABILITY

IF SHORTFALL > PREDEFINED THRESHOLD THEN CALCULATE_WEIGHTINGS SEND_ALARM

ELSEIF COVERAGE < DESIREDCOVERAGE THEN

CALCULATE_WEIGHTINGS

SEND_ALARM ELSEIF DEPENDANT_USERS = TRUE THEN CALCULATE_WEIGHTINGS

SEND_ALARM ENDIF

CALCULATE VΕIGHTINGS

TOTAL WEIGHTING = ALARM SEVERITY * SHORTFALL * IMPORTANCE * DETERIORATION

END CALCULATE_WEIGHTINGS

SENDALARM

IF TOTAL WEIGTHING > BROADCAST_REQUEST_THRESHOLD SEND ALARM ENDIF

END SEND ALARM The variable SHORTFALL is defined as the communications resources required to provide adequate service to subscribers at a particular time (i.e., REQUIRED_FOR_TRAFFIC) minus the resources that are available (i.e., AVAILABLE). If this SHORTFALL value is greater than a predefined threshold (i.e., PREDEFINED THRESHOLD) then the network element module 302 calculates the total weighting element (TOTAL WEIGHTING) in the CALCULATE_WEIGHTINGS subroutine and decides whether to send an alarm (or other notification) to the monitoring module 300 (as ascertained in the SEND_ALARM subroutine). The NE weighting logic 310 can select the value PREDEFINEDJTHRESHOLD using, for instance, a look-up table. This value can also be broadcast by the monitoring module 300. The calculation of the TOTAL WEIGHTING and decision to send an alarm is also triggered when the coverage provided by a network element module 302 or a subset of network element modules (i.e., COVERAGE) is below a prescribed threshold (i.e., DESIRED_COVERAGE). Coverage can be defined, for instance, as the coverage provided by a base station of a radio communications system. The calculation of the TOTAL WEIGHTING and decision to send an alarm is also triggered upon the ascertained existence of dependant users (i.e., DEPENDANT JSERS = TRUE). A dependant user situation exists when the alarm conditions in the network element module 302 propagate to other network element modules.

The CALCULATE_WEIGHTΓNGS subroutine consists of multiplying the values ALARM_SEVERITY, SHORTFALL, IMPORTANCE and DETERIORATION to produce the TOTAL WEIGHTING score. The ALARM_SEVERITY score conesponds to the default severity value discussed in the first example. The NE weighting logic 310 can determine this value by reference to a look-up table, which maps events occurring within the network element module to severity levels. The IMPORTANCE value can also be determined from a look-up table, and generally conesponds to the "relative importance" weighting component discussed above in the first example. The DETERIORATION value can likewise be determined from a look-up table. It conesponds to the length of time that a faulty condition has existed (i.e., its persistency) within the network element module 302.

The SEND_ALARM routine comprises the same analysis described above. Namely, the network module element 302 transmits a notification to the monitoring module 300 if the TOTAL WEIGTHING value exceeds the priority threshold value (BROADCAST_REQUEST_THRESHOLD) broadcast by the monitoring module 300.

The MM weighting logic 305 of the monitoring module 300 can use the same or similar algorithm to calculate its priority thresholds which it downloads to the network element modules. In alternative embodiments, the system can omit either the MM weighting logic 305 or the NE weighting logic 310. In these embodiments, the dynamic weighting would be performed exclusively by either the NE weighting logic 310 or the MM weighting logic 305, respectively.

4. Additional Alarm Processing Functionality Additional alarm processing functionality can be added to the system shown in Figure 3. Useful features can include the following, a. interactions with the alarm list

As previously discussed, the system in Fig. 3 can include an alarm list 314, which stores a record of the alarms occurring within the network element module 302. It includes an alarm ID identifying the alarms from all other alarms, as well as a number other attributes. The following table identifies a set of possible alarm attributes.

A number of possible operations are envisioned for extracting information from the alarm list 314. For instance, the operator can send a "subscribe" operation command to the network element module 302, which instructs the network element module 302 to forward all alarms upon their generation without subsequent intenogation from the network element module 302. After an operator has sent the "subscribe" command, the network element module 302 can forward newly registered alarms to the momtoring module 300 using a "notify new alarm" operation. When the state of a previously registered alarm has merely changed (e.g., from critical to major), the network element module 302 can notify the monitoring module 300 of such a change using the "the notify changed alarm" operation.

The operator can also receive all of the alarm records stored in the alarm list 314 using the "get alarm list" operation. Prior to retrieving the alarms in the alarm list 314, the monitoring module 300 can inquire as to the number of alarms in the alarm list 314 list using a "get alarm count" command.

The "subscribe" and "get alarm list" commands contain a number of parameters. These parameters can specify conditions used by the network element module 302 in processing and reporting alarms. For instance, according to the present invention, the commands can be adapted to specify whether the network element module 302 is to apply the weighting procedure discussed above to determine whether to forward an alarm notification, or which alarms go into the reported batch list, or whether the network element module 302 is to directly forward alarm notifications without weighting applied thereto (i.e., forward the default severity information). b. alarm correlation

The network element modules and or the monitoring module 300 can employ alarm conelation to reduce the number of alarms. Alarm conelation consists of detecting commonalties between alarms, determining the principal alarms, and discarding their side effects (e.g., redundant alarms). c. failure analysis processing

Fault diagnosis and recovery can be used at the momtoring module 300. Fault diagnosis consist of applying appropriate test sequences to the received alarms and notifications to locate the fault origin by reducing the number of suspicious components to a limited set containing, optimally, a single faulty component. Fault recovery consists of restoring the system to its normal operation either by isolating the faulty component or by repairing it.

5. Glossary

The following is a list of principal terms used in the specification and their respective definitions. Monitoring Module (MM). Any component, device, system, or software module for monitoring notifications.

Network Element Module (NE). Any entity capable of generating notifications in the context of any network. Default Threshold (T_deβ. A default threshold value produced by the monitoring module.

Default Severity Value (S_deJ). A default value characterizing the severity of an alarm or event.

Weighting Component (WC). A value used to adjust the weight of a default value.

Total Weighting Element (W_M . A value produced by combining one or more weighting components.

Weighted Threshold (TJ. A value produced by modifying the default threshold (T_def) by one or more weighting components. Final Severity Value (S_βm!). A value produced by modifying the default severity value (S_def) by one or more weighting components.

Variations of the above described principles will be apparent to those skilled in the art. All such variations and modifications are considered to be within the scope and spirit of the present invention as defined by the following claims.

Claims

WHAT TS CLAIMED TS:

1. A system for reporting notifications generated by a network, comprising: a network element module associated with one or more resource elements of the network, the network element module including: dynamic network element module weighting logic for weighting relevancy associated with at least one event occurring within the network element module using at least one weighting component to produce a final severity value, wherein the weighting component dynamically varies depending on changing conditions in the network; reporting logic for determining whether to transmit a notification based on the final severity value; and a monitoring module for receiving the notifications transmitted from the network element module.

2. The system according to claim 1, wherein the network element module weighting logic applies one or more of the following components to modify the relevancy associated with the at least one event occurring within the network: a) relative importance assigned to the network element module; b) load on the network element module; c) use of back-up resources by the network element module; d) bit enor rate on a link between the momtoring module and the network element module; e) classification of data handled by the network element module; f) geographic location of the network element module; g) time of day when the at least one event occurs; h) day of week when the at least one event occurs; i) size of the network element module; j) whether the network element module handles subscriber traffic or whether it predominantly provides support for other network element modules; and k) classification of users of the network element module.

3. The system according to claim 1, wherein the network element module weighting logic determines the final severity value by assessing a total weighting element, and by multiplying the total weighting element by a default severity value.

4. The system according to claim 3, wherein the network element module transmits notifications inespective of the total weighting element if the default severity level exceeds a predefined threshold.

5. The system according to claim 3, wherein the network element module transmits a notification based solely on the default severity level when the total weighting element exceeds a predefined threshold.

6. The system according to claim 1, wherein the reporting logic determines whether to send a notification to the monitoring module by comparing the final severity value with a priority threshold value.

7. The system according to claim 1, wherein the monitoring module includes monitoring module weighting logic for computing a priority threshold value depending on at least one dynamic weighting component.

8. The system according to claim 7, wherein the monitoring module includes broadcast logic for broadcasting the priority threshold value to the network element module, and the reporting logic determines whether to send a notification to the monitoring module by comparing the final severity value with the priority threshold value.

9. A network element module for reporting notifications generated in a network to a monitoring module, the network element module comprising: dynamic network element module weighting logic for weighting relevancy associated with at least one event occurring within the network element module by at least one weighting component to produce a final severity value, wherein the weighting component dynamically varies depending on changing conditions in the network; and reporting logic for determining whether to transmit a notification based on the final severity value.

10. The network element module according to claim 9, wherein the network element module weighting logic applies one or more of the following components to modify the relevancy associated with the at least one event occurring within the network: a) relative importance assigned to the network element module; b) load on the network element module; c) use of back-up resources by the network element module; d) bit enor rate on a link between the monitoring module and the network element module; e) classification of data handled by the network element module; f) geographic location of the network element module; g) time of day when the at least one event occurs; h) day of week when the at least one event occurs; i) size of the network element module; j) whether the network element module handles subscriber traffic or whether it predominantly provides support for other network element modules; and k) classification of users of the network element module.

11. The network element module according to claim 9, wherein the reporting logic determines whether to send a notification to the momtoring module by comparing the final severity value with a priority threshold value.

12. A monitoring module for receiving notifications generating by a network element module in a network, the monitoring module comprising: dynamic monitoring module weighting logic for weighting relevancy associated with at least one event occurring within the network by at least one weighting component to produce a priority threshold value, wherein the weighting component dynamically varies depending on changing conditions in the network; and broadcast logic for broadcasting the priority threshold value to at least one network element module.

13. A method for transmitting notifications from a network element module within a network to a reporting module, comprising the steps of: broadcasting a priority threshold value from the monitoring module to the network element module; at the network element module, weighting relevancy associated with at least one event occurring within the network element module by at least one weighting component to produce a final severity value, wherein the weighting component dynamically varies depending on changing conditions in the network; and at the network element module, determining whether to transmit a notification from the network element module to the monitoring module based on a comparison between the priority threshold value and the final severity value.

14. The method according to claim 13, wherein the weighting step applies one or more of the following relevancy components to modify the relevancy associated with the at least one event occurring within the network: a) relative importance assigned to the network element module; b) load on the network element module; c) use of back-up resources by the network element module; d) bit enor rate on a link between the monitoring module and the network element module; e) classification of data handled by the network element module; f) geographic location of the network element module; g) time of day when the at least one event occurs; h) day of week when the at least one event occurs; i) size of the network element module; j) whether the network element module handles subscriber traffic or whether it predominantly provides support for other network element modules; and k) classification of users of the network element module.

15. The method according to claim 13, wherein the weighting step determines the final severity value by assessing a total weighting element, and by multiplying the total weighting element by a default severity value.

16. The method according to claim 15, wherein the network element module transmits notifications inespective of the total weighting element if the default severity level exceeds a predefined threshold.

17. The method according to claim 15, wherein the network element module transmits a notification based solely on the default severity level when the total weighting element exceeds a predefined threshold.

18. The method according to claim 13, further including another weighting step, performed at the monitoring module, for computing a priority threshold value depending on at least one dynamic weighting component.

19. The method according to claim 18, further including a step of broadcasting the priority threshold value from the monitoring module to the network element module.