Fault Manager

Executive summary:

There are many fault management systems on the market today and most are fairly predictable in their touted feature set. So REWSS has designed its own Fault Manager to offer features and functionalities not often found in other similar products.

While most similar products simply collect all system generated alarms and draw focus to those with the highest severity. Some will even go so far as to filter away the less severe alarms since they are tagged (often incorrectly) as mere side effects of the more severe alarms. And almost all only pay attention to the current or recent alarms.

The REWSS approach is to collect everything and ignore nothing. Additionally, REWSS does not just consider the 1-off instance of receiving an alarm with a known severity level. REWSS maintains a historical log of all system generated alarms and uses this as a basis for establishing historical trends of alarming activity. The power of this lies in the ability to not only detect when an alarm is received but also to know if the frequency rate at which the alarms are being received is in line with expected levels. As an example, consider a low-level (low severity) alarm that is typically generated by a switch at a rate of 5 per hour. In and of themselves these alarms are not too interesting because of their low severity levels. But if the switch suddenly starts generating those alarms at a rate of 50 per hour then this should certainly be noticed and investigated because it means that something has just changed on the network which could indicate a fault of some sort. This is where the REWSS Fault Manager excels, by making available several interfaces that not only show alarm occurrences but also show the frequency that they occur at.

With this more intelligent approach to evaluate system generated alarms, REWSStools® have a greater degree of accuracy in identifying customer affecting issues.

Furthermore, the REWSS Fault Manager does not stop at only the alarm events. In a similar fashion, REWSS collects other spontaneous data like MML, failed calls, statistical call samplings, etc … which can all be useful data sources for detecting and diagnosing network faults. Sometimes, the patterns of calls in these reports can indicate a network problem equally as fast or faster than the system generated alarms.

The value for the operator:

• Improved MTTR through better fault detection and diagnosis mechanisms
• Simple GUI to highlight trends in alarm activities
• Built in intelligence to evaluate frequency of occurrence instead of just the alarm itself
• Broader spectrum of data sources for correlation with system generated alarms