ion is programed to respond with a corrective action when a fault is detected. The management application can send commands to the network elements (southbound), send mail to concerned experts (northbound), or restart processes on the management application server. Thus in automatic method interaction with northbound interface, southbound interface, or to self is possible. Fault information is presented as a log or alarm in the GUI. A log can represent nonalarm situations like some useful information for the user. A log specifying that an audit was performed on a network element is an info log and does not raise an alarm. An alarm or log usually has several parameters (see Table 3.1). A detailed set of alarm parameters for specific networks are available in 3GPP specification 32 series on OAM&P. Having discussed the basic fault functionality, let us look into some applica- tions that are developed using the fault data that is detected and displayed. Some of the applications that can be developed using fault data are: Fault/event processing Fault/event filtering Fault/event correlation Event Processing: There are three types of event processing: simple, stream, and complex. In simple event processing when a particular event occurs, the manage- ment application is programed to initiate downstream action(s). In stream event processing, events are screened for notability and streamed to information subscrib- ers. In complex event processing (CEP) events are monitored over a long period of time and actions triggered based on sophisticated event interpreters, event pattern definition and matching, and correlation techniques. Management applications built to handle events are said to follow event driven architecture. Fundamentals of EMS, NMS and OSS/BSS Table 3.1 Parameters in an Alarm/Log Parameter Description Notification The same alarm can occur multiple times. An easy way to track an alarm is using its notification ID. Alarm ID A particular error condition is associated to an ID. For example we can have CONN100 as t