ETSI EN 301 251 V4.2.1 (1998-12)

Digital cellular telecommunications system (Phase 2) (GSM); Fault management of the Base Station System (BSS) (GSM 12.11 version 4.2.1)

REN/SMG-061211PR1

Digitalni celični telekomunikacijski sistem (faza 2) – Upravljanje okvar za sisteme baznih postaj (BSS) (GSM 12.11, različica 4.2.1)

General Information

• Status: Published
• Publication Date: 09-Dec-1998
• Technical Committee: SMG 6 - Operations & Maintenance
• Current Stage: 12 - Completion
• Due Date: 04-Dec-1998
• Completion Date: 10-Dec-1998
• Ref Project: SIST EN 301 251 V4.2.1:2003 - Digital cellular telecommunications system (Phase 2) (GSM); Fault management of the Base Station System (BSS) (GSM 12.11 version 4.2.1)

Standards Content (Sample)

2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.Digital cellular telecommunications system (Phase 2) (GSM); Fault management of the Base Station System (BSS) (GSM 12.11 version 4.2.1)33.070.50Globalni sistem za mobilno telekomunikacijo (GSM)Global System for Mobile Communication (GSM)ICS:Ta slovenski standard je istoveten z:EN 301 251 Version 4.2.1SIST EN 301 251 V4.2.1:2003en01-december-2003SIST EN 301 251 V4.2.1:2003SLOVENSKI
STANDARD
EN 301 251 V4.2.1 (1998-12)European Standard (Telecommunications series)Digital cellular telecommunications system (Phase 2);Fault management of the Base Station System (BSS)(GSM 12.11 version 4.2.1)GLOBAL SYSTEM
FOR MOBILE COMMUNICATIONSRSIST EN 301 251 V4.2.1:2003

ETSIEN 301 251 V4.2.1 (1998-12)2GSM 12.11 version 4.2.1ReferenceREN/SMG-061211PR1 (bl0020oo.PDF)KeywordsDigital cellular telecommunications system,Global System for Mobile communications (GSM)ETSIPostal 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] copies of this ETSI deliverablecan be downloaded fromhttp://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 251 V4.2.1:2003

ETSIEN 301 251 V4.2.1 (1998-12)3GSM 12.11 version 4.2.1ContentsIntellectual Property Rights.5Foreword.5Introduction.51Scope.72References.72.1Normative references.72.2Informative references.93Definitions and abbreviations.93.1Definitions.93.2Abbreviations.114General requirements on fault management.114.1Overview of the service components.134.1.1Alarm Surveillance service component.134.1.2Fault Localisation service component.134.1.3Fault Correction service component.134.1.4Testing service component.135Fault management service components.135.1Alarm surveillance.135.1.1The model.145.1.2Threshold Management.165.1.2.1General.165.1.2.2Counter Thresholds.175.1.2.3Gauge thresholds.175.1.2.4Operations.185.1.3Alarm Reporting.195.1.4Log control.205.1.5Alarm summary.205.2Fault localisation.215.3Fault correction.215.4Testing.225.4.1The model.235.4.2Testing requirements.245.4.3Test Categories.255.4.3.1Resource Self Test.255.4.3.2Resource Boundary Test.255.4.3.3Connection Test.255.4.3.4Data Integrity Test.255.4.3.5Loopback Test.265.4.3.6Protocol Integrity Test.265.4.3.7Test-Infrastructure Test.266Fault management functions.266.1Alarm surveillance functions.266.1.1Threshold Management functions.266.1.2Alarm Reporting functions.286.1.3Log control functions.296.1.4Alarm summary functions.306.1.5Alarm surveillance related basic services.306.2Fault localisation functions.326.2.1Alarm report function.326.2.2Test management functions.326.3Fault correction functions.326.4Test management functions.33SIST EN 301 251 V4.2.1:2003

ETSIEN 301 251 V4.2.1 (1998-12)4GSM 12.11 version 4.2.16.4.1Functions.336.4.1.1Controlled Test Request function.336.4.1.2Uncontrolled Test Request function.336.4.1.3Resume/suspend Test function.336.4.1.4Terminate Test function.346.4.1.5Test Result function.346.4.1.6Scheduling Conflict Report function.346.4.2Test management related basic functions.347BSS specific fault management functions.347.1BSS specific alarm surveillance functions.357.2BSS specific fault localisation functions.357.3BSS specific fault correction functions.357.4BSS specific testing function.367.5BSS-OS communication failure.36Annex A (normative):BSS specific probable causes.37A.1BSS specific probable causes.37A.2ASN.1 syntax for BSS specific probable cause definitions.40Annex B (informative):Change History.43History.44SIST EN 301 251 V4.2.1:2003

ETSIEN 301 251 V4.2.1 (1998-12)5GSM 12.11 version 4.2.1Intellectual 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) (EN) has been produced by ETSI Special Mobile Group (SMG).This specification describes the fault management of any NE of a GSM PLMN through the Q3 interface, with focus onthe Base Station System (BSS) within the digital cellular telecommunications system.The contents of this en is subject to continuing work within SMG and may change following formal SMG approval.Should SMG modify the contents of this EN, it will be re-submitted foe OAP by SMG with an identifying change ofrelease date and an increase in version number as follows:Version 4.x.ywhere:4indicates GSM Phase 2;xthe second digit is incremented for all other types of changes, i.e. technical enhancements, corrections,updates, etc.;ythe third digit is incremented when editorial only changes have been incorporated in the specification.National transposition datesDate of adoption of this EN:4 December 1998Date of latest announcement of this EN (doa):31 March 1999Date of latest publication of new National Standardor endorsement of this EN (dop/e):30 September 1999Date of withdrawal of any conflicting National Standard (dow):30 September 1999IntroductionThis EN specifies the requirements and model necessary for the standardised fault management (FM) aspects ofoperation, administration and maintenance (OAM) of a multivendor GSM PLMN.The management of a GSM PLMN follows the systems management model outlined in ITU-T X.701 [5] whichstructures systems management into various aspects. This EN addresses the functional aspects of fault management.Fault management provides the following facilities during the operation and maintenance phases of the PLMN undernormal and failure conditions:-installation and acceptance testingSIST EN 301 251 V4.2.1:2003

ETSIEN 301 251 V4.2.1 (1998-12)6GSM 12.11 version 4.2.1-putting into service-keeping the network operational.The structure of this document has been defined taking into consideration two aspects:1)The structured, top-down process of the standardisation. A general description of the ‘Fault Management’ of aNetwork Element (NE) is presented in clause 4. In clause 5, there is a specification of the four fault management‘Service Components’ and, in clauses 6 and 7, the specification of the ‘Functions’
which the above servicecomponents are based on.2)The reusability of this specification for other NEs of the PLMN. The requirements in clauses 4, 5 and 6 havebeen specified in a generic way (referring to a generic NE instead of a specific Base Station System) and all BSSspecific management functions are specified separately in clause 7.GSM fault management is based upon the context set by GSM 12.00. Principles, concepts and definitions are based onthe M-series of the ITU-T standards (with the exception of the Alarm Surveillance management functions based onQ.821). Where the M-series of standards is not applicable, then the X-series is used as far as possible.SIST EN 301 251 V4.2.1:2003

ETSIEN 301 251 V4.2.1 (1998-12)7GSM 12.11 version 4.2.11ScopeThis EN describes the fault management of any NE of a GSM PLMN through the Q3 interface, with focus on the BaseStation System (BSS).The OAM of the GSM Public Land Mobile Network (PLMN) is organised and described in terms of TMN ManagementServices. GSM 12.00 describes the architecture and gives a general overview of the OAM services, while the rest of theGSM 12 series gives the detailed specification for each service and other aspects of the OAM.Among all the TMN Management Services listed in GSM 12.00, the following are addressed by this specification:-Management of the BSS (also covered by GSM 12.20).-Restoration and Recovery (also covered by GSM 12.06).This Phase 2 version of GSM 12.11 deals with "Fault Management" aspects of the above services.For the TMN Management Services covered, the following "TMN Management Service Components" have been defined inclause 5:-Alarm surveillance.-Fault localisation.-Fault correction.-Testing.The above TMN Management Service Components are based on several "Management Functions", some of which aredefined in other ITU-T documents (e.g. State Management Functions, Alarm Reporting Functions, etc.), and others whichare specifically defined here, in clauses 6 and 7.For some management functions, the Management Information Model is already provided by some ITU-Trecommendations, GSM 12.00 and GSM 12.20.This EN does not include the GDMO definition of the information model.Although sometimes considered as part of fault management, various administrative policies and procedures such astrouble ticketing and tracking, parts inventory, etc. are not included in this EN. Such aspects may be considered to be theresponsibility of the operator and thus outside the scope of the EN.2ReferencesReferences 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.2.1Normative referencesThis EN incorporates, by dated or undated reference, provisions from other publications. These normative references arecited at the appropriate places in the text and the publications are listed hereafter. For dated references, subsequentSIST EN 301 251 V4.2.1:2003

ETSIEN 301 251 V4.2.1 (1998-12)8GSM 12.11 version 4.2.1amendments to, or revisions of, any of these publications apply to this EN only when incorporated in it by amendment orrevision. For undated references the latest edition of the publication referred to applies.[1]ITU-T Recommendation M.20 (1992): "Maintenance Philosophy for TelecommunicationNetworks".[2]ITU-T Recommendation M.3100 (1995): "Generic Network information Model".[3]ITU-T Recommendation M.3200 (1992): "TMN Management Services: Overview".[4]ITU-T Recommendation M.3400 (1992): "TMN Management Functions".[5]ITU-T Recommendation X.701 (1992) ½ ISO/IEC 10040: " Information technology - OpenSystems Interconnection - Systems Management Overview ".[6]ITU-T Recommendation X.721 (1992) ½ ISO/IEC 10165-2: " Information technology - OpenSystems Interconnection - Structure of management information: Definition of ManagementInformation ".[7]ITU-T Recommendation X.722 (1992) ½
ISO/IEC 10165-4: "Information technology - OpenSystems Interconnection - Structure of management information: Guidelines for the Definition ofManaged Objects".[8]not used[9]ITU-T Recommendation X.733 (1992) ½
ISO/IEC 10164-4: "Information technology - OpenSystems Interconnection - Systems Management: Alarm Reporting Function".[10]ITU-T Recommendation X.734 (1992) ½
ISO/IEC 10164-5: "Information technology - OpenSystems Interconnection - Systems Management: Event Report Management Function".[11]ITU-T Recommendation X.735 (1992) ½
ISO/IEC 10164-6: "Information technology - OpenSystems Interconnection - Systems Management: Log Control Function".[12]ITU-T Recommendation X.737 (1995) ½ (ISO/IEC 10164-14): "Information technology - OpenSystems Interconnection - Systems Management: Confidence and Diagnostic Test Categories".[13]ITU-T Recommendation X.745 (1994) ½ ISO/IEC 10164-12: "Information technology - OpenSystems Interconnection - Test Management Function".[14]ITU-T Recommendation X.751 (1995) ½ (ISO/IEC 10164-17): "Information technology - OpenSystems Interconnection - Change Over Function".[15]ITU-T Recommendation Q.821: (1993)
"Q3 Interface for Alarm Surveillance".[16]ETR 100 (GSM 01.04): Digital cellular telecommunications system (Phase 2); "Abbreviations andacronyms".[17]ETS 300 590 (GSM 08.08): Digital cellular telecommunications system (Phase 2);"MobileSwitching Centre (MSC) to Base Station System (BSS) Interface; Layer 3 Specification".[18]ETS 300 612-1 (GSM 12.00): Digital cellular telecommunications system (Phase 2);
"Objectivesand Structure of GSM PLMN Management".[19]ETS 300 612-2 (GSM 12.01): Digital cellular telecommunications system (Phase 2);
"CommonAspects of GSM/DCS 1800 PLMN Management".[20]ETS 300 615 (GSM 12.04): Digital cellular telecommunications system (Phase 2);"PerformanceManagement and Measurements for a GSM PLMN".[21]ETS 300 617 (GSM 12.06): Digital cellular telecommunications system (Phase 2); "GSM NetworkConfiguration Management".[22]ETS 300 622 (GSM 12.20): Digital cellular telecommunications system (Phase 2); "Base StationSystem (BSS) Management Information".SIST EN 301 251 V4.2.1:2003

ETSIEN 301 251 V4.2.1 (1998-12)9GSM 12.11 version 4.2.12.2Informative references1)ITU-T Recommendation M.3010 (1992): "Principles for a Telecommunications ManagementNetwork".2)ITU-T Recommendation X.710 (1991): "Common management information service definition forCCITT applications". ISO/IEC 9595: "Information technology - Open Systems Interconnection -Common management information service definition" is technically aligned with ITU-T X.710.3)ITU-T Recommendation X.711 (1991): "Common management information protocol specificationfor CCITT applications" ISO/IEC 9596: "Information technology - Open Systems Interconnection- Common management information protocol specification " is technically aligned with ITU-TX.711.4)ITU-T Recommendation X.725 (1995):½ ISO/IEC 10165-7: "Information technology - OpenSystems Interconnection - Structure of management information: General Relationship Model".5)ITU-T Recommendation X.731 (1992): ½ ISO/IEC 10164-2: "Information technology - OpenSystems Interconnection - Systems Management: State Management Function".6)ETS 300 593 (GSM 08.52): Digital cellular telecommunications system (Phase 2); "Base StationController to Base Transceiver Station Interface Principles".7)ETS 300 596 (GSM 08.58): Digital cellular telecommunications system (Phase 2); "BSC-BTSLayer 3 Specification".8)ETS 300 597 (GSM 08.60): Digital cellular telecommunications system (Phase 2);
"Inbandcontrol of remote transcoders and rate adapters ".9)ETS 300 623 (GSM 12.21): Digital cellular telecommunications system (Phase 2);
"NetworkManagement Procedures and Messages On the A-bis Interface".10)ETS 300 624 (GSM 12.22): Digital cellular telecommunications system (Phase 2);
"Interworkingof GSM Network Management (NM) procedures and messages at the Base Station Controller(BSC)".3Definitions and abbreviations3.1DefinitionsFor the purposes of the present document, the following definitions apply:Alarm: A notification, of the form defined by the alarm reporting function (ITU-T X.733 [9]), of a specific event.Active resource: An active resource in the context of redundancy is equivalent to a primary resource.Alarm report: A specific type of event report used to convey alarm information.Outstanding alarm condition: The state in which the conditions that originated an alarm are still present in the system.Anomaly: An anomaly is a discrepancy between the actual and desired characteristics of an item (ITU-T M.20 [1]). Inthe context of this specification, the item may also be external to the NE (e.g. : environmental alarm detector).Asymmetric redundancy: A redundancy where the primary and secondary resources have different capabilities, andtherefore cannot exchange their roles (where the secondary may take the primary role, but the primary may not take thesecondary role). Once the faulty primary resource is repaired and restored to service a change back needs to beperformed.Back up: A back up resource is a secondary resource providing redundancy to a primary resource.Backed up: A backed up resource is a primary resource which has a secondary resource providing redundancy.SIST EN 301 251 V4.2.1:2003

ETSIEN 301 251 V4.2.1 (1998-12)10GSM 12.11 version 4.2.1Change-back: A change back is the reverse change over in an asymmetric redundancy to restore the resources into theiroriginal roles.Change-over: Change over is the action within a system capable of supporting redundancy which results in a secondaryresource taking over the primary role. In a symmetric redundancy, the primary resource may take the secondary role.Cleared Alarm: An alarm notification with the perceived severity set to cleared.Cold standby: A secondary resource that requires initialisation activity before it can provide backup capability isdefined as being in a cold standby state (ITU-T X.751 [14]).Counter: Counters are a management abstraction of an underlying process, which may be associated with a definedinternal event in management information. The current value of a counter is incremented when this event occurs (seenote). It can take any values in its range. When a counter reaches its maximum value, it wraps around and countsupwards from 0; overflow information is not in general retained. An additional notification may be defined for counterswith wrap behaviour.NOTE:The rule that a counter value can increase only in single increments is a descriptive convention thatsimplifies the description of a counter threshold. It does not imply that it will always be possible toobserve each increment in the counter's range, since the events counted may occur in rapid succession.Counter Threshold: A counter threshold is the application of the thresholding mechanism to a counter.Defect: A defect is a limited interruption in the ability of an item to perform a required function. It may or may not leadto maintenance action depending on the results of additional analysis (M.20 [1]). In the context of this specification, theitem may also be external to the NE (e.g. : environmental alarm detector).Duplex redundancy: A duplex redundancy is a redundancy in which a given function can be performed by tworesources: a primary resource and secondary resource (also known as active and standby resources respectively).Failure: A failure is the termination of the ability of an item to perform a required function (M.20 [1]). In the context ofthis specification, the item may also be external to the NE (e.g. : environmental alarm detector).NOTE: After a failure, the item has a fault (M.20 [1]).Fault: A fault is the inability of an item to perform a required function, excluding that inability due to preventivemaintenance, lack of external resources or planned actions.NOTE: A fault is often the result of a failure of the item itself, but may exist without prior failure
(M.20 [1]).Gauge: The gauge is the management abstraction of the value of a dynamic variable, such as the number of connectionscurrently operated by a protocol machine or the rate of change of a traffic counter. There is no restriction on what thedynamic variable may represent, within the constraints set out below. The value of the gauge is subject to change ineither direction.
The value of the increment or decrement is unconstrained, except that a change that would take thegauge beyond its minimum or maximum value, will leave the gauge value at its minimum or maximum valuerespectively, until it is subsequently again within the gauge range values.Gauge Threshold: A gauge threshold is the application of the thresholding mechanism to a gauge.Hot standby: A secondary resource that is able to provide backup capability for a primary resource without the
needfor initialisation activity is defined as being in a hot standby state (X.751 [14]).Least Replaceable Unit (LRU): The smallest piece of equipment that can be replaced by field service personnel.N+K redundancy:
A redundancy where a given function can be performed by N primary resources and K secondaryresources.
When a failure occurs on one of the N primary resources, one of the K secondary resources may take overthe role of that faulty primary resource.Primary resource: A primary resource (in a system capable of supporting redundancy) is a resource that is performinga given function. On failure of a primary resource a secondary resource may take over the role of the faulty primaryresource. A primary resource may also be referred to as an "active" or "backed up" resource.Redundancy: The capability of a system to perform fault tolerant functionality by means of spare resources (or groupsof resources).SIST EN 301 251 V4.2.1:2003

ETSIEN 301 251 V4.2.1 (1998-12)11GSM 12.11 version 4.2.1Secondary resource: A secondary resource (in a system capable of supporting redundancy) is a resource that may backup a primary resource. A secondary resource may take over the role of a primary resource on failure of that resource. Asecondary resource may also be referred to as a "standby" or "back up" resource.Standby resource: A standby resource in the context of redundancy is equivalent to a secondary resource.Symmetric redundancy: A redundancy where the primary and secondary resources have the same capabilities, andtherefore each of the resources can exchange their roles (primary and secondary). Once the faulty resource is repairedand restored to service there is no need to perform a change back.Thresholding: Thresholding is the general mechanism (based on counters or gauges) to generate a defined notificationfrom numeric changes in the value(s) of a counter(s) or gauge(s). The defined notification is generated as a result of avalue change crossing the threshold level of a counter or gauge.Threshold Level: A threshold level is a value which a threshold mechanism compares with the value of a counter orgauge, to determine whether a defined notification is to be generated.3.2AbbreviationsFor the purpose of the present document, the following abbreviations apply, in addition to those listed inGSM 01.04 [16]:AOAssociated ObjectACSEAssociation Control Service ElementASN.1Abstract Syntax Notation (number) 1BSCBase Station ControllerBSSBase Station SystemBTSBase Transceiver StationCASCCurrent Alarm Summary ControlCMISCommon Management Information ServiceCMISECommon Management Information Service ElementCMIPCommon Management Information ProtocolEFDEvent Forwarding DiscriminatorFTAMFile Transfer Access and ManagementGDMOGuidelines for the Definition of Managed ObjectsLRULeast Replaceable UnitMIBManagement Information BaseMOCManaged Object ClassMORTManaged Object Referring to TestMOSManagement Operations ScheduleNENetwork ElementOAMOperation, Administration and MaintenanceOMCOperations and Maintenance CentreOSOperations SystemOSIOpen Systems InterconnectionPLMNPublic Land Mobile NetworkQOSQuality of ServiceROSERemote Operation Service ElementSFTCSimple File Transfer ControlTARRTest Action Request ReceiverTMNTelecommunications Management NetworkTOTest Object4General requirements on fault managementGSM fault management follows TMN principles as specified in GSM 12.00 [18]. These principles provide formanagement of a GSM PLMN based onan information model. This model is developed through the definition of arequired set of management services which are then decomposed into service components. These service componentsare supported by a number of management functions according to M.3400 [4], and finally an information model can beSIST EN 301 251 V4.2.1:2003

ETSIEN 301 251 V4.2.1 (1998-12)12GSM 12.11 version 4.2.1defined for supporting this set of functions. It is expected that this information model will be defined in a future GSMphase 2+ version of this document.In GSM 12.00, the terms reactive maintenance and proactive maintenance are used to identify two different forms ofmaintenance for a GSM network element. Reactive maintenance is the use of the above management functions to detecta fault and restore all or part of the network element following a failure. Proactive maintenance is the use of the abovemanagement functions and manual routine maintenance activities to prevent, as far as possible, the occurrence of afailure. This EN does not explicitly assign the above management functions to either proactive or reactive maintenance,and generically defines the management functions such that they may be used either as part of proactive or reactivemaintenance. The remainder of this EN thus makes no further reference to either proactive or reactive maintenance.Fault Management is a functional area which can support a number of management services (M.3400) [4]. Thefollowing list gives examples of the general objectives of the NE's fault management:- Inform the operator and/or OS of the current NE condition;- Provide timely and accurate data regarding any abnormal change in the condition of the NE;-Maintain synchronisation between the actual conditions in the NEs and the knowledge of the conditions asunderstood by the OS;- Provide procedures which allow system recovery either automatically or on operator demand after a faultdetection.To support these objectives the NE shall offer the following set of capabilities:- Surveillance capability to monitor the system such that faults, defects and anomalies may be detected andreported;- Fault Localisation capability to identify the one or more replaceable units at fault;- Fault Correction capability to isolate the faulty units and restore the system to operation;- Testing capability to verify the proper operation of physical and functional resources in the NE.To support fault management, the state management capability may also be necessary, for example, to isolate a faultyunit by changing its administrative state, to provide a specific environment for testing etc. The usage of statemanagement for fault management purposes will be described in each clause where it is appropriate.In addition to the above, the capabilities of other functional management areas are often used in support of faultmanagement. For example, parts of performance management services may be used for the fault detection capability(e.g.: counters and gauges for threshold management) and configuration management functions may be used to restorethe system to the best operational configuration.Based on M.3400 [4], GSM fault management requirements can be achieved by means of the following managementservice components:-Alarm surveillance service components;-Fault localisation service component;-Fault correction service component;-Testing service component;-Trouble administration service component.Of this list, the trouble administration component is not addressed by this EN as it is too closely related with theoperator's operational procedures and thus is not suitable for standardisation.The operator and the OS are informed of an NE failure by means of functions provided by the alarm surveillancecomponent: the alarm reporting functions. The information provided by alarm reporting should be sufficient to localisethe fault. However, if necessary, the operator may also use the testing capabilities to obtain further details for faultdiagnosis. Depending on the type of the detected fault and its impact on the telecommunication services, the faultcorrection service component provides automatic or manual actions to configure the NE so as to minimise the loss of thetelecommunication services. When the faulty unit(s) is repaired,the fault correction service component again providesautomatic or manual actions to restore the previously faulty unit(s) to its normal operation. To complete the faultmanagement process, the operator is able to perform a final test to certify the behaviour of the repaired system.SIST EN 301 251 V4.2.1:2003

ETSIEN 301 251 V4.2.1 (1998-12)13GSM 12.11 version 4.2.14.1Overview of the service components4.1.1Alarm Surveillance service componentThe Alarm Surveillance Service Component performs system monitoring and fault detection in near real time. When afailure occurs in an NE, an alarm record is stored in a log (depending on the filter criteria) and an alarm report isforwarded (depending on the filter and forwarding criteria) as soon as possible to the OS across the Q3 interface. Thenature and severity of the faults are determined by the NE. It is important that alarm reports are not lost in case oftemporary interruption of communication between the NE and the OS.4.1.2Fault Localisation service componentThe objective of Fault Localisation is to identify the faulty unit by means of the information provided by the NE when itnotifies the OS of the failure. If necessary, further identification by means of localisation routines (e.g.: tests controlledby the OS) can also be run to get more details.4.1.3Fault Correction service componentAfter the identification of the fault and the replaceable faulty units, support by the Fault Correction service component isnecessary in order to perform system recovery and/or restoration, either automatically by the NE and/or the OS, ormanually by the operator. The first fault correction action is the isolation of the faulty unit, to reduce the effect of thefault on other parts, internal or external to the NE.4.1.4Testing service componentThe Testing service component provides support for the other three fault management capabilities. Testing can becarried out in two ways: uncontrolled and controlled by the management system, and can be performed through periodicscheduling or on demand. Several categories of tests are necessary to cover all the requirements.5Fault management service componentsAccording to the TMN scheme (see M.3200 [3] and M.3400 [4]), the general requirements on fault managementdescribed in the previous clauses are achieved by means of management service components. This clause contains amore detailed description of the requirements and defines the related management service components.5.1Alarm surveillanceThis service component requires that the OS and the operator have a consistent and up-to-date view of the currentoperating condition and quality of service of the managed network elements. For efficient and accurate faultmanagement of a PLMN, it is also essential to achieve early detection of faults so that they can be corrected beforesignificant effects have been noticed by the end-user.In support of this, the Alarm Surveillance functions are used to monitor and interrogate NEs about faults, defects andanomalies. This results in the following requirements:a)All detected faults, defects and anomalies in the NE shall be reported to the OS (for each case which matches thereporting conditions set by the OS). The NE/OS shall therefore support the sending/reception of unsolicited eventreports notifying such events.Whenever possible, the NE should generate a single notification for a single fault. When a single fault results inthe failure of other functionalities, the system should filter these "dependency faults".There are a number of possible mechanisms by which the NE can detect faults, defects and anomalies. Dependingon the implementation within the NE, several sources of information may be available. The most obviousexamples are:SIST EN 301 251 V4.2.1:2003

ETSIEN 301 251 V4.2.1 (1998-12)14GSM 12.11 version 4.2.1-hardware/firmware detectors: co-operating or supervising units which continuously check the correctness ofanalogue or digital signals (sense points, transmission error detectors);-software detectors: to detect run time software errors as well as equipment errors;-performance detectors: to monitor the performance of the NE and generate a quality of service alarmnotification if it
is out of normal range.Some of these detectors are manageable and some are not, depending on the nature of their implementation.Furthermore, some of the manageable aspects of these detection functions (such as managing of thresholds forquality of service alarms) are the subject of standardisation in this EN (these are described below), whilst othersare outside of the scope.b) The forwarding of alarm reports through the Q3 interface shall be manageable both in terms of filtering (whichreports shall be forwarded and which shall be discarded) as well as in terms of report destination(s). The alarmreporting is based on the model described in X.734 [10], i.e. the result of the fault detection process shall be analarm notification sent to the Event pre-processing which may generate a potential event report that is sent to allthe existing EFDs. The EFD is a managed object which receives the potential alarm reports and determines whichevent reports are to be forwarded and which are to be discarded. For the forwarded reports it also determines thedestination, the time frame and the forwarding mode (i.e. confirmed or non-confirmed).c) The NE shall be able to log alarm information as alarm records and support later retrieval of the logged alarmrecords. The logging functionality is based on the model described in X.735 [11] and can be used for any type ofevent information, including the alarm information. According to this model, when a fault is detected, an alarmnotification is also sent to the Log pre-processing which may generate a potential log report that is sent to all theexisting logs. The Log is a managed object which receives the potential log reports and determines which of themare stored as log records and which are discarded.d)The NE shall be able to provide information to the OS about all the current outstanding alarm conditions in theNE. The outstanding alarm information may be reported in a summary on demand or periodically to the OS. Thisfunctionality is based on the Q.821 [15] and can be used to obtain a view of the NE’s current alarm condition ondemand. This functionality can also be used to align alarm information between the OS and NE, for instance afteran interruption of communication between the OS-NE (e.g. link failure, OS restart, NE restart) without waitingfor the forwarding of all the events which occurred during the failure.To support these alarm surveillance requirements over the Q3 interface, a number of management functions are definedin more detail in clause 6. These functions are grouped as follows:- Threshold Management functions (X.721 [6]);- Alarm Reporting functions (M.3400 [4]/Q.821[15]/X.733 [9]/X.734[16]/GSM 12.00 [18]);- Log control functions (M.3400 [4]/Q.821[15] X.735 [11]);- Alarm Summary functions (M.3400 [4]/Q.821[15]).Alarm surveillance also has implications for the operating practices for co-ordination whenever multiple
OSs areinvolved in management operations. Such practices are the responsibility of the operator and are not standardised in thisEN.5.1.1The modelThe model adopted for Alarm Surveillance is depicted in figure 1. In this figure, the circles represent managed objects,stacks of circles represent sets of managed objects, and the names of the MOC(s) are reported in the middle of thecircles.The leftmost stack of managed objects in figure 1 represents the managed objects of the NE that can generate alarmnotifications (for example, in the case of a BSS, instances of the GSM 12.20 MOCs and their subclasses).The squares represent attributes belonging to managed objects not yet defined (and not shown in figure 1).The solid arrows represent the information flow and the dotted ones the control flow. Only the flows related to theAlarm Surveillance are represented and are described subsequently.The "Event/Log pre-processing" is an NE internal function (implementation dependent) and is n
...