5i' FASCICLE IV.1 Recommendations M.10 to M.782 GENERAL MAINTENANCE PRINCIPLES MAINTENANCE OF INTERNATIONAL TRANSMISSION SYSTEMS AND TELEPHONE CIRCUITS Blanc MONTAGE: PAGE 2 = PAGE BLANCHE INTRODUCTION Recommendation M.10 GENERAL RECOMMENDATION CONCERNING MAINTENANCE To enable Administrations to cooperate effectively in main- taining the characteristics required for the international telecom- munication services, the relevant CCITT Recommendations, which are based on long experience, should be applied. Recommendation M.15 MAINTENANCE CONSIDERATIONS FOR NEW SYSTEMS 1 General To ensure that new systems are implemented so as to permit compatible international operation and maintenance in the most effective manner, the following guiding principles are indicated. 2 Principles 2.1 When a new system is being studied, early consideration should be given to operational and maintenance requirements. 2.2 The maintenance organization and maintenance facilities (including test equipment) should be considered early enough to ensure their availability when the new system is introduced. 2.3 In order to reduce total (lifetime) costs and to improve the efficiency of maintenance, new systems should be provided with internal supervision and fault localization functions. Such func- tions reduce the number and type of external test equipment to a minimum, and make it possible to omit most external routine tests. 2.4 Where existing maintenance procedures, for example fault reporting, are not appropriate, alternative procedures should be considered early enough to ensure their application when the new system is introduced. However, any new procedures should consider established maintenance principles accepted by the CCITT. Blanc Recommendation M.20 MAINTENANCE PHILOSOPHY FOR TELECOMMUNICATIONS NETWORKS (The principles described in Recommendation M.21 should also be taken into account.) 1 General 1.1 Maintenance involves the whole of operations required for setting up and maintaining, within prescribed limits, any element entering into the setting-up of a connection (see Recommendation M.60) program the maintenance operations required to _________________________ establish and maintain an analogue, digital or mixed network, the following general strategy is recommended. 1.1.1 A maintenance organization should be established using the guiding principles set forth in Recommendations M.70 and M.710 for automatic circuits switched over analogue, digital and mixed networks. In addition, the concept of control and subcontrol sta- tions found in Recommendations M.80 and M.90 for international cir- cuits and transmission systems should be implemented. 1.1.2 The strategy should include the following maintenance operations considerations: a) It should consider the evolution of the network from the present highly analogue environment to the future almost wholly digital environment. In doing this, it must consider the new services and functions offered by the networks (e.g. CCITT Signal- ling System No. 7 and ISDN) and the maintenance tools and capabili- ties becoming available (e.g. performance monitoring). b) It should employ an overall maintenance philoso- phy that uses the maintenance entity concept, failure classifica- tion and network supervision process specified in S 3. c) It should provide for the maintenance of the network systems, equipment and circuits during the following activities: - installation and acceptance testing (S 4); - bringing into service (S 4); - keeping the network operational (S 5). It should support other maintenance activities (S 6) asso- ciated with the administration of maintenance operations (e.g., data bases, spare parts, failure statistics, etc.) along with a detailed plan for preventive maintenance, where required, on the various telecommunication equipments. d) It should have as a major aim to minimize both the occurrence and the impact of failures and to ensure that in cause of failure: - the right personnel can be sent to - the right place with - the right equipment - the right information at _________________________ It is recognized that for some Administrations, bring- ing into service is not considered to be part of maintenance. - the right time to perform - the right actions. 1.2 To apply this general strategy in a network, the following principles can be used: Preventive maintenance The maintenance carried out at predetermined intervals or according to prescribed criteria and intended to reduce the proba- bility of failure or the degradation of the functioning of an item. Corrective maintenance The maintenance carried out after fault recognition and intended to restore an item to a state in which it can perform a required function. Controlled maintenance A method to sustain a desired quality of service by the systematic application of analysis techniques using centralized supervisory facilities and/or sampling to minimize preventive maintenance and to reduce corrective maintenance. 1.3 In general for all three types of network (analogue, digi- tal and mixed), the use of controlled maintenance principles is recommended, i.e., the maintenance actions are determined on the basis of information generated in the maintained system or coming from auxiliary supervision systems. 1.4 The advantages of the controlled maintenance approach are that it directs future maintenance activity to those areas where a known improvement in service to the customer will be achieved. The monitoring techniques which are inherent in controlled maintenance provide data which simplify the identification of hidden faults by using statistical analysis. 1.5 The smaller the portion of the network which is affected by a failure, the more difficult and/or less economic it may be to detect it using controlled maintenance techniques. In these cases corrective and/or preventive maintenance techniques may have to be employed. 1.6 In analogue and mixed networks a mixture of the above-mentioned principles are used, depending on the existing equipment included in the network (see Recommendations M.710, M.715 to M.725). 1.7 The maintenance philosophy and fundamental principles are closely linked to: - availability performance; - network technical performance; - network economics. 2 Maintenance objectives 2.1 Purpose The main purpose of a general maintenance philosophy for analogue, digital and mixed networks is to accomplish the aims defined in S 1.1. In addition the following objectives should be fulfilled: - For a defined level of service the total cost should be kept to a minimum by the use of appropriate methods (e.g. centralized operation and maintenance). - The same maintenance philosophy should be applied to exchanges, transmission equipment, data equipment, subscriber terminals, etc., wherever possible. 2.2 Economics New technology provides new possibilities for low cost mainte- nance not only for individual exchanges, but for the whole network, e.g. using the same technology for both transmission and switching. The operation and maintenance functions in a network should be planned in such a way that the life cost will be a minimum. For a defined level of service the total cost consists of: - investment cost - operations cost - maintenance cost - cost for loss of traffic. 2.3 Transition from analogue to digital networks The basic philosophy, as described in this Recommendation, is valid in principle, for analogue, mixed and digital networks. How- ever, many digital network parts are more suited to the implementa- tion of controlled maintenance than are analogue network parts. Due to new technological developments maintenance functions can be incorporated within the digital equipment. Analogue equipment often requires additional external maintenance systems in order to permit controlled maintenance, e.g. ATME No. 2 (Recommendation O.22 [1]). 2.4 Centralized maintenance operations The introduction of digital telecommunications equipment with enhanced maintenance operations functions, including the facility for remote reporting and control, provides new opportunities for centralization. Supplement No. 6.2 [2] provides a description of a centralized maintenance organization. There are many benefits that can be gained from centralization. These include the ability to: - be more flexible in the organization of mainte- nance operations and administration; - utilize highly skilled mechanical resources more efficiently; - utilize more effectively data and data bases; - improve maintenance effectiveness; - decrease maintenance costs; - increase the availability of transmission and switching systems; - improve quality of service. Note - By the use of remote terminals, an Administration can choose how they allocate their technical staff between local and centralized locations. Because of these benefits, it is recommended that centralized maintenance and other operations capabilities be considered when specifying new telecommunications systems and equipments. The gen- eral principles for setting-up, operating and maintaining a Telecommunication Management Network (TMN) to support centralized maintenance and other operations are given in Recommendation M.30. 3 Overall maintenance philosophy 3.1 Maintenance entity concepts In order to facilitate efficient maintenance, the telecommuni- cation network (analogue and digital) is divided into parts, called Maintenance Entities (MEs), Maintenance Entity Assemblies (MEAs) and Maintenance Sub-Entities (MSEs). Examples of MEs, MEAs and MSEs are given in Figures 1, 2 and 3/M.20. Figure 1/M.20, p. 1 Figure 2/M.20, p. 2 Figure 3/M.20, p. 3 3.1.1 Definition of Maintenance Entity Maintenance entities are defined by the following principles: - The different equipments of a telecommunications network constituting the MEs are interconnected at consecutive and easily identifiable interface points at which points the interface conditions defined for these equipments apply and which possess the means of detecting maintenance events and failures. - If the telecommunication equipment supports bidirectional transmission, it normally consists of telecommunica- tions equipment transmitting in both directions and then both directions are considered part of the same ME. - When a failure occurs within a network, it is desirable that the maintenance alarm indication appears at the failed maintenance entity. When this is not practical, the indica- tion should appear at the closest possible entity. - Maintenance alarm information indications in an entity should not cause related alarm information indications at other entities. In the event that such indications are permitted to occur, they should clearly indicate that the failure has occurred upstream, and not in the other entities displaying the information. Meeting these four principles ensures that the responsible maintenance personnel are called into action, and that usually no unnecessary maintenance activity is initiated elsewhere. In an integrated digital network, for example, easily identif- iable points may be provided by digital distribution frames. Even in a location where no digital distribution frame is provided, an equivalent point, where defined interface conditions apply, will _________________________ If an easily identifiable interface point is not avail- able, the interface point may be replaced by a point permitting sectionalization with functions such as, e.g., looping-back or performance monitoring. normally be identifiable. The interface between the exchange termi- nals and the digital switch may be accessed on a virtual basis. 3.1.2 An ME has to perform a determined function between transmission interfaces (see Figure 4/M.20). The performance is checked by internal failure detection and conveyed to the mainte- nance interface either automatically after a failure occurrence, or after a request for maintenance information. Figure 4/M.20, p. In addition, other operations and administrative functions may be carried out by the maintenance interface. Several types of maintenance interfaces are described in Recommendation M.30 which covers the TMN. 3.1.3 Definition of Maintenance Entity Assembly A maintenance entity assembly (MEA) is defined by the follow- ing principles: - An MEA contains a group of MEs assembled for additional maintenance purposes. - Principles that apply for MEs apply also for MEAs. - An MEA may detect failures and maintenance event information which can not be detected by MEs. - An MEA may provide end-to-end maintenance alarm information which can not be provided by MEs. End-to-end information may be collected by using additional supervision means. 3.1.4 Defintion of Maintenance Sub-Entity (MSE) A maintenance sub-entity is defined by the following princi- ples: - The different parts of an MSE constituting the MEs are interconnected at consecutive and easily identifiable interface points. - When a failure occurs within an MSE, it is desir- able that the maintenance alarm information indication appears at the failed maintenance entity containing the MSE. - An failed MSE should be identified as failed by the fault location process, but should lead only to the identifica- tion of the failed ME by the supervision process. - An MSE generally corresponds to the item which is replaceable during routine operations in the event of a failure. 3.1.5 The choice of ME, MEA and MSE should be compatible with the maintenance organization of an Administration (Recommendations M.710, M.715 to M.725). 3.1.6 Relationship between Maintenance Entities and Network Elements The relationship between maintenance entities and network ele- ments is defined in Recommendation M.30. 3.2 Failure concepts The following definitions and classifications are used in developing the concept of a failure. 3.2.1 Anomalies An anomaly is a discrepancy between the actual and desired characteristics of an item. The desired characteristic may be expressed in the form of a specification. An anomaly may or may not affect the ability of an item to perform a required function. As an example, for a multiplexer one type of elementary infor- mation that can be detected is an error in the frame alignment word. This elementary information is an anomaly. More examples of anomalies are given in Recommendation M.550. 3.2.2 Defects A defect is a limited interruption in the ability of an item to perform a required function. It may or may not lead to mainte- nance action depending on the results of additional analysis. Successive anomalies causing a decrease in the ability of an item to perform a required function are considered as a defect. As an example, the G.700 [3] series recommends that three consecutive errored frame alignment words will give a loss of frame alignment. This loss of frame alignment is a defect. More examples of defects are given in Recommendation M.550. The process of using anomalies and defects is explained in S 3.3. 3.2.3 Failures A failure is the termination of the ability of an item to per- form a required function. Analysis of successive anomalies or defects affecting the same item can lead to the item being considered as "failed". 3.2.3.1 Classification of failures The severity of the failure depends on the failure effect. This effect can be related to: - the network service performance requirements as experienced by the subscribers; - the probability that multiple failures will occur, thus resulting in a deteriorating performance as seen by the customer; - the probable loss of revenue to the Administra- tion. The failures can be classified according to their importance and consequences to the quality of service provided to the sub- scribers and to the network technical performance: - failures which result in complete interruption of service(s) for one or several subscribers; - failures which result in partial interruption of service(s) (e.g. degradation of transmission quality) to one or several subscribers; - failures which decrease the availability perfor- mance of the equipment and/or the network but do not affect the subscribers. - A failure can be either a permanent or intermit- tent condition and this may alter its effect on the network. - The severity of a failure can be determined by measuring the down time, up time and failure rate of the ME. These items are defined in Supplement No. 6 to Fascicle II.3 [4]. 3.2.4 Fault A fault is the inability of an item to perform a required function, excluding that inability due to preventive maintenance, lack of external resources or planned actions. Note - A fault is often the result of a failure of the item itself, but may exist without prior failure. 3.3 Network supervision Network supervision is a process in which the anomalies and defects detected by the maintenance entities ME or MEA are analyzed and checked. This analysis may be internal or external to the entity. In the external case it can be accomplished either locally or on a centralized basis. For maintenance, this supervision process has to include the following actions: a) Locating "failed" equipment, or the equipment in which a fault is suspected or a failure is believed to be imminent. It is generally carried out by analytical or statistical identifi- cation processes. The supervision process consists of three con- tinuously running concurrent processes: - the supervisory process for anomalies (short period), - the defect supervisory process (medium period), and - the malfunction supervisory process (long period). Each process is interfaced by the characteristic data, e.g. accumulated anomaly data and accumulated defect data. The supervisory processes for anomalies and defects respectively, indi- cate that the anomaly or defect states have been reached. The mal- function supervisory process evaluates the performance level of the maintenance entity and judges it to be normal, degraded or unac- ceptable. These levels are determined from the anomalies and defects received and analyzed over a given time. The thresholds limiting degraded or unacceptable performance limits and the pro- cess period are defined for each defect and confirmed fault or group of anomalies and defects and also for each type of entity. Indications of degraded and unacceptable performance levels are generated each time the corresponding threshold is exceeded. This process is shown in Figure 5/M.20. b) Reporting of failures to maintenance personnel. c) Transmission of data to the maintenance person- nel, relating to specific functional features of the network (traffic, state of equipment, particular malfunctions, etc.). This information can be transmitted systematically or on demand. d) Protecting the system by transmitting to all concerned network equipment the necessary information for automatic initialization of internal or external protection mechanisms, e.g., reconfiguration, traffic rerouting, etc. e) Modify the supervision process due to: - the type of service being offered over a given portion of the network; - the time of day. Figure 5/M.20, p. 4 Bringing new international transmission systems and circuits into service 4.1 Installation and acceptance testing For new systems, this work may include the necessary installa- tion of new equipment. Once the new equipment is working, the Administration should make the necessary tests to ensure the new system meets required specifications. Acceptance testing of the new system or equipments should be based on policies established by the Administration. However, Administrations may wish to use the per- formances monitoring techniques found in Recommendation M.24 to aid in their acceptance testing of new transmission systems. 4.2 Setting-up and lining-up As soon as Administrations have decided to bring a new inter- national transmission system and/or circuit into service, the necessary contacts are made between their technical service for the exchange of information. Those services jointly select the control and sub-control stations for the new system or circuit (see Recommendations M.80 and M.90). The technical service of each Administration is responsible for the setting-up and lining-up of the line or circuit sections in _________________________ Installation and acceptance testing is not generally considered part of maintenance. its territory, and for arranging that the adjustments and tests required are made by the station staff concerned. 4.3 Detailed considerations To set-up a line section or circuit which crosses a frontier, Administrations should arrive at bilateral agreements on the basis of CCITT Recommendations and, for radio-relay sections, the Recom- mendations of the CCIR. Administrations should refer to the follow- ing Recommendations for detailed considerations associated with bringing into service the following entities: 4.3.1 New transmission systems CCITT Volume IV, S 2.3, Recommendations M.450 through M.480 and M.24. 4.3.2 Telephone circuits CCITT Volume IV, S 3.1, Recommendations M.570 through M.590. 4.3.3 Common channel signalling systems CCITT Volume IV, S 4, Recommendations M.761 and M.782. 4.4 Bringing into service After the control station has determined from reports provided by the subcontrol station that appropriate tests and adjustments have been performed, the control station conducts overall tests of the system or circuit. The overall tests results are recorded, operations systems data bases are updated and synchronized between Administrations, and the system and/or circuits are placed in ser- vice. At this time the system and/or circuits are transferred to a performance measuring state (see S 5.1) to track and insure their continuing proper operation. 5 Maintenance phases under normal and fault conditions Under normal conditions in the network, performance informa- tion should be gathered from MEs on a continuous or periodic basis. This data can be used to detect acute fault conditions which gen- erate alarm reports. Further analysis may reveal subtle degrada- tions which generate maintenance information reports. After the occurrence of a failure in the network, a number of maintenance phases are required to correct the fault and to pro- tect, when possible, the traffic affected by the fault if it has been interrupted. As an example, Figure 6/M.20 lists the maintenance phases which are involved before and after a failure occurrence in a maintenance entity (ME). The parameters determining the different phases are indicated in the figure. It is intended to characterize different maintenance strategies with the aid of the maintenance phases. The mechanics used to implement the various maintenance processes should be defined in connection with each specific appli- cation in the relevant Recommendations. The maintenance phases are described below in more detail. Figure 6/M.20, p. 5.1 Performance measuring Different types of performance measuring mechanisms can be used: a) continuous checking, b) routine or periodic testing, c) checking of behavior in live traffic, d) checking of behavior in the absence of live traffic. The rules governing the measurement mechanisms are defined when conceiving the systems; no intervention of the maintenance personnel is necessary. Under some conditions, however, the person- nel can control some operations which may prove necessary for periodic or casual checking, such as: - modifying the priority level of a checking pro- cess; - modifying the nominal period in the case of periodical checking; - carrying out some partial or recurrent checks (e.g. test on demand). The choice of a measurement mechanism depends on the require- ments for the "quality of service" as seen by the subscribers, and on the technical network performance and the nature of the equip- ment. In addition, several mechanisms may be operated in the same item of equipment. Typical measurement mechanisms are listed below. 5.1.1 Continuous checking All the time an item is active, it is being checked for good performance. If the item does not fulfill the test requirements, it is considered to have failed. 5.1.2 Routine or periodic testing Items are tested periodically, initiated either by the system or by the maintenance staff. The frequency of the test depends on the importance of the item, the failure rate and the number of items of that type present in the element. 5.1.3 Checking in live traffic Checking behavior in live traffic can be done directly or sta- tistically. This checking exists if the ME itself indicates a failed per- formance or the continuous detection of anomalies or defects. All of the elementary information from the different detectors is either retransmitted by each entity to a processing unit or pro- cessed locally. Performance parameters are derived from this information. 5.1.3.1 Processing of performance parameters Some performance parameters in use are Errored Seconds (ES), Severely Errored Seconds (SES) and Degraded Minutes (DM). These particular parameters are defined in Recommendation G.821 [5]. Each of the performance parameters (e.g., ES, SES, DM) is to be processed separately in order to evaluate the performance level of the entity's operation. 5.1.3.2 Evaluation of unacceptable performance Unacceptable performance is characterized by a significant and long-lasting degradation in quality. It can be associated with the failed state. It is ascertained by statistical analysis of each of the per- formance parameters individually, throughout a given time T1. As soon as the result of statistical analysis reaches a N1 threshold (defined for each entity individually), the entity is declared to be at an unacceptable level of performance. Elsewhere, for each defect corresponding to an interruption, lasting x consecutive seconds, the entity is considered as having reached an unacceptable level. 5.1.3.3 Evaluation of degraded performance Each of the performance parameters is analyzed statistically over a time T2 which can be a relatively long period. As soon as the result of statistical analysis reaches a N2 threshold (to be defined), the entity can be considered to be at degraded performance. The time T2 will depend on the entity in question. This checking leads to maintenance decisions on statistical grounds: - the number of times in which the item performs its function "normally" is compared with the number of times the performance of the item does not fulfill the requirements; - the average time of functioning is compared with standard values; - the number of times an item performs its function during a certain period is compared to normal values. If the degraded performance level is characterized by a gra- dual degradation in quality, the maintenance personnel should be informed before this decrease in performance becomes unacceptable to the user. 5.1.4 Checking in the absence of live traffic (traffic is zero) Checking of system internal functions is done once a process is over, or when a process has been initiated several times. Exam- ples are operational checks which start when a customer initiates an action to use the network. 5.2 Failure detection Failures should be discovered by the Administration indepen- dently of, and preferably before, the subscriber, i.e., the major- ity of failures are both detected and remedied without the sub- scriber having been aware of them. Failures are classified depending on their nature (see S 3.2) and may be categorized depending on their severity. Corresponding maintenance alarm information is then passed on to the appropriate entities. 5.3 System protection When a failure has occurred or performance has degraded, the following functions must be performed: - as a result of the medium and longer period supervision process a signal must be transmitted to all the con- cerned network equipment of any necessary information for automatic (preferred) initialization of internal or external protection mechanisms, e.g., reconfiguration, traffic rerouting, etc.; - decision on any necessary actions, e.g. putting an item "out of service" or "in testing condition", changing to a configuration with minimal or degraded service. A specific protection method is recommended for transmission systems using manual or automatic restoration on a maintenance entity basis: a) If a failure occurs either in maintenance enti- ties without automatic changeover capabilities or with automatic changeover capabilities but no standby available, the following actions should be executed: 1) initiate maintenance alarm information identify- ing the maintenance entity containing the failed equipment; 2) transmit an alarm indication signal (AIS) in the direction affected (downstream direction) or give an upstream failure indication (UFI) at equipment which has not failed; 3) initiate a service alarm indication at the appropriate entities, e.g. primary PCM multiplex or digital switch interfaces. (As a consequence the circuits may be removed from ser- vice.) b) If a failure occurs in a maintenance entity hav- ing automatic changeover capability with a standby available, the following actions should be automatically executed: 1) changeover to the standby; Note - Whether or not connections are released as a result of automatic changeover depends on the service performance objec- tives assigned to each maintenance entity. 2) initiate maintenance alarm information indicat- ing the maintenance entity containing the failed equipment. 5.4 Failure or performance information Information on failure, unacceptable performance or degraded performance will normally be transmitted to the maintenance staff and other parts of the network notified when appropriate. Information for the use of personnel is available either in the entity, when the processing of anomalies or defects is inter- nal, or via a unit which provides processing, when external to the entity. 5.4.1 Alarm information categories The following maintenance alarm information may be associated with the information of failure or unacceptable or degraded perfor- mance: a) Prompt maintenance alarm (PMA) A prompt maintenance alarm is generated in order to ini- tiate maintenance activities (normally immediately) by maintenance personnel to remove from service a defective equipment for the pur- pose of restoring good service and effecting repair of the failed equipment. b) Deferred maintenance alarm (DMA) A deferred maintenance alarm is generated when immediate action is not required by maintenance personnel, e.g. when perfor- mance falls below standard but the effect does not warrant removal from service, or generally if automatic changeover to standby equipment has been used to restore service. c) Maintenance event information (MEI) This information has to be generated as a consequence of events when no immediate actions by the maintenance staff are required because the total performance is not endangered. The maintenance actions can be performed on a scheduled basis or after the accumulation of maintenance event information indications. Starting with the malfunction supervisory process from Figure 5/M.20, Figure 7/M.20 shows the alarm informtion process for an ME. The actual PMA, DMA or MEI may or may not be generated in the ME. When generated outside the ME, the alarm information pro- cess may combine information from other sources (e.g., other MEs, time of day, traffic load, etc.) with the output from the malfunc- tion supervisory process to decide if a PMA, DMA or MEI should be generated. When an AIS or UFI is received, an ME may be required to generate an SA. Both the malfunction supervisory process and the alarm infor- mation process, including the use of PMAs, DMAs and MEIs, can also be applied to other non-telecommunications equipment. Figure 7/M.20, p. 5.4.2 Other fault and service indications In order to avoid unnecessary maintenance actions and to sig- nal the unavailability of the service, the following fault indica- tions are used: - Alarm indication signal (AIS) An alarm indication signal (AIS) is a signal associated with a defective maintenance entity and is, when possible, transmitted in the direction affected (downstream direction) as a substitute for the normal signal, indicating to other nondefective entities that a failure has been identified and that other mainte- nance alarms consequent to this failure should be inhibited. The binary equivalent of the AIS corresponds to an all 1s signal. Note 1 - The AIS is different from the "alarm information to the remote end"; see S 5.4.4. Note 2 - The AIS capability does not impose any restric- tions on the binary content of signals which may be transmitted over the digital hierarchy at the primary multiplex and higher lev- els. The implications at the 64-kbit/s level and at lower bit rates are under study, since ambiguity arises between AIS and an all 1s information signal. Note 3 - For a maintenance entity with multidestination ends (e.g. in networks with TDMA/DSI satellite systems) alarm indi- cation signals on a circuit basis may useful. This subject is under study. Note 4 - In the particular case of the 44 736 kbit/s hierarchical level, the AIS is defined as a signal: i) with a valid frame alignment signal, parity and justification control bits as defined in Table 2/G.752 [6]; ii) with the tributary bits being set to a 1010 | | | sequence, starting with a binary one ("1") after each frame alignment, multiframe alignment and justification control bit; iii) and with all justification control bits being set to binary zero ("0"). Demultiplexers of the 44 | 36 kbit/s hierarchical level must produce the all 1s AIS at their tributary outputs when they receive the 44 | 36 kbit/s AIS at their high speed inputs. - Service alarm (SA) A service alarm is generated at maintenance entities at which the service originates and/or terminates to indicate that the particular service is no longer available (e.g. when a primary block is no longer available for setting up connections, the PCM muldex will extend a service alarm indication to the exchange equipment). The service alarm should be generated when performance falls below a level specified for a particular service. This level may coincide with that for initiating also a prompt maintenance alarm. - Upstream failure indication (UFI) The upstream failure indication given by a maintenance entity indicates that the signal arriving at that maintenance entity is defective. The UFI indicates that the failure has occurred upstream of this point, and no unnecessary maintenance activities are initiated. The appearance of an alarm indicates either a fault in the equipment generating the alarm or a failure of the incoming signal (an upstream failure). To distinguish between these two possibili- ties it is necessary to provide an independent test, either of the input signal, or of the equipment generating the alarm. The input signal can be checked for proper parity, for example, by a monitor included in the protection switching equipment. A defective input signal indicates an upstream failure. Alternatively, the equipment generating the alarm can be tested independently, by looping, for example, and if the equipment operates correctly, an upstream failure is indicated. Note - For a multiple destination maintenance entity (e.g. in networks with TDMA/DSI satellite systems) alarm indication signals on a circuit basis may be useful. This subject is under study. 5.4.3 Transmission and presentation of alarm information The failure information at the alarm interface is used to determine the faulty ME or part of ME. The information can be presented either locally, or remotely via an alarm collection sys- tem. The alarms may be presented as: - an indication at an alarm interface (e.g. contact function, d.c. signal) - an alarm message on the man-machine interface. 5.4.4 Alarm information to the remote end Equipment which is a source of digital multiple signals (i.e. multiple equipment or exchanges) may, in case of a fault condition, transmit alarm information within a specified bit or specified bits of the pulse frame. This information is intended for evaluation at the remote terminal (at the end of the digital link). Examples: see Recommendation G.704, S 2.3.2 [7], Recommendation G.732, S 4.2.3 [8] and Recommendation G.733, S 4.2.4 [9]. 5.5 Fault localication Where the initial failure information is insufficient for fault localization within a failing ME, it has to be augmented with information obtained by additional fault localization routines. The routines can employ ME internal or external test systems, initiated manually or automatically, at the local and/or remote end. A test system, serving one or more MEs could have the follow- ing functions: - alarm collection, e.g. by sampling of alarm interfaces and assembling of alarm messages; - request for failure information, e.g. by address- ing different MEs; - test programs, e.g. for selection of essential alarms, editing, etc.; - control of special devices, e.g. for looping measurement of electrical characteristics; - display of results, e.g. for all MEs within a network region. It should be particularly noted that: - the corrective maintenance action time and the activity of repair centres (these repair centres may receive unfailed items or sub-items) are strongly conditioned by the local- ization efficiency (not yet defined); - if an ME can be subdivided into MSEs, the faulty MSE should be identified as failed in the fault localization pro- cess; - for interchangeable items, the failed item must be identified uniquely. 5.6 Logistic delay 5.6.1 The logistic delay is the period of time between the fault localization and arrival of the maintenance staff of site. In the case of an ISDN, the logistic delay will depend on the type of failures and how they are reported, i.e. by PMA, DMA or MEI. 5.6.2 Following a PMA or DMA alarm, fault correction will be performed normally in the course of a specific trip of the mainte- nance staff. The logistic delay may vary from a few hours in the case of PMA alarms, to a few days in the case of DMA alarms. 5.6.3 Following an MEI, which indicates that no immediate actions are necessary, the maintenance action can be postponed until the next scheduled maintenance visit unless an accumulation of MEIs demands earlier action. 5.7 Fault correction Fault correction normally requires change or repair of an ME, MSE or a part thereof. One or more fault corrections can be per- formed in the course of a maintenance visit. It is desirable that strategies be developed to accomplish fault correction satisfying overall maintenance objectives with a minimum number of visits, using the concept of logistic delay. Failed interchangeable items will be sent to a specialized repair centre, where appropriate test equipment is available (the system itself should not act as a test machine). Normally, cooperation between maintenance elements in dif- ferent Administrations will result in the satisfactory identifica- tion and correction of faults. There may be circumstances, however, where the fault escalation procedure defined in Recommendation M.711 may be required. 5.8 Verification After the fault has been corrected, checks must be made to assure the ME is working properly. The verification can be made locally or remotely. 5.9 Restoration The corrected part of the ME or MSE is restored to service. Blocked MEs are deblocked and changeover to spare may be ter- minated. 6 Additional maintenance activities Besides the above-mentioned phases, the following activities may be required. 6.1 Maintenance support Maintenance support covers the functions identified below: - management of information of network equipment in operation, - management of operating data (routing data mainly), - correction instruction for hardware and software, - repairing of removable items, - management of maintenance stocks, - network and equipment documentation. The quantity of spare parts held depends on: - organization of maintenance entities, - failure rate of an item, - turn around time (actual repair time, transport), - number of items in operation, - risk that no spare part is available. 6.2 Failure statistics If all failures are recorded, this information, after process- ing, can serve the following organizational fields: a) management, e.g. evaluating system performance, b) organization of maintenance, e.g. use of test equipment, subscriber complaints versus test results, amount of spare parts, c) maintenance activities, e.g. identifying weak components where preventive maintenance actions are necessary. 6.3 Preventive maintenance actions Mechanical parts (such as magnetic equipment heads) have to be cared for periodically. After analyzing failure statistics, decisions can be made to interchange items even before failures have occurred, if they seem to be weak items. 7 Other maintenance considerations 7.1 Reference test frequency considerations (Under study.) 7.2 Use of maintenance test lines and loop-backs (Under study.) References [1] CCITT Recommendation Specification for CCITT automatic transmission measuring and signalling testing equipment ATME No. 2 , Vol. IV, Rec. O.22. [2] CCITT Supplement New operation and maintenance organi- zation in the Milan Italcable Intercontinental telecommunication centre , Vol. IV, Supplement No. 6.2. [3] CCITT Recommendations of the G.700 Series Digital net- works , Vol. III, Rec. G.700 to G.956. [4] CCITT Supplement Terms and definitions for quality of service, network performance, dependability and trafficability stu- dies , Vol. II, Fascicle II.3, Supplement No. 6. [5] CCITT Recommendation Error performance on an interna- tional digital connection forming part of an integrated services digital network , Vol. III, Rec. G.821. [6] CCITT Recommendation Characteristics of digital multi- plex equipments based on a second order bit rate of 6312 kbit/s and using positive justification , Vol. III, Rec. G.752. [7] CCITT Recommendation Functional characteristics of interfaces associated with network nodes , Vol. III, Rec. G.704. [8] CCITT Recommendation Characteristics of primary PCM multiplex equipment operating at 2048 kbit/s , Vol. III, Rec. G.732. [9] CCITT Recommendation Characteristics of primary PCM multiplex equipment operating at 1544 kbit/s , Vol. III, Rec. G.733. Recommendation M.21 PRINCIPLES FOR MAINTENANCE PHILOSOPHY AND CONSIDERATIONS FOR MAINTENANCE STRATEGY FOR | TELECOMMUNICATION SERVICES 1 Introduction The purpose of this Recommendation is to provide principles for a maintenance philosophy which can be applied to all telecom- munication services, and from which a common strategy can be derived. 2 Quality of Service An important concept in the consideration of a maintenance philosophy is that of Quality of Service (QOS). This is defined in Recommendation E.800 [1] as "the collective effect of service performances which determine the degree of satis- faction of a user service". 3 Quality of Service factors QOS comprises a number of Quality of Service factors or per- formances which are enumerated and defined in Recommendation E.800 [1] and listed below. Some of these comprise further factors. They are illustrated in Figure 1/M.21 which is taken from Recommendation E.800 [1]. i) service support performance; ii) service operability performance; iii) serveability performance; iv) service accessibility performance; _________________________ It is intended that the subject matters contained in this Recommendation will be studied and developed further as the results of the work done in other Study Groups on Quality of Service concepts become available. v) service retainability performance; vi) service integrity; vii) transmission performance; viii) trafficability performance; ix) propagation performance; x) availability (performance); xi) reliability (performance); xii) maintainability (performance); xiii) maintenance support (performance). Figure 1/M.21, p. 4 Relationship between Quality of Service factors which are relevant in maintenance Figure 1/M.21 indicates the relationship between the availa- bility performance of individual items (e.g., terminal equipment, networks, etc.) which are used in the operation of a service and the serveability performance of that service. This relationship is such that, given satisfactory trafficability and propagation per- formances, then the availabiity performance of each item is the means by which satisfactory serveability of a service is obtained. 5 Principles of maintenance philosophy for telecommunication service 5.1 Serveability performance of a service should be completely and precisely defined, in terms of parameters to be taken into con- sideration and performance objectives, tolerances and conditions for these parameters. 5.2 Performance objectives of items used for services should be considered with reference to the serveability performance of these services. 5.3 In the case where an item is shared by services, then its performance objectives should be such as to enable the service with the most stringent serveability requirement to meet this, given that trafficability and propagation performance are satisfactory. 5.4 Maintenance arrangements for a service should be such that all Quality of Service factors which are relevant to maintenance are satisfactory. 5.5 As factors other than those of Quality of Service (mainte- nance and operation costs, durability of equipments, etc.) and a large variety of networks and services need to be taken into con- sideration when organizing maintenance, arrangements for mainte- nance of a service should be defined as far as possible within a common and global approach. 6 Maintenance considerations for new telecommunication ser- vices 6.1 When a new service is to be introduced, early considera- tion should be given to its operational and maintenance require- ments. In practice, these will depend on its Quality of Service objectives and therefore on the performance parameter objectives which are set for each item which is used for operating the service (e.g., terminal equipment, network, etc.). Thus each item should be considered individually. 6.2 If such an item is unique to a service, there will be new operational and maintenance requirements. 6.3 If such an item is not unique to a service and it is already used in providing an existing service, then consideration should be given to whether the existing operational and maintenance requirements need to be changed. This will depend on whether the performance parameter objectives are changed. 6.4 Operational and maintenance requirements should address the following areas: - line-up and provisioning procedures; - maintenance procedures, including those for fault prevention, detection, reporting and localization; - restoration procedures; - restoration requirements (e.g., maximum permitted number of restoration links in tandem, maximum permitted propaga- tion delay, maximum tolerable interruption duration, degree of pro- tection required); - serveability performance; - organization of operation and maintenance effort to deal with the above-mentioned areas; - the interaction required between elements and centres of operation and maintenance effort; - testing equipment and facilities for use within the operation and maintenance organization; - the exchange of contact point information (as indicated in Recommendation M.93); - maintenance limits for transmission performance parameters. 6.5 Consideration should also be given to whether, in the pro- vision and maintenance of a service, these subject areas require inter-administration agreements or the development of specific CCITT Recommendations. References [1] CCITT Recommendation Quality of Service and dependabil- ity vocabulary , Vol. II, Rec. E.800. | Recommendation M.30 PRINCIPLES FOR A TELECOMMUNICATIONS MANAGEMENT NETWORK 1 General This Recommendation presents the general principles for plan- ning, operating and maintaining a Telecommunications Management Network (TMN). The purpose of a TMN is to support Administrations in management of its telecommunications network. A TMN provides a host of management functions to the telecommunication network and offers communications between itself and the telecommunication net- work. In this context a telecommunications network is assumed to consist of both digital and analogue telecommunications equipment and associated support equipment. The basic concept behind a TMN, therefore, is to provide an organized network structure to achieve the interconnection of the various types of Operations Systems (OSs) and telecommunications equipment using an agreed upon architecture with standardized pro- tocols and interfaces. This will provide the telecommunication net- work Administrations and telecommunication equipment manufacturers a set of standards to use when developing equipment for and design- ing a management network for modern telecommunication networks [including their Integrated Services Digital Networks (ISDNs)]. 1.1 Relationships of a TMN to a telecommunication network A TMN can vary in size from a very simple connection between an OS and a single piece of telecommunication equipment to a mas- sive network interconnecting many different types of OSs and telecommunication equipment. It may provide a host of management functions and offers communications both between the OSs and between OSs and the various parts of the telecommunication network which consists of many types of digital and analogue telecommunica- tion equipment and associated support equipment, such as transmis- sion systems, switching systems, multiplexers, signalling termi- nals. Such equipment is referred to generically as network elements (NEs). Figure 1/M.30 shows the general relationship between a TMN and a telecommunications network which it manages. Note that a TMN is conceptually a separate network that interfaces a telecommunica- tions network at several different points to receive information from it and to control its operations. However, a TMN may often use parts of the telecommunication network to provide its communica- tions. Figure 1/M.30, p. 1.2 Field of application The following are examples of the networks and major types of equipment that may be managed over the TMN: - public and private networks, including ISDNs; - transmission terminals (multiplexers, cross con- nects, channel translation equipment, etc.); - digital and analogue transmission systems (cable, fibre, radio, satellite, etc.); - restoration systems; - digital and analogue exchanges; - circuit and packet switched networks; - signalling terminal and systems including signal transfer points (STP) and real time data bases; - PBXs and customer terminals; - ISDN user terminals; - associated support systems (test modules, power systems, air conditioning units, building alarms systems, etc.). In addition, by the monitoring, testing or control of these equipments, a TMN may be used to manage distributed entities such as circuits. 2 TMN architecture and definitions The following definitions for the TMN architecture are concep- tual in nature and are thus intended to be working definitions that cover the most common and general cases. It should be recognized that, because of the exceedingly complex nature of some telecommun- ications equipment and because of the ability, using microproces- sors, to distribute functionality within various network parts, these definitions may not rigidly cover every possible physical configuration that may be encountered. However, even these excep- tions are expected to fit within the general TMN concept and to be covered by its principles. 2.1 TMN functional architecture A TMN functionally provides the means to transport and process information related to the management of telecommunication net- works. As shown in Figure 2/M.30, it is made up of operations sys- tem functions (OSFs), mediation functions (MFs) and data communica- tions functions (DCFs). The function blocks provide the TMN general functions which enable a TMN to perform the TMN application func- tions. A TMN is also connected to network element functions (NEFs) and workstation functions (WSFs). Figure 2/M.30 shows the function blocks of a TMN all like reference points (q to q, f to f, and x to x) are connected through the facility of the DCF. The WSF may also be directly connected to the NEF through a connection external to the TMN. 2.1.1 Definition of function blocks 2.1.1.1 operations system function (OSF) block The OSF block processes information related to telecommunica- tion management to support and/or control the realization of vari- ous telecommunication management functions. Details of the OSF are given in S 5.2. 2.1.1.2 mediation function (MF) block The MF block acts on information passing between NEFs and OSFs to achieve smooth and efficient communication. Major MFs include communication control, protocol conversion and data handling, communication of primitive functions, processes involving decision making, and data storage. Details of the MF are given in S 5.4. 2.1.1.3 data communications function (DCF) block The DCF block provides the means for data communication to transport information related to telecommunications management between function blocks. Details of the CDF are given in S 5.3. Figure 2/M.30, p. 2.1.1.4 network element function (NEF) block The NEF block communicates with a TMN for the purpose of being monitored and/or controlled. Details of the NEF are given in S 5.5. 2.1.1.5 work station function (WSF) block The WSF block provides means for communications among function blocks (OSF, MF, DCF, NEF) and the user. Details of the WSF are given in S 5.6. 2.1.2 Definitions of reference points The following reference points define conceptual points of information exchange between non-overlapping function blocks. A reference point becomes an interface when the connected function blocks are embodied in separate pieces of equipment. 2.1.2.1 q reference points The q reference points connect the function blocks NEF to MF, MF to MF, MF to OSF and OSF to OSF either directly or via the DCF. Within the class of q reference points the following distinctions are made: q1: the q1reference points connect NEF to MF either directly or via the DCF; q2: the q2reference points connect MF to MF either directly or via the DCF; q3: the q3reference points connect MF to OSF and OSF to OSF either directly or via the DCF. 2.1.2.2 f reference points The f reference points connect function blocks OSF, MF, NEF, DCF to the WSF. 2.1.2.3 g reference points The g reference points are points between the WSF and the user. 2.1.2.4 x reference points The x reference points connect a TMN to other management type networks including other TMNs. 2.2 TMN physical architecture Figure 3/M.30 shows a generalized physical architecture for the TMN. 2.2.1 Definitions of the physical architecture TMN functions can be implemented in a variety of physical con- figurations. The following are the definitions for consideration of implementation schemes. 2.2.1.1 operations system (OS) The OS is the stand alone system which performs OSFs. 2.2.1.2 mediation device (MD) The MD is the stand alone device which performs MFs. MDs can be implemented as hierarchies of cascaded devices. 2.2.1.3 data communications network The DCN is a communication network within a TMN which supports the DCF at the reference point q3. 2.2.1.4 local communication network (LCN) The LCN is a communication network within a TMN which supports the DCF normally at the reference points q1and q2. 2.2.1.5 network element (NE) The NE is comprised of telecommunication equipment (or groups/parts of telecommunication equipment) and support equipment that performs NEFs and has one or more standard Q-type interfaces. 2.2.1.6 workstation (WS) The WS is the stand alone system which performs WSFs. Figure 3/M.30, p. 2.2.2 Definitions of the standard interfaces Standard interfaces are defined corresponding to the reference points. 2.2.2.1 Q interface The Q interface is applied at q reference points. To provide flexibility of implementation, the class of Q interfaces is made up of the following three subclasses: - interface Q1, intended to connect NEs containing no MF to MDs or to NEs containing MF via an LCN - interface Q2, intended to connect MDs to MDs, NEs containing MF to MDs or to other NEs containing MF via an LCN - interface Q3, intended to connect MDs, NEs con- taining MF and OSs to OSs via a DCN. Note 1 - Applications different from primary applications are not excluded when different functions are combined for implementa- tion. Note 2 - A higher numbered interface will generally use a more sophisticated protocol than a lower numbered interface. 2.2.2.2 F interface The F interface is applied at f reference points. 2.2.2.3 G interface The G interface is applied at the g reference point. 2.2.2.4 X interface The X interface is applied at the x reference point. 2.3 TMN protocol families The Q interfaces as present on the DCN and the LCN determine protocol families PQDC\dNand PQL\dC\dN. 2.3.1 Definitions of the TMN protocol families 2.3.1.1 PQvDvCvN A family of protocol suites for use with the DCN applied to the Q3interface. 2.3.1.2 PQvLvCvN A family of protocol suites for use with the LCN, applied to the Q1and Q2interfaces. 2.4 Consideration of reference and physical configurations 2.4.1 q-class considerations 2.4.1.1 q-class reference configuration Figure 4/M.30 shows the q-class reference configuration illus- trating the q1, q2and q3reference points and the types of func- tional blocks that can be connected to the reference points. Figure 4a/M.30 shows the case with explicit DCF (with data commun- ication functions indicated). Since the DCF process preserves the information content, the same reference point appears on both sides of a DCF in the figure. 2.4.1.2 Physical realization of the reference configuration Figure 5/M.30 shows examples of the relationship of the physi- cal configurations to the reference configuration with DCFs not explicitly shown (implicit DCF case). It illustrates combinations of physical interfaces at the reference points q1, q2and q3. At reference points where a physical interface appears, this is denoted with a capital Q. Figure 5/M.30, case a), shows an NE physically connected via a Q1interface to an MD, two MDs interconnected with a Q2interface and the top MD connected with OS via the Q3interface. Figure 5/M.30, case b), shows an NE physically connected to an MD via a Q1interface. The MFs are merged into one MD which inter- faces to the OS via a Q3interface, (see also Note 1). Figure 5/M.30, case c), shows an NE with an internal MF which is interconnected to an MD via a Q2interface. The MD is connected to the OS via a Q3interface. Figure 5/M.30, case d), shows an NE with MFs directly con- nected to the OS via a Q3interface. Note 1 - Where a reference point is shown in Figure 5/M.30 this means that the point is inside a physical box. The designer is free to apply any implementation. It is not necessary that this point is physically present inside the equipment. Note 2 - Any other equipment may be present between two adja- cent boxes, which is necessary for the connection of these boxes. This equipment represents the DCF of Figure 2/M.30. Such equipments perform OSI network functions and are not shown in Figure 5/M.30, e.g., the Q3interface normally connects to the DCN which provides the data communication to the OS. Figure 4/M.30, p. 12 Figure 6/M.30 shows the same examples of the relationship of the physical configuration to the reference configuration as those given in Figure 5/M.30, but with the DCFs explicitly shown (expli- cit DCF case). It also shows different possible configurations that may be used for an LCN (e.g. star, bus or ring). Figure 5/M.30, p. Figure 6/M.30, p. Figure 7/M.30 shows examples, with the DCFs not explicitly shown, of a special group of physical configurations in which NEs are cascaded to provide a single interface to the higher order TMN equipment. This is convenient for co-located NEs which generally contain different levels of MF, e.g., transmission equipment co-located with an exchange. Figure 7/M.30 case a), shows how an NE without an internal MF is connected via a Q1interface to an NE with an internal MF which itself has a Q2interface to an MD. Figure 7/M.30 case b), shows how an NE with an internal MF is connected via a Q2interface to an NE with higher level MF, which itself has a Q3interface to OS. Figure 7/M.30 case c), shows another possibility where an NE without an internal MF has a Q1interface to an NE with an internal MF which itself has a Q3interface to OS. Figure 8/M.30 shows simplified examples of how NEs and MDs might be physically cascaded to serve multiple NEs. The examples show the connections to the OSs, but do not explicitly show the connections to the DCFs. 3 Functions associated with a TMN The functions associated with a TMN can be split into two parts: - TMN general functions provided by the function blocks defined in S 2.1; and - TMN application functions listed in S 3.2; 3.1 TMN general functions The TMN general functions provide support for the TMN applica- tion functions. Examples of TMN general functions are: - transport, which provides for the movement of information among TMN elements; - storage, which provides for holding information over controlled amounts of time; - security, which provides control over access for reading or changing information; - retrieval, which provides access to information; - processing, which provides for analysis and information manipulation; - user terminal support which, provides for input/output of information. 3.2 TMN applications functions A TMN is intended to support a wide variety of application functions which cover the operations, administration, maintenance and provisioning of a telecommunication network. These four categories have a different meaning depending on the organization of an Administration. Moreover, some of the infor- mation which is exchanged over the TMN may be used in support of more than one management category. Therefore, the classification of the information exchange within the TMN is independent of the use that will be made of the information. While it cannot claim to be complete, this section describes some of the most important application functions in terms of the OSI management categories, expanded to fit the need of a TMN. The application functions have been classified in accordance with fields of use into major management categories: a) performance management, b) fault (or maintenance) management, c) configuration management, d) accounting management, e) security management. These allocations are provisional and subject to future review and rearrangement. It should be noted that the functional configuration of the TMN will change depending on the phases in the life cycle and the momentary status of the related telecommunications equipment. Typi- cal examples can be found in the development of installation func- tions and testing functions, notably when utilizing movable support equipment. Figure 7/M.30, p. Figure 8/M.30, p. 3.2.1 Performance management Performance management provides functions to evaluate and report upon the behaviour of telecom equipment and the effective- ness of the network or network element. Its role is to gather sta- tistical data for the purpose of monitoring and correcting the behaviour and effectiveness of the network, network element or equipment and to aid in planning and analysis. As such, it is car- rying out the performance measuring phase of Recommendation M.20. The following functionalities have been defined: 3.2.1.1 Performance monitoring functions Performance monitoring involves the continuous collection of data concerning the performance of the NE. While acute fault condi- tions will be detected by alarm surveillance methods, very low rate or intermittent error conditions in multiple equipment units may interact resulting in poor service quality. Performance monitoring is designed to measure the overall quality on the monitored parame- ters in order to detect such deterioration. It may also be designed to detect characteristic patterns before signal quality has dropped below an acceptable level. 3.2.1.2 Traffic management and network management functions A TMN collects traffic data from NEs and sends commands to NEs to reconfigure the telecommunication network or modify its opera- tion to adjust to extraordinary traffic. A TMN may request traffic data reports to be sent from NEs, or such a report may be sent upon threshold triggering, or periodi- cally, or on demand. At any time the TMN may modify the current set of thresholds and/or periods in the network. Reports from the NE may consist of raw data which is processed in a TMN, or the NE may be capable of carrying out analysis of the data before the report is sent. 3.2.1.3 Quality of Service (QOS) observation functions A TMN collects QOS data from NEs and supports the improvements in QOS. The TMN may request QOS data reports to be sent from the NE, or such a report may be sent automatically on a scheduled or threshold basis. At any time, the TMN may modify the current schedule and/or thresholds. Reports from the NE on QOS data may consist of raw data which is processed in a TMN, or the NE may be capable of carrying out analysis of the data before the report is sent. Quality of Service includes monitoring and recording of param- eters relating to; - connection establishment (e.g. call set up delays, successful and failed call requests); - connection retention; - connection quality; - billing integrity; - keeping and examining of logs of system state histories; - cooperation with fault (or maintenance) manage- ment to establish possible failure of a resource and with confi- guration management to change routing and load control parameters/limits for links etc.; - initiation of test calls to monitor QOS parame- ters. 3.2.2 Fault (or maintenance) management Fault (or maintenance) management is a set of functions which enables the detection, isolation and correction of abnormal opera- tion of the telecommunication network and its environment. It pro- vides facilities for the performance of the following maintenance phases from Recomendation M.20, S 5. 3.2.2.1 Alarm surveillance functions A TMN provides the capability to monitor NE failures in near real time. When such a failure occurs, an indication is made avail- able by the NE. Based on this, a TMN determines the nature and severity of the fault. For example, it may determine the effect of the fault on the services supported by the faulty equip- ment. This can be accomplished in either of two ways: a data base within a TMN may serve to interpret binary alarm indications from the NE, or if the NE has sufficient intelligence, it may transmit self-explanatory messages to a TMN. The first method requires lit- tle of the NE beyond a basic self-monitoring capability. The second method requires additionally that both the NE and a TMN support some type of message syntax which will allow adequate description of fault conditions. 3.2.2.2 Fault localization functions Where the initial failure information is insufficient for fault localization it has to be augmented with information obtained by additional failure localization routines. The routines can employ internal or external test systems and can be controlled by a TMN (see Recommendation M.20). 3.2.2.3 Testing functions (requested, on demand, or as a routine test) Testing can be carried out in one of two ways. In one case, a TMN directs a given NE to carry out analysis of circuit or equip- ment characteristics. Processing is executed entirely within the NE and the results are automatically reported to the TMN, either immediately or on a delayed basis. Another method is where the analysis is carried out within the TMN. In this case, the TMN merely requests that the NE provide access to the circuit or equipment of interest and no other mes- sages are exchanged with the NE. 3.2.3 Configuration management Configuration management provides functions to exercise con- trol over, identify, collect data from and provide data to NEs. 3.2.3.1 Provisioning functions Provisioning consists of procedures which are necessary to bring an equipment into service, not including installation. Once the unit is ready for service, the supporting programmes are ini- tialized via the TMN. The state of the unit, e.g., in service, out of service, stand-by, reserved, and selected parameters may also be controlled by provisioning functions. Over the spectrum of network elements, the use of the provi- sioning functions can vary widely. For small transmission elements, these functions are used once and rarely again. Digital switching and cross-connect equipment may require frequent use of these func- tions as circuits are put up and dropped. 3.2.3.2 Status and control functions The TMN provides the capability to monitor and control certain aspects of the NE on demand. Examples include checking or changing the service state of an NE or one of its sub-parts (in service, out of service, stand-by) and initiating diagnostics tests within the NE. Normally, a status check is provided in conjunction with each control function in order to verify that the resulting action has taken place. When associated with failure conditions, these functions are corrective in nature (e.g., service restoral). Status and control functions can also be part of routine maintenance when executed automatically or on a scheduled periodic basis. An example is switching a channel out of service in order to perform routine diagnostic tests. A TMN will enable the exclusion of faulty equipment from operation and as a result it may rearrange equipment or re-route traffic. A TMN can enable the entry of a proposed configuration in order to automatically analyze the feasibility of that design before implementing it. 3.2.3.3 Installation functions The TMN can support the installation of equipment which makes up the telecommunication network. It covers also the extension or reduction of a system. Some NEs call for the initial exchange of data between themselves and the TMN. An example of another function is the installation of programs into NEs from data base systems within the TMN. In addition, administrative data can be exchanged between NEs and the TMN. Acceptance testing programmes can be done under control of, or supported by, the TMN. A detailed list of installation functions for an SPC-exchange is provided in Recommendation Z.331, S 3.3 [1]. 3.2.4 Accounting management Accounting management provides a set of functions which enables the use of the network service to be measured and the costs for such use to be determined. It provides facilities to: - collect accounting records, - set billing parameters for the usage of services. 3.2.4.1 Billing functions An OS within the TMN can collect data from NEs which is used to determine charges to customer accounts. This type of function may need extremely efficient and redundant data transport capabili- ties in order to maintain records of billing activity. Often the processing must be carried out in near real time for a large number of customers. 3.2.5 Security management (For further study.) 4 Planning and design considerations A TMN should be designed such that it has the capability to interface with several types of communications paths to ensure that a framework is provided which is flexible enough to allow for the most efficient communications between the NE and the TMN, work sta- tions and the TMN, between elements within the TMN or between TMNs. The basis for choosing the appropriate interfaces however, should be the functions performed by the elements between which the appropriate communications are performed. The interface requirements are measured in terms of function attributes that are required to provide the most efficient inter- face. The following is a listing of the function attributes. This list is incomplete and will be subject to further study. 4.1 Functions attributes a) Reliability The capability of the interface to ensure that data and control is transferred such that integrity and security are main- tained. b) Frequency How often data is transferred across the interface boun- dary. c) Quantity The amount of data that is transferred across the inter- face during any transaction. d) Priority Indicates precedence to be given to data in case of com- petition for network resources with other functions. e) Availability Determines the use of redundancy in the design of the com- munications channels between interfacing elements. f ) Delay Identifies the amount of buffering that may be tolerable between interfacing elements. This also impacts communications channel designs. Annex C to this Recommendation provides a table of possible ranges for these function attributes and provides a definition for each range suggested. 4.2 Functional characteristics Each major type of telecommunications equipment has functional characteristic needs that can be used to describe the complexity of the interface. There are, however, a basic group of TMN application functions that cross all major types of telecommunications equip- ment. However, there are also unique TMN application functions that are performed by specific categories of major telecommunications equipment. Alarm surveillance is an example of the former, whereas billing information collection is an example of the latter. Functional characteristics of the elements within a TMN, e.g., OS, DCN, MD also describe the complexity of interfaces between these elements. Thus an identification of the functions performed by the elements within a TMN are also important con- siderations in determining the appropriate interfaces both within the TMN and to the NEs. 4.3 Critical attributes Attribute values for a given function are generally consistent across the network elements. When considering a single Q interface it is important to identify the controlling attribute ranges for the design of the interface. If there are conflicting attribute values for different functions in a given network element, more than one interface may be needed. Overall TMN attribute values for the interfacing of elements within the TMN depend on the type and number of functions performed within these elements. In this case the functions are not con- sistent across TMN elements, but are controlled by the individual TMN design of an Administration. 4.4 Protocol selection In many cases more than one PQ protocol suites will meet the requirements for the network element or TMN element under con- sideration. Care should be taken by the Administration to select the protocol suite that optimizes the relationship between the total cost to implement that protocol suite and the data communica- tions channels that carry the information across the interface. The subject of protocol selection methodology will require further study in conjunction with other Study Groups. 4.5 Communications considerations LCN and DCN architectures must be planned and designed to ensure that their implementation provides appropriate degrees of availability and network delay while minimizing cost. One must con- sider the selection of communications architectures, e.g., star, multipoint, loop, tree. The communications channels, e.g., dedi- cated lines, circuit switched networks and packet networks used in providing the communications paths, also play an important role. 5 Detailed TMN architectural considerations 5.1 General The TMN architecture must provide a high degree of flexibility to meet the various topological conditions of the network itself and the organization of the Administrations. Examples of the topo- logical conditions are the physical distribution of the NEs, the number of NEs and the communication volume of the NEs. Examples of the organization are the degree of centralization of personnel and the administrative practices. TMN architecture will be such that the NEs will operate in the same way, independently of the OS architecture. The TMN must be carefully designed in order to prevent a sin- gle fault from making the transfer of critical management messages impossible. Congestion in the DCN or LCN should not cause blocking or excessive delay of network management messages that are intended to correct the congestion situation or restore a faulty system. As an example of the single fault situation in a critical NE such as a local switch, a separate channel can be provided for emergency action | The emergency action function, when provided, requires an independent maintenance capability when the normal OS is inopera- tive or when the NE has degraded to the point where the normal sur- veillance functions cannot operate. For these reasons the emergency action OS may be separate from the normal maintenance OS, although they are usually at the same location. OSs and NEs which provide the emergency action function may require at least two physical access channels to the DCN for redundancy. Another example is a TMN which is used to determine charges to the customers. The OSs and the NEs which are associated with this function require at least two physical DCN communication channels in order to provide sufficient reliability in the collection pro- cess by the OSs of charging messages from the NEs. The nature of transmission line systems provides the possibil- ity to transport a management message in two directions so that, assuming only one fault exists at a time, one of the two directions is available. 5.2 Operations system 5.2.1 Functional OS configuration There are at least three functional types of OSFs, i.e. basic, network and service. Basic OSFs perform TMN application functions related to NEs located in specific regions. Network OSFs realize the network TMN application functions by performing the communica- tion between basic OSFs. Service OSFs perform specific TMN appli- cation functions for managing an individual service. Basic OSFs and network OSFs share the same infrastructure of a telecommunication network. Service OSFs are concerned with service aspects of one or more telecommunication networks. 5.2.2 Physical OS configuration The OS physical architecture must provide the alternatives of either centralizing or distributing the general functions, which include: a) support application programs; b) data base functions; c) user terminal support; d) analysis programs; e) data formatting and reporting. The OS functional architecture may be realized on various numbers of OSs, depending on the network size. The categorization of TMN function attributes as given in Tables C-1/M.30 to C-3/M.30 are also important factors in the OS physical architecture. For example, the choice of hardware depends strongly on whether an OS provides real time, near real time or non-real time service. Normally OS functions will be implemented in a set of OSs with a Q3interface connected to the DCN. However, this should not pre- clude a practical realization whereby some of these functions are implemented in an NE or an MD. An OS which supports maintenance must provide for two types of data communication: spontaneous transmission of messages concerning problems from the NE to the OS, and two-way dialogue, when the OS obtains supporting information from the NE and sends commands to the NE. In addition, a maintenance OS is responsible for assuring the integrity of the maintenance data channels through a data com- munication network. 5.3 TMN data communication considerations 5.3.1 Data communication networks considerations A DCN for a TMN should, wherever possible, follow the refer- ence model for open systems interconnection for CCITT applications as specified in Recommendation X.200 [2]. Within a TMN the necessary physical connection (e.g. circuit switched or packet switched) may be offered by communication paths constructed with all kinds of network components, e.g., dedicated lines, public switched data network, ISDN, common channel signal- ling network, public switched telephone network, local area net- works, terminal controllers, etc. In the extreme case the communi- cation path provides for full connectivity, i.e. each attached sys- tem can be physically connected to all others. All connections not using a type Q, F or X interface are out- side of a TMN. A data communications network (DCN) connects NEs with internal mediation functions or mediation devices to the OSs and always interfaces at the standard Q3level. The use of standard Q3interfaces enables maximum flexibility in planning the necessary communications. In general, a DCN does not provide all the data communication functions for a TMN. Therefore, the communication between Q1, Q2and Q3interfaces may require communication links, as part of an LCN. A DCN can be implemented using point-to-point circuits, a switched network or a packet network. The facilities can be dedi- cated to a DCN or be a shared facility (e.g. using CCITT Signalling System No. 7 or an existing packet switched network). 5.3.2 Local communications network considerations Within a TMN, the necessary physical connection may be locally offered by all kinds of network configurations, e.g., point-to-point, star, bus or ring. A local communication network (LCN) connects NEs to MDs or MDs to MDs and generally interfaces at two standard levels, Q1and Q2, within a telecommunication center. However, for practical reasons, an LCN may connect remote NEs to local MDs. In some cases, NEs with internal mediation functions may be connected to a DCN through an LCN via a standard Q3interface. 5.4 Mediation 5.4.1 Mediation considerations Mediation is a process within a TMN which acts on information passing between network elements (NE) and operations systems (OS) via a data communication network. Mediation devices use standard interfaces and can be shared by several NE(s) and/or OS(s). Note - Mediation devices accommodate different designs of NEs when acting on information passing from these NEs to OSs by appropriate implementation of communication functions. The media- tion function may be implemented in stand alone devices or combined with other unrelated functions (e.g. with a local processor or with a switching exchange). Mediation functions can be implemented as a hierarchy of cascaded devices using standard interfaces. Examples of the mediation function are concentration, protocol conversion, collection/control and processing. The mediation function may be absent in some implementations. The cascading of mediation devices and various interconnection structures between MDs on one hand and MDs and NEs on the other hand provides for great flexibility in the TMN. Some options are shown in Figure 8/M.30. It enables cost effective implementations of the connection of NEs of different complexity (e.g. switching equipment and transmission multiplex equipment) to the same TMN. In addition, it gives the capability for future design of new equip- ment to support a greater level of processing within individual NEs, without the need to redesign an existing TMN. It may be possible to recognize a mediation type process in some network elements similar to the one described above. For the purpose of this Recommendation, it is convenient to regard the function of mediation as being wholly contained within the TMN. However, this does not preclude practical realizations where some or all of the mediation functions are implemented within the net- work element, which must still interface to the TMN via a standard- ized Q interface. The choice of any interface which may be required for a network element is left to the discretion of the Administra- tions. 5.4.2 Process of mediation Mediation is a process that routes and/or acts on information passing between NEs and OSs. The processes that can form mediation can be classified into the following five general process categories: 1) communication control; 2) protocol conversion and data handling; 3) transfer of primitive functions; 4) decision making processes; 5) data storage. A number of more specific processes can be identified within each of these general process categories, some examples of which are given below. Mediation may consist of one or more of these specific processes: a) communications control: - polling, - addressing, - communications networking, - ensuring integrity of data flows; b) protocol conversion and data handling: - protocol conversion at either lower or upper OSI levels, - concentration of data, - compression or reduction of data, - collection of data, - data formatting, - data translation; c) tranfer of primitive functions: - command/response statement, - alarm statements, - alarm forwarding, - test results/data, - operational measurement data, - upload of status report, - local alarming; d) decision making processes: - work station access, - thresholding, - data communications back-up, - routing/re-routing of data, - security (e.g., log-in procedures), - fault sectionalization tests, - circuit selection and access for tests, - circuit test analysis; e) data storage: - data-base storage, - network configuration, - equipment identification, - memory back-up. Certain mediation processes may be carried out autonomously. The mediation function of the TMN permits a flexible design of the architecture NE to OS. Different architectural designs for operations, administration and maintenance communications can be accommodated in the same TMN by appropriate implementation of the hierarchical configuration of mediation. By these means, NEs of different complexity (e.g. switching exchange or multiplex equip- ment) can connect into the same TMN. 5.4.3 Implementation of mediation processes Mediation processes can be implemented as stand-alone equip- ment or as part of an NE. In either case the mediation function remains part of the TMN. In the stand-alone case the interfaces towards both NEs and OSs are one or more of the standard operations interfaces (Q1, Q2and Q3). Where mediation is part of an NE only, the interfaces towards the OSs are specified as one or more of the standard opera- tions interfaces (Q2and Q3). Mediation that is part of an NE (e.g. as part of a switching exchange) may also act as mediation for other NEs. In this case standard operations interfaces (Q1and Q2) to these other NEs are required. Also, the mediation functions within an NE which carries out the mediation function for other NEs is regarded as being a part of the TMN. 5.5 Network element considerations In the TMN reference model, a network element performs the network element function (NEF), and may in addition perform one or more MFs. The study of various application examples leads to the desira- bility to distinguish between the following functions contained in an NEF: - The Maintenance entity function (MEF) is involved in the telecommunication process. Typical MEFs are switching and transmission. A maintenance entity (ME) can contain one or more MEFs. - The support entity function (SEF) is not directly involved in the telecommunication process. Typical SEFs are fault localization, billing, protection switching. A support entity (SE) can contain one or more SEFs. - The Q-adapter function (QAF) is used to connect to TMN those MEs and SEs which do not provide standard TMN inter- faces. Typical QAFs are interface conversions. A Q-adapter (QA) can contain one or more QAFs and may also contain MFs. This approach to definitions of the parts of an NE which per- form operations functions implies the following relationships: - an NE contains MEs or SEs or both MEs and SEs; - an NE may or may not contain a QA. Note that the various parts of an NE are not geographically constrained to one physical location. For example, the parts may be distributed along a transmission system. Figure 9/M.30 shows the NE reference model outside the TMN with related physical implementations. The m-reference point separates the maintenance entity function (MEF), the support entity function (SEF), and the Q-adapter function (QAF). Figure 10/M.30 shows different types of Q-adapters connected to MEs and SEs. The Q-adapters are not required if MEs or SEs are supplied with Q-interfaces. The M-interface can be of parallel, star or bus-type. Examples of network elements are shown in Annex A. Figure 9/M.30, p. 17 5.6 Work stations In Figure 2/M.30 and 3/M.30, the work station reference points and interfaces are shown at a number of locations. An Administra- tion may choose to implement a work station at only some of these locations. The TMN work stations and their interfaces are subjects for further study. 5.7 TMN standard interfaces TMN standard interfaces provide for the interconnection of NEs, OSs, MDs and WSs through the DCN or LCN. The purpose of an interface specification is to assure compatibility of devices interconnected to accomplish a given TMN application function, independent of the type of device or of the supplier. This requires compatible communication protocols and a compatible data represen- tation method for the messages, including compatible generic mes- sage definitions for TMN application functions. A minimum set of protocol suites, to be applied to TMN standard interfaces, should be determined according to the protocol selection method described in S 4.4. Figure 9/M.30, p. Consideration should be given to compatibility with the most efficient data transport facilities available to reach individual network elements (e.g. leased circuits, circuit switched connec- tions, X.25 packet switched connections, CCITT Signalling System No. 7, embedded operations channels and ISDN access network D- and B-channels). It is recognized that NEs, OSs, DCNs, LCNs, MDs and WSs may have other interfaces in addition to the Q, F, G and X interfaces defined in this Recommendation. It is also recognized that this equipment may have other functionality in addition to that associ- ated with information sent or received via Q, F, G and X inter- faces. These additional interfaces and related functionality are outside the TMN. 5.7.1 Q The PQL\dC\dNfunction attributes required at the Q1/Q2interfaces are strongly dependent on the mediation functions needed, as well as the mediation function partitioning between cas- caded MDs. Since the purpose of putting MDs between OSs and NEs is to make flexible implementation possible, mediation function parti- tioning should not be restricted to only one case. Therefore, one minimum set of protocol suites should be selected to be applied to both Q1and Q2interfaces instead of selecting a different set for each of them. The choice of individual protocol suites from the recommended PQL\dC\dNfamily should be left to the Administrations. The protocol suites to be applied to the Q1and Q2interfaces need not implement all layers of the OSI model. Details of the Q1and Q2interface specification and the PQL\dC\dNfamily of protocol suites are given in Recommendation G.771 [3]. 5.7.2 Q For the PQDC\dNprotocols, it is recommended that each set of TMN application functions with similar protocol needs be supported with unique protocol selections for layers 4 to 7 as defined by the OSI Reference Model (Recommendation X.200 [2]). The anulling of service options of individual layers above layer 3, and even entire layers above layer 3, may be necessary for justifiable economic reasons. In addition, protocol options will likely be required for the PQDC\dNprotocols for layers 1, 2 and 3 in order to permit the use of the most efficient data transport. Details of the Q3interfaces and the PQDC\dNprotocols are given in Recommendation Q.513 [4]. 5.7.3 F interface | (under study) 5.7.4 X interface | (under study) Interconnection to other TMNs. 6 User interface (under study) This section will provide information and recommendations about the possible location and type of user work stations to be provided with a TMN. It will discuss work station back-up con- siderations when parts of the TMN have failed. 7 TMN maintenance considerations (under study) This section will provide information and recommendations about the considerations associated with the maintenance of the TMN itself. Blanc