ETSI EN 301 167 V1.1.1 (1998-08)

Transmission and Multiplexing (TM); Management of Synchronous Digital Hierarchy (SDH) transmission equipment; Fault management and performance monitoring; Functional description

DEN/NA-042137

Prenos in multipleksiranje (TM) – Upravljanje prenosne opreme sistema sinhrone digitalne hierarhije (SDH) – Obvladovanje okvar in lastnosti – Funkcijski opis

General Information

• Status: Published
• Publication Date: 25-Aug-1998
• Technical Committee: NA 4 - Network Architecture, Operations, Maintenance, Principle & Performance
• Current Stage: 12 - Completion
• Due Date: 21-Aug-1998
• Completion Date: 26-Aug-1998
• Ref Project: SIST EN 301 167 V1.1.1:2003 - Transmission and Multiplexing (TM); Management of Synchronous Digital Hierarchy (SDH) transmission equipment; Fault management and performance monitoring; Functional description

Standards Content (Sample)

2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.Prenos in multipleksiranje (TM) – Upravljanje prenosne opreme sistema sinhrone digitalne hierarhije (SDH) – Obvladovanje okvar in lastnosti – Funkcijski opisTransmission and Multiplexing (TM); Management of Synchronous Digital Hierarchy (SDH) transmission equipment; Fault management and performance monitoring; Functional description33.040.20Prenosni sistemTransmission systemsICS:Ta slovenski standard je istoveten z:EN 301 167 Version 1.1.1SIST EN 301 167 V1.1.1:2003en01-december-2003SIST EN 301 167 V1.1.1:2003SLOVENSKI
STANDARD
EN 301 167 V1.1.1 (1998-08)European Standard (Telecommunications series)Transmission and Multiplexing (TM);Management of Synchronous Digital Hierarchy (SDH)transmission equipment;Fault management and performance monitoring;Functional descriptionSIST EN 301 167 V1.1.1:2003

ETSIEN 301 167 V1.1.1 (1998-08)2ReferenceDEN/NA-042137 (at000ico.PDF)Keywordsmanagement, SDH, TMN, transmission, transportETSIPostal addressF-06921 Sophia Antipolis Cedex - FRANCEOffice address650 Route des Lucioles - Sophia AntipolisValbonne - FRANCETel.: [phone]
Fax: [phone]Siret N° 348 623 562 00017 - NAF 742 CAssociation à but non lucratif enregistrée à laSous-Préfecture de Grasse (06) N° 7803/[e-mail]://www.etsi.frhttp://www.etsi.orgCopyright NotificationNo part may be reproduced except as authorized by written permission.The copyright and the foregoing restriction extend to reproduction in all media.© European Telecommunications Standards Institute 1998.All rights reserved.SIST EN 301 167 V1.1.1:2003

ETSIEN 301 167 V1.1.1 (1998-08)3ContentsIntellectual Property Rights.5Foreword.51Scope.62Normative references.63Abbreviations.74Fault management.84.1Purpose.84.2Additional definitions.84.2.1Functional architecture.94.2.2Alarm information description and management.94.3Time stamping.115Performance monitoring.115.1General principles.115.1.1Generic definition of the block.115.1.2In-service monitoring.115.1.3Out-of-service monitoring.115.1.4Error performance events and parameters.125.1.4.1Determination of error performance events and parameters.125.1.5Definition of unavailability.145.1.6Unavailability parameters.145.1.7Performance data collection.145.1.7.1Data collection for maintenance purposes.155.1.7.2Data collection for error performance purposes.155.1.7.3Performance monitoring history.155.1.8Performance filtering and thresholding.185.1.8.115-minute treatment.185.1.8.224 hour treatment.185.1.9Synchronous Equipment Management Function (SEMF).205.1.10Maintenance thresholds.215.1.11Time-stamping.215.1.12Additional performance events and parameters.215.2Performance monitoring of SDH paths.225.2.1Block definition.225.2.2Error performance parameters.225.2.3Events and parameters determination.235.2.3.1Anomalies.235.2.3.2Defects.235.2.3.3Determination of the performance events.235.2.4Unavailability of path.245.2.4.1Criteria for a uni-directional path.245.2.4.2Criteria for a bi-directional path.245.2.5Data management.245.2.5.1Performance monitoring history.245.2.5.2Error performance evaluation.255.2.5.3Unavailability management.255.2.6Maintenance thresholds configuration.255.2.6.115-minute thresholds.255.2.6.224-hour thresholds.265.3Performance monitoring of multiplex sections.265.3.1Block definition.265.3.1.1Block definition for STM-N sections (1 £N £ 16).265.3.1.2Block definition for STM-64 section.265.3.1.3Block definition for STM-0 section.26SIST EN 301 167 V1.1.1:2003

ETSIEN 301 167 V1.1.1 (1998-08)45.3.1.4Block sizes.265.3.2Error performance events.265.3.3Events determination for multiplex sections.275.3.3.1Anomalies.275.3.3.2Defects.275.3.3.3Determination of the performance events.275.3.4Unavailability of multiplex section.285.3.5Data management.285.3.5.1Performance monitoring history.285.3.5.2Unavailability management.285.3.6Maintenance thresholds configuration.285.3.6.115-minute thresholds.285.3.6.224-hour thresholds.295.4Performance management of regenerator sections.295.4.1Block definition.295.4.1.1Block definition applicable to STM-1.295.4.1.2Block definition applicable to STM-N (4£N£64).295.4.1.3Block definition applicable to bit rates STM-0.295.4.1.4Block sizes.295.4.2Error performance events.305.4.3Events determination for regenerator sections.305.4.3.1Anomaly.305.4.3.2Defects.305.4.3.3Determination of the performance events.305.4.4Unavailability of regenerator section.315,4.5Data management.315.4.5.1Performance monitoring history.315.4.5.2Unavailability management.315.4.6Maintenance thresholds configuration.325.4.6.115-minute thresholds.325.4.6.224-hour thresholds.32History.33SIST EN 301 167 V1.1.1:2003

ETSIEN 301 167 V1.1.1 (1998-08)5Intellectual Property RightsIPRs essential or potentially essential to the present document may have been declared to ETSI. The informationpertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be foundin SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in respectof ETSI standards", which is available free of charge from the ETSI Secretariat. Latest updates are available on theETSI Web server (http://www.etsi.fr/ipr or http://www.etsi.org/ipr).Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guaranteecan be given as to the existence of other IPRs not referenced in SR 000 314 (or the updates on the ETSI Web server)which are, or may be, or may become, essential to the present document.ForewordThis European Standard (Telecommunications series) has been produced by ETSI Technical Committee NetworkAspects (NA).The present document specifies the fault management and performance monitoring aspects of the Synchronous DigitalHierarchy (SDH) transmission equipments.National transposition datesDate of adoption of this EN:7 August 1998Date of latest announcement of this EN (doa):30 November 1998Date of latest publication of new National Standardor endorsement of this EN (dop/e):31 May 1999Date of withdrawal of any conflicting National Standard (dow):31 May 1999SIST EN 301 167 V1.1.1:2003

ETSIEN 301 167 V1.1.1 (1998-08)61ScopeThe present document specifies the functional requirements for fault management and performance monitoring aspectsof SDH equipments.The Telecommunications Management Network (TMN) provides management functions which cover the planning,installation, operations, administration, maintenance and provisioning of telecommunications networks and services.ITU-T Recommendation M.3010 [1] proposes five management functional areas identified as follows:-Fault management;-Performance management;-Configuration management;-Security management;-Accounting management.The present document provides guidance and supporting information for the functional specification for the first two ofthese management areas.The TMN functionality is realized by means of processes in Equipment Management Function (EMF) in NetworkElements (NE), Element Management Systems (EMS) and Network Management Systems (NMS) or OperationSystems (OS).The present document fully specifies the EMF functionalities. NMS/OS functionalities are described only if needed forclarification.2Normative referencesReferences may be made to:a)specific versions of publications (identified by date of publication, edition number, version number, etc.), inwhich case, subsequent revisions to the referenced document do not apply; orb)all versions up to and including the identified version (identified by "up to and including" before the versionidentity); orc)all versions subsequent to and including the identified version (identified by "onwards" following the versionidentity); ord)publications without mention of a specific version, in which case the latest version applies.A non-specific reference to an ETS shall also be taken to refer to later versions published as an EN with the samenumber.[1]ITU-T Recommendation M.3010: "Principles for a Telecommunications management network".[2]ITU-T Recommendation M.20: "Maintenance philosophy for telecommunications networks".[3]ETS 300 417: "Generic functional requirements for Synchronous Digital Hierarchy (SDH)equipment".[4]ITU-T Recommendation M.3100: "Generic network information model".[5]ITU-T Recommendation X.733: "Data networks and open system communications OSImanagement. Information technology – Open Systems Interconnection – Systems Management:Alarm reporting function".SIST EN 301 167 V1.1.1:2003

ETSIEN 301 167 V1.1.1 (1998-08)7[6]ITU-T Recommendation X.734: "Data networks and open system communications OSImanagement. Information technology – Open Systems Interconnection – Systems Management:Event report management function".[7]ITU-T Recommendation X.735: "Data networks and open system communications OSImanagement. Information technology – Open Systems Interconnection – Systems Management:Log control function".[8]ITU-T Recommendation G.826: "Error performance parameters and objectives for international,constant bit rate digital paths at or above the primary rate".[9]ETS 300 416: "Availability performance of path elements of international paths".[10]ITU-T Recommendation M.2120: "PDH path, section and transmission system and SDH path andmultiplex section fault detection and localization procedures".[11]ITU-T Recommendation M.2101: "Performance limits for bringing-into-service and maintenanceof international SDH paths, sections and transmission systems".[12]EN 301 129: "Transmission and Multiplexing (TM); Digital Radio Relay Systems (DRRS);Synchronous Digital Hierarchy (SDH); System performance monitoring parameters of SDHDRRS".[13]ITU-T Recommendation G.707: "Network node interface for the synchronous digital hierarchy(SDH)".[14]ITU-T Recommendation M.2110: "Bringing-into-service of international PDH paths, sections andtransmission systems and SDH paths and multiplex sections".[15]ITU-T Recommendation G.783: "Characteristics of synchronous digital hierarchy (SDH)equipment functional blocks".[16]ITU-T Recommendation G.784: "Synchronous digital hierarchy (SDH) management".3AbbreviationsFor the purposes of the present document, the following abbreviations apply:AISAlarm Indication SignalARAvailability RatioAUAdministrative UnitBBEBackground Block ErrorBBERBackground Block Error RatioBIPBit Interleaved ParityCSESConsecutive SESEBErrored BlockEDCError Detection CodeEMFEquipment Management FunctionENEuropean NormeESErrored SecondESRErrored Second RatioFE BBEFar-End Background Block ErrorFE ESFar-End Errored SecondFE SESFar-End Severely Errored SecondFFSFor Further StudyHPHigh order PathLOFLoss Of FrameLOMLoss Of MultiframeLOPLoss Of PointerLOSLoss Of SignalLPLow order PathSIST EN 301 167 V1.1.1:2003

ETSIEN 301 167 V1.1.1 (1998-08)8MOMean time between digital path OutageMPManagement PointMSMultiplex SectionNENetwork ElementNE BBENear-End Background Block ErrorNE ESNear-End Errored SecondNE SESNear-End Severely Errored SecondNMSNetwork Management SystemOIOutage IntensityOSOperation SystemPJEPointer Justification EventPLMPath Label MismatchPSProtection SwitchPSCProtection Switch CountPSDProtection Switch DurationRDIRemote Defect IndicationREIRemote Error IndicationRSRegenerator SectionSDHSynchronous Digital HierarchySEMFSynchronous Equipment Management FunctionSESSeverely Errored SecondSESRSeverely Errored Second RatioSTM-nSynchronous Transfer Module nTMNTelecommunication Management NetworkVCVirtual ContainerUNEQUnequippedUTCUniversal Time Co-ordinated4Fault managementFault management is a set of functions which enables the detection, isolation and correction of abnormal operation of thetelecommunication network and its environment.4.1PurposeThis subclause describes the generic process of alarm handling in SDH network element.4.2Additional definitionsThese definitions have been derived from ITU-T Recommendation M.20 [2].fault: A fault is the inability of a function to perform a required action. This does not include an inability due topreventive maintenance, lack of external resources, or planned actions.anomaly: The smallest discrepancy which can be observed between the actual and desired characteristics of an item.The occurrence of a single anomaly does not constitute an interruption in the ability to perform a required function.Anomalies are used as the input for the performance monitoring process and for the detection of defects.defect: The density of anomalies has reached a level where the ability to perform a required function has beeninterrupted. Defects are used as input for performance monitoring, the control of consequent actions, and thedetermination of Fault Cause (FC).fault cause: A single disturbance or fault may lead to the detection of multiple defects. A FC is the result of acorrelation process which is intended to pinpoint the defect that is representative of the disturbance or fault that iscausing the problem.failure: The FC persisted long enough to consider the ability of an item to perform a required function to be terminated.The item may be considered as failed; a fault has now been detected.SIST EN 301 167 V1.1.1:2003

ETSIEN 301 167 V1.1.1 (1998-08)9alarm: A human observable indication that draws attention to a failure (detected fault) usually giving an indication ofthe severity of the fault.4.2.1Functional architectureThe functional architecture is depicted in figure 1.Anomaly processing, defect filtering, consequent action functional blocks are defined in ETS 300 417 [3].Fault cause persistency, which allows the NE to wait a certain amount of time before to entering in the failure state andtherefore it conditions the generation of alarms. The persistency time needed to declare a failure is settable independence of defect characteristics (toggling, stable, .). Only a defect which passes that filter could be subsequentlyreported as an alarm.A failure shall be declared if the fault cause persists continuously for X seconds. The failure shall be cleared if the faultcause is absent continuously for Y seconds. X and Y shall be within the range between 100 ms and 30 s in steps of Z ms.The incremental value Z shall follow a logarithmic scale (for further study). It is recommended that X < = Y.Severity assignment, which is used to assign the management perception of the severity of a Fault which could dependon the service dependency of the fault, a non service affecting Fault will be alarmed with a severity of Warning orMinor, while a service affecting fault will be reported with a severity of Major or Critical. A service independent faultwill be alarmed with any value of the severity. This is an information that is provided by the OS (refer toITU-T Recommendation. M.3100 [4]).Station alarm, represents the synthesis of alarm for purpose of audible and visual indication to a human operator in thestation. Station alarms can be suppressed by management operations.Unit alarm represents the synthesis of alarm on replaceable unit basis, the unit could be a board, sub-rack, etc.Alarm notification, represents the ability to generate alarm. For more details refer toITU-T Recommendation. X.733 [5].Alarm filtering, which is used to filter the alarm depending on the contents of the alarm such as the type and cause ofthe alarm, the source of the alarm, the severity, the correlation information etc. prior to report and/or log alarms. Alarmfiltering is different for logging and reporting.Alarm logging and alarm reporting. alarm reporting allows the reporting of those alarms which have passed the alarmfiltering process to a single or multiple destinations. for more details refer to ITU-T Recommendation.X.734 [6] andITU-T Recommendation. X.735 [7].4.2.2Alarm information description and managementThis subclause aims to classify alarms in terms of severity, type, probable cause, etc. Furthermore, basic principles ofalarm management should be identified.The above issues need further study.SIST EN 301 167 V1.1.1:2003

ETSIEN 301 167 V1.1.1 (1998-08)10Alarm LoggingAlarm ReportingAlarm NotificationFault Persistency ProcessingDefect FilteringDefect CorrelationSeverity Assigment
MessageCommunication
FunctionConsequent actionFunctional BlockSEMFQ InterfaceFailureFault CauseDefectAnomalyF1F3F4F2Alarm FilteringAlarm FilteringStation AlarmUnit AlarmPotential Alarm ReportAlarm ReportFigure 1: Fault managementSIST EN 301 167 V1.1.1:2003

ETSIEN 301 167 V1.1.1 (1998-08)114.3Time stampingFault cause notification implies the time-stamping of its activation/deactivation time. The stamped time shall be the oneindicated by the local real time clock of NE. The time-stamping shall have a resolution of one second with respect to theNE clock. The relationship between the time given by a particular NE and the Universal Time Co-ordinated (UTC) isfor further study.5Performance monitoringPerformance monitoring is important part of the performance management, that provides functions to evaluate andreport upon the behaviour of telecommunication equipment and the effectiveness of the network or network element. Itsrole is to provide information for maintenance purposes and for network error performance evaluation.The performance monitoring requirement is generic in that it defines the parameters for paths and sections independentof the physical transport network providing the paths.ITU-T Recommendation. G.826 [8] defines error performance parameters and objectives for international digital pathsat or above the primary rate. It is worthwhile noticing that ITU-T Recommendation. G.826 [8] is only applicable to pathlayer and no direct allocation of the objectives can be derived for NEs.All the SDH equipments are described in terms of functional blocks, so a minimum set of parameters common to allequipments will be used.5.1General principles5.1.1Generic definition of the blockThe error performance parameters are based upon the measurement of blocks defined as follows:A block is a set of consecutive bits associated with the path and the section; each bit belongs to one and only one block.Consecutive bits may not be contiguous in time.Subclauses 5.2.1, 5.3.1 and 5.4.1 contain definition of block sizes for paths, multiplex and regenerator sections.5.1.2In-service monitoringEach block is monitored by means of an inherent Error Detection Code (EDC), e.g. Bit Interleaved Parity (BIP). TheEDC bits are physically separated from the block to which they apply. If there is a discrepancy between the EDC and itscontrolled block, it is always assumed that the controlled block is in error, because usually it is not possible to determinewhether a block or its controlling EDC is in error.Estimation of errored blocks on an in-service basis is dependent upon the type of EDC available.5.1.3Out-of-service monitoringThe out-of-service monitoring can be used for Bringing-Into-Service (BIS) purposes of trails. The description of BIS isrecommended in ITU-T M-Series recommendations and it is outside of the scope of the present document.The out-of-service monitoring can be performed by using the same approach as for the in-service monitoring.SIST EN 301 167 V1.1.1:2003

ETSIEN 301 167 V1.1.1 (1998-08)125.1.4Error performance events and parametersError performance parameters are evaluated from the following error performance events:-EB - Errored Block. A block in which one or more bits are in error.-ES - Errored Second. A one-second period with at least one errored block or at least one defect.-SES - Severely Errored Second. A one-second period which contains ³ X % errored blocks or at least onedefect. An SES is also an ES.-BBE - Background Block Error. An errored block not occurring as part of an SES.The defects and performance criteria are listed in the relevant sections. The value of X is given in subclause 5.2.2 forPath, in subclause 5.3.2 for Multiplex Section (MS) and subclause 5.4.2 for Regenerator Section(RS).The error performance parameters are:-ESR - Errored Second Ratio. It is the ratio of ES in available time to total seconds in available time during afixed measurement interval.-SESR - Severely Errored Second Ratio. It is the ratio of SES in available time to total seconds in availabletime during a fixed measurement interval.-BBER - Background Block Error Ratio. It is the ratio of errored blocks in available time to total blocks duringa fixed measurement interval, excluding all blocks during SES and unavailable time.These parameters shall only be evaluated during the available periods. For a definition of the entry to/exit from criteriafor the unavailable state see subclause 5.1.5.5.1.4.1Determination of error performance events and parametersError performance events defined in subclause 5.1.4 are determined by anomalies (errored blocks) or by defects. Theprocedure to determine the error performance events is shown in figure 2. The shown diagram is intended to be asimplified version to explain the relationship between anomalies, defects and error performance events. The diagram isapplicable to a uni-directional trail.cES, cSES and cBBE represent counts of ES, SES, BBE respectively. These counts are reset at the start of ameasurement period.EB is the count of errored blocks within an ES whilst % EB represents the proportion of errored blocks within an EScompared to the number of blocks per second.In figure 1 the entering/exiting processes to/from unavailable state are not described. Furthermore for figure 2 it isevident that if the trail is in unavailable state no counter need to be updated. In practice, the status of a second (i.e. error-free, ES or SES) shall always be determined before testing the status of path availability. In other words, error events arealways detected regardless of whether the path is available or not - only the counting of events is inhibited duringunavailability periods for the purposes of long-term performance monitoring. This process is reflected in the flow chartalthough consequent actions on changes of availability state are not.In case of path, error performance parameters can be evaluated during, or at the end of, a measurement period P asfollows:()()[]BBERcBBEPUAScSES=--xblock per second(1)()ESRcESPUAS=-(2)()SESRcSESPUAS=-(3)SIST EN 301 167 V1.1.1:2003

ETSIEN 301 167 V1.1.1 (1998-08)13Performance parameters of a path uni- or bi-directional are determined by means of the information at the near-end andat the far-end. When a near-end SES is caused by a near-end defect, the far-end performance can not be evaluated duringthat second. When a near-end SES is resulting from ³ 30 % errored blocks, which does not cause a near-end defectcontributing to performance monitoring, the far-end performance evaluation continues during the near-end SES (theNear-End and Far-End information are defined in subclause 5.1.7.3).%EB ³ Xdefects?anomalies?cES = cES + 1cBBE = cBBE + EBendmonitoredsecondcES = cES + 1cSES = cSES + 1YNYYYYNNNTrail inavailablestateTrail inavailablestate ?ES (but notan SES)SES (thereforean ES)Note 1NOTE 1: The value of X is defined in the subclause 5.2.2 for path, in 5.3.2 for MS and in 5.4.2 for RS.NOTE 2: The determination of unavailability time introduces a delay of 10 seconds. This delay should beconsidered when counting BBE, ES and SES.Figure 2: Flow chart illustrating the evaluation of error performance events by means of defects andanomaliesSIST EN 301 167 V1.1.1:2003

ETSIEN 301 167 V1.1.1 (1998-08)145.1.5Definition of unavailabilityA period of unavailable time begins at the onset of ten consecutive SES events. These ten seconds are considered to bepart of unavailable time. A new period of available time begins at the onset of ten consecutive seconds, none of which isSES. These ten seconds are considered to be part of available time.An example of determination of unavailable period is given in figure 3.Those criteria are given for a single direction. Unavailability criteria for a path or a section are defined in specificclauses in the present document.10 sec<10 sec<10sec10 secBeginning detectionEnding detectionUnavailable periodSESES which is not a SESNon errored secondFigure 3: Example of unavailability period determination5.1.6Unavailability parametersUnavailability parameters are given in ETS 300 416 [9] and they are:-AR - Availability Ratio. It is the proportion of time that a path or a section is in the available state during anobservation period. AR is calculated by dividing the total available time during the observation period by the duration ofthe observation period.-OI - Outage Intensity. It is the number of unavailable period in the observation time.NOTE:The reciprocal of OI parameter, Mean time between digital path Outages (MO) can be used for design,measurement and maintenance applications.These parameters are evaluated by the OS. As an example they can be evaluated by means of the date-time stamping ofthe beginning and ending of unavailable periods recorded in the equipment.The notifications have to be sent to the OS for the beginning and ending of unavailable periods.5.1.7Performance data collectionTwo types of performance information collection are defined:-the collection as specified in ITU-T Recommendation M.2120 [10], i.e. based on information of each direction oftransport separately. It is further on referred to as uni-directional history management. This is for maintenanceapplication.-the collection as specified in ITU-T Recommendation G.826 [8], i.e. based on information of both directions oftransport together. It is further on referred to as bi-directional history management. This is for performanceapplication.The history registers in NEs are suitable for fault location procedure. Any collection of data for long term analysis (e.g.1 month data collection for performance evaluation) can be performed by the NMS/OS.SIST EN 301 167 V1.1.1:2003

ETSIEN 301 167 V1.1.1 (1998-08)15Data collection for maintenance and performance purposes require different sets of registers, if both options areimplemented in the same trail.This description of performance information collection is a generic requirement. Its application to paths or sections isdefined in specific clauses hereafter.5.1.7.1Data collection for maintenance purposesThe 15 minute and 24 hour registers are defined for in-service measurement and for maintenance purposes.A 15 minute period has been recognized suitable to undertake maintenance action, if needed, in the short period. A 24hour period has been recognized suitable to detect long term degradation in the network. The maintenance procedure arerecommended in ITU-T Recommendations M.2120 [10] and M.2101 [11].Each performance event is counted, during available time, over two different periods of time of 15 minutes and 24 hoursrespectively. The register containing the count of present period is usually called "current register".In any NE the periods of 15 minutes for the counting of all performance events start synchronously.In any NE the periods of 24 hours for the counting of all performance events start synchronously.Anyway, it shall be possible to reset an individual current register to zero by means of an external command comingfrom the OS.These counters operate as follows:-15 minute registerAt the beginning of a counting interval the register shall be reset to zero. At the end of the period, the non-zero countsare stored in registers in the Network Element (NE). Each 15 minute period is identified with a time stamp(see subclause 5.1.11).-24 hour registerPerformance events are counted separately over a consecutive periods of 24 hours each, by cumulating 15 minute periodcounts. It is not required to update 24 hour current register on second by second basis.At the beginning of a counting interval the register shall be reset to zero. The non-zero counts are stored in registers inthe Network Element (NE). Each 24 hour period is identified with a time stamp (see subclause 5.1.11).5.1.7.2Data collection for error performance purposesPerformance events are counted separately over a consecutive period of 24 hours each. At the end of the current 24 hourperiod, the counts are stored in historical registers and the current 24 hour counts reset to zero.The counting is stopped during unavailability period.It shall be possible to reset an individual current register to zero by means of an external command coming from the OS.This is essentially applicable to the path performance application according to ITU-T Recommendation. G.826 [8].5.1.7.3Performance monitoring historyThe concepts of "Near-End" and "Far-End" performance monitoring are used to refer to performance monitoringinformation associated with the two directions of transport. For a trail from A to Z:-at node A the near-end information represents the performance of the unidirectional trail from Z to A, while theFar-End information represents the performance of the unidirectional trail from A to Z;SIST EN 301 167 V1.1.1:2003

ETSIEN 301 167 V1.1.1 (1998-08)16-at node Z the near-end information represents the performance of the unidirectional trail from A to Z, while theFar-End information represents the performance of the unidirectional trail from Z to A.At either end of the trail (A or Z) the combination of near-end and far-end information presents the performance of thetwo directions of the trail.At node A (or Z) the near-end error performance events, Near-End ES (NE ES), Near-End SES (NE SES), and Near-End BBE (NE BBE) are derived by means of the near-end information at local node A (or Z). At node A (or Z) the far-end error performance events, Far-End ES (FE ES), Far-End SES (FE SES), Far-End BBE (FE BBE) are derived bymeans of far-end information at node A (or Z).-Uni-directional history managementPerformance events are counted during available time over periods of 15 minutes and 24 hours.The 15 minute registers form a stack of at least 17 registers, one current and 16 recent. At the end of the 15 minuteperiod, the content of the current 15 minute register is transferred to the first of the recent registers, with a time-stamp toidentify the particular 15 minute period. When all of the 15 minute recent registers are full, a wrapping mechanism isused to discard the oldest information.NOTE:Wrapping is the deletion of the earliest record to allow a new record when all registers are full.The 24 hour registers form a stack of two registers, one current and one recent. The current 24 hour register shall bereset to zero at the end of each 24 hour period, after the data have been transferred to the recent 24 hour register.These registers will be provided per performance event and per direction of transmission. The uni-directionalperformance monitoring in based on counts of Near-end performance events. This is the uni-directional historymanagement and it is illustrated in figure 4.Performance events (BBE, ES, SES) counts may be monitored for a threshold crossing as specified in subclause 5.1.8.-Bi-directional history managementPerformance events are counted during available time over periods of 24 hours.The 24 hour registers form a stack of 2 registers, one current and one recent. The current 24 hour register shall be resetto zero at the end of each 24 hour period, after the data have been transferred to the recent 24 hour register.The bi-directional performance monitoring in based on counts of Near-end and Far-end performance events Thebi-directional history management is illustrated in figure 5. It is essentially applicable to the path performanceevaluation. For uni-directional path near-end data collection is applicable only.-ReportingPerformance data stored in registers may be collected by the OS for analysis without affecting the content of the register,when requested by the OS, periodically or upon the crossing or reaching of a performance monitoring threshold.Performance events (BBE, ES, SES) counts may be monitored for a threshold crossing as specified in subclause 5.1.8.SIST EN 301 167 V1.1.1:2003

ETSIEN 301 167 V1.1.1 (1998-08)17Q3InterfaceMessage communication function15 min recent24 h recent24 h current15 min current24 hourthresholdreport15 minutethresholdreportNear endor Far endRegister inputsBBE, ES, SES15 min recent15 min recent15 min recentUATcmd>=>=16152124 hourthresholdvalue24 hourthresholdvalueResetA)15 min24 h15 min24 h15 min24 hBBEESSESUAT cmdNear endorFar end15 min UAS24 h(note 2)(note 2)(note 2)(note 2)(note 1)NOTE 1:The UAS register is optional.NOTE 2:The determination of unavailable time introduces a delay of 10 seconds. This delay should be consideredwhen counting BBE, ES and SES.B)Figure 4: A) Registers process for maintenance purposes B) Uni-directional history managementSIST EN 301 167 V1.1.1:2003

ETSIEN 301 167 V1.1.1 (1998-08)18NE BBENE ESNE SESNE UAT cmdFE UAT cmdORUAT cmd24h current24h UAScurrent24h recent24h current24h current24h recent24h recent24h recent24h recentFE SESFE ESFE BBE24h current24h current24h current24h recent24h recentResetResetResetResetResetResetReset (note 1) (note 2) (note 2) (note 2) (note 2) (note 2) (note 2) (note 2)NOTE 1:The UAS register is optionalNOTE 2:The determination of unavailable time introduces a delay of 10 seconds. This delay should be consideredwhen counting BBE,ES and SES.NE SES, NE BBE, NE ES - Near-End performance parameterFE SES, FE BBE, FE ES - Far-End performance parameterNOTE 3:For uni-directional path near-end data collection is applicable only.Figure 5: Registers process for performance purposes5.1.8Performance filtering and thresholdingThe performance filtering and thresholding mechanism should be used for maintenance application only.5.1.8.115-minute treatmentA threshold can be crossed at any second within the 15 minute fixed window. As soon as a threshold is reached orcrossed for a given performance event, a threshold report is generated. This is illustrated in figure 6.Optionally a reset threshold should be supported. A reset threshold occurs at the end of the 15 minute period in whichthe count of performance event is less than the reset threshold value and there was not an unavailability period in the15 minute period. It can only occur subsequently to a 15 minute period with a corresponding crossing threshold. Nomore than one threshold report shall be generated until there has been a 15 minute period with a count of performanceevents less than the reset threshold value. This is illustrated in figure 7, figure 8 and figure 9.5.1.8.224 hour treatmentA threshold can be crossed at any 15 minute within the 24 hour fixed window. As soon as a threshold crossing isdetected, a threshold report is generated. This is illustrated in figure 6.SIST EN 301 167 V1.1.1:2003

ETSIEN 301 167 V1.1.1 (1998-08)19PerformanceEvent ValueThresholdReportThresholdReportMonitored period (15 minute or 24 hours)Monitored periodtimethresholdFigure 6: Threshold report for a performance eventThresholdReportResetThresholdReportPerformanceEvent ValueThresholdResetThreshold15 minute period15 minute p
...