An initial view of Performance Management is described in [105]. This shows an example decomposition of Performance Management processes to identify essential information flows. It shows a slice through the Telecom Operations Map from a Performance Management point of view. This slice is applicable to Mobile Networks and other networks. Although the "slice" or view is quite large, it does not contain all interfaces or process activities that are related to Performance Management. It does however show the main processes and interfaces involved in Performance Management. Please refer to [105] for further detail.

During the lifetime of a 3GPP system, its logical and physical configuration will undergo changes of varying degrees and frequencies in order to optimise the utilisation of the network resources. These changes will be executed through network configuration management activities and/or network engineering, see TS 32.600. Many of the activities involved in the daily operation and future network planning of a 3GPP system require data on which to base decisions. This data refers to the load carried by the network and the grade of service offered. In order to produce this data performance measurements are executed in the NEs, which comprise the network. The data can then be transferred to an external system, e.g. an Operations System (OS) in TMN terminology, for further evaluation. The purpose of the present document is to describe the mechanisms involved in the collection of the data and the definition of the data itself. The Performance Management functional area concerns the management of performance measurements and the collection of performance measurement data across a 3GPP system. It defines the administration of measurement schedules by the Network Element Manager (EM), the generation of measurement results in the Network Elements (NEs) and the transfer of these results to one or more Operations Systems, i.e. EM(s) and/or Network Manager(s) (NM(s)). The management requirements have been derived from existing telecommunications operations experience. The management definitions were then derived from other standardisation work so as to minimise the re-invention factor. References are given as appropriate. The objectives of the present document are:

• To provide the descriptions for a standard set of measurements;
• To produce a common description of the management technique for measurement administration and result accumulation; and
• To define a method for the bulk transmission of measurement results across a management interface.

The definition of the standard measurements is intended to result in comparability of measurement data produced in a multi-vendor 3GPP system, for those measurement types that can be standardised across all vendors' implementations. As far as possible, existing standardisation in the area of Performance Management is re-used and enhanced where particular requirements, peculiar to the mobile telephony environment, have been recognised. Performance management is further specified in TS 32.400-series [53].

Fault Management is accomplished by means of several processes/sub-processes like fault detection, fault localisation, fault reporting, fault correction, fault repair, etc. These processes/sub-processes are located over different management layers, however, most of them (like fault detection, fault correction, fault localisation and fault correction) are mainly located over the Network Element and Network Element Management layers, since this underlying network infrastructure has the 'self healing' capabilities. It is possible, however, that some faults/problems affecting the telecom services are detected within the "Network and Systems Management" layer, by correlating the alarm/events (originated by different Network Elements) and correlating network data, through network data management. Network data management logically collects and processes performance and traffic data, as well as usage data. While the Fault Management triggered within the Network Element and NE management layers is primarily reactive, the Fault Management triggered within the Network and Systems Management layer is primarily proactive. Meaning triggered by automation rather than triggered by the customer; and this is important for improving service quality, customer perception of service and for lowering costs. Focusing on the Network and Systems Management layer, when a fault/problem is detected, no matter where and how, several processes are implicated, as described in Figure 6. Figure 6 taken from the Telecom Operations Map [100] shows an example of how Fault Management data can be used to drive an operator's service assurance process. Service assurance then becomes primarily proactive, i.e. triggered by automation rather than triggered by the customer. It is argued that this approach is crucial to improving service quality, customer perception of service and for lowering costs.

TOM assurance activities (and their associated interfaces) shown in Figure 6 can be associated with ITU-T TMN service components from TS 32.111-series [3] according to Table 1:

The TOM assurance example shown in Figure 6 also recognises that Performance Management data can also be used to detect network problems. The TOM assurance example also adds some detail to the Service Management Layer by showing how activities such as determining and monitoring Service Level Agreements (SLAs) and trouble ticket reporting are interfaced to the Network Management layer.

A 3GPP system is composed of a multitude of Network Elements (NE) of various types and, typically, different vendors, which inter-operate in a co-ordinated manner in order to satisfy the network users' communication requirements. The occurrence of failures in a NE may cause a deterioration of this NE's function and/or service quality and will, in severe cases, lead to the complete unavailability of the respective NE. In order to minimise the effects of such failures on the Quality of Service (QoS) as perceived by the network users it is necessary to:

• detect failures in the network as soon as they occur and alert the operating personnel as fast as possible;
• isolate the failures (autonomously or through operator intervention), i.e. switch off faulty units and, if applicable, limit the effect of the failure as much as possible by reconfiguration of the faulty NE/adjacent NEs;
• if necessary, determine the cause of the failure using diagnosis and test routines; and
• repair/eliminate failures in due time through the application of maintenance procedures.

This aspect of the management environment is termed "Fault Management" (FM). The purpose of FM is to detect failures as soon as they occur and to limit their effects on the network Quality of Service (QOS) as far as possible. The latter is achieved by bringing additional/redundant equipment into operation, reconfiguring existing equipment/NEs, or by repairing/eliminating the cause of the failure. Fault Management (FM) encompasses all of the above functionalities except commissioning/decommissioning of NEs and potential operator triggered reconfiguration (these are a matter of Configuration Management (CM), cf. TS 32.600). FM also includes associated features in the Operations System (OS), such as the administration of a pending alarms list, the presentation of operational state information of physical and logical devices/resources/functions, and the provision and analysis of the alarm and state history of the network. Fault management is further specified in TS 32.111-series [3].

This clause describes an architecture for security management of the TMN that is divided into two layers, as shown in Figure 7. No individual layer is dependent on any specific technology in the other one.