5i' Recommendation M.251 MAINTENANCE FUNCTIONS TO BE IMPLEMENTED IN CCITT-MML 1 Introduction This Recommendation identifies the maintenance functions to be controlled by means of the CCITT-MML. The CCITT-MML (man-machine language) is intended to handle the functions required to manage telecommunication systems, e.g. via a telecommunication management network (TMN) (see Recommendation M.30). The man-machine interface (MMI) enables the exchange of information between users and systems encoded in MML. Interaction between the users and the controlled systems is based on a repertoire of inputs, outputs, special actions and man-machine interaction mechanisms, including dialogue procedures. This Recommendation deals with the specification and control of maintenance functions. The tests appropriate to particular maintenance functions remain as described in the relevant M-series Recommendations. When defining MML-functions the tasks which need to be per- formed (jobs) are first identified, in order to derive system func- tions to be controlled. The relationship between jobs, system functions and MML-functions is described in S 1.2 of Recommendation M.250. For each system function, one or more MML-functions are derived. Each MML-function is then described using the "meta-language" defined in Recommendation Z.333 [1], which permits the information structure to be defined in detail represent the actual command structure of any real implementation of the man-machine language. Each of the MML-functions could be implemented by providing a separate and distinctive command, or several MML-functions could be implemented using a single command. _________________________ This Recommendation is not yet complete, a number of items are for continuing studies. For further studies, other methodologies than those described in Z.333 [1] may be considered. 2 System functions System functions can often be categorized and divided to break down a task and simplify the implementation and control of such functions by the use of MML. An example showing the generalized functional architecture for a TMN is given in Figure 1/M.251. The MML will be implemented at the g reference point. Maintenance functions are related to the network element func- tions, as well as to the TMN general functions and TMN application functions as defined in Recommendation M.30. This complex of maintenance functions are to be described in two ways: i) on the basis of the "maintenance phases" of Recommendation M.20; ii) the rest (under study). 3 Scope The term "maintenance" covers all aspects which have to do with failures, such as supervision, detection, localization, infor- mation, repair, etc. The general concepts and philosophy are fully described in Recommendation M.20. The description of the maintenance functions on the basis of Recommendation M.20 has the advantage that general descriptions of the various maintenance activities are obtained, valid for all network elements. In this case no separate descrip- tions for maintenance of "terminals", "subscriber lines", "exchanges", "lines between exchanges", etc. are necessary. Figure 1/M.251, p. 4 Maintenance functions in the various maintenance phases The maintenance functions and their relationship to the maintenance phases, defined in S 4 of Recommendation M.20, are listed in Table 1/M.251. These maintenance functions have to be described; the status of these descriptions are given below: 4.1 Failure detection 4.1.1 Continuous checking (see Note) 4.1.2 Routine or periodic testing (see Note) 4.1.3 Checking in live traffic (see Note) 4.1.4 Checking in absence of live traffic (see Note) H.T. [T1.251] TABLE 1/M.251 _____________________________________________________________ Maintenance phases Maintenance functions _____________________________________________________________ 1 Failure detection { 1.1 Continuous checking 1.2 Routine or periodic testing 1.3 Checking in live traffic 1.4 Checking in absence of live traffic } _____________________________________________________________ 2 System protection _____________________________________________________________ 3 Failure information _____________________________________________________________ 4 Failure localization { 4.1 Assembling alarm messages 4.2 Request for failure information 4.3 Test/Measurement 4.4 Setting of loops } _____________________________________________________________ 5 Failure correction _____________________________________________________________ 6 Verification 6.1 Test/Measurement _____________________________________________________________ 7 Restoration 7.1 Deblocking _____________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table 1/M.251 [T1.251], p. 4.2 System protection (under study) 4.3 Failure information (under study; e.g. change of alarm levels) 4.4 Failure location 4.4.1 Assembling alarm messages (under study) 4.4.2 Request for failure information (under study) 4.4.3 Test/measurement (see Note) 4.4.4 Setting of loops (under study) 4.5 Failure correction (under study) 4.6 Verification 4.6.1 Test/measurement (see Note) 4.7 Restoration 4.7.1 Deblocking (under study) Note - As far as these functions are controlled by MML, they are covered by Annex A (whether the totality has been covered is still under study). 5 Other maintenance functions The maintenance functions in the areas of support of mainte- nance, of failure statistics and of preventive maintenance are under study. 6 Relation to Recommendation Z.331 "Maintenance functions" In Recommendation Z.331 [2], a list is given of maintenance functions. Items of that list which are covered, in a general way, by this Recommendation are listed in Table 2/M.251. H.T. [T2.251] TABLE 2/M.251 __________________________________________________________________________________ Maintenance functions { Covered in this Recommendation } __________________________________________________________________________________ { Maintenance of subscribers' lines } { Testing one subscriber line and associated equipment } Yes { Testing a group of subscriber lines and associated equipment } Yes { Measuring one subscriber line and associated equipment } Yes { Measuring a group of subscriber lines and associated equipment } Yes { Blocking or unblocking a subscriber line for maintenance } Under study { Observing or supervising subscriber lines and equipment } Under study { Maintenance of circuits between exchanges and associated equipment } { Testing/Measuring one or group circuit(s) and associated equipment } Yes { Observing and supervising circuit(s) and associated equipment } Under study { Control the status of one or group circuit(s) } Under study Analyzing maintenance data Under study { Administering and controlling maintenance reports } Under study { Switching network maintenance } Making test calls Yes Initiating a call trace Yes Holding faulty connections Under study { Testing and measuring peripheral equipment } Yes { Testing and measuring switching units } Yes { Reducing service for low priority subscribers } Under study { Setting up a connection via a specific path } Under study { Supervising and measuring the Quality of Service } Yes { Localizing faults in the speech path } Yes { Providing access for traffic observations for maintenance } Under study Reporting alarms Under study { Recording switching unit status } Under study { Control system maintenance } Reporting system status Under study Reporting alarms Under study Localizing faults Yes { Testing on a functional basis after repair } Yes { Initiating periodic testing operations } Yes { Changing system configuration for maintenance } Under study Checking consistency of data Under study Initiating restart Under study { Setting traps for programme faults tracing } Under study Changing memory contents Under study { Memory dumping for maintenance purposes } Under study { Controlling overload parameters } Under study { Changing the criteria for degradation of service } Under study { Reducing service for low-priority subscribers } Under study __________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table 2/M.251 [T2.251], p. 7 Description of maintenance functions in annexes to this Recommendation Annex A - General description of maintenance tests/measurements Annex B - General description of failure information (under study) Annex C - Protection, restoration (under study) Annex D - Support of maintenance (under study). ANNEX A (to Recommendation M.251) General description of maintenance tests/measurements A.1 Introduction One of the purposes of maintenance is to detect, localize and repair failures. Failures can be detected by means of different methods, one of them being tests/measurements. The following description of tests/measurements is valid for all objects in a network. An object being defined for this purpose is anything in the network upon which a test/measurement can be performed. This description has been made according to Recommendation Z.332 [3]. A.2 Tests and measurements A.2.1 Document A A.2.1.1 Introduction Maintenance tests and/or measurements may be performed on a demand and routine basis, according to the maintenance strategies. A.2.1.2 List of class B functions A.2.1.2.1 Tests/measurements A.2.1.3 List of jobs A.2.1.3.1 Plan a routine test/measurement - The purpose of the job is to create (or change) a list of tests and test programmes containing all of the data neces- sary for the test/measurements to be run successfully and to iden- tify the objects on which the tests/measurements are to be run. - The system is supposed to record all of the necessary data and create (or change) required test/measurement sets. - The user is supposed to introduce all the data needed. - The complexity of the job may be high depending on the amount of data to be introduced. - The frequency of the job is very low. - The job is supposed to be performed at network and/or OMC level. A.2.1.3.2 Define/change/delete the schedule of routine tests/measurements - The purpose of the job is to schedule new (or change/delete existing) routine tests/measurements depending on the number and types of objects to be tested/measured and the availi- bility of test equipment and test functions. - The system is supposed to schedule (or change/delete) the requested tests/measurements according to the schedule input by the user. - The user is supposed to input the test/measurement types and related data (test/measurement sets information) and time parameters, such as start time, stop time, etc., in order to obtain the required schedule. - The complexity of the job is medium. - The frequency of the job is low. - The job is supposed to be performed at network and/or OMC level. Note - Change of the schedule may be done by a combination of deleting the schedule in use and defining a new one. A.2.1.3.3 Activate the execution of routine tests/measurements - The purpose of the job is to perform a routine test/measurement according to a specified schedule. This allows the verification on a routine basis of the correct functioning of one or more objects. - The system is supposed to perform the tests/measurements according to the specified schedule. The results may be stored within the system for later analysis and/or output or routed to a designated hardcopy device. The system may also be required to provide an output error message if it is unable to per- form some of the requested tests/measurements. - The user may be required to input variables such as schedule identity, start time, stop time and a start point for a series of tests/measurements. - The complexity of the job is low. - The frequency of the job is medium. - The job is supposed to be performed at network and/or OMC level. A.2.1.3.4 Stop/suspend the execution of a certain routine test/measurement - The purpose of the job is to stop/suspend the execution of the test/measurement before the scheduled stop time. - The system is supposed to stop/suspend the execu- tion of the test/measurement according to the time data introduced by the user. - The user is supposed to introduce the identity of the test measurement to be stopped/suspended and the time data of the actual stop/suspension. - The complexity of the job is low. - The frequency of the job is low. - The job is supposed to be performed at network and/or OMC level. A.2.1.3.5 Activate the execution of on-demand tests/measurements - The purpose of the job is to perform on-demand tests/measurements on one or more objects in order to verify the correct functioning of the object(s). - The system is supposed to perform the actions requested on the specified objects as soon as possible. As many of the system parameters as possible should be system resident. The results may de displayed to the user, stored within the system and/or routed to hardcopy devices depending on the routing control information. The system should output an error message (or code) if it is unable to perform the requested test/measurement. - The user is supposed to input the type of the test/measurement and the identities of the objects to be tested/measured. The user may also have to input relevant parame- ters. These would normally be modifications of the system resident default values for a particular test/measurement execution (e.g., the number of times the test/measurement is retried). - The complexity of the job is low, unless the user has to input a large number of parameters values. - The frequency of the job is high. - The job is supposed to be performed at network and/or OMC level. A.2.1.3.6 Delete one or more obsolete test/measurement data - The purpose of the job is to delete the data related to a certain test/measurement component which are of no more interest. - The system is supposed to delete the specified data, providing the necessary safety strategies. - The user is supposed to specify the identity of the data to be deleted. - The complexity of the job is low. - The frequency of the job is low. - The job is supposed to be performed at network and/or OMC level. A.2.1.3.7 Retrieve relevant data of tests/measurements - The purpose of the job is to retrieve information on the tests and/or measurements that are currently defined in the system. - The system is supposed to provide to the user the requested information. - The user is supposed to identify the requested information. - The complexity of the job is low. - The frequency of the job is high. - The job is supposed to be performed at network and/or OMC level. A.2.1.3.8 Retrieve the results of tests and/or of measurements already performed - The purpose of the job is to retrieve the recorded results in order to examine them. - The system is supposed to provide to the user the requested information. - The user is supposed to introduce the identity of the items to be displayed. - The complexity of the job is low. - The frequency of the job is high. - The job is supposed to be performed at network and/or OMC level. A.2.2 Document B A.2.2.1 Introduction The model in Figure A-1/M.251 describes in a general (function independent) way those system functions called tests/measurements which can be controlled by the user by means of MML functions. This model can be applied to measurements as well as to tests for maintenance purposes. A.2.2.2 Maintenance test/measurement model A.2.2.2.1 Test/measurment elements A test/measurement is identified by three basic elements: time, entities, objects (when, what, where). Time includes all necessary information to define the start, the duration and periodicity of a certain test/measurement. Entities describe the quantities for which data collection must be performed with a certain test/measurement, e.g. loss, noise, gain/slope, signalling performance, etc. Objects are intended as individual items within each object type on which the tests/measurements are performed. Examples of objects types are circuits, group of circuits, transmission equip- ment, facilities, etc. A.2.2.2.2 Test/measurement matrix The definition of tests/measurements is based on an abstract model which contains the definition of a test/measurement matrix (see Figure A-1/M.251), in which each row represents one uniquely definable entity, e.g. transmission loss/noise test, and each column represents a uniquely definable object type, e.g. a group of circuits, a destination. A certain combination of entities and object types corresponds to certain entities in the test/measurement matrix and forms a test/measurement type. It is recognized that part of these test/measurement types may be standardized while the rest of them could be system and/or administration dependent. It should be noted that not all the entries in the test/measurement matrix can be used because some of them will be meaningless (e.g. signalling tests on incoming cir- cuits). Figure A-1/M.251, p. A single object is defined by its type and/or its individual object identity. In some test/measurement types the number of the objects is fixed, in other types one can choose, for the actual test/measurement, some or all the allowed objects by means of administration MML commands. Chosen (selected) objects form an object list. The object identity contains all necessary information to identify the address of the object in any part of the network (e.g. node-address, exchange-address, etc.). The structure of division of object types and entities is open-ended in such a way that any new object type or entity may be added. If the start of a test/measurement is instantaneous, it can also be called "on-demand" or " one-shot" test/measurement A.2.2.2.3 Basic categories of tests/measurements Two basic categories of tests/measurements are envisaged (see Figure A-2/M.251). The category A is a test/measurement of undeter- mined duration while the category B is intended to be performed only for a predetermined duration. The start of a test/measurement may be intended as instantane- ous or delayed for a defined time duration __t1from the activation of the measurement. Since the stop time of a measurement of category. A is not given when the test/measurement is activated or created, it has to be given during the test/measurement unless the test/measurement is intended to go on forever. When deactivation is requested, there may be a defined delay of __t2before the test/measurement is stopped. In the creation of a test/measurement, a start time optionally be provided, in which case for that particular test/measurement, the activation function is not necessary. Time parameters needed to control a test/measurement can be divided into three groups: 1) test/measurement type dependent time parameters (interval parameters of a test/measurement type, e.g repeat test interval) ; 2) test/measurement dependent time parameters (e.g. time parameters which define the periodicity of test measure- ment). These parameters refer always to relative time or specific dates; 3) test/measurement independent time parameters (e.g. time parameters which are related to the actual start or stop of a certain test/measurement in activation and deactivation func- tions). Figure A-2/M.251, p. A.2.2.2.4 Structure of a test/measurement A test/measurement consists of: - test/measurement set information; - time information; _________________________ A repeat test interval is the minimum time interval be- fore the repetition of a test can be attempted. - output routing information. Figure A-3/M.251 shows a model relating these parameters to maintenance tests/measurements. This model is useful in illustrat- ing the relationships between test/measurement sequences (test/measurement sets), time parameters, some of which relate to routing tests only (i.e., they have no relevance to on-demand tests/measurements) and the specification of output media [which can be assumed to be according to the specification of the output destination(s)]. Test/measurement set information, time information, output media information as well as object lists may be predefined. It should be noted that predefinition characteristics are system dependent. Figure A-3/M.251, p. A.2.2.2.4.1 Test/measurement set information Test/measurement set information consists of one or more selected test/measurement types with defined objects (object lists) and test/measurement type dependent parameters. Note that normally, for maintenance purposes, test/measurement types are fixed at a given moment in time and that they cannot be created, deleted or changed by MML commands; only later supplier releases may change these test/measurement types according to new requirements. It is recognized that the Administrations may require MML functions to administer test/measurement types, grouping predefined entities with object types. Such functions should be considered as a system extension and upgrade function and, therefore, should belong to the system control function area. However, due to the fact that system control functions are not yet recommended, they are included in the subsequent descriptions. A.2.2.2.4.2 Time information Tests/measurements of categories A and B (see Figure A-2/M.251) may perform continuous recording or recording on predetermined days (recording days). For tests/measurements performing continuous recording, only the start date is needed. A.2.2.2.4.3 Output routing information Output routing information defines the output destinations (there may be more than one), the output formats and the number of copies required. An output destination may be an internal (system resident) log or file. This file may be analyzed at a later time and its data used to provide reports both to the users and for administrative purposes. A.2.2.2.4.4 Summary Test/measurement set information, time information, output routing information as well as object lists may be predefined. It should be noted that predefinition characteristics are normally system dependent. A.2.3 Document C A.2.3.1 List of MML functions 1) Creation - create a test/measurement set - create a list of objects - create a time data list - create an output media list - create a routine test/measurement 2) Changing - change a test/measurement set - change a list of objects - change a time data list - change an output media list - change a routine test/measurement 3) Deletion - delete a test/measurement set - delete a list of objects - delete a time data list - delete an output media list - delete a routine test/measurement 4) Interrogation - interrogate a test/measurement set - interrogate a list of objects - interrogate a time data list - interrogate an output media list - interrogate a routine test/measurement 5) Activation - activate a routine test/measurement - activate an on-demand test/measurement 6) Deactivation - deactivate a routine test/measurement - deactivate an on-demand test/measurement 7) Output - output the results of a routine test/measurement - output the results of an on-demand test/measurement 8) Administration of test/measurement types - create a test/measurement type - change a test/measurement type - delete a test/measurement type Note - These functions are not yet recommended, but are included, so that Administrations are able to consider the manage- ment of different test/measurement types. A.2.4 Document D A.2.4.1 Introduction All the information entities needed for the MML functions related to the maintenance tests administration have been identified and are reported in this Document D by means of diagrams representing each MML function information structure. See Figures A-5/M.251 to A-35/M.251. The same information structure diagrams apply to maintenance measurements administration func- tions. A schematic overview of these functions is given in Figure A-4/M.251. Figure A-4/M.251, p. A.2.4.2 Information structure diagrams for each MML function Figure A-5/M.251, p.8 Figure A-6/M.251, p.9 Figure A-7/M.251, p.10 Figure A-8/M.251, p.11 Figure A-9/M.251, p.12 Figure A-10/M.251, p.13 Figure A-11/M.251, p.14 Figure A-12/M.251, p.15 Figure A-13/M.251, p.16 Figure A-14/M.251, p.17 Figure A-15/M.251, p.18 Figure A-16/M.251, p.19 Figure A-17/M.251, p.20 Figure A-18/M.251, p.21 Figure A-19/M.251, p.22 Figure A-20/M.251, p.23 Figure A-21/M.251, p.24 Figure A-22/M.251, p.25 Figure A-23/M.251, p.26 Figure A-24/M.251, p.27 Figure A-25/M.251, p.28 Figure A-26/M.251, p.29 Figure A-27/M.251, p.30 Figure A-28/M.251, p.31 Figure A-29/M.251, p.32 Figure A-30/M.251, p.33 Figure A-31/M.251, p.34 Figure A-32/M.251, p.35 Figure A-33/M.251, p.36 Figure A-34/M.251, p.37 Figure A-35/M.251, p.38 A.2.5 Document G Glossary of used terms : a) start/stop date - The start/stop day of a test/measurement on a routine basis. b) start/stop time - The start/stop time of a test/measurement on a routine basis. c) test/measurement day - Day in which the test/measurement is performed according to the associated schedule. d) objects - Individual items on which test/measurements are performed (e.g. circuits, group of circuits, transmission equipments, etc.) e) OMC - Operation and maintenance centre. ANNEX B (to Recommendation M.251) General description of failure information (under study) ANNEX C (to Recommendation M.251) Protection, restoration (under study) ANNEX D (to Recommendation M.251) Support of maintenance (under study) References [1] CCITT Recommendation Methodology for the specification of the man-machine interface - Tools and methods , Vol. X, Rec. Z.333. _________________________ This list is the subject of further study. [2] CCITT Recommendation Introduction to the specification of the man-machine interface , Vol. X, Rec. Z.331. [3] CCITT Recommendation, Methodology for the specification of the man-machine interface - General working procedure , Vol. X, Rec. Z.332. MONTAGE: PAGE 234 = PAGE BLANCHE