EP1299973A1 - Technique de surveillance d'un reseau utilisant une logique dynamique a base de regles - Google Patents

Technique de surveillance d'un reseau utilisant une logique dynamique a base de regles

Info

Publication number
EP1299973A1
EP1299973A1 EP01950189A EP01950189A EP1299973A1 EP 1299973 A1 EP1299973 A1 EP 1299973A1 EP 01950189 A EP01950189 A EP 01950189A EP 01950189 A EP01950189 A EP 01950189A EP 1299973 A1 EP1299973 A1 EP 1299973A1
Authority
EP
European Patent Office
Prior art keywords
network element
element module
weighting
module
network
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP01950189A
Other languages
German (de)
English (en)
Inventor
Gary Gubbins
Michael Kelly
Robert Thomas Lambert
Patricia Murphy
Barry O'driscoll
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Telefonaktiebolaget LM Ericsson AB
Original Assignee
Telefonaktiebolaget LM Ericsson AB
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telefonaktiebolaget LM Ericsson AB filed Critical Telefonaktiebolaget LM Ericsson AB
Publication of EP1299973A1 publication Critical patent/EP1299973A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q3/00—Selecting arrangements
    • H04Q3/0016—Arrangements providing connection between exchanges
    • H04Q3/0062—Provisions for network management
    • H04Q3/0075—Fault management techniques
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0823—Errors, e.g. transmission errors
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/16—Threshold monitoring

Definitions

  • 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.
  • 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.
  • Telecommunication Management Network Telecommunication Management Network
  • Object-oriented protocols such as those set forth in the ITU conceptualize the managed network as including one or more network elements (NE).
  • 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.
  • 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.
  • 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.
  • the technique includes broadcasting a priority threshold value from a monitoring module to a network element module.
  • 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 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.
  • 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).
  • 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 e.g., 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.
  • 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.
  • 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.
  • Figure 4 shows an exemplary protocol for reporting notifications to the monitoring module according to 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • network element module encompasses any entity capable of generating notifications in the context of any network.
  • 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.
  • 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.
  • 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.
  • the monitoring module 300 assigns priority thresholds to events occurring within the managed communications network in step 402.
  • 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 ).
  • the broadcast logic 306 broadcasts the weighted threshold values to the network element module 302.
  • 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 ).
  • 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 ) 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.
  • 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.
  • 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.
  • 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.
  • 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).
  • 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.
  • 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.
  • 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.
  • 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.
  • the system can omit the MM weighting logic 305.
  • the dynamic filtering is performed using solely the NE weighting logic 310.
  • the broadcast priority thresholds are constant or can be manually modified by a systems operator.
  • the system can omit the NE weighting logic 310.
  • the dynamic filtering is performed using solely the MM weighting logic 305.
  • the reporting logic compares the default severity values with the broadcast priority thresholds.
  • the NE weighting logic 310 can be calculated using the NE weighting logic 310 by modifying a default severity value (S de£ ) by a total weighting element (W totaI ).
  • W total WC 1 + WC 2 + . . . WC n .
  • the NE weighting logic 310 can use the following exemplary components (WC). a. relative importance.
  • a first weighting component i.e., W
  • W pertains to the importance ascribed to the network element module in the network.
  • a radio network controller which monitors a set of radio base stations
  • 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.”
  • 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).
  • a second weighting component pertains to the load on the network element module.
  • 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 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).
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the network element module 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.
  • 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.
  • 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.
  • the weighting components (WC) represent dynamically varying quantities. This is because the ⁇ variables (p) may change.
  • 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(a j) can be out of 100 points.
  • the total weighting element (W total ) is applied to the default severity value (S def ).
  • the default severity value 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.
  • 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.
  • 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.
  • 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.
  • 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
  • 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).
  • a predefined threshold i.e., PREDEFINED THRESHOLD
  • 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 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 priority threshold value BROADCAST_REQUEST_THRESHOLD
  • 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.
  • the system can omit either the MM weighting logic 305 or the NE weighting logic 310.
  • the dynamic weighting would be performed exclusively by either the NE weighting logic 310 or the MM weighting logic 305, respectively.
  • 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
  • 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.
  • 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.
  • the network element module 302 can forward newly registered alarms to the momtoring module 300 using a "notify new alarm” operation.
  • 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.
  • 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).
  • alarm correlation 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).
  • 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.
  • Monitoring Module Any component, device, system, or software module for monitoring notifications.
  • Network Element Module 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.
  • S deJ Default Severity Value
  • Weighting Component 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.
  • TJ Weighted Threshold

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

L'invention concerne une technique permettant la signalisation d'alarmes et autres notifications d'un module élément réseau à un module de surveillance. Cette technique utilise une technique dynamique à base de règles pour pondérer la pertinence des événements réseau et comporte la diffusion d'une valeur seuil de priorité du module de surveillance au module élément réseau. A réception de la valeur seuil de priorité, le module élément réseau pondère la pertinence associée à au moins un événement apparaissant dans le module élément réseau par au moins un composant de pondération pour produire une valeur de gravité finale. Le module élément réseau détermine ensuite s'il convient de transmettre une notification du module élément réseau au module de surveillance sur la base d'une comparaison entre la valeur seuil de priorité et la valeur de gravité finale. En variante, la valeur seuil de priorité est également calculée sur la base d'une procédure de pondération. Les composants de pondération utilisés par la procédure de pondération dans le module de surveillance et/ou le module élément réseau concernent généralement les conditions actuelles qui prévalent dans le module élément réseau et autres attributs du module élément réseau, tel que l'état du module élément réseau dans le réseau. En conséquence, la pertinence associée aux événements varie de façon automatique et dynamique avec les conditions de changement du réseau. L'utilisation du filtrage intelligent dans le module élément réseau fournit rapidement à l'utilisateur les alarmes les plus pertinentes apparaissant dans le réseau à un moment donné.
EP01950189A 2000-07-13 2001-07-13 Technique de surveillance d'un reseau utilisant une logique dynamique a base de regles Withdrawn EP1299973A1 (fr)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US61575800A 2000-07-13 2000-07-13
US615758 2000-07-13
PCT/SE2001/001632 WO2002007386A1 (fr) 2000-07-13 2001-07-13 Technique de surveillance d'un reseau utilisant une logique dynamique a base de regles

Publications (1)

Publication Number Publication Date
EP1299973A1 true EP1299973A1 (fr) 2003-04-09

Family

ID=24466686

Family Applications (1)

Application Number Title Priority Date Filing Date
EP01950189A Withdrawn EP1299973A1 (fr) 2000-07-13 2001-07-13 Technique de surveillance d'un reseau utilisant une logique dynamique a base de regles

Country Status (3)

Country Link
EP (1) EP1299973A1 (fr)
AU (1) AU2001271214A1 (fr)
WO (1) WO2002007386A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130080349A1 (en) * 2011-09-28 2013-03-28 International Business Machines Corporation Management and notification of object model changes

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8782203B2 (en) 2007-09-14 2014-07-15 International Business Machines Corporation Propagating accelerated events in a network management system
US20110098981A1 (en) * 2008-06-20 2011-04-28 Hanspeter Bobst Method and apparatus for processing measured values of parameters of a telecommunication network
US9049261B2 (en) * 2012-06-26 2015-06-02 Google Inc. Prioritized management and presentation of notifications

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2684472A1 (fr) * 1991-11-29 1993-06-04 Cit Alcatel Systeme expert supportant les contraintes du temps reel.
WO1995012291A1 (fr) * 1993-10-28 1995-05-04 British Telecommunications Public Limited Company Systeme de gestion du trafic dans un reseau de telecommunications
US5777549A (en) * 1995-03-29 1998-07-07 Cabletron Systems, Inc. Method and apparatus for policy-based alarm notification in a distributed network management environment

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
None *
See also references of WO0207386A1 *

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130080349A1 (en) * 2011-09-28 2013-03-28 International Business Machines Corporation Management and notification of object model changes
US9946988B2 (en) * 2011-09-28 2018-04-17 International Business Machines Corporation Management and notification of object model changes
US9946989B2 (en) 2011-09-28 2018-04-17 International Business Machines Corporation Management and notification of object model changes

Also Published As

Publication number Publication date
AU2001271214A1 (en) 2002-01-30
WO2002007386A1 (fr) 2002-01-24

Similar Documents

Publication Publication Date Title
US7504936B2 (en) Method and apparatus for dynamically prioritize network faults based on real-time service degradation
CN102396255B (zh) 动态移动网络通信控制
EP2537366B1 (fr) Configuration de l'état opérationnel de dispositifs sans fils tolérants au retard, basée sur le niveau de trafic de réseau d'un secteur particulier du réseau
US9009307B2 (en) Automated alert management
EP2544406B1 (fr) Procédé et agent de gestion pour la corrélation de notifications d'événements
CN108809679B (zh) 对网络节点的控制方法、装置及监控设备
CN101502144A (zh) 无线通信网络中的元件管理系统
CN107947998B (zh) 一种基于应用系统的实时监测系统
CN103309790A (zh) 移动终端监控方法和装置
US7209968B1 (en) System and method for recovering management of network element(s) responsive to failure of a distributed gateway
CN113438129B (zh) 数据采集方法及装置
JPH07183948A (ja) 通信システムで生じる事象を予測する規則を生成するデータの処理方法
US7120633B1 (en) Method and system for automated handling of alarms from a fault management system for a telecommunications network
WO2004004249A1 (fr) Procede et appareil d'estimation de charge et de commande d'admission d'appels dans un environnement de traitement d'appel
EP1622310A2 (fr) Système de gestion pour des systèmes de gestion de réseau
EP1299973A1 (fr) Technique de surveillance d'un reseau utilisant une logique dynamique a base de regles
CN101695049A (zh) 一种监控系统中的业务处理方法及装置
US20040213215A1 (en) IP telephony service system and accounting method
CN114615337B (zh) 设备调度方法、系统、服务器及存储介质
CN113824595B (zh) 链路切换控制方法、装置和网关设备
CN112004161B (zh) 地址资源的处理方法、装置、终端设备和存储介质
CN101163040A (zh) 一种自动向用户通知被监控设备连接状态的方法
CN116203855B (zh) 换电柜仓位控制方法、装置、设备及存储介质
KR101146836B1 (ko) 매니저 고장시 관리 네트워크를 운영하기 위한 방법 및설비들
JP2006146303A (ja) アクセス管理機構

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20021217

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE TR

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE TR

AX Request for extension of the european patent

Extension state: AL LT LV MK RO SI

RIN1 Information on inventor provided before grant (corrected)

Inventor name: O'DRISCOLL, BARRY

Inventor name: MURPHY, PATRICIA

Inventor name: LAMBERT, ROBERT, THOMAS

Inventor name: KELLY, MICHAEL

Inventor name: GUBBINS, GARY

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: TELEFONAKTIEBOLAGET LM ERICSSON (PUBL)

17Q First examination report despatched

Effective date: 20061222

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN WITHDRAWN

18W Application withdrawn

Effective date: 20070219