.rs .\" Troff code generated by TPS Convert from ITU Original Files .\" Not Copyright ( c) 1991 .\" .\" Assumes tbl, eqn, MS macros, and lots of luck. .TA 1c 2c 3c 4c 5c 6c 7c 8c .ds CH .ds CF .EQ delim @@ .EN .nr LL 40.5P .nr ll 40.5P .nr HM 3P .nr FM 6P .nr PO 4P .nr PD 9p .po 4P .rs \v | 5i' .ce 1000 ANNEX\ A .ce 0 .ce 1000 (to Recommendation M.30) .sp 9p .RT .ce 0 .ce 1000 \fBExamples of network elements\fR .sp 1P .RT .ce 0 .PP A.1 A network element (NE) is the grouping of telecommunication and other equipment that can communicate operations and administrative messages via a telecommunication management network (TMN) over one or more standard interfaces for the purpose of being monitored and/or controlled. .sp 1P .RT .PP Network elements are not part of a TMN if they contain only maintenance entities (ME) and/or support entities (SE), as defined in Recommendation\ M.20. Network elements with mediation functions are partly within a TMN, as described in \(sc\ 5.5. .PP The various parts of NEs and their interfaces are shown in a) of Figure\ A\(hy1/M.30 for ME, in b) of Figure\ A\(hy1/M.30 for SE, and in c) of Figure\ A\(hy1/M.30 for QA. Using these units, Figure\ A\(hy2/M.30 shows an example of NE\(hyconfigurations. As illustrated, one NE may contain a number of MEs and SEs connected to a Q\(hyadapter. .PP The following interfaces are used: .RT .LP a) T telecommunications interface, which carries the information flow to be managed by TMN; .LP b) Q Q\d1\u, Q\d2\uand Q\d3\uTMN\(hyinterfaces as described in this Recommendation; .LP c) M non\(hystandardized maintenance interface as described in this Recommendation; .LP d) TS telecommunication support interface, which is related to the function of the support element or used for connection of monitors/work stations. .PP A.2 Relations between NE, ME, SE and QA for maintenance are illustrated in Figures\ A\(hy3/M.30 to A\(hy10/M.30 using a number of examples. .sp 9p .RT .PP The abbreviations used in the figures are: .LP CFS Common frequency supply .LP CTE Channel translation equipment .LP DCC Digital cross connect .LP DIG\ MUX Digital multiplexer .LP GTE Group translation equipment .LP LT Line terminal .LP M (non\(hystandardized) Maintenance interface .LP ME Maintenance entity .LP MTE Mastergroup translation equipment .LP NE Network element .LP Q Q\d1\u, Q\d2\u, Q\d3\uinterfaces .LP QA Q\(hyadapter .LP SE Support entity .LP SMTE Supermastergroup translation equipment .LP STE Supergroup translation equipment .LP SUR Supervision unit, dependent repeater .LP SUT Supervision unit, line terminal .LP T Telecommunications interface .LP TS Telecommunications support interface .LP .rs .sp 5P .ad r Blanc .ad b .RT .LP .bp .LP .rs .sp 16P .ad r \fBFigure A\(hy1/M.30, (N), p. 1\fR .sp 1P .RT .ad b .RT .LP .rs .sp 31P .ad r \fBFigure A\(hy2/M.30, (N), p. 2\fR .sp 1P .RT .ad b .RT .LP .bp .LP .rs .sp 20P .ad r \fBFigure A\(hy3/M.30, (N), p. 3\fR .sp 1P .RT .ad b .RT .LP .rs .sp 27P .ad r \fBFigure A\(hy4/M.30, (N), p. 4\fR .sp 1P .RT .ad b .RT .LP .bp .LP .rs .sp 18P .ad r \fBFigure A\(hy5/M.30, (N), p. 5\fR .sp 1P .RT .ad b .RT .LP .rs .sp 10P .ad r \fBFigure A\(hy6/M.30, (N), p. 6\fR .sp 1P .RT .ad b .RT .LP .rs .sp 14P .ad r \fBFigure A\(hy7/M.30, (N), p. 7\fR .sp 1P .RT .ad b .RT .LP .bp .LP .rs .sp 25P .ad r \fBFigure A\(hy8/M.30, (N), p. 8\fR .sp 1P .RT .ad b .RT .LP .rs .sp 20P .ad r \fBFigure A\(hy9/M.30, (N), p. 9\fR .sp 1P .RT .ad b .RT .LP .bp .LP .rs .sp 15P .ad r \fBFigure A\(hy10/M.30, (N), p. 10\fR .sp 1P .RT .ad b .RT .ce 1000 ANNEX\ B .ce 0 .ce 1000 (to Recommendation M.30) .sp 9p .RT .ce 0 .ce 1000 \fBTMN application functions\fR .sp 1P .RT .ce 0 .LP B.1 \fIIntroduction\fR .sp 1P .RT .PP The TMN application functions are classified in the five categories specified in \(sc\ 3.2. .PP The functional list has been classified according to the OSI management categories as an aid in selecting the protocol and the application language for the TMN interfaces. .PP The list of functions, its terminology and classification is preliminary and is expected to be refined as the study proceeds. .PP The application functions are not intended as requirements for any NE or TMN. Each function in the list is included because it may be necessary for some implementation of a related application. Some functions will be appropriate for a certain implementation of an interface application, but unnecessary or inconvenient for others. .RT .sp 1P .LP B.2 \fIIndex of list of application functions described in \(sc\ B.3\fR .sp 9p .RT .LP B.3.1 Performance management .LP B.3.1.1 Performance monitoring (PM) .LP B.3.1.2 Traffic management and network management (NM) .LP B.3.1.3 Quality of service (QOS) observations .LP B.3.2 Fault (or maintenance) management .LP B.3.2.1 Alarm surveillance .LP B.3.2.2 Fault localization .LP B.3.2.3 Testing .LP B.3.2.3.1 Voiceband and voiceband data circuits test .LP B.3.2.3.1.1 Access and control .LP B.3.2.3.1.2 Monitor and talk .LP B.3.2.3.1.3 Measurement .LP B.3.2.3.1.4 Signalling and supervision .LP B.3.2.3.2 Digital data circuit test .LP B.3.2.3.2.1 Test access .bp .LP B.3.3 Configuration management .LP B.3.3.1 Provisioning .LP B.3.3.1.1 NE configuration .LP B.3.3.1.2 Administrative fonctions .LP B.3.3.1.3 Data base management .LP B.3.3.2 Status and control .LP B.3.3.2.1 Message handling systems network .LP B.3.3.2.2 Leased circuit network .LP B.3.3.2.3 Transmission network .LP B.3.3.3 Installation .LP B.3.4 Accounting management .LP B.3.5 Security management .LP .sp 3 .sp 1P .LP B.3 \fIList of application functions\fR .sp 9p .RT .sp 1P .LP B.3.1 \fIPerformance management\fR .sp 9p .RT .sp 1P .LP B.3.1.1\ \ \fIPerformance monitoring (PM)\fR .sp 9p .RT .LP 1) \fIRequest PM data\fR \ \(em\ TMN requests the NE to send current PM data; .LP 2) \fIPM data report\fR \ \(em\ NE sends performance data to the TMN. It may be generated routinely by the NE, sent upon demand by the TMN or by exception when a parameter threshold has been exceeded; .LP 3) \fISchedule PM data report\fR \ \(em\ TMN directs NE to establish a schedule for the reporting of PM data; .LP 4) \fIRequest PM data report schedule\fR \ \(em\ TMN directs NE to send the current PM data reporting schedule. NE responds with the schedule; .LP 5) \fIStart/stop PM data\fR \ \(em\ TMN directs the NE to start or stop the collection of PM data; .LP 6) \fIInitialize PM data\fR \ \(em\ TMN directs NE to reset storage registers for PM data; .LP 7) \fISet PM attributes\fR \ \(em\ TMN directs NE to assign designated values to PM attributes; .LP 8) \fIRequest PM attributes\fR \ \(em\ TMN requests NE to send current PM attributes; .LP 9) \fIPM attributes report\fR \ \(em\ NE sends the currently assigned PM attributes to TMN; .LP 10) \fIRequest protocol conversion data\fR \ \(em\ TMN requests NE to transmit the data concerning the protocol conversion performance, such as the types and their number of protocol conversions; .LP 11) \fIProtocol conversion data report\fR \ \(em\ NE sends data concerning protocol conversion performance. .sp 1P .LP B.3.1.2\ \ \fITraffic management and\fR \fInetwork management (NM)\fR .sp 9p .RT .LP 1) \fISet traffic data attributes\fR \ \(em\ TMN directs NE to set parameters to collect traffic data; .LP 2) \fIRequest traffic data attributes\fR \ \(em\ TMN requests NE to report the current traffic data attributes; .LP 3) \fIRequest traffic data\fR \ \(em\ TMN requests NE to transmit traffic data to TMN; .LP 4) \fITraffic data report\fR \ \(em\ NE sends specified traffic data to TMN; .LP 5) \fIRequest clock sync\fR \ \(em\ TMN requests NE to transmit its current clock time to TMN; .LP 6) \fIClock sync report\fR \ \(em\ NE sends the current clock time; .bp .LP 7) \fISet error analysis\fR \ \(em\ TMN directs NE to assign designated values to error analyses parameters. These are used by NE to recognize that a given unit is faulty based on the detection of errors and intermittent troubles; .LP 8) \fIRequest error analysis data\fR \ \(em\ TMN requests NE to report the current error analysis parameters or resulting data; .LP 9) \fIError analyses report\fR \ \(em\ NE sends error analyses data to TMN; .LP 10) \fISet NM data attributes\fR \ \(em\ TMN directs NE to set parameters to generate required NM measurement data; .LP 11) \fIRequest NM data attributes\fR \ \(em\ TMN requests NE to report the current NM data attributes; .LP 12) \fIRequest NM data\fR \ \(em\ TMN requests NE to send the NM data to TMN. This includes periodic measurement data and status and alerting discrete information; .LP 13) \fINM data report\fR \ \(em\ NE sends required NM data to TMN; .LP 14) \fISent NM control\fR \ \(em\ TMN directs the NE to perform specified real\(hytime NM controls; .LP 15) \fIControl report\fR \ \(em\ NE sends NM control status information to the TMN; .LP 16) \fISet NM thresholds\fR \ \(em\ TMN directs the NE to set or change the congestion thresholds used by the NE to perform automatic NM control; .LP 17) \fIRequest NM threshold\fR \ \(em\ TMN requests the NE to send the current congestion thresholds to the TMN; .LP 18) \fINM threshold report\fR \ \(em\ NE sends current congestion thresholds to TMN. .sp 1P .LP B.3.1.3\ \ \fIQuality of service (QOS) observations\fR .sp 9p .RT .LP 1) \fISchedule QOS data report\fR \ \(em\ TMN directs NE to establish a schedule for the report of QOS data; .LP 2) \fIRequest QOS data report schedule\fR \ \(em\ TMN directs NE to send the current QOS data reporting schedule; .LP 3) \fIQOS report\fR \ \(em\ NE reports to TMN the value of an observed QOS parameter. It may be sent on demand by TMN or on a scheduled basis; .LP 4) \fISet QOS threshold\fR \ \(em\ TMN directs NE to set or change the QOS parameter threshold; .LP 5) \fIRequest QOS threshold\fR \ \(em\ TMN directs NE to send the current QOS threshold; .LP 6) \fIExceptional QOS report\fR \ \(em\ NE reports to TMN the value of an observed parameter when a parameter threshold has been exceeded; .LP 7) \fIInitialize QOS data\fR \ \(em\ TMN directs NE to reset storage registers for QOS data; .LP 8) \fIStart/stop QOS data\fR \ \(em\ TMN directs NE to start or stop the collection of QOS data; .LP 9) \fISchedule QOS test calls\fR \ \(em\ TMN directs NE to establish a schedule for the execution of QOS test calls; .LP 10) \fIRequest QOS test call schedule\fR \ \(em\ TMN directs NE to send the current QOS test call schedule; .LP 11) \fIQOS test call report\fR \ \(em\ NE reports to TMN the result of QOS test calls. It may be sent on demand by TMN or on a scheduled basis; .LP 12) \fISet QOS test call attributes\fR \ \(em\ TMN directs NE to set or change the attributes of QOS test calls; .LP 13) \fIStart/stop QOS test calls\fR \ \(em\ TMN directs NE to start or stop sending test calls; .LP 14) \fIInitialize QOS test calls\fR \ \(em\ TMN directs NE to reset the storage registers for test calls; .LP 15) \fIRequest QOS test call attributes\fR \ \(em\ TMN directs NE to send the current QOS test call attributes; .LP 16) \fISchedule (semi) automatic observations\fR \ \(em\ TMN directs NE to establish a schedule for the execution of (semi) automatic observations; .bp .LP 17) \fIRequest (semi) automatic observation schedule\fR \ \(em\ TMN directs NE to send the current (semi) automatic observation schedule; .LP 18) \fIAutomatic observation report\fR \ \(em\ NE reports to TMN the result of automatic observations. It may be sent on demand by TMN or on a scheduled basis; .LP 19) \fISet (semi) automatic observation attributes\fR \ \(em\ TMN directs NE to set or change the attributes of (semi) automatic observations; .LP 20) \fIStart/stop (semi) automatic observations\fR \ \(em\ TMN directs NE to start or stop the (semi) automatic observations; .LP 21) \fIInitialize automatic observations\fR \ \(em\ TMN directs NE to reset the storage registers for automatic observations; .LP 22) \fIRequest (semi) automatic observation attributes\fR \ \(em\ TMN directs the NE to send the current (semi) automatic observation attributes. .sp 1P .LP B.3.2 \fIFault (or maintenance) management\fR .sp 9p .RT .sp 1P .LP B.3.2.1\ \ \fIAlarm surveillance\fR .sp 9p .RT .LP 1) \fIRequest alarm information\fR \ \(em\ TMN requests NE to send current alarm information; .LP 2) \fIAlarm information report\fR \ \(em\ NE notifies TMN of alarm information. It may be sent automatically on occurrence, or on demand by TMN; .LP 3) \fISchedule alarm report\fR \ \(em\ TMN directs NE to establish a schedule for the reporting of alarms; .LP 4) \fIRequest alarm report schedule\fR \ \(em\ TMN directs NE to send the current schedule for alarm reporting. NE responds with the schedule; .LP 5) \fICondition alarm\fR \ \(em\ TMN directs NE to assign alarm attributes, modes and thresholds; .LP 6) \fIRequest condition\fR \ \(em\ TMN requests NE to report the current assignment of alarm attributes, modes and thresholds; NE responds with the assignments; .LP 7) \fIRoute alarm\fR \ \(em\ TMN directs NE to send alarms to designated locations; .LP 8) \fIRequest alarm route\fR \ \(em\ TMN requests NE to send the current assignment of alarm routes for a specified set of alarms; NE responds with the routes; .LP 9) \fIAllow/inhibit alarms\fR \ \(em\ TMN directs NE to allow/inhibit either local audible/visual alarms or remote alarms; .LP 10) \fIAlarm cut\(hyoff\fR \ \(em\ TMN directs NE to reset designated audible alarms. .sp 1P .LP B.3.2.2\ \ \fIFault localization\fR .sp 9p .RT .LP 1) \fIRequest diagnostic data\fR \ \(em\ TMN requests NE to send the results of a diagnostic sequence; .LP 2) \fIStop diagnostic in progress\fR \ \(em\ TMN directs the NE to stop a particular diagnostic procedure in progress; .LP 3) \fIDiagnostic report\fR \ \(em\ NE reports the results of a diagnostic sequence to the TMN. It may be used in conjunction with the request and stop functions and has applications where it may be necessary or desirable to repeat diagnostic tests for a period of time to \*Qcatch\*U a failure; .LP 4) \fISchedule diagnostic\fR \ \(em\ TMN directs NE to establish a routine schedule for the initiation of a diagnostic; .LP 5) \fIRequest diagnostic schedule\fR \ \(em\ TMN requests NE to report the current schedule of diagnostics; .LP 6) \fIDiagnostic schedule report\fR \ \(em\ NE sends the current schedule of diagnostics; .LP 7) \fIRequest exercise report\fR \ \(em\ TMN requests NE to send the results of a particular exercise; .LP 8) \fIExercise report\fR \ \(em\ NE sends the results of an exercise to TMN; .LP 9) \fIStop exercise\fR \ \(em\ TMN directs NE to stop a particular exercise in progress; .bp .LP 10) \fISchedule exercise\fR \ \(em\ TMN directs NE to establish a routine schedule for the initiation of an exercise; .LP 11) \fIRequest exercise report schedule\fR \ \(em\ TMN directs NE to send the current schedule of an exercise. NE responds with the schedule; .LP 12) \fIOperate/release loopback\fR \ \(em\ TMN directs NE to establish or release a specific loopback. It may be activated either remotely by TMN or locally by craft action; .LP 13) \fITest internal access path\fR \ \(em\ TMN directs NE to connect a termination on NE to another termination by a specified path within NE, then test the path; .LP 14) \fIHold network path\fR \ \(em\ TMN directs NE to hold a particular network path; .LP 15) \fIStart/stop program traps\fR \ \(em\ TMN directs NE to start or stop a specific program trap; .LP 16) \fIProgram trap report\fR \ \(em\ NE automatically reports to TMN the occurrence of a program trap; .LP 17) \fIStart/stop program trace\fR \ \(em\ TMN directs NE to start or stop a specific trace; .LP 18) \fIProgram trace report\fR \ \(em\ NE automatically reports to TMN the results of a trace; .LP 19) \fIStart/stop audit\fR \ \(em\ TMN directs NE to start or stop an audit; .LP 20) \fIAudit report\fR \ \(em\ NE automatically reports to TMN the results of an audit; .LP 21) \fISchedule audit\fR \ \(em\ TMN directs NE to establish a specified schedule for a given audit; .LP 22) \fIRequest audit schedule\fR \ \(em\ TMN requests NE to send the current audit schedule. NE responds with the test schedule; .LP 23) \fIStart/stop loop insulation test\fR \ \(em\ TMN directs NE to start or stop a loop insulation test; .LP 24) \fISchedule loop insulation test\fR \ \(em\ TMN directs NE to schedule a loop insulation test; .LP 25) \fIRequest loop insulation test schedule\fR \ \(em\ TMN requests NE to send current loop insulation test schedule. NE responds with the schedule. .sp 1P .LP B.3.2.3\ \ \fITesting\fR .sp 9p .RT .sp 1P .LP B.3.2.3.1 \fIVoiceband and voiceband data circuits test\fR .sp 9p .RT .sp 1P .LP B.3.2.3.1.1 \fIAccess and control\fR .sp 9p .RT .LP 1) \fIConnect test access\fR \ \(em\ TMN directs NE to provide a monitor connection to the transmission pairs of the accessed circuits; .LP 2) \fIDisconnect test access\fR \ \(em\ TMN directs NE to drop access to the circuit under test and return the circuit to its normal state; .LP 3) \fIRequest test result\fR \ \(em\ TMN requests NE to report intermediate or final results from a measurement; .LP 4) \fITest result report\fR \ \(em\ NE sends the results of a test to TMN; .LP 5) \fIChange terminate and leave (T&L)\fR \ \(em\ TMN directs NE to change T&L state of the circuit under test and report the resulting T&L state to TMN; .LP 6) \fIRequest to terminate and leave\fR \ \(em\ TMN directs NE to report the T&L status of the circuit under test; .LP 7) \fITerminate and leave report\fR \ \(em\ NE reports the T&L status of the circuit under test; .LP 8) \fIChange pairs\fR \ \(em\ TMN directs NE to execute reversals of specified transmission pairs for 4\(hy and 6\(hywire metallic circuits on either the equipment or facility side of the test port; .LP 9) \fIChange leads\fR \ \(em\ TMN directs NE to execute reversal of tip and ring leads of metallic transmission pairs on the circuit under test; .LP 10) \fIChange port restore\fR \ \(em\ TMN directs NE to clear all test conditions and restore the circuit to a monitor state; .LP 11) \fIRequest facility test status\fR \ \(em\ TMN directs NE to send the status of the facility carrying the circuit under test; .LP 12) \fIFacility test status report\fR \ \(em\ NE sends the status of the facility carrying a specified circuit. .bp .sp 1P .LP B.3.2.3.1.2\ \ \fIMonitor and talk\fR .sp 9p .RT .LP 1) \fIConnect talk and split\fR \ \(em\ TMN directs NE to establish talk and listen paths between the circuit under test and the monitor/talk line; .LP 2) \fIConnect monitor listen\fR \ \(em\ TMN listens selectively to the circuit under test and monitors any transmission pair in either direction; .LP 3) \fIChange monitor level\fR \ \(em\ the TMN directs NE to change the level of the monitor connection; .LP 4) \fIChange monitor filter\fR \ \(em\ TMN directs NE to remove or insert the single frequency notch filter placed in the monitor connection; .LP 5) \fIDisconnect monitor\fR \ \(em\ TMN directs NE to remove any monitor or talk conditions established on the circuit under test. .sp 1P .LP B.3.2.3.1.3\ \ \fIMeasurement\fR .sp 9p .RT .LP 1) \fIMeasure circuit characteristic\fR \ \(em\ TMN directs NE to measure a circuit characteristic including, but not restricted to, voltage, current, tip\(hyring\(hyground capacitance and resistance, noise, tone and outpulsing signals; .LP 2) \fIApply test signals\fR \ \(em\ TMN directs NE to send a test signal on the circuit. Examples are outpulsing and ringing signals; .LP 3) \fIRemove test signal\fR \ \(em\ TMN directs NE to remove the test signal sent by the apply function; .LP 4) \fIStop measurement\fR \ \(em\ TMN directs NE to terminate continuous or repeating type measurements. .sp 1P .LP B.3.2.3.1.4\ \ \fISignalling and supervision\fR .sp 9p .RT .LP 1) \fIChange split and supervision\fR \ \(em\ TMN directs NE to set up metallic test access splitting of the circuit and supervise in both directions for both a.c. and d.c. supervision; .LP 2) \fIRequest supervision status\fR \ \(em\ TMN requests NE to send in an analysis of the current signalling state of the circuit under test; .LP 3) \fISupervision status report\fR \ \(em\ TMN reports the current signalling state of a circuit under test to TMN. .sp 1P .LP B.3.2.3.2\ \ \fIDigital data circuit test\fR .sp 9p .RT .sp 1P .LP B.3.2.3.2.1\ \ \fITest access\fR .sp 9p .RT .LP 1) \fIConnect test access digital\fR \ \(em\ TMN directs NE to provide test access to a digital data circuit; .LP 2) \fIMonitor digital signals\fR \ \(em\ TMN establishes digital data monitor test access and determines the presence of network control codes or customer data; .LP 3) \fIChange digital test access to split\fR \ \(em\ TMN directs NE to provide split test access to the digital circuit under test; .LP 4) \fITest digital loopback\fR \ \(em\ TMN directs NE to provide a loopback on the circuit under test and perform a loopback test; .LP 5) \fIChange latching loopback\fR \ \(em\ TMN splits the circuit under test and changes the operate and release functions of digital network element latching loopback devices; .LP 6) \fIChange multipoint junction unit functions\fR \ \(em\ TMN directs NE to perform various control functions such as block, select, unselect, and release, on the multipoint junction unit (MJU) in the circuit; .LP 7) \fITest\fR \fImultipoint junction unit\fR \ \(em\ TMN directs NE to split the circuit under test and performs primary and secondary channel tests on the multipoint junction unit (MJU); .LP 8) \fITest straightaway\fR \ \(em\ TMN directs NE to split the circuit under test and connect the required test modules to perform a straightaway test; .LP 9) \fIEstablish loop around access\fR \ \(em\ TMN directs NE to establish a test access to a metallic circuit by selecting a test access path (TAP) and providing a looparound on the selected TAP; .LP 10) \fIConnect monitor state\fR \ \(em\ TMN directs NE to establish a monitor state without the need to re\(hyaccess the circuit under test. This function will remove or reset any previous state or condition except the terminate and leave state; .bp .LP 11) \fIChange split metallic/digital\fR \ \(em\ TMN directs NE to split the specified pair or pairs at the metallic or digital access point of the circuit under test, and connect it to the TAP. Both the facility (F) and equipment (E) sides of the split circuit are connected to the TAP, in agreement with the lead\(hypair assignment and configuration code; .LP 12) \fIChange terminate and leave metallic/digital\fR \ \(em\ TMN directs NE to change the terminate and leave state of the circuit under test; .LP 13) \fISilence repeater\fR \ \(em\ TMN directs NE to shut down a repeater; .LP 14) \fIRequest TAPs status\fR \ \(em\ TMN requests the status of all TAPs serving NE; .LP 15) \fITAPs status report\fR \ \(em\ NE reports the status of all TAPs to TMN; .LP 16) \fIReset TAPs\fR \ \(em\ TMN directs NE to release all existing test access connections in the NE. It also restores all TAPs involved to an idle state; .LP 17) \fIDiagnose TAP\fR \ \(em\ TMN directs NE to carry out a looparound of the TAPs from the test system for purposes of diagnosis. .sp 1P .LP B.3.3 \fIConfiguration management\fR .sp 9p .RT .sp 1P .LP B.3.3.1\ \ \fIProvisioning\fR .sp 9p .RT .sp 1P .LP B.3.3.1.1\ \ \fINE configuration\fR .sp 9p .RT .LP 1) \fIRequest configuration\fR \ \(em\ TMN requests that the NE report the current configuration of each entity; .LP 2) \fIConfiguration report\fR \ \(em\ For each entity, NE reports status, capacity of the entity, optional parameters, type of entity (in sufficient detail for TMN identification) and the version and revision of the version; .LP 3) \fIGrow\fR \ \(em\ TMN notifies NE of the presence of a newly installed entity; .LP 4) \fIPrune\fR \ \(em\ TMN notifies NE of the disconnection of an entity; .LP 5) \fIRestore\fR \ \(em\ TMN notifies NE to begin monitoring the newly installed entity; .LP 6) \fIAssign\fR \ \(em\ TMN notifies NE that a previously unequipped entity is now equipped; .LP 7) \fIDelete\fR \ \(em\ TMN notifies NE that a previously unequipped entity is no longer equipped; .LP 8) \fISet service state\fR \ \(em\ TMN directs NE to place the specified entity in one of the following states: in service (available for use), out of service (unavailable for use), standby (not faulty but not performing normal function), reserved; .LP 9) \fIRequest assignments\fR \ \(em\ TMN requests that NE report the identity of each assigned entity. The request may be for a specified entity or for all equipped entities; .LP 10) \fIAssignment reports\fR \ \(em\ NE reports the identity of each assigned channel for each equipped entity or for a specified entity; .LP 11) \fISet parameters\fR \ \(em\ TMN directs NE to set parameters associated with a specified entity; .LP 12) \fISet service thresholds\fR \ \(em\ TMN directs NE to set performance thresholds for the specified channel; .LP 13) \fIAdd/drop\fR \ \(em\ TMN directs NE to insert or remove a channel from the complement of through\(hychannels; .LP 14) \fICross\(hyconnect\fR \ \(em\ TMN directs NE to interconnect two specified channels operating at the same rate; .LP 15) \fIDisconnect\fR \ \(em\ TMN directs NE to remove the interconnection between two specified channels; .LP 16) \fIStart transmission test\fR \ \(em\ TMN directs NE to begin a transmission test on a given circuit; .LP 17) \fIBalance\fR \ \(em\ TMN directs NE to perform a balance test/adjustment; .LP 18) \fIStart transponder test\fR \ \(em\ TMN directs NE to look for a transponder signal on the given circuit; .LP 19) \fISet report periods\fR \ \(em\ The TMN directs NE to set or change report periods; .LP 20) \fIRequest report periods\fR \ \(em\ The TMN requests NE to send the current periods to the TMN. .bp .sp 1P .LP B.3.3.1.2\ \ \fIAdministrative functions\fR .sp 9p .RT .LP 1) \fISet clock\fR \ \(em\ TMN directs NE to set NE system clock to current calendar, date and time; .LP 2) \fIBackup copy\fR \ \(em\ TMN directs NE to make a backup copy of the designated NE data base file for purposes of archiving for future restoral; .LP 3) \fITerminate procedure\fR \ \(em\ TMN directs the NE to terminate a process between a TMN and a NE; .LP 4) \fIRoute messages\fR \ \(em\ TMN directs NE to route automatic messages generated by NE to one or multiple communications channels; .LP 5) \fISet service controls\fR \ \(em\ TMN directs NE to assign user access and functional capability. .sp 1P .LP B.3.3.1.3\ \ \fIData base management\fR .sp 9p .RT .LP 1) \fIInitialize\fR \ \(em\ TMN configures a new data base which is related to an NE. This may or may not be downloaded to the NE. This may also include loading a new program related to the NE; .LP 2) \fIReinitialize\fR \ \(em\ TMN reconfigures the data base within an NE while it is in service; .LP 3) \fIUpdate\fR \ \(em\ TMN adds, changes or deletes one or more records in the data base of an NE. This can be done in a delayed activation mode or upon command entry. It may also be able to enter data base updates on a test basis prior to permanent entry; .LP 4) \fIQuery\fR \ \(em\ TMN reads NE for all or part of its data base contents; .LP 5) \fIBackup\fR \ \(em\ TMN keeps a copy of all or part of the data base of an NE. In case of memory failure in the NE, the TMN downloads the backup copy to the NE. .sp 1P .LP B.3.3.2\ \ \fIStatus and control\fR .sp 9p .RT .LP 1) \fIRequest status\fR \ \(em\ TMN requests NE to send current status information; .LP 2) \fIStatus report\fR \ \(em\ NE reports to TMN the value of a monitored parameter. It may be sent on demand by TMN or on a scheduled basis; .LP 3) \fISchedule status report\fR \ \(em\ TMN directs NE to establish a schedule for the reporting of status information; .LP 4) \fIRequest status report schedule\fR \ \(em\ TMN directs NE to send the current schedule of status reporting. NE responds with the schedule; .LP 5) \fIAllow/inhibit automatic restoration\fR \ \(em\ TMN directs NE to allow or inhibit automatic restoration in an M+N or duplex system; .LP 6) \fIOperator/release automatic restoration\fR \ \(em\ TMN directs NE to switch a specified line or equipment to the redundant unit or release it from the redundant unit. For an M+N system, service is placed on the redundant unit and taken off of the working unit. For a duplex system the main unit becomes standby and the standby unit becomes the main unit. .sp 1P .LP B.3.3.2.1\ \ \fIMessage handling systems network\fR .sp 9p .RT .LP 1) \fIRequest message storage status data\fR \ \(em\ TMN requests NE to transmit the message storage status data of store and forward communication to TMN; .LP 2) \fIMessage storage status data report\fR \ \(em\ NE sends the status data to TMN. .sp 1P .LP B.3.3.2.2\ \ \fILeased circuit network\fR .sp 9p .RT .LP 1) \fIRequest status of dynamic provisioning of leased\fR \fIcircuit network\fR \ \(em\ TMN requests NE to transmit the status of dynamic provisioning to TMN; .LP 2) \fIStatus report of dynamic provisioning of leased circuit\fR \fInetworks\fR \ \(em\ NE sends the current status to TMN. .sp 1P .LP B.3.3.2.3\ \ \fITransmission network\fR .sp 9p .RT .LP 1) \fIRequest status of automatic transmission restoration\fR \ \(em\ TMN requests NE to transmit the switching activities and current status of automatic transmission restoration; .LP 2) \fIStatus report of automatic transmission restoration\fR \ \(em\ NE sends the current status of the switching operations to TMN. .bp .sp 1P .LP B.3.3.3\ \ \fIInstallation\fR .sp 9p .RT .PP A detailed list of installation functions for an SPC\(hyexchange is provided in Recommendation\ Z.331\ [1], \(sc\ 3.3. .RT .sp 1P .LP B.3.4 \fIAccounting management\fR .sp 9p .RT .PP This term and the subject is for further study. .RT .sp 1P .LP B.3.5 \fISecurity management\fR .sp 9p .RT .LP 1) \fIChange channel class\fR \ \(em\ TMN directs NE to change the security user class of an operations channel; .LP 2) \fIChange terminal class\fR \ \(em\ TMN directs NE to change the security class of NE terminal; .LP 3) \fIDial capability\fR \ \(em\ TMN directs NE to initiate a secure dial\(hyout/dial\(hyback capability to TMN; .LP 4) \fILog in\fR \ \(em\ TMN sends the appropriate password and identification of an NE communications channel; .LP 5) \fILog off\fR \ \(em\ TMN directs NE to terminate communication on a channel; .LP 6) \fIChange\fR \ \(em\ TMN directs NE to change the log\(hyin code assigned to NE; .LP 7) \fIChange dial number\fR \ \(em\ TMN directs NE to change the auto\(hydial\(hyback number that NE uses to call back the calling party upon receipt of a dial\(hyout call. .sp 2P .LP B.4 \fIGlossary\fR .sp 1P .RT .sp 1P .LP B.4.1 \fBalarm\fR .sp 9p .RT .PP An alerting indication to a condition that may have immediate or potential negative impact on the state of the monitored NE. .RT .sp 1P .LP B.4.2 \fBalarm attribute\fR .sp 9p .RT .PP A collective reference to delaying, stretching and severity of alarm indications. .RT .sp 1P .LP B.4.3 \fBalarm route\fR .sp 9p .RT .PP A path between an NE and a TMN for the transmission of alarm information. .RT .sp 1P .LP B.4.4 \fBaudit\fR .sp 9p .RT .PP A test of the validity of data and/or generic programs in the NE. .RT .sp 1P .LP B.4.5 \fBcontrol\fR .sp 9p .RT .PP A modifier of the state of an NE. .RT .sp 1P .LP B.4.6 \fBdelaying\fR .sp 9p .RT .PP Withholding the report of alarm information until the condition has persisted for a predetermined amount of time. .RT .sp 1P .LP B.4.7 \fBdiagnostic\fR .sp 9p .RT .PP A routine in the NE which performs detailed tests to isolate troubles. .RT .sp 1P .LP B.4.8 \fBexercise\fR .sp 9p .RT .PP Sequential operations which test the overall functioning of an NE or sub\(hysystem. .RT .sp 1P .LP B.4.9 \fBinitialization\fR .sp 9p .RT .PP Setting a process to a specified state. This may be a restart state or intermediate levels. .bp .RT .sp 1P .LP B.4.10\ \ \fBloopback\fR .sp 9p .RT .PP A procedure used in fault location whereby a signal is returned to its source along the same path on which it was received. .RT .sp 1P .LP B.4.11\ \ \fBmode\fR .sp 9p .RT .PP The alarm characteristic of being either continuous or self\(hyretiring. .RT .sp 1P .LP B.4.12\ \ \fBperformance monitoring (PM)\fR .sp 9p .RT .PP The monitoring of various parameters of an NE on an in\(hyservice basis to measure the quality of performance. .RT .sp 1P .LP B.4.13\ \ \fBperformance monitoring attributes\fR .sp 9p .RT .PP Characteristics of PM parameters including thresholds and pattern recognition criteria. .RT .sp 1P .LP B.4.14\ \ \fBseverity\fR .sp 9p .RT .PP An alarm attribute indicating the magnitude of the related failure. Some measures of severity include major, minor, service affecting and non\(hyservice affecting. .RT .sp 1P .LP B.4.15\ \ \fBsupervisory signal\fR .sp 9p .RT .PP A signal indicating the state or change of state of a circuit. .RT .sp 1P .LP B.4.16\ \ \fBscheduling\fR .sp 9p .RT .PP Can include the assignment of time intervals to the execution of one or more functions by the NE. It can also include inhibition or allowance of execution of the function without affecting prior scheduling. .RT .sp 1P .LP B.4.17\ \ \fBstatus\fR .sp 9p .RT .PP Information on the current state of an NE. .RT .sp 1P .LP B.4.18\ \ \fBstretching\fR .sp 9p .RT .PP Holding the indication of an alarm condition for a predetermined amount of time, even after the condition resolves to increase the chance that the TMN has scanned the indication. .RT .sp 1P .LP B.4.19\ \ \fBterminate and leave (T&L)\fR .sp 9p .RT .PP Terminating one or both direction of transmission on an outgoing transmission path. .RT .sp 1P .LP B.4.20\ \ \fBtest access point (TAP)\fR .sp 9p .RT .PP A virtual or physical testing path between a test system and the circuit under test in the NE. .RT .sp 1P .LP B.4.21\ \ \fBthresholding\fR .sp 9p .RT .PP Assignment of a specified value of a monitored parameter such that trouble indication is generated only when this value is exceeded. .RT .sp 1P .LP B.4.22\ \ \fBtrace\fR .sp 9p .RT .PP A report of the execution flow of a specified event. .RT .sp 1P .LP B.4.23\ \ \fBtrap\fR .sp 9p .RT .PP An automatic report of a specified event which would otherwise not be reported. .bp .RT .ce 1000 ANNEX\ C .ce 0 .ce 1000 (to Recommendation M.30) .sp 9p .RT .ce 0 .ce 1000 \fBTables of function attribute ranges\fR .sp 1P .RT .ce 0 .PP The 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, workstations and the TMN, between elements within the TMN or between TMNs. In this case the term efficiency relates to the cost, reliability and quantity of the data transported. .sp 1P .RT .PP Costs are impacted by two aspects. The first is the actual cost to transport data across the network between the TMN and the NE. To minimize this cost various network architectures are considered, e.g.,\ star, multipoint, loop, tree. The communications required must also be considered, e.g.\ leased circuits, circuit switched or packet\(hyswitched networks. In making this choice, network availability and cross\(hynetwork delays must be evaluated as attributes to be used in the decision\(hymaking process. .PP The second aspect is the design of the interface including the selection of the appropriate communications protocol. In this case there are several attributes associated with functions performed within the NE that would help to govern this choice. These attributes include: reliability, frequency, quantity and the requirement for priority. .PP This Annex provides tables of ranges for each of the function attributes that should be taken into consideration when planning the design of the data communications channels and selecting the appropriate protocol to be used to interface between a TMN and NE, TMN and workstation, or between elements within a TMN. Table\ C\(hy1/M.30 shows the basic function attributes. Table\ C\(hy2/M.30 shows examples of TMN attributes to support the OSs requiring real\(hytime operations, and Table\ C\(hy3/M.30 shows examples of the same attributes for a non real\(hytime OS. .RT .ce \fBH.T. [T1.30]\fR .ce TABLE\ C\(hy1/M.30 .ce \fBBasic table of function attributes\fR .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; lw(60p) | cw(48p) | cw(48p) | cw(60p) . Attributes Requirements Nature of attributes _ .T& cw(60p) | lw(48p) | lw(48p) | cw(60p) , ^ | l | l | ^ , ^ | l | l | ^ . { Performance,\fR or grade of service (P) } Delay (speed) Short Medium Long { Objective of design and control (acceptable/unacceptable) } Reliability (accuracy) High Medium Low Availability High Medium Low _ .T& cw(60p) | lw(48p) | lw(24p) sw(24p) | lw(60p) , ^ | l | l | l | ^ , ^ | ^ | l | l | ^ , ^ | l | c s. { Characteristics of TMN traffic (C) } Quantity { Large Medium Small Frequency } Non\(hy periodic Often Medium Seldom Periodic Often Medium Seldom Priority High Medium Low { Condition or parameter of design and control } _ .TE .nr PS 9 .RT .ad r \fBTableau C\(hy1/M.30 [T1.30], p.\fR .sp 1P .RT .ad b .RT .LP .bp .ce \fBH.T. [T2.30]\fR .ce TABLE\ C\(hy2/M.30 .ce \fBExample of function attributes for .ce real\(hytime operation\fR .ce | ua\d\u)\d\u,\d \ub\d\u)\d .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; lw(12p) | cw(42p) | cw(60p) | cw(114p) . Attributes Requirements Attribute ranges _ .T& cw(12p) | lw(42p) | lw(60p) | lw(114p) , ^ | l | l | l ^ | l | l | l. (P) Delay (speed) Short Medium Long { Network delay < \ 1 s Network delay \(= 10 s Network delay > 10 s } Reliability (accuracy) High Medium Low { No errors (goal) Infrequent errors (not service affecting) Can tolerate errors } Availability High Medium Low { Network availability > 99.95 % Network availability > 99.5 % Network availability < 99.5 % } _ .T& cw(12p) | lw(42p) | lw(30p) sw(30p) | lw(114p) , ^ | l | l | l | l ^ | ^ | l | l | l ^ | l | l s ^ | ^ | ^ | ^ | l. (C) Quantity { Large \fB.\fR Medium Small } { > 256 octets per transaction < (10\u6\d to 10\u7\d octets per job) | uc\d\u)\d < 256 octets per transaction < 16 octets per transaction } Frequency Non\(hyperiodic Often Medium Seldom { > 1 transaction per 10 ms > 1 transaction per 10 s < 1 transaction per 10 s (week, month) | uc\d\u)\d } Periodic Often Medium Seldom { > 1 transaction per 10 s > 1 transaction per minute < 1 transaction per minute (hour, day) | ud\d\u)\d } _ .T& lw(12p) | lw(42p) | lw(30p) sw(30p) | lw(114p) , ^ | l | l | l | l ^ | ^ | l | l | l ^ | l | l s ^ | ^ | ^ | ^ | l. Priority { High Medium Low } .TE .LP \ua\d\u)\d \*QReal\(hytime\*U has a two\(hyfold meaning: .LP i) on\(hyline activities consistently carried out from time\(hyto\(hytime, such as sampling of system status (type\ A), .LP ii) activities that are not frequently done but require quick operation once they have been called for (type\ B). .LP \ub\d\u)\d Attributes can be considered for: .LP i) each command, each inquiry, the responses to them, and each spontaneous report, .LP ii) an operation which consists of the combination of the categories in\ i), e.g.\ a command and its response. .LP \uc\d\u)\d For example, file loading, system recovery, etc. (type B). .LP \ud\d\u)\d For example, system file saving, call data saving, etc. .LP \fB .TE .TS box center ; rw(12p) | cw(42p) | lw(30p) sw(30p) | lw(114p) , ^ | l | l | l | l ^ | ^ | l | l | l ^ | l | l s ^ | ^ | ^ | ^ | l. TABLE\ C\(hy3/M.30 .T& cw(12p) | cw(42p) | lw(30p) sw(30p) | lw(114p) , ^ | l | l | l | l ^ | ^ | l | l | l ^ | l | l s ^ | ^ | ^ | ^ | l. { \fBExample of function attributes for non\(hyreal\(hytime operation\fR | ua\d\u)\d\u,\d \ub\d\u)\d } .T& lw(12p) | cw(42p) | cw(60p) | cw(114p) . Attributes Requirements Attribute ranges _ .T& cw(12p) | lw(42p) | lw(60p) | lw(114p) , ^ | l | l | l ^ | l | l | l. (P) Delay (speed) Short Medium Long { Network delay < 30 s Network delay < 15 min Network delay \(>=" 15 min } Reliability (accuracy) High Medium Low { No errors (goal) Infrequent errors (not service affecting) Can tolerate errors } Availability High Medium Low { Network availability > 99.95 % Network availability > 95 % Network availability \(= 95 % } _ .T& cw(12p) | lw(42p) | lw(30p) sw(30p) | lw(114p) , ^ | l | l | l | l ^ | ^ | l | l | l ^ | l | l s ^ | ^ | ^ | ^ | l. (C) Quantity { Large \fB.\fR Medium Small } { > 4096 octets per transaction < (10\u6\d to 10\u7\d octets per job) | uc\d\u)\d < 256 octets per transaction < 256 octets per transaction } Frequency Non\(hyperiodic Often Medium Seldom { > 1 transaction per minute \(>=" 1 transaction per hour < 1 transaction per hour (week, month) | uc\d\u)\d } Periodic Often Medium Seldom { > 1 transaction per minute \(>=" 1 transaction per hour < 1 transaction per hour } _ .ad r \fBTableau C\(hy2/M.30 [T2.30], p. 12\fR .sp 1P .RT .ad b .RT .LP .rs .sp 7P .ad r Blanc .ad b .RT .LP .bp .ce \fBH.T. [T3.30]\fR .ce TABLE\ C\(hy3/M.30 .ce \fBExample of function attributes for .ce non\(hyreal\(hytime operation\fR .ce | ua\d\u)\d\u,\d \ub\d\u)\d .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; lw(12p) | lw(42p) | lw(60p) | lw(114p) . _ .T& lw(12p) | cw(42p) | cw(60p) | cw(114p) . Attributes Requirements Attribute ranges _ .T& cw(12p) | lw(42p) | lw(60p) | lw(114p) , ^ | l | l | l ^ | l | l | l. (P) Delay (speed) Short Medium Long { Network delay < 30 s Network delay < 15 min Network delay \(>=" 15 min } Reliability (accuracy) High Medium Low { No errors (goal) Infrequent errors (not service affecting) Can tolerate errors } Availability High Medium Low { Network availability > 99.95 % Network availability > 95 % Network availability \(= 95 % } _ .T& cw(12p) | lw(42p) | lw(30p) sw(30p) | lw(114p) , ^ | l | l | l | l ^ | ^ | l | l | l ^ | l | l s ^ | ^ | ^ | ^ | l. (C) Quantity { Large \fB.\fR Medium Small } { > 4096 octets per transaction < (10\u6\d to 10\u7\d octets per job) | uc\d\u)\d < 256 octets per transaction < 256 octets per transaction } Frequency Non\(hyperiodic Often Medium Seldom { > 1 transaction per minute \(>=" 1 transaction per hour < 1 transaction per hour (week, month) | uc\d\u)\d } Periodic Often Medium Seldom { > 1 transaction per minute \(>=" 1 transaction per hour < 1 transaction per hour } _ .ad r \fBTableau C\(hy3/M.30 [T3.30], p. 13\fR .sp 1P .RT .ad b .RT .LP .sp 2 .sp 2P .LP \fBReferences\fR .sp 1P .RT .LP [1] CCITT Recommendation \fIIntroduction to the specifications of the\fR \fIman\(hymachine interface\fR , Vol.\ X, Rec.\ Z.331. .LP [2] CCITT Recommendation \fIReference model of open systems interconnection\fR \fIfor CCITT applications\fR , Vol.\ VIII, Rec.\ X.200. .LP [3] CCITT Recommendation \fIQ\(hyinterfaces and associated protocols for\fR \fItransmission equipment in the telecommunication management network (TMN)\fR , Vol.\ III, Rec.\ G.771. .LP [4] CCITT Recommendation \fIExchange interfaces for operations,\fR \fIadministration and maintenance\fR , Vol.\ VI, Rec.\ Q.513. .bp .sp 2P .LP \fBRecommendation\ M.32\fR .RT .sp 2P .ce 1000 \fBPRINCIPLES\ FOR\ USING\ ALARM\ INFORMATION\ FOR\ MAINTENANCE\fR .EF '% Fascicle\ IV.1\ \(em\ Rec.\ M.32'' .OF '''Fascicle\ IV.1\ \(em\ Rec.\ M.32 %' .ce 0 .sp 1P .ce 1000 \fBOF\ INTERNATIONAL\ TRANSMISSION\ SYSTEMS\ AND\ EQUIPMENT\fR .ce 0 .sp 1P .LP \fB1\fR \fBGeneral\fR .sp 1P .RT .PP 1.1 This Recommendation presents the general principles for employing those maintenance features and capabilities of international transmission systems and equipment which are based on alarm information. .sp 9p .RT .PP It describes a set of strategies, in addition to the maintenance philosophy in Recommendation\ M.20, to use these alarm\(hybased features and capabilities in an effective and efficient manner. This Recommendation is also intended to address the interactions between alarms of digital and analogue transmission systems and equipments. .PP Alarm interactions for mixed analogue/digital transmission systems and equipment are under study. .RT .PP 1.2 While this Recommendation discusses the strategy to employ these features and capabilities, the actual arrangements to provide and use them are left to the discretion of the Administrations. .sp 9p .RT .sp 2P .LP \fB2\fR \fBTypes of\fR \fBalarms and related messages\fR .sp 1P .RT .PP Alarm information may be categorized as follows: .RT .LP a) Prompt maintenance alarm (PMA); .LP b) Deferred maintenance alarm (DMA); .LP c) Maintenance event information (MEI). .PP Definitions of PMA, DMA and MEI are found in Recommendation\ M.20, \(sc\ 5.4.1. .sp 2P .LP \fB3\fR \fBGuidance for using alarm information\fR .sp 1P .RT .sp 1P .LP 3.1 \fIHierarchy\fR .sp 9p .RT .PP The alarm information from transmission systems and equipment is based on a hierarchy of: .RT .LP a) alarms and indications displayed on failed equipment or systems, .LP b) office audible/visual alarms which alert local staff, and .LP c) remote information which appears on a display monitored by centralized maintenance staff which is not collocated with the failed equipment or systems. .PP This alarm hierarchy is used in failure localization, either for a maintenance entity, or for specific equipment within a maintenance entity. .sp 1P .LP 3.2 \fIDisplay\fR .sp 9p .RT .PP Alarm information can be displayed to help in localization in different ways, such as: .RT .LP a) locally\ \(em\ on the equipment, .LP b) on site\ \(em\ in the same building as the equipment, or .LP c) remotely\ \(em\ at a building not collocated with the equipment. .PP Both localized and on\(hysite displays are used by on\(hysite maintenance staff. Remote displays are normally used either for coverage during periods when a building is not staffed or to obtain a wider maintenance perspective from a single location on a possibly large number of systems. .PP For example, the remote maintenance strategy of \(sc\ 3.5 can be used first to localize a trouble to a maintenance entity. Then, maintenance staff can obtain further remote (or otherwise made available) information to localize the failure to specific equipment. After this, the maintenance staff can use the local alarm maintenance strategy of \(sc\ 3.7 to isolate and correct the failure. .bp .RT .sp 1P .LP 3.3 \fIConsiderations for local or remote alarm monitoring\fR .sp 9p .RT .PP Alarm information may be displayed locally on equipment, or on\(hysite in the same building as the monitored equipment using external monitoring equipment. Use of such displays implies that maintenance staff must be present or visit the site to observe the information. .PP Remote alarm monitoring provides a means for staff at a centralized location, not collocated with the transmission systems and equipment, to monitor them. .PP The choice between local and remote monitoring and the degree of centralization and automation employed depends on a number of factors, including the type of maintenance organization, the expected failure rates and the physical locations involved. .RT .sp 1P .LP 3.4 \fIReducing unnecessary maintenance activity\fR .sp 9p .RT .PP When an equipment failure requiring some maintenance activity occurs, alarms should, if possible, be generated by the maintenance entity of which the equipment is part. The general rule is that maintenance activities should be directed only at the maintenance entity in which the failure exists. Thus, techniques should be used which prevent unwanted alarms (and the resulting unnecessary maintenance activity) beyond the maintenance entity in which a failure exists. Also, maintenance entities downstream of the failed maintenance entity should have a means of recognizing that a failure has occurred upstream, as part of the aim of reducing maintenance activity. Provision may be made at a maintenance entity to indicate an upstream failure and/or inhibit unnecessary actions. For example, in digital transmission systems and equipment, this may be accomplished by the use of: .RT .LP \(em alarm indication signal (AIS); .LP \(em service alarm (SA); .LP \(em upstream failure indication (UFI). .PP For definition of AIS, SA and UFI see Recommendation M.20, \(sc\ 5.4.2. .sp 1P .LP 3.5 \fIConsiderations for\fR \fIremote maintenance alarm information\fR .sp 9p .RT .PP Remote maintenance alarm information provides a means for staff not collocated with transmission systems and equipment to nonetheless monitor and control them. The monitored equipment may be located in unstaffed locations. This section recommends the principles which should be followed if remote alarm information is provided. .RT .PP 3.5.1 Identification and localization are required to determine what the response should be: start restoration of service by using alternate routes, dispatch for maintenance of failed equipment, or wait and gather further information to better identify the nature and/or seriousness of the problem. .PP 3.5.2 The decision to send maintenance staff is based upon the maintenance philosophy in Recommendation\ M.20, \(sc\ 1.1. .sp 1P .LP 3.6 \fIMaintenance alarm arrangements\fR .sp 9p .RT .PP Maintenance alarm arrangements are based on the use of audible/visual alarm systems. These systems provide alarms which direct on\(hysite staff to the location of the failed equipment. The objective when providing audible/visual alarm indications is that they should permit on\(hysite maintenance staff to detect and locate the source of failure in a timely fashion in line with other priorities. Note that distinctive sounds may be used to differentiate audible alarms. Also, visual signals should be able to direct maintenance staff to the failed equipment or to a point where the location of the failure can be determined. .RT .sp 1P .LP 3.7 \fIUse of\fR \fIlocal alarm information\fR .sp 9p .RT .PP 3.7.1 Local alarm information is concerned with alerting on\(hysite maintenance staff to equipment failures. The local maintenance activities usually entail the location and correction of the failure. To carry this out effectively and efficiently, information which helps direct the maintenance staff to the failure should be provided directly from the failed equipment. .PP 3.7.2 Local alarm information is derived from local failure indications, together with the maintenance staff use of tests and relevant documentation. This should be sufficient to localize the failure within the failed equipment. .bp .PP 3.7.3 Note that a further purpose of local failure indications is to provide a backup for remote indications, in the event that there is a failure in communications between monitored equipment and a central monitoring location. .sp 2P .LP \fB4\fR \fBGeneral considerations\fR .sp 1P .RT .sp 1P .LP 4.1 \fIMonitoring\fR .sp 9p .RT .PP In general, failures of equipment should be detected by continuous (or nearly continuous) automatic monitoring, as opposed to monitoring or testing involving human intervention. Note that shared, but automatic, monitoring is considered nearly continuous. Continuous (or nearly continuous) monitoring is often made feasible by virtue of advances in technology, and by virtue of the large number of circuits affected or jeopardized by a transmission system failure. In addition, continuous (or nearly continuous) monitoring is faster, more reliable, and less labor intensive than alternative monitoring strategies. .RT .sp 1P .LP 4.2 \fIUses of PMA, DMA and MEI\fR .sp 9p .RT .PP 4.2.1 When reporting or displaying alarms either locally or remotely, it is important to distinguish between PMA/DMA indications and MEI\ indications. PMA/DMA indications are those which cause maintenance staff to be alerted (e.g., by ringing a bell), and MEI\ indications are those which are displayed in response to staff interrogations or in conjunction with other indications (e.g., alarms) which are spontaneously generated. .PP 4.2.2 These distinctions should be defined for each transmission system and equipment in order for alarm indications to be properly processed. These distinctions may be of particular importance when using remote alarm surveillance systems, where large numbers of PMA, DMA and MEI\ indications must be dealt with by maintenance staff. .PP 4.2.3 MEI indications may be used as aids in failure localization or verification of remote operations (such as remote control of protection switching) under manual control. The information conveyed by MEI\ indications may also be used to supplement that conveyed by PMA/DMA indications. .PP 4.2.4 Note that detection of failures is accomplished by having suitable monitors associated with each maintenance entity. The criteria for activating alarm indications at a maintenance entity should generally be based on limits on the maintenance entities, which will generally be related to the performance objectives of the transmission systems. .PP 4.2.5 To aid in the dispatch of personnel, remote indications should include the following information: .LP a) identification of the failed transmission system or equipment and nature of trouble condition, .LP b) distinction between service\(hyaffecting failures and non\(hyservice\(hyaffecting failures where such a distinction is possible, and .LP c) severity of the failure which has occurred. .sp 1P .LP 4.3 \fITransmission and presentation of alarm information\fR .sp 9p .RT .PP 4.3.1 There are two basic interface arrangements for transferring alarm information between monitored and monitoring equipment: .LP a) discrete, parallel, and .LP b) serial data. .PP The parallel method of data gathering and control uses discrete wires for implementing each function. The serial data method of gathering and control uses a single pair of wires to carry serial (in time) data points, rather than individual wires for each point. Much new telecommunications equipment is \*Qintelligent\*U, that is, it employs microprocessor circuit design, which lends itself more readily to serial data transfer rather than to parallel. .PP 4.3.2 The presentation of alarm information can be: .LP a) visual (lamp, LED, printer or display indication), and/or .LP b) audible (bell, tones or voice). .PP The alarm information may be presented as: .LP a) an indication at an alarm interface (e.g., contact function, d.c. signal) and/or .LP b) an alarm message on the man\(hymachine interface. .bp .PP This alarm message may contain: .LP i) heading (name of maintenance entity, date, time,\ etc.), .LP ii) category of failure (PMA, DMA, MEI), .LP iii) description of failure, which may include the cause of failure, location of the failed item(s) and other information which can be useful in locating the failed item(s), .LP iv) possible consequences of the failure, and .LP v) automatic actions performed by the network (internal protection and service actions). .sp 1P .LP 4.4 \fIPossible use of MEIs\fR .sp 9p .RT .PP Administrations using MEI may desire to alert maintenance staff by means of a PMA or DMA. The criteria and arrangements .FS The arrangements to generate such information may take place in the transmission system or in auxiliary supervision systems. .FE for generating PMA or DMA based on analysis of MEI are left to their discretion. .RT .sp 1P .LP 4.5 \fIConsiderations for\fR \fIprotection switching and control\fR .sp 9p .RT .PP To meet transmission system availability objectives or maintenance criteria, transmission systems may be provided with protection equipment. Such equipment, if provided, may have the following capabilities: .RT .LP a) automatic protection switching of service from failed regular equipment to working standby equipment, .LP b) automatic protection switching of service to overcome transmission degradation caused, for example, by radio path fading, .LP c) remotely controlled protection switching of service between regular equipment and standby equipment, and/or .LP d) locally controlled protection switching of service between regular equipment and standby equipment. \v'6p' .sp 2P .LP \fBRecommendation\ M.34\fR .RT .sp 2P .ce 1000 \fBPERFORMANCE\ MONITORING\ ON\ INTERNATIONAL\ TRANSMISSION\fR .EF '% Fascicle\ IV.1\ \(em\ Rec.\ M.34'' .OF '''Fascicle\ IV.1\ \(em\ Rec.\ M.34 %' .ce 0 .sp 1P .ce 1000 \fBSYSTEMS\ AND\ EQUIPMENT\fR .ce 0 .sp 1P .LP \fB1\fR \fBGeneral\fR .sp 1P .RT .PP 1.1 This Recommendation presents the general principles for employing performance monitoring features and capabilities on international transmission systems and equipment for maintenance purposes. Performance monitoring data is one category of maintenance information as described in Recommendation\ M.20, \(sc\ 5.4. .sp 9p .RT .PP 1.2 As an example, the need for performance monitoring may be seen by considering a defective transmission system or equipment which will increasingly degrade for a period of time prior to total failure. In the early stages, the failing system or equipment generates errors over isolated short duration intervals, possibly causing short losses of frame alignment. As the severity of the degradation increases with time, the quantities and densities of errors and losses of frame alignment increase to more severe levels. Since these error bursts and losses of frame alignment are usually too short in duration to initiate automatic\(hyprotection switching or to generate alarms, they will propagate through the network unchecked and affect customers. The degradation process may last for days, weeks or even months if not corrected before a detectable failure occurs. In many cases, the defective equipment will never completely fail, but continually generate errors and losses of frame alignment. .PP 1.3 This Recommendation describes a possible strategy to employ performance monitoring features and capabilities. The choice of applying this strategy and the actual arrangements to provide it are left to the discretion of the Administrations. .bp .sp 2P .LP \fB2\fR \fBGeneral strategy for using performance monitoring data\fR .sp 1P .RT .sp 1P .LP 2.1 \fIGeneral\fR .sp 9p .RT .PP Performance monitoring is generally used to collect data which may identify degrading systems before they fail and cause alarms. The maintenance staff response to performance monitoring data does not usually require the same priority as to other alarm information. .RT .sp 1P .LP 2.2 \fILocal or remote performance monitoring\fR .sp 9p .RT .PP Performance data may be displayed locally on equipment, or on\(hysite in the same building as the monitored equipment using external monitoring equipment (for example, portable test sets). Use of such displays implies that maintenance staff must visit the site at least periodically to retrieve the data. .PP Remote performance monitoring provides a means for staff at a centralized location to monitor distant transmission systems and equipment. .PP The choice between local and remote monitoring and the degree of centralization and automation employed depends on a number of factors, including the type of maintenance organization, the expected failure rates and the physical locations involved. .RT .sp 1P .LP 2.3 \fIMonitoring strategies\fR .sp 9p .RT .PP In general, failures of equipment should be detected by continuous automatic performance monitoring, as opposed to monitoring or testing involving human intervention. This capability, however, implies that the performance monitor feature is built into the digital terminal system, or that dedicated external performance monitor equipment is provided for each termination. .PP An alternative to providing dedicated external performance monitor equipment is to provide remote access to protected monitor points and share external performance monitoring equipment with a number of terminal systems. This alternative of shared, but automatic monitoring is considered nearly continuous. .PP Continuous (or nearly continuous) monitoring is often made feasible by virtue of advances in technology, and by virtue of the large number of circuits affected or jeopardized by a transmission system failure. While continuous performance monitoring capabilities built into transmission systems and terminals are clearly the preferred implementation for new systems, the concept of nearly continuous monitoring offers an efficient and cost\(hyeffective means of providing automatic monitoring capabilities for existing digital systems not having the built\(hyin capabilities. In addition, continuous (or nearly continuous) monitoring is faster, more reliable, and less labor intensive than manual monitoring strategies. .RT .sp 1P .LP 2.3.1 \fIUses of\fR \fIperformance monitoring data\fR .sp 9p .RT .PP Three general ways in which performance monitoring data may be used for maintenance purposes are: .RT .LP a) for routine monitoring of transmission systems and equipment, .LP b) for demand monitoring initiated by staff, .LP c) for initiating a deferred maintenance alarm when performance has degraded beyond pre\(hydetermined limits. .PP 2.3.2 For routine monitoring , performance data which may be useful in predicting degrading systems is routinely collected and reported to a person on a scheduled or periodic basis. The reporting of data may provide, for example, daily, weekly or monthly summaries of performance. .PP As an example, remotely located monitoring equipment may continuously observe the performance of a collocated transmission system and store the significant data until a central computer requests the remote monitoring equipment to report the data. The central computer may routinely request data once every day. Then the central computer would convert the data into a report format useful for maintenance staff. Maintenance staff may use this routine data to determine trends in performance and schedule preventive maintenance or repairs before a failure has occurred. Or it may use the data to verify that transmission objectives are being met. .bp .PP 2.3.3 For demand monitoring , the staff requests performance data on an essentially real\(hytime basis from a monitored entity. This type allows the staff to retrieve detailed information from the monitored entity. .PP The main uses of demand monitoring are repair verification, installation and acceptance testing. However, for some transmission systems (for example, a radio system), demand monitoring may be used with other test equipment or signal generators to perform fault localization. .PP 2.3.4 A deferred maintenance alarm is initiated if performance has degraded so much that it is important for the staff to be alerted independently of the routine reporting of performance data. The deferred maintenance alarm should be indicated to the staff as soon as practical. It would be expected that maintenance staff would respond relatively quickly to this alarm for restoration and correction. .sp 1P .LP 2.3.5 \fICriteria for\fR \fIselection of performance monitoring data\fR .sp 9p .RT .PP The general criteria for selection of performance monitoring data are as follows: .RT .LP a) the data should be chosen depending on their use; i.e.,\ maintenance (\(sc\ 2), verification (\(sc\ 3.1) or characterization (\(sc\ 3.2); .LP b) the amount of data and their resolution should be adjusted so as to minimize the amount of data collected, stored and reported consistent with the uses of performance monitoring data in \(sc\ 2.3.1; .LP c) the data should be of a form which allows comparison of performance among different transmission systems and equipment; .LP d) for each data element it is important to select an appropriate measurement time interval. .sp 1P .LP 2.4 \fITypes of\fR \fIinterfaces to monitoring equipment\fR .sp 9p .RT .PP 2.4.1 For specific applications, Administrations should consider using a serial interface for transfer of perfor mance monitoring data between the monitored entity and the equipment which is monitoring it. To derive maximum benefit in using the performance monitoring data, very fine resolution for representing each data element may be necessary. This may imply that an impractically large number of wires may be required if a serial interface is not used. For other applications where little performance data is transferred or where each performance data element can be represented with few levels of coarse resolution, a discrete interface may be appropriate (see \(sc\ 4.3 of Recommendation\ M.32). .PP 2.4.2 It is recommended that Administrations evaluate both interface arrangements using the above considerations and use the one which is most economical and feasible for the specific application. .sp 1P .LP 2.5 \fIData collection and report screening\fR .sp 9p .RT .PP 2.5.1 Performance monitoring implies the collection of data from transmission systems and equipment which may be performing satisfactorily a large portion of the time they are monitored. To meet the objectives for performance monitoring, a means of screening the data is desirable so that only useful information is provided. Administrations should base the amount of screening on the desired maintenance staff responses and the processing, storage and communications needs related to the data quantities. .PP 2.5.2 As an example of screening, consider the case where there are two thresholds available in a remotely located performance monitoring equipment. For a particular monitored entity, a storage threshold may be used such that performance data for that entity measured over a given time interval need not be stored or reported unless the threshold is exceeded. Then a deferred maintenance alarm threshold may be used such that when the performance data exceeds this threshold, the monitoring equipment will not only store the data but also generate a deferred maintenance alarm. .PP 2.5.3 Note that in a system in which processing is shared between remotely located monitoring equipment and a central processor, the central processor may contain thresholds which may be used to further screen or process information reported to the maintenance staff. .bp .sp 2P .LP \fB3\fR \fBOther possible uses of\fR \fBperformance monitoring data\fR .sp 1P .RT .PP In addition to maintenance, performance monitoring data may be used for: .RT .LP a) verification of transmission system or equipment performance objectives, .LP b) characterization of transmission systems and equipment. .PP 3.1 The verification of objectives is concerned with the transmission systems and equipment as a whole and how well the analogue or digital signal streams are being delivered to the aggregate of customers using these systems and equipment. Thus, even if a particular regular equipment is operating poorly, when a protection equipment is operating properly, signal streams are still being delivered to customers intact. Thus, monitoring for verification of objectives should usually be done only when the equipment which is the object of the verification is carrying live traffic. The monitored verification data can be used to give a general picture of the performance of the transmission system and equipment, construct network measures, and verify that transmission objectives are being met. .PP 3.2 Characterization includes collection of data that may be used by transmission system and equipment designers. This type of data is often very specialized, and often must be collected in very large quantities in order to do an appropriate system characterization. It is also often collected with monitoring equipment specifically designed for the purpose. \v'6p' .sp 2P .LP \fBRecommendation\ M.35\fR .RT .sp 2P .sp 1P .ce 1000 \fBPRINCIPLES\ CONCERNING\fR | \fBLINE\(hyUP\ AND\ MAINTENANCE\ LIMITS\fR .EF '% Fascicle\ IV.1\ \(em\ Rec.\ M.35'' .OF '''Fascicle\ IV.1\ \(em\ Rec.\ M.35 %' .ce 0 .sp 1P .PP The following principles have been adopted in respect of line\(hyup and maintenance action limits for analogue and digital international circuits, links and lines: .sp 1P .RT .LP i) There should be separate limits for line\(hyup and maintenance action. .LP ii) There should be a single limit specified for maintenance action, and this limit should be chosen such that, if exceeded, a fault would be considered to exist. (However, the subject of prompt and deferred maintenance action requirements is under study and the result of this study may reflect on the number of limits required for maintenance action.) .LP iii) After clearance of a fault, an international circuit, link or line should be returned to service within the line\(hyup limit or, in the circumstances where this is not practical, as close as possible to the line\(hyup limit. In all cases, the circuit, link or line should be returned to service within the maintenance action limit. .PP It is intended that, wherever practical, these principles be embodied in new M and N\ Recommendations, and be taken into account when the M and N\ Recommendations have cause to be reviewed or amended. \v'6p' .sp 2P .LP \fBRecommendation\ M.36\fR .RT .sp 2P .sp 1P .ce 1000 \fBPRINCIPLES\ FOR\ THE\ MAINTENANCE\ OF\ ISDNs\fR .EF '% Fascicle\ IV.1\ \(em\ Rec.\ M.36'' .OF '''Fascicle\ IV.1\ \(em\ Rec.\ M.36 %' .ce 0 .sp 1P .LP \fB1\fR \fBGeneral\fR .sp 1P .RT .PP The purpose of this Recommendation is to apply general maintenance principles to determine the maintenance strategy to be adopted by Administrations and other maintenance service providers (MSP) in order to maintain ISDNs. .PP In providing this guidance, due consideration has been given to the principles identified in Recommendations\ M.20, M.30, M.32 and\ M.34 and to the activities identified in the I.600\(hySeries Recommendations\ [1]. .bp .RT .sp 1P .LP 1.1 \fIScope of application\fR .sp 9p .RT .LP 1) considering that Recommendation M.20 defines the maintenance philosophy for telecommunications networks; .LP 2) considering that Recommendation M.30 defines the principles for the telecommunications management network (TMN); .LP 3) considering that Recommendation I.601 [2] describes reference configurations, general architecture for maintenance of ISDN subscriber access and subscriber installation, which are applied in: .LP \(em Recommendation I.602 [3] for the ISDN subscriber installations, .LP \(em Recommendation I.603 [4] for the ISDN subscriber basic accesses, .LP \(em Recommendation I.604 [5] for the ISDN subscriber primary rate accesses, .LP \(em Recommendation I.605 [6] for the static multiplexed basic rate accesses, .LP \(em Recommendation I.606 (under study) for the ISDN subscriber higher rate access; .LP 4) considering that Recommendations Q.940 [7] and Q.942 (under study) describe the model, service elements and protocols to be provided at the ISDN user/network interfaces for management; .LP 5) considering that Recommendation M.550 provides the maintenance limits for digital paths and sections to achieve the performance objectives given in Recommendation\ G.821\ [8], .LP this Recommendation defines the ISDN maintenance concepts to be applied for the maintenance of subscriber installations, networks, including the transit network, and interworking between ISDNs and other networks, including both existing and future public and private networks. .PP This Recommendation takes into consideration basic ISDN features such as: .LP \(em open communication via the S/T reference points; .LP \(em portability of terminals between S/T reference points, from subscriber installation to subscriber installation, and from ISDN to ISDN. .sp 2P .LP \fB2\fR \fBOverview\fR .sp 1P .RT .sp 1P .LP 2.1 \fIGeneral maintenance principles for ISDN\fR .sp 9p .RT .PP The fundamental maintenance strategy is to rely on performance monitoring wherever possible in order to apply the controlled maintenance principles of Recommendation\ M.20. .PP The maintenance capabilities provided must allow for the clear differentiation of troubles between subscriber and network equipment. .PP The maintenance capabilities provided must allow for clear differentiation between faults and legitimate subscriber activities. .PP A MSP should be able to localize the fault in his domain without disturbing the network or other domains. This should be possible locally and remotely, i.e.,\ across networks and between any allowed management entities. .PP Testing will be needed both to supplement the performance monitoring for trouble detection and to provide additional trouble localization ability. .PP The subscriber installation should be able to receive failure or performance information if sent from the network side. The network should be able to receive failure or performance information from the subscriber side. .PP A capability should be provided to control the status of the subscriber access and of the subscriber equipment during maintenance operations. .PP The subscriber installation (or its MSP) should be able to receive information, if sent from the network, about the maintenance status of its access. .PP Only the Administration may initiate maintenance action within the subscriber access. .PP The subscriber or his MSP, either private or Administration, may initiate maintenance action within the subscriber installation. .bp .RT .sp 1P .LP 2.2 \fISupervision of the subscriber access and end\(hyto\(hyend performance\fR \fImeasuring\fR .sp 9p .RT .PP For maintenance purposes, each maintenance entity (ME) and maintenance entity assembly (MEA) provides its own performance measuring according to Recommendation\ M.20. The generated anomaly and defect informations allows decision and identification of ME or MEA in the degraded or unacceptable functioning state, and reporting that state to the associated management entity. .PP The network can only measure the performance of MEs and MEAs. The problem of how to combine the performance of the MEs and MEAs of the transit network with that of the subscriber accesses to determine the end\(hyto\(hyend performance as seen by the subscriber is for further study. .RT .LP 2.3 \fIManagement reference models\fR .sp 1P .RT .sp 2P .LP 2.3.1 \fIReference definitions\fR .sp 1P .RT .sp 1P .LP 2.3.2 \fBsubscriber access maintenance center (SAMC)\fR .sp 9p .RT .PP An SAMC represents a group of functions, network equipment elements and staff controlled by the Administration, which together have the responsibility and capability for maintenance functions and maintenance actions within the subscriber access. .RT .sp 1P .LP 2.3.2.1 \fBsubscriber access maintenance entity (SAME)\fR .sp 9p .RT .PP The SAME controls the subscriber access maintenance functions and provides communications for such activities. The SAME might be distributed. .PP Example of SAME functions: .RT .LP \(em control loopbacks in an NT1 or LT; .LP \(em supervise the service state of the subscriber access; .LP \(em provide access to subscriber access performance information. .sp 1P .LP 2.3.2.2 \fBsubscriber installation maintenance entity (SIME)\fR .sp 9p .RT .PP An SIME represents a group of dedicated functions contained within the functional groups (as specified in Recommendation\ I.411\ [9]) of the subscriber installation (i.e.\ TE1 and NT2) which have, for example, the following purposes: .RT .LP \(em interaction with the (human) user; .LP \(em handling of maintenance protocol from the SAME and/or a MSP; .LP \(em control of internal testing and maintenance mechanisms. .PP It is considered that the functions of the SIME may be distributed throughout the protocol layers implemented in the subscriber equipment and management/maintenance entities, including NT1 functions in some applications, but the precise architecture and protocol of the SIME is not a subject of this Recommendation. .PP Examples of SIME functions: .RT .LP \(em control TE loopbacks; .LP \(em identify TE service capability; .LP \(em control generation of test signals for maintenance of subscriber installation wiring; .LP \(em provide access to performance data within subscriber installation, e.g.\ layer two and three protocol performance; .LP \(em security screen requests from MSPs. .sp 1P .LP 2.3.2.3 \fBmaintenance service provider (MSP)\fR .sp 9p .RT .PP The MSP represents a group of functions, equipment and maintenance staff, that together have the responsibility for maintaining the subscriber installation or a part of the subscriber installation. A MSP cannot control the maintenance functions of the subscriber access. If authorized, it can request information from the SAMC about the subscriber access. .RT .LP 1) Agreement and responsibility for maintenance between the subscriber and the MSP for each part or parts of the subscriber installation should be made at the time of subscription to the maintenance service (this may take the form of a commercial contract). In any case, provision to allow a customer to change the maintenance service provider(s) is recommended. The subscriber may choose not to make such an agreement with a MSP. .bp .LP 2) Maintenance service providers can be .LP \(em private providers, .LP \(em the Administration, .LP \(em the subscriber. .LP 3) Private MSPs that are connected to ISDN by a S/T interface are referred to as external MSPs. Administration MSPs may also be connected via S/T interface or by other means as described below. .LP 4) The interfaces between ISDNs and MSPs are for further study. .LP 5) It is the sole responsibility of a subscriber installation and not of the network to ensure that an unauthorized MSP cannot obtain access to maintenance functions in the subscriber installation. .PP Examples of MSP functions: .LP \(em request SIME maintenance activity; .LP \(em request SAMC maintenance information that is allowed; .LP \(em provide test responders. .sp 1P .LP 2.3.2.4 \fBoperation, administration and maintenance centre (OAMC)\fR .sp 9p .RT .PP The OAMC is an Administration's centre with the responsibility for the general operation, administration and maintenance of the network. It includes both staff and associated operations systems. The functions may be distributed among many centres and OSs. .PP Examples of OAMC functions: .RT .LP \(em request SAME to control loopback activation; .LP \(em supervise the bringing into service of subscriber access; .LP \(em obtain performance information on the subscriber access from the SAME; .LP \(em manage teleservices provided to a subscriber; .LP \(em screen requests from MSPs for authorization. .PP The SAMC is composed of the SAME and part of the OAMC. .sp 1P .LP 2.3.2.5 \fIManagement entities\fR .sp 9p .RT .PP Management entities are groups of capabilities that collectively provide management functions, such as operations, administration, maintenance and provisioning. For the network part, the functions may be implemented by a combination of capabilities in network elements and operations systems. For the subscriber part, management functions may be contained within the subscriber installations. .RT .sp 1P .LP 2.3.3 \fIReference maintenance configuration\fR .sp 9p .RT .PP Shown in Figure 1/M.36 is the reference maintenance configuration, which gives the relationship between the subscriber installation and subscriber access to be maintained and the various maintenance centers, entities and providers. .PP This reference model shows the possible physical interconnection between Terminal Equipment (TE), Local Exchanges (LE), OAMC and MSPs. .PP The lines between physical devices containing each functional entity represent physical communications paths over which the management information may flow. It is envisioned that the higher layer protocols for management and maintenance would be the same. See Figure\ 7/I.601\ [2] for another representation of this communication. Service primitives are required to facilitate interworking with a variety of lower layer protocols. Further study is needed to define these service primitives. Thus, the connections between the various entities could be provided by D\(hychannels, X.25 networks, Signalling System No.\ 7, or leased lines. .PP In this reference configuration, the subscriber access is maintained by a SAMC. Local or remote users or MSPs may communicate with the SAMC to request certain maintenance functions under its control. The SAME provides the communications interface for network local management functions and contains the control functions for such local activity. The SAME functions may either be entirely part of the local exchange or may be distributed between the LE and an OAMC. .bp .RT .LP .rs .sp 35P .ad r \fBFigure 1/M.36, (N), p.\fR .sp 1P .RT .ad b .RT .sp 1P .LP 2.3.4 \fIRelationship to telecommunications management network\fR .sp 9p .RT .PP The telecommunications management network (TMN) is intended to provide an Administration with an independent communications network to carry its management (operations, administration and maintenance) messages to and from its operations system (OSs) to the telecommunications network it manages, including its ISDN and associated network elements. Figure\ 2/M.36 shows an example of one possible relationship of a TMN to the ISDN that is shown in Figure\ 1/M.36. .PP In Figure 2/M.36, the TMN would carry management messages between the OAMC (including an Administration MSP, if provided) and the ISDN over a Q\(hytype TMN interface (see Recommendation\ M.30 for a description of the TMN interfaces). The TMN would also provide the communications for an Administration's externally provided MSP using the TMN PQ\(hyDCN protocol suite (as defined in Recommendation\ M.30) over a T\(hytype physical ISDN interface. .PP A private MSP may be connected directly to the ISDN via a T\(hytype interface. It may also be connected to the TMN by interworking via other network interworking interfaces that are under study. .PP While supporting the ISDN, the TMN is also supporting other management functions for the Administration, including the maintenance of transmission system equipment. .bp .RT .LP .rs .sp 29P .ad r \fBFigure 2/M.36, (N), p.\fR .sp 1P .RT .ad b .RT .sp 1P .LP 2.3.5 \fICommunications reference models\fR .sp 9p .RT .PP Communications between functional groups is required for the maintenance of ISDNs. The communications configurations for maintenance of the subscriber access and the subscriber installation are shown in Recommendation\ I.601\ [2]. Configurations for the transit part and for end\(hyto\(hyend ISDN maintenance are for further study. .RT .sp 2P .LP 2.4 \fIISDN management protocol principles\fR .sp 1P .RT .sp 1P .LP 2.4.1 \fIGeneral review\fR .sp 9p .RT .PP The different management functions which may be contained, for example, in the SAMC, SIME, MSP,\ etc., are implemented in one or several real systems. A \fBreal system\fR is a set of one or more computers, associated software,\ etc., that form an autonomous whole capable of performing information processing and/or information transfer. Each real system contains one or more management entities that supports management functions. A real open system is a real system which complies with the requirements of Recommendation\ X.200\ [10] in its communication with other real systems. .PP \fINote\fR \ \(em\ Two different modeling concepts are applicable to ISDN management protocol: .RT .LP \(em ISDN protocol reference model (ISDN PRM), as defined in Recommendation\ I.320\ [11]; .LP \(em reference model of open systems interconnection for CCITT Applications (OSI PRM), defined in Recommendation\ X.200\ [10]. .bp .PP These two reference models have the following commonalities: .LP \(em both the ISDN PRM and the OSI PRM organize communications functions into layers and describe the relation of these layers with respect to each other; .LP \(em the concepts and the associated terminology, which have been introduced in Recommendations\ X.200\ [10] and X.210\ [12] are fully applicable to the ISDN PRM. They include the concept of layer, layer service, and the notions of service primitives, peer entities and peer protocol. .sp 1P .LP 2.4.2 \fIRequirements for ISDN maintenance activities\fR .sp 9p .RT .PP Maintenance of ISDN equipments and interfaces is part of the general management process in an ISDN management entity. It is intended that maintenance of ISDN equipments by remote MPS through ISDN interfaces should follow the principles of Recommendation\ X.200 and of open systems management, which are under study. .PP Systems management is achieved through a set of application processes running in different management entities that communicate together and play complementary roles to provide management activities. .PP Within a management entity, system management functions are controlled and performed by the \fIsystem management element\fR . The system management element can be seen as a set of application processes communicating with remote application processes by the use of one or more application layer entities. An application process is an element within a management entity which performs the information processing for a particular application. .PP The definitions of the functions among management entities needed to maintain the ISDNs according to the principles stated in this Recommendation are for further study. .RT .sp 2P .LP \fB3\fR \fBBasic rate access\fR .sp 1P .RT .sp 1P .LP 3.1 \fIBasic rate access maintenance models\fR .sp 9p .RT .PP Three access configurations are described below, along with a common subscriber equipment arrangement that applies to all three models. For each model, the maintenance entities are identified using reference points to delimit them. Some of these reference points are or may become standard interfaces. The ownership boundaries between network and customer are outside the scope of this Recommendation. .PP Because the D\(hychannels shown in the models below all route through several MEs (maintenance entities), they are not MEs themselves but will be treated as maintenance entity assemblies. The D\(hychannels carry several protocol layers that will be treated using the management and maintenance protocols that are under study. These include a definition of a layer management entity concept for each of the layers. .PP Other models are possible, but only a few, representative models are included here. Models including leased lines and digital crossconnect systems are left for further study. .RT .sp 1P .LP 3.1.1 \fISimple model\fR .sp 9p .RT .PP This model, shown in Figure 3/M.36, is similar to that shown in Figure\ 2/M.20. In the model, the V\d1\uinterface may be replaced by a function, such as a loopback point in a combined LT/ET, while still providing a boundary between MEs. .RT .sp 1P .LP 3.1.2 \fISubscriber equipment arrangements\fR .sp 9p .RT .PP This model is shown in Figure 4/M.36. .RT .sp 1P .LP 3.1.3 \fIMultiplexed interface\fR .sp 9p .RT .PP This model is shown in Figure 5/M.36. .PP In this case, several basic rate accesses using V\d1\ureference points are multiplexed or concentrated to interface the exchange termination. For static multiplexing, a V\d6\uinterface is applied. For dynamic multiplexing (multiplexing on the D\(hychannel) or concentrating (dynamic assignment of the B\(hychannels), a V\d2\uinterface is applied. The V\d2\uand V\d6\uinterfaces are defined in Recommendation\ Q.512\ [13]. Performance monitoring is applied to the digital section of the basic rate access (between T interface and V\d1\ureference point) and between the multiplex/concentrator and the exchange termination. .bp .RT .LP .rs .sp 11P .ad r \fBFigure 3/M.36, (N), p. 16\fR .sp 1P .RT .ad b .RT .LP .rs .sp 13P .ad r \fBFigure 4/M.36, (N), p. 17\fR .sp 1P .RT .ad b .RT .LP .rs .sp 13P .ad r \fBFigure 5/M.36, (N), p. 18\fR .sp 1P .RT .ad b .RT .LP .bp .sp 1P .LP 3.1.4 \fIRemote multiplexed interface\fR .sp 9p .RT .PP The model is shown in Figure 6/M.36. .PP This is similar to the previous model except that it is extended between the multiplex and the ET by one or more digital links which may route over higher order links. .RT .LP .rs .sp 11P .ad r \fBFigure 6/M.36, (N), p.\fR .sp 1P .RT .ad b .RT .sp 1P .LP 3.1.5 \fIBasic rate leased lines\fR .sp 9p .RT .PP This is for further study. .RT .sp 2P .LP 3.2 \fIRequired capabilities\fR .sp 1P .RT .sp 1P .LP 3.2.1 \fITransmission format maintenance features (layer 1)\fR .sp 9p .RT .PP The format will be such as to support performance monitoring in both directions of transmission. Specifically, there will be error detection in each direction computed across the digital signal, for example, with CRC (cyclic redundancy check) or other error detection methods. .PP Transmission errors detected at the LT are converted to near\(hyend error (NEE) indications. Transmission errors detected at the NT are converted to far\(hyend error (FEE) indications and sent back to the LT. This enables performance for both directions to be assessed by the Administration. .PP A function of the C\(hychannel may be to provide support of maintenance functions such as loopback activation and performance monitoring data gathering. .RT .sp 1P .LP 3.2.2 \fIMaintenance states and control\fR .sp 9p .RT .PP This is an area for further study, including: .RT .LP \(em restricting access to some capabilities to network or customer; .LP \(em security issues. .sp 1P .LP 3.2.3 \fIPerformance monitoring capabilities (layer 1)\fR .sp 9p .RT .PP It shall be possible to report the performance information from the exchange to the OAMC (see \(sc\ 3.2.3.2). It shall be possible to reset the parameter counts. Other issues under study include: .RT .LP \(em combining all links in subscriber access; .LP \(em parameter consistency; .LP \(em identifying maintenance phases impacted by PM (performance monitoring). .sp 1P .LP 3.2.3.1 \fIMaintenance entities monitored\fR .sp 9p .RT .PP It shall be possible to monitor the NT to LT links. .bp .RT .sp 1P .LP 3.2.3.2 \fIRequired performance monitoring parameters and history\fR .sp 9p .RT .PP The following principles apply to performance monitoring parameters and history: .RT .LP a) parameters should be counted separately in each direction when feasible to help isolate troubles and to better estimate network service provided to users; .LP b) to support different maintenance uses, parameters should be counted for short durations (e.g.,\ 15\ minutes to one hour) and longer durations (e.g.\ 24\ hours) as specified in Recommendation\ M.550; .LP c) error counts and when they occur should be retained to help deal with intermittent troubles; .LP d) thresholding, covered in Recommendations M.34 and M.550; .LP e) the threshold values should be settable by the OAMC; .LP f ) performance information should be reported from the exchange to the OAMC: .LP \(em when threshold crossings occur; .LP \(em on demand from the OAMC. .sp 1P .LP 3.2.4 \fITesting capabilities\fR .sp 9p .RT .PP Testing should introduce minimal disruption on other B\(hy and D\(hychannels, and should not disrupt the subscriber's terminal equipment. Other testing capabilities are for further study. .RT .sp 1P .LP 3.4.2.1 \fILoopbacks\fR .sp 9p .RT .PP The loopback capabilities for basic rate access, including types, locations, and control domains, are given in Recommendations\ I.602\ [3] and I.604\ [4]. .RT .sp 1P .LP 3.2.4.2 \fITest lines\fR .sp 9p .RT .PP For further study. .RT .sp 1P .LP 3.2.4.3 \fITest and monitor points\fR .sp 9p .RT .PP For further study. .RT .sp 1P .LP 3.2.4.4 \fISelf tests and diagnostics\fR .sp 9p .RT .PP For further study. .RT .sp 1P .LP 3.2.5 \fISupervision and verification of protocol implementations\fR .sp 9p .RT .PP The principles for the supervision and verification of ISDN access protocol implementations are: .RT .LP a) Protocol errors due to implementation problems or other failures need to be detected. This may be based on the logging and counting of protocol violations; .LP b) Protocol problems need to be sectionalized, analyzed, and isolated. The following techniques may be used: .LP \(em access to log of protocol violation information; .LP \(em monitoring of the layer 2 frames and the layer\ 3 messages; .LP \(em test access and protocol testing. .PP See Recommendation I.603\ [4] for more information. .sp 2P .LP \fB4\fR \fBPrimary rate access\fR .sp 1P .RT .sp 1P .LP 4.1 \fIPrimary rate access maintenance models\fR .sp 9p .RT .PP Four primary rate access configurations are shown below, along with one figure showing four customer premises configurations, that can apply to any of the access models. .PP Maintenance entries are not indicated for these configurations, because there are several different implementations of primary rate access. The definitions of MEs is for further study. .bp .RT .sp 1P .LP 4.1.1 \fISimple access model\fR .sp 9p .RT .PP The simple case of primary rate access from the NT2 directly to the exchange is shown in Figure\ 7/M.36. A variant of this model includes higher order links. .RT .LP .rs .sp 12P .ad r \fBFigure 7/M.36, (N), p.\fR .sp 1P .RT .ad b .RT .sp 1P .LP 4.1.2 \fISubscriber configurations\fR .sp 9p .RT .PP There are several subscriber configurations that can appear behind any of the NT1s shown in the primary rate cases, as shown in Figure\ 8/M.36. .PP The first is the simplest case of separate NT1 and NT2, followed by a primary rate TE. Another case is with the NT1 and NT2 combined into one unit. A third case is a NT2 which is a PBX on which terminate several basic rate access lines connecting TEs to the PBX. A final case is one in which the NT2 is a multiplexer on which terminate several basic rate access lines connecting\ TEs to the multiplex. .RT .LP .rs .sp 25P .ad r \fBFigure 8/M.36, (N), p.\fR .sp 1P .RT .ad b .RT .LP .bp .sp 1P .LP 4.1.3 \fIDigital crossconnect system (DCS)\fR .sp 9p .RT .PP A model introducing a new network element, the digital crossconnect system (DCS) , in the simple access model is shown in Figure\ 9/M.36. .PP The DCS is a static crossconnect of B\(hychannels, routing some to the exchange and some to the leased circuit network. Processing of the D\(hychannel by the DCS is for further study, as discussed in Annex\ A. .RT .LP .rs .sp 10P .ad r \fBFigure 9/M.36, (N), p.\fR .sp 1P .RT .ad b .RT .sp 1P .LP 4.1.4 \fIPrimary rate leased circuits\fR .sp 9p .RT .PP In this case, all the B\(hy and D\(hychannels traverse the network from one NT2 to the other, without being terminated on a network switch. The network simply provides transport for a private ISDN, as shown in Figure\ 10/M.36. .RT .LP .rs .sp 7P .ad r \fBFigure 10/M.36, (N), p.\fR .sp 1P .RT .ad b .RT .sp 2P .LP 4.2 \fIRequired capabilities\fR .sp 1P .RT .sp 1P .LP 4.2.1 \fITransmission format maintenance features\fR .sp 9p .RT .PP For further study. .RT .sp 1P .LP 4.2.2 \fIMaintenance states and control\fR .sp 9p .RT .PP For further study. .RT .sp 2P .LP 4.2.3 \fIPerformance monitoring capabilities\fR .sp 1P .RT .sp 1P .LP 4.2.3.1 \fIMaintenance entities monitored\fR .sp 9p .RT .PP For further study. .RT .sp 1P .LP 4.2.3.2 \fIRequired performance monitoring parameters and history\fR .sp 9p .RT .PP For further study. Includes layer 1 and layer 2 monitoring. .bp .RT .sp 2P .LP 4.2.4 \fITesting capabilities\fR .sp 1P .RT .sp 1P .LP 4.2.4.1 \fILoopbacks\fR .sp 9p .RT .PP The loopback capabilities for primary rate access, including types, locations, and control domains, are given in Recommendations\ I.602\ [3] and\ I.604\ [5]. .RT .sp 1P .LP 4.2.4.2 \fITest lines\fR .sp 9p .RT .PP For further study. .RT .sp 1P .LP 4.2.4.3 \fITest and monitor points\fR .sp 9p .RT .PP For further study. .RT .sp 1P .LP 4.2.4.4 \fISelf tests and diagnostics\fR .sp 9p .RT .PP For further study. .RT .sp 1P .LP 4.2.5 \fISupervision and verification of protocol implementations\fR .sp 9p .RT .PP The principles for the supervision and verification of ISDN access protocol implementations are: .RT .LP a) protocol errors due to implementation problems or other failures need to be detected. This may be based on the logging and counting of protocol violations; .LP b) protocol problems need to be sectionalized, analyzed, and isolated. The following techniques may be used: .LP \(em access to log of protocol violation information; .LP \(em monitoring of the layer 2 frames and the layer 3 messages; .LP \(em test access and protocol testing. .PP See Recommendation I.604\ [5] for more information. .sp 2P .LP \fB5\fR \fBBroadband ISDN access\fR .sp 1P .RT .PP For further study. .RT .sp 2P .LP \fB6\fR \fBEnd\(hyto\(hyend maintenance\fR .sp 1P .RT .sp 1P .LP 6.1 \fIEnd\(hyto\(hyend models\fR .sp 9p .RT .PP This section provides two examples of end\(hyto\(hyend ISDN connections. Figure\ 11/M.36 shows connection examples where a call from one subscriber access (primary or basic rate) is switched through the public network to another subscriber access. .RT .LP .rs .sp 11P .ad r \fBFigure 11/M.36, (N), p.\fR .sp 1P .RT .ad b .RT .LP .bp .PP Figure 12/M.36 shows an end\(hyto\(hyend leased circuit arrangement example where at each end a subscriber primary rate access is connected to a DCS. From the DCSs, B\(hychannels are connected both to the switched and to provide an end\(hyto\(hyend connection between the subscriber locations. .PP A variation on this example would have a second primary rate access, without a D\(hychannel, connected end\(hyto\(hyend via a DCS. In this case there is a possibility of a hidden fault between the DCSs that is not reported to either end and is not detected via the loss of the D\(hychannel. Thus, this is a configuration where a continuity check is required to detect the fault. .RT .LP .rs .sp 15P .ad r \fBFigure 12/M.36, (N), p.\fR .sp 1P .RT .ad b .RT .sp 1P .LP 6.2 \fIISDN interworking model\fR .sp 9p .RT .PP Primary or basic rate subscribers via their ISDN access may wish to interwork with other networks \(em with the public switched telephone network (PSTN), with a packet switched data network (PSDN) and with another public or private ISDN. A model for this interworking is shown in Figure\ 13/M.36. .PP An example of the interworking unit (IWU) would be a modem pool used in the PSTN case. Maintenance of interworking is for further study. .RT .LP .rs .sp 11P .ad r \fBFigure 13/M.36, (N), p.\fR .sp 1P .RT .ad b .RT .sp 1P .LP 6.3 \fITerminal equipment functions for remote operations\fR .sp 9p .RT .PP For further study. .RT .sp 1P .LP 6.4 \fINetwork to network interworking functions for maintenance\fR .sp 9p .RT .PP For further study. .bp .RT .ce 1000 ANNEX\ A .ce 0 .ce 1000 (to Recommendation M.36) .sp 9p .RT .ce 0 .ce 1000 \fBDigital crossconnect system considerations for ISDN\fR .sp 1P .RT .ce 0 .PP DCSs may also process the D\(hychannel. They may break the D\(hychannel layer 2, so that there are two tandem layer\ 2 links between the NT2 and the ET. The DCS routes layer\ 3 packets from the NT2 either to the exchange or to the leased network based on the routing of the associated B\(hychannel. Thus, the DCS may also act as a packet crossconnect for the D\(hychannel. .sp 1P .RT .PP However, the DCS does not perform switch functions. Its crossconnect function is controlled over a separate administrative link, not over the D\(hychannel with Q.931\ [14] call control. This model also includes leased circuits. .PP The B\(hychannels traverse the network without terminating on a switch. The associated D\(hychannel information can be carried in the leased network in the same digital paths as the B\(hychannels, or separately from the B\(hychannels, on the Signalling System No.\ 7 signalling network. .RT .sp 2P .LP \fBReferences\fR .sp 1P .RT .LP [1] CCITT Recommendations of the I.600\(hySeries \fIMaintenance principles for\fR \fIISDN\fR , Vol. III. .LP [2] CCITT Recommendation \fIGeneral maintenance principles of ISDN subscriber\fR \fIaccess and subscriber installation\fR , Vol.\ III, Rec.\ I.601. .LP [3] CCITT Recommendation \fIApplication of maintenance principles to ISDN\fR \fIsubscriber installation\fR , Vol.\ III, Rec.\ I.602. .LP [4] CCITT Recommendation \fIApplication of maintenance principles to ISDN\fR \fIbasic accesses\fR , Vol.\ III, Rec.\ I.603. .LP [5] CCITT Recommendation \fIApplication of maintenance principles to ISDN\fR \fIprimary rate access\fR , Vol.\ III, Rec.\ I.604. .LP [6] CCITT Recommendation \fIApplication of maintenance principles to static\fR \fImultiplexed ISDN basic accesses\fR , Vol.\ III, Rec.\ I.605. .LP [7] CCITT Recommendation \fIISDN user network interface protocol for\fR \fImanagement\fR , Vol.\ VI, Rec.\ Q.940. .LP [8] CCITT Recommendation \fIError performance of an international digital\fR \fIconnection forming part of an integrated services digital network\fR , Vol.\ III, Rec.\ G.821. .LP [9] CCITT Recommendation \fIISDN user\(hynetwork interfaces \(em reference\fR \fIconfigurations\fR , Vol.\ III, Rec.\ I.411. .LP [10] CCITT Recommendation \fIReference model of open system interconnection\fR \fIfor CCITT applications\fR , Vol.\ VIII, Rec.\ X.200. .LP [11] CCITT Recommendation \fIISDN protocol reference model\fR , Vol. III, Rec.\ I.320. .LP [12] CCITT Recommendation \fIOpen system interconnection (OSI) layer service\fR \fIdefinition conventions\fR , Vol.\ VIII, Rec.\ X.210. .LP [13] CCITT Recommendation \fIExchange interfaces for subscriber access\fR , Vol. VI, Rec.\ Q.512. .LP [14] CCITT Recommendation \fIISDN user\(hynetwork interface layer 3\fR \fIspecification\fR , Vol. VI, Rec.\ Q.931. .sp 2P .LP \fBRecommendation\ M.50\fR .RT .sp 2P .sp 1P .ce 1000 \fBUSE\ OF\ TELECOMMUNICATION\ TERMS\ FOR\ MAINTENANCE\fR .EF '% Fascicle\ IV.1\ \(em\ Rec.\ M.50'' .OF '''Fascicle\ IV.1\ \(em\ Rec.\ M.50 %' .ce 0 .sp 1P .PP For their dealings with their colleagues in other countries, personnel at operation centres and other maintenance units should refer to Fascicle\ I.3, \fITerms and Definition\fR , of Volume\ I of this Book. .sp 1P .RT .PP For maintenance technology, the definitions given in Recommendation\ M.60 are preferred. .LP .bp