SIST EN 301 384 V1.1.1:2003
(Main)Telecommunications Management Network (TMN); Performance monitoring for Plesynchronous Digital Hierarchy (PDH) interfaces; Information model for the Network Element (NE) view
- Abstract
Definition of the information model for performance monitoring of PDH-interfaces for the Network Element View Reference documents: prETS 300 417, ETS 300 371, DEN/TM-02246
- Status
- Published
- Publication Date
- 31-Oct-2003
- Technical Committee
- SPN - Services and Protocols for Networks
- Current Stage
- 6060 - National Implementation/Publication (Adopted Project)
- Start Date
- 01-Nov-2003
- Due Date
- 01-Nov-2003
- Completion Date
- 01-Nov-2003
SIST EN 301 384 V1.1.1:2003 is the Slovene version of ETSI EN 301 384 V1.1.1 for Telecommunications Management Network (TMN). It specifies the information model for performance monitoring of PDH interfaces in the Network Element (NE) view. It is aimed at TMN implementations, network elements, and management systems that need to exchange PDH performance data, alarms, and history information.
What does SIST EN 301 384 V1.1.1:2003 specify?
SIST EN 301 384 V1.1.1:2003 specifies the TMN information model used to monitor performance on PDH interfaces from the NE side. In practice, it defines the managed object classes, their packages, attributes, name bindings, and ASN.1 definitions needed to represent performance counters and related alarms.
The document is organized into:
- Scope
- References
- Abbreviations
- Performance Monitoring Management Model
- Managed object class definitions
- Packages
- Attributes
- Actions
- Notifications
- Name bindings
- ASN.1 definitions
- History
The scope says the model is for performance monitoring of PDH interfaces and that it uses reference documents for TMN architecture, PDH information models, and transport-network maintenance concepts. It also states that protocol stacks, network-level management processes, application contexts, conformance requirements, and information models for other systems are outside the model.
What are the key requirements of SIST EN 301 384 V1.1.1:2003?
SIST EN 301 384 V1.1.1:2003 defines a set of object classes for current performance data and history data, with separate treatment for near end, far end, unidirectional, and bidirectional monitoring. That matters because an implementation has to place the right counters in the right object and know whether it is collecting local or remote end results.
Performance data classes and counters
Clause 5 defines classes such as pdhCurrentDataUnidirectional, pdhCurrentDataNearEnd, pdhCurrentDataFarEnd, pdhCurrentDataBidirectional, and pdhErrorPerformanceCurrentData. These classes hold the current register counts for a PDH path during a collection period.
The counters include BBE, ES, SES, and, where applicable, FEES, FESES, UAS, FEBBE, CSES, and FECSES. For a reader, this means the NE must implement the counters that match the monitored direction and path type, not a generic one-size-fits-all register.
Granularity and threshold handling
The document fixes the granularityPeriod behavior through the object definitions and ASN.1 constraints, and the threshold-reset variants use 15-minute granularity. granularityPeriod is assigned at creation time, so the monitoring interval is not a free-running setting.
Threshold handling is tied to thresholdDataInstance, currentProblemList, and the threshold reset packages. If a threshold is crossed, the model uses currentProblemList to indicate thresholdCrossed, and the network element must distinguish the high and low values stored in the threshold list.
Unavailable time and alarms
The model defines unavailable time entry and exit using 10 consecutive SES events and 10 consecutive non-SES events. Separate near-end and far-end unavailability are maintained, and the far-end behavior applies only where far-end monitoring is supported.
When an unavailable period starts or ends, the model calls for communication alarms with the probable cause Unavailable, and the cleared state is reported at the end of the unavailable period. In practice, this tells the implementer how to raise alarms and when to stop counting certain events.
History retention and name bindings
History classes such as pdhPathHistoryData, pdhPathHistoryDataNearEnd, and pdhPathHistoryDataFarEnd store observed events at the end of an observation interval. The name bindings show how current and history objects are contained and named under the monitoring sinks.
This matters for element managers because history is not just optional logging - it is part of the object model and is created automatically at the end of the granularity period.
What terms does SIST EN 301 384 V1.1.1:2003 define?
- TMN - Telecommunications Management Network, the management architecture used for exchanging performance and alarm information.
- NE - Network Element, the equipment being monitored and managed.
- PDH - Plesiochronous Digital Hierarchy, the transmission hierarchy covered by the model.
- BBE - Background Block Error, a performance counter used in the near-end and some far-end models.
- SES - Severely Errored Second, a key event used to detect poor performance and unavailable time.
- UAS - Unavailable Seconds, the counter for seconds that belong to an unavailable period.
Who uses SIST EN 301 384 V1.1.1:2003?
SIST EN 301 384 V1.1.1:2003 is used by TMN designers, NE vendors, and network operators who implement PDH performance monitoring. It is also relevant to quality and operations teams that need to specify counters, alarms, history retention, and threshold behavior for PDH transport equipment.
In practice, these users apply it when designing the Q3 or element-manager interface, mapping PDH counters into management objects, or checking that a device reports near-end and far-end performance in the expected way.
What changed in SIST EN 301 384 V1.1.1:2003 from the previous edition?
SIST EN 301 384 V1.1.1:2003 is identified as identical to EN 301 384 Version 1.1.1.
Which standards are used with SIST EN 301 384 V1.1.1:2003?
| Reference | What it contributes |
|---|---|
| ITU-T Recommendation G.784 | SDH management basis for performance monitoring. |
| EN 301 167 | Functional description for SDH fault management and performance monitoring. |
| ITU-T Recommendation M.3010 | TMN architecture and management context. |
| EN 300 371 | PDH information model for the NE view. |
| ITU-T Recommendation M.2120 | Maintenance and fault detection/localization procedures for transport networks. |
| ITU-T Recommendation Q.822 | Q3 interface performance management model and managed-object foundation. |
| EN 300 417-1-1 and EN 300 417-5-1 | Generic transport functionality and PDH path-layer functions. |
| ITU-T Recommendation G.826 | Error-performance parameters and unavailable-period entry/exit criteria. |
| ITU-T Recommendation X.739 | Metric objects and attributes, including scannerId and historyDataId. |
| ITU-T Recommendation M.3100 | Generic network information model, including shared management objects. |
What does the SIST EN 301 384 V1.1.1:2003 document contain?
The document contains object class definitions, package definitions, attribute usage, and name bindings for the PDH performance monitoring model. Clause 11 provides the ASN.1 module PDHPMASN1, together with inheritance figures for current data and history data classes and the naming tree for the relevant managed objects.
It also includes the practical containment and creation rules that tell an implementation when history objects are created and how they are linked to current data objects. That makes the standard useful not only for conformance checking, but also for software design and interface implementation.
Get Certified
Connect with accredited certification bodies for this standard
ANCE
Mexican certification and testing association.
Intertek Slovenia
Intertek testing, inspection, and certification services in Slovenia.
LNE (Laboratoire National de Métrologie et d'Essais)
French national laboratory for metrology and testing.
Sponsored listings
Frequently Asked Questions
SIST EN 301 384 V1.1.1:2003 is a standard published by the Slovenian Institute for Standardization (SIST). Its full title is "Telecommunications Management Network (TMN); Performance monitoring for Plesynchronous Digital Hierarchy (PDH) interfaces; Information model for the Network Element (NE) view". This standard covers: Definition of the information model for performance monitoring of PDH-interfaces for the Network Element View Reference documents: prETS 300 417, ETS 300 371, DEN/TM-02246
Definition of the information model for performance monitoring of PDH-interfaces for the Network Element View Reference documents: prETS 300 417, ETS 300 371, DEN/TM-02246
SIST EN 301 384 V1.1.1:2003 is classified under the following ICS (International Classification for Standards) categories: 33.040.35 - Telephone networks. The ICS classification helps identify the subject area and facilitates finding related standards.
SIST EN 301 384 V1.1.1:2003 is available in PDF format for immediate download after purchase. The document can be added to your cart and obtained through the secure checkout process. Digital delivery ensures instant access to the complete standard document.
Standards Content (Sample)
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.Telekomunikacijsko upravljavno omrežje (TMN) - Nadzorovanje zmogljivosti vmesnikov pleziohrone digitalne hierarhije (PDH) - Informacijski model, gledano s strani
omrežnega elementa (NE)Telecommunications Management Network (TMN); Performance monitoring for Plesynchronous Digital Hierarchy (PDH) interfaces; Information model for the Network Element (NE) view33.040.35Telefonska omrežjaTelephone networksICS:Ta slovenski standard je istoveten z:EN 301 384 Version 1.1.1SIST EN 301 384 V1.1.1:2003en01-november-2003SIST EN 301 384 V1.1.1:2003SLOVENSKI
STANDARD
EN 301 384 V1.1.1 (1999-05)European Standard (Telecommunications series)Telecommunications Management Network (TMN);Performance monitoring forPlesynchronous Digital Hierarchy (PDH) interfaces;Information model for the Network Element (NE) viewSIST EN 301 384 V1.1.1:2003
ETSIETSI EN 301 384 V1.1.1 (1999-05)2ReferenceDEN/TMN-00040 (ctc00ico.PDF)KeywordsNE, PDH, performance, Q3 interface,transmissionETSIPostal addressF-06921 Sophia Antipolis Cedex - FRANCEOffice address650 Route des Lucioles - Sophia AntipolisValbonne - FRANCETel.: +33 4 92 94 42 00
Fax: +33 4 93 65 47 16Siret N° 348 623 562 00017 - NAF 742 CAssociation à but non lucratif enregistrée à laSous-Préfecture de Grasse (06) N° 7803/88Internetsecretariat@etsi.frIndividual copies of this ETSI deliverablecan be downloaded fromhttp://www.etsi.orgIf you find errors in the present document, send yourcomment to: editor@etsi.frCopyright 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 1999.All rights reserved.SIST EN 301 384 V1.1.1:2003
ETSIETSI EN 301 384 V1.1.1 (1999-05)3ContentsIntellectual Property Rights.4Foreword.41Scope.52References.53Abbreviations.64Performance Monitoring Management Model.75Managed object class definitions.76Packages.137Attributes.138Actions.139Notifications.1310Name bindings.1411ASN.1 definitions.15History.17SIST EN 301 384 V1.1.1:2003
ETSIETSI EN 301 384 V1.1.1 (1999-05)4Intellectual 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.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 CommitteeTelecommunications Management Network (TMN).National transposition datesDate of adoption of this EN:14 May 1999Date of latest announcement of this EN (doa):31 August 1999Date of latest publication of new National Standardor endorsement of this EN (dop/e):29 February 2000Date of withdrawal of any conflicting National Standard (dow):29 February 2000SIST EN 301 384 V1.1.1:2003
ETSIETSI EN 301 384 V1.1.1 (1999-05)51ScopeThe present document provides an information model for the performance monitoring of Synchronous Digital Hierarchy(SDH) network. This model describes the managed object classes and their properties for the performance monitoringfunction, as defined in ITU-T Recommendation G.784 [1] and EN 301 167 [2] and as related to SDH Network Elements(NEs). These objects are useful to describe information exchanged across interfaces defined inITU-T Recommendation M.3010 [3] Telecommunications Management Network (TMN) architecture for themanagement of the performance monitoring function.PDH performance monitoring functions are used to monitor specified performance events of specified terminationpoints managed objects as defined in EN 300 371 [4] and to report these performance data, as well as quality of servicealarms to its managing system according to a given schedule.ITU-T Recommendation M.2120 [5] defines maintenance of transport network,ITU-T Recommendation G.784 [1] defines the management of SDH based NE. The present document defines the objectmodel based on ITU-T Recommendation Q.822 [6] according to the requirements described inITU-T Recommendation G.784 [1], EN 301 167 [2] and ITU-T Recommendation M.2120 [5]. This model uses genericmechanism defined in ITU-T Recommendation Q.822 [6].The present document defines:-an information model, as related to the performance monitoring function for the Plesynchronous DigitalHierarchy (PDH).The present document does not define:-the protocol stack to be used for message communication;-the network level management processes;-the application contexts;-the conformance requirements to be met by an implementation of this information model;-information models for other systems or equipment.The information model defined here (and the corresponding message set) is concerned with the management of NEs, theequipment by which they are implemented and the functions contained within them. More precisely, it applies to anequipment domain visible at the element manager to element interface and is only concerned with information availablewithin that domain. Information proper to the domain of a network level management process is not included within thismodel.2ReferencesThe following documents contain provisions which, through reference in this text, constitute provisions of the presentdocument.· References are either specific (identified by date of publication, edition number, version number, etc.) ornon-specific.· For a specific reference, subsequent revisions do not apply.· For a non-specific reference, 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.SIST EN 301 384 V1.1.1:2003
ETSIETSI EN 301 384 V1.1.1 (1999-05)6[1]ITU-T Recommendation G.784 (1994): "Synchronous Digital Hierarchy (SDH) Management".[2]EN 301 167: "Transmission and Multiplexing (TM); Management of Synchronous DigitalHierarchy (SDH) transmission equipment; Fault management and performance monitoring;Functional description".[3]ITU-T Recommendation M.3010 (1996): "Principles for a Telecommunications ManagementNetwork".[4]EN 300 371: "Telecommunications Management Network (TMN); Plesiochronous DigitalHierarchy (PDH) information model for the Network Element (NE) view".[5]ITU-T Recommendation M.2120 (1997): "PDH path, section and transmission system and SDHpath and multiplex section fault detection and localization procedures".[6]ITU-T Recommendation Q.822 (1994): "Stage 1, stage 2 and stage 3 description for the Q3interface - Performance Management".[7]ITU-T Recommendation G.774-01 (1996): "Synchronous Digital Hierarchy (SDH) performancemonitoring for the network element view".[8]ITU-T Recommendation G.774-06 (1997): "Synchronous Digital Hierarchy (SDH) unidirectionalperformance monitoring for the network element view".[9]EN 300 417-1-1: "Transmission and Multiplexing (TM); Generic requirements of transportfunctionality of equipment; Part 1-1: Generic processes and performance".[10]EN 300 417-5-1: "Transmission and Multiplexing (TM); Generic requirements of transportfunctionality of equipment; Part 5-1: Plesiochronous Digital Hierarchy (PDH) path layerfunctions".[11]ITU-T Recommendation G.826 (1996): "Error performance parameters and objectives forinternational, constant bit rate digital paths at or above the primary rate".[12]ITU-T Recommendation X.739 (1993): "Information technology - Open Systems Interconnection -Systems Management: Metric objects and attributes".[13]ITU-T Recommendation M.3100 (1995): "Generic network information model".3AbbreviationsFor the purposes of the present document, the following abbreviations apply:BBEBackground Block ErrorCSESConsecutive Severely Errored SecondsCTPConnection Termination PointESErrored SecondFEBBEFar End Background Block ErrorFEESFar End Errored SecondFESESFar End Severely Errored SecondsNENetwork ElementPDHPlesynchronous Digital HierarchySDHSynchronous Digital HierarchySEMFSynchronous Equipment Management FunctionSESSeverely Errored SecondTMNTelecommunications Management NetworkTRThreshold ResetTTPTrail Termination PointUASUnavailable SecondsSIST EN 301 384 V1.1.1:2003
ETSIETSI EN 301 384 V1.1.1 (1999-05)74Performance Monitoring Management ModelThe performance monitoring requirements to be met by the SDH Equipment Management Function (SEMF) aredescribed in ITU-T Recommendation G.784 [1], subclause 5.3 and in EN 301 167 [2], subclauses 5.1 to 5.2. Thefunctional model given in the SEMF for performance monitoring of SDH signals is basically applicable for PDH signalsas well.5Managed object class definitionsIn the context of the present document, the IMPORTS clause specifies the object classes which can be instantiated in theScope of the present document. The IMPORTS clause does not include uninstantiated superclasses.BEGINIMPORTScurrentData,historyDataFROM Q822-PM-ASN1Module {itu(0) recommendation(0) q(17) q822(822) informationModel(0)managedObjectClass(3)};ENDPDH Current Data UnidirectionalpdhCurrentDataUnidirectional
MANAGED OBJECT CLASSDERIVED FROM
"Recommendation Q.822: 1993": currentData;CHARACTERIZED
BY-"Recommendation Q.822: 1993": zeroSuppressionPkg,-"Recommendation Q.822: 1993": thresholdPkg,pdhCurrentDataUnidirectionalPackage
PACKAGE-BEHAVIOUR pdhCurrentDataUnidirectionalBehaviour;-ATTRIBUTES-"Recommendation M.3100: 1995": currentProblemListGET,-"Recommendation X.739: 1993": granularityPeriod
PERMITTED VALUES
PDHPMASN1.UniDGranularityPeriod;;;CONDITIONAL
PACKAGES-"Recommendation G.774-01: 1994":
historyPackage
PRESENT IF
"an instance does not support flexible assignment of the history length",-"Recommendation G.774-01: 1994":
unavailableTimeAlarmPackage
PRESENT IF
"starting and ending of unavailable period has to be reported and the-granularity period is 24 hours";REGISTERED AS {};pdhCurrentDataUnidirectionalBehaviour BEHAVIOURDEFINED AS"The pdhCurrentDataUnidirectional class is used to define generic characteristic for unidirectionalPDH performance monitoring from which subclasses are defined in order to hold performance eventcounts for a specific monitoring point. Subclasses of this class are used in order to supportperformance monitoring of PDH trails at various layers as described in EN
300 417-5-1. Theperformance monitoring events ES, SES and BBE which are monitored by some of the subclasses of thissubclass are defined in annex B/G.826 and are based on the performance event primitives specified inEN
300 417-1-1 and EN
300 417-5-1. The granularityPeriod attribute can only be assigned a value atcreation time.This class can only contain one reference to an instance of the thresholdData object class in the thresholdDataInstanceattribute.If a threshold is reached or crossed then the currentProblemList attribute shall indicate it with the probable causethresholdCrossed. Subclass of this class is used to monitor the near-end or far-end performance data of the trail.A period of unavailable time begins at the onset of 10 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 non-SES events. Theseten seconds are considered to be part of available time.The unavailability conditions are kept separate for near end and far end monitoring. This means that near endunavailability is deduced from near end conditions only (e.g. 10 consecutive SES at the near end) and far endunavailability is deduced from far end conditions only (e.g. 10 consecutive SES at the far end).SIST EN 301 384 V1.1.1:2003
ETSIETSI EN 301 384 V1.1.1 (1999-05)8For threshold reset subclasses of this object class the following rules apply:·No more than one QOS alarm shall be generated until there has been a 15 minutes rectangular fixed window withless error count than the low error count threshold and no unavailable period exists.·To provision the high and low threshold value, the counterThresholdAttributList attribute of theITU-T Recommendation Q.822 [6] - thresholdDataInstance is used. In this attribute all the thresholds (high andlow) for each necessary counter are stored in a list. This means for example, that the high threshold for ES andthe low threshold for ES are individually stored in the same list. It is up to the network element to recognizewhich is the high and which is the low one.If the unavailableTimeAlarmPackage is present and if an unavailable period starts then a communication alarm shall besent with a probable cause of Unavailable and the presence of this unavailable condition is indicated by thecurrentProblemList attribute. If an unavailable period is ending then a communication alarm shall be sent with aprobable cause of Unavailable and a severity of Cleared. An available condition is indicated by the absence of theunavailable condition in the current problem list. The unavailable condition has no effect on the operationalState. Eachsubclass of this class shall define the performance attributes required to hold the mandatory or optional performanceevents. These performance event counts (except UAS) are inhibited during unavailable time of its own direction (at thenear end or at the far end).Attributes which are defined in a subclass of this class shall be included in history information using the historyData, orone of its subclass, unless it is explicitly specified in the subclass of this class that a particular attribute be not included.Each subclass of this class shall indicate which subclass of the history data is used for history retention. The followingconditional packages are not used in this class: filterSuppressionPkg, observedManagedObjectPkg.Concerning the subclasses of this class the following rule applies:If a subclass of this class has a granularity period of 15 minutes, it should be either an instance with the threshold resetfunctionality or an instance without this functionality instantiated (per termination point), but not both.";PDH Current Data Near EndpdhCurrentDataNearEnd
MANAGED OBJECT CLASSDERIVED FROM
pdhCurrentDataUnidirectional;CHARACTERIZED
BYpdhCurrentDataNearEndPackage
PACKAGE
BEHAVIOUR
pdhCurrentDataNearEndBehaviour;
ATTRIBUTES
"Recommendation G.774-01: 1994":
bBE
REPLACE-WITH-DEFAULT
GET,
"Recommendation G.774-01: 1994":
eS
REPLACE-WITH-DEFAULT
GET,
"Recommendation G.774-01: 1994":
sES
REPLACE-WITH-DEFAULT
GET;;;CONDITIONAL
PACKAGES"Recommendation G.774-06: 1997":
nearEndUASCurrentDataPackage
PRESENT IF
"an instance supports it","Recommendation G.774-01: 1994":
cSESCurrentDataPackage
PRESENT IF
" the granularity period is 15 minutes and an instance supports it";REGISTERED AS
{ } ;pdhCurrentDataNearEndBehaviour
BEHAVIOURDEFINED AS"Instances of the pdhCurrentDataNearEnd managed object class are used to hold the current near endregister counts for a PDH path during a collection period.The following performance primitives are observed: Defect Seconds (pN_DS) and Errored Blocks (nN_B). Theseprimitives are provided by monitoring functions represented in superior PDH termination points and are defined in PDHpath layers according EN 300 417-5-1 [10].For these performance primitives the following performance events are defined:BBEBackground Block Error.ESErrored Second.SESSeverely Errored Second.UASUnavailable Second: This counter is used to store one second intervals pertaining to an unavailabletime period at the near end.SIST EN 301 384 V1.1.1:2003
ETSIETSI EN 301 384 V1.1.1 (1999-05)9In addition, the optional performance event CSES (Consecutive SES) is defined.This managed object class uses the pdhPathHistoryDataNearEnd managed object class for history retention.A QOS alarm shall be sent as soon as a threshold is reached or crossed. At the end of the granularity period the QOSalarm is implicitly cleared and, providing there are no other outstanding threshold crossing QOS alarms,thresholdCrossing is removed from the currentProblemList (i.e. no notification is sent). A new QOS alarm shall be sentif the threshold is reached or crossed again during the next granularity period. Only one threshold value per performancecounter will be supported.";PDH Current Data Near End Threshold Res
...