o track down the source of the problem and to solve it. It is wasteful for staff to spend time on finding out how to resolve a problem after the problem has arisen because, at that point, all efforts should be directed towards fixing the problem. The architecture of the fault management system addresses these issues by allow- ing filters and parsers to be plugged in easily. Filters help validate notifications received from the various managed elements and also apply domain-specific rules to notifications. Rules can be structured to validate the incoming events based on time, thresholds or number of events. For example, transient or temporary and self- correcting system failures occur as a normal part of network operation. Rules can be useful in these circumstances for filtering out transient network failures. This helps reduce thousands of events to 10-20 real problems that need to be addressed. Parsers disseminate the raw data so that concerned parties quickly receive a meaning- ful interpretation. OSS for Telecom Networks Client External FE Tier Application Session Handing Security & Audit Application Event Root Cause Performance Auto Fault Correlation Analysis Metrics Rectification Alert Notification Modelling Validation Actions Alerts Rules & Filters Event Notification Modelling Validation Actions Events Rules & Filters Inputs Network Notifications Inputs [Discovery, Status poll, CORBA Threshold,...] Fault Back End Server Architecture Figure 12.2 Fault management information flow. FMS allows automated action to be taken at various levels of the event flow. The actions supported out-of-the-box47 include e-mail, paging, command execution and custom actions. Apart from the automated actions, FMS has a formal notification mechanism. In particular, external applications can register with FMS for notifi- cations. Registered applications are notified during the various stages of event flow. An RDBMS is used as the persistence layer which facilitates achieving the high level goals of availability, scalability, perfor