raffic to be rerouted in the event of a cable fault, while not breaching other service parameters imposed on network traffic. In some networks, the NEs detect a cable break and send that information to the OSS. The OSS then calculates that particular paths have been affected (namely OSS for Telecom Networks fault somewhere in dashed sub-path fault localisation fault localised to dashed link Figure 2.13 Fault management function - localisation of the fault in Figure 2.12. the paths between the NEs which detected the cable break) and the OSS will send a command to reroute traffic. Some OSS can be programmed to suggest the best stand-by path at the time the main path is provisioned or after a fault occurs. Situations in which the quality of a leased line proves to be too low may also occur. The OSS then triggers an alarm before any rerouting is initiated. A command by the OSS to NEs to reroute traffic is generally executed within seconds. 2.6 Fault Management Fault management comprises network monitoring, fault isolation and network testing. Staff at the NOC can decide which details of a fault are to be reported to their manager, reported to the customer and stored in case there is a need for future reference. Staff at the NOC also define the events and criteria which will trigger an alarm and how alarms should be displayed on the alarm list and at the work- station. We shall see just how detailed these options can be in the discussion of the fault management product from AdventNet in Chapter 12. The OSS can localise the fault after an alarm is triggered. If a DXC issues an alarm, an OSS staff member sitting at his/her workstation can detect and identify a faulty printed board assembly, for example by scrolling the network picture for the DXC concerned. A work order would then be raised to replace the faulty board. A different procedure would be more appropriate for an increased BER since increased BER might be caused by a fault in a signal regenerator. Once it is known that the BER has increased, measurements would