Title of Invention

"METHOD FOR SYNCHRONIZING ALARMS IN A COMMUNICATION SYSTEM AND A COMMUNICATION SYSTEM THEREOF"

Abstract The invention relates to a method for handling alarms via a management network of a communications system, whereby the management network comprises at least two management centers (NMC, OMC) in different management levels. At least one of the at least two management centers functions as an element manager (OMC) and at least one of the at least two management centers functions as a network manager (NMC) that is assigned to and of a higher ranking than the element manager (OMC) that is assigned to and of a higher ranking than the element manager (OMC) in its function as agent. According to the invention: an alarm is mapped onto a functional object class in the element manager (OMC) while taking an object model into consideration at the interface (NM-EM) between the network manager (NMC) and element manager (OMC); the alarm is relayed from the element manager (OMC) to the network manager (NMC); the alarm is handled in the network manager (NMC), and a synchronization of the alarm status between the network manager (NMC), and the element manager (OMC) ensues in the element manager (OMC) using an operating that is the uniform for the interface (NM-EM) between the network manager (NMC) and the element manager (OMC) in the communications system.
Full Text The invention relates to a method for handling alarms in a management system of a communications network according to the preamble of claim 1.
The invention also relates to an element manager of a management system of a communications network for handling alarms according to the preamble of claim 8.
The invention finally relates to a communications system for handling alarms via a management network according to the preamble of claim 12.
The principles of telecommunications network management, which are also called TMN principles (TMN: Telecommunications Management Network), define a plurality of management layers for the management of the telecommunications network - for example a mobile communications network -with each layer, with the exception of the uppermost and lowest layers, having a dual function. In a managing system, each level, apart from the lowest, performs a manager function for the level below. In the managed system each level, apart from the uppermost, is given an agent function for the next-higher layer.
Individual devices or elements of the telecommunications network (network resources) perform the role of an agent in a TMN hierarchy. Agents must detect relevant events (for example alarms) in the network as quickly as possible, generate corresponding messages - what are known as notifications -and transmit these event reports to managers to make efficient network management possible.
The management network of a communications network as a rule includes at least two management systems at various management levels, at least one of the at least two management systems functioning as an element manager and at least one of the at least two management systems functioning as a network manager of a higher order than the element manager.
Element managers function as a manager with respect to a lower level and, with respect to the next-higher management level of the network manager, act as agents.
For network monitoring and control a manager starts what are known as operations (requests which are executed in agents) and receive corresponding responses. An agent detects relevant network events (for example alarms), generates messages (what are known as notifications) and transmits them as event reports to the manager to make efficient network management possible.
A management network of this type for a mobile communications network with agent-manager relationship includes for example operation and maintenance centres (OMC Operation and Maintenance Centre) and a plurality of network management centres (NMC Network Management Centre). In addition, a management level of the management network, which contains the network element level with a plurality of base station systems, can, for example, be provided. At the network element management level, operation and maintenance centres can, for example, in each case provide the manufacturer-specific management functionality for individual base stations of the base station system, for example. At the network management level, network management centres each produce an integrated management functionality that, as a rule, is independent of the manufacturer. In this case a plurality of network management centres can have access to the same network system of the next-lower management level, the network element management level, for example the network management centres of at least one operation and maintenance centre of the next-lower management level.
Provided between the network systems of different management levels are conventionally defined interfaces for transmitting information during manager-agent communication, what are known as management interfaces, which in an object-oriented environment are characterised by a communications protocol (for example CMIP (Common Management Information Protocol according to ITU-T X.711) or CORBA (Common Object Request Broker Architecture) and an object model. Interfaces of this type are provided, for example, between the network element management level and network element level (for example OMC-BSS (BSS Basestation Subsystem) in a GSM mobile communications network) or between the network management level and network element management level (for example NMC-OMC).
A precondition of optimum management of a telecommunications network is that only the relevant event reports from the lower-order agents are forwarded as quickly as possible to the manager systems. Under normal conditions, i.e. if the communication between agents and managers is functioning, this takes place via a filtering mechanism present in the agent (for example in a CMIP-based management interface, with the aid of Event Forwarding Discriminators, what are known as EFDs, according to ITU-T X.734 "Systems Management: Event Report Management Function").
The object of this filter is, by way of appropriate tests, to forward to the manger only those notifications which satisfy specific criteria. A manager is capable of creating or deleting such filters in
the agent and of establishing the filter criteria. As a result, each manager can at any time control the flow of information according to its individual requirements.
The management network considered in particular hereinafter includes at least two management systems at various management levels, at least one of the at least two management systems functioning as an element manager and at least one of the at least two management systems functioning as the network manager allocated to and of a higher order than the element manager in its function as an agent.
Document DE 198 01 785 Al describes a method for handling alarms in a communications system. A message, via which an alarm data alignment is requested, is sent by a manager to an agent. The message contains a parameter via which the alarm data alignment is controlled. The alarm data alignment takes place if, after a break in the connection, communication is re-established between manager and agent. After receiving the request, the agent successively sends the requested alarms to the manager.
Document US 2003/0162537 Al describes a management system which includes a manufacturer-independent device as the manager. An agent receives manufacturer-dependent information, which is transmitted to the manufacturer-independent manager in a manufacturer-independent format.
The ITU-T standards (International Telecommunications Union - Telecommunication standardization sector) of series X.73x define various system management functions for management of telecommunications networks which can be used by application processes in a centralized or decentralized management environment. As one of the most important functions of network monitoring and control, fault management and alarm handling take place with the aid of management systems. The management systems can in this case be located in particular at the network element management level (for example OMC, element manager) or network management level (for example NMC, network manager).
There is conventionally a large number of network resources in a telecommunications network which are modelled as what are known as object instances (MOI Management Object Instance) and can generate alarms. Each alarm is consequently generated as a result of at least one event in at least one network resource of the communications network. There are different types of relationships between
different network resources, so, for example, an event in one network resource can cause a series of further events in the same and/or in different network resources of a network unit.
From an operational perspective two management levels are of great importance to the management of an entire telecommunications network:
- The "network element management" level (EM level), the functionality of which is produced by
(regional) element managers (conventionally called OMCs) which, as a rule, are supplied by the same
manufacturer as the associated network systems or network elements (NE). The OMCs must take into
consideration all manufacturer-specific properties of the network elements (i.e. also the corresponding
hardware features).
- The "network management level" (NM level), the functionality of which is produced by a network
manager (conventionally called an NMC), which can also be supplied by a third-party manufacturer.
To make functional integration of manufacturer-specific network regions under a uniform NMC
possible, the interface between NMC and the (regional) OMCs must be manufacturer-independent.
The manufacturer independency of the OMC-NMC interface can be ensured in an object-oriented management environment by the exclusive use of what are known as functional-related object classes (functional-related MOC (Management Object Class). The functional objects model the network resources of a telecommunications network from a functional, manufacturer-independent perspective. In contrast thereto, the manufacturer-specific interface between the OMC and the network elements (for example BSS (Base Station System) and SSS (Switching Sub-System) in a GSM network) also recognises what are known as hardware related object classes (equipment-related MOC) which differ from manufacturer to manufacturer. In this management hierarchy each manufacturer-specific OMC plays a dual role: manager for the NEs and agent for the higher-order NMC.
The alarms can basically be handled at both management levels:
- at the EM level, i.e. in a manufacturer-specific OMC system (which is in each case responsible for a
network region), conventionally on work days. The change in the status of an alarm is conventionally
automatically communicated to the NMC via a corresponding event report in this case.
- at the NM level, i.e. in an NMC system, conventionally during the period when the OMCs are idle,
for example at night or at the weekends. If the status of an alarm is changed by an operator in this
case, the lower-order element manager must automatically be synchronised, so all management
systems receive the same level of information. The current 3GPP standards of the TS 32.xxx series
define different operations in which the affected alarms must be . specified individually for
synchronisation of this type.
For a large number of handled alarms this type of synchronisation is efficient for neither the NM-EM interface nor the OMCs.
A synchronisation of alarms at the EM level after a change in the alarm status at the NM level is specified in the 3GPP standards of the TS 32.xxx series as follows:
- a different operation (with a different syntax in each case) is defined for each type of alarm
handling: acknowledgement, unacknowledgement, clearing, set comments.
- each alarm to be synchronised must be identified in the operation by a clear identifier.
Synchronisation of a relatively large number of handled alarms in particular thus proves to be complex.
The object underlying the invention is to disclose a method, an element manager and a communications system of the type mentioned at the outset by way of which synchronisation can be simplified and which, in particular, makes it possible for a plurality of alarms handled at the NM level to be simultaneously synchronised using the OMC systems.
This object is achieved according to the invention with respect to the method by the features of claim 1, with respect to the element manager by the features of claim 8 and with respect to the communications system by the features of claim 12. Developments and configurations of the invention can be found in particular in the dependent claims.
According to the invention
- in the element manager, an alarm is mapped onto a functional object class while taking an object
model into consideration at the interface between network manager and element manager,
- the alarm is forwarded from the element manager to the network manager,
the alarm is handled in the network manager
and
- synchronisation of the alarm status between network manager and element manager takes place in
the element manager using an operation that is uniform for the interface between network manager
and element manager in the communications system.
As a result of this measure, improved handling of alarms with respect to synchronisation is made possible, in that a universal, manufacturer-independent mechanism is made available which can be used not only for GSM (Global System for Mobile communication) and UMTS (Universal Mobile Telecommunication System) mobile communications networks but also for the management of any desired telecommunications networks. The invention allows handling of alarms in the management systems which achieve functions of various management levels, for example network element management or network management. As a rule there are a large number of network element managers (for example OMCs) and a large number of network managers (for example NMCs) present.
The method according to the invention can, in principle, be used for all telecommunications networks. This expressly also includes precisely those telecommunications networks that are not cable-dependent as mobile communications networks in particular require effective fault management.
Alarms incoming from a network element are received in the element manager in its logical functional part in accordance with the management functionality as a network element manager and are passed, prior to forwarding to the network manager, to the logical functional part in accordance with the management functionality as an agent with respect to the network manager. Information on the alarm can be stored in both logical functional parts. The alarm is not necessarily forwarded from the element manager for all alarms, but, as a rule, for those alarms which are relevant to the network manager. These alarms are mapped onto a functional object class in the element manager prior to forwarding to the network manager. Sending to the network manager preferably takes place substantially in real time, i.e. without excessively long delays. As a rule the alarm is forwarded to the network manager via a filtering device (for example EFD). Sending to the network manager can take place by means of filtering devices that can be adjusted and/or varied in terms of their activity. In
particular the effect of the filtering devices can for example be configured so as to be adjustable and/or variable primarily with respect to the management system. What is known as an Event Forwarding Discriminator (EFD) can preferably be used as the filtering device in the context of the invention. The object of the filtering device in this functionality (event reporting according to ITU-T X.734) is to route to the manager only those event reports which satisfy specific filter criteria. In this case the manager is capable of creating or deleting EFDs of this type in the agent and of establishing the filtering criteria (via the discriminatorConstruct attribute). As a result, each manager can at any time control the flow of information according to its individual requirements. The filtering device in the element manager can conventionally be created or deleted with respect to its activity content by the network manager, and/or can be established with respect to its filtering criteria by the network manager.
In an advantageous embodiment of the invention information relating to the content of the alarm incoming at the element manager and/or of the alarm mapped onto a functional object class while taking the object model into consideration at the interface between network manager and element manager is at least intermittently stored in the element manager. Use is preferably made of both of said possibilities. With respect to the second of said possibilities, this means that alarms incoming at the element manager (for example OMC) as event reports are advantageously converted to the respectively corresponding functional object class according to the information model of the interface between element manager (in its function as an agent) and network manager (for example NMC in its function as a manager).
In particular the at least intermittently stored information can include an alarm list for alarms incoming at the element manager and an alarm list for alarms mapped onto a functional object class while taking the object model into consideration at the interface between network manager and element manager.
The information stored in the element manager relating to the content of the alarm incoming at the element manager and/or of the alarm mapped onto a functional object class while taking the object model into consideration at the interface between network manager and element manager is preferably at least partially used during synchronisation by means of the uniform operation.
In a development of the invention an object instance is transmitted as a reference instance for the functional object class, onto which the alarm was mapped while taking the object model into
consideration at the interface between network manager and element manager, from the network manager to the element manager for synchronisation by means of the uniform operation in the element manager. For this purpose, in particular the alarms incoming at the element manager are converted to the respectively corresponding functional object class according to the information model of the interface between element manager and network manager.
This method can be developed further in that while taking into consideration the information stored in the element manager relating to the content of the alarm incoming at the element manager and/or of the alarm mapped onto a functional object class while taking the object model into consideration at the interface between network manager and element manager, return mapping onto an object instance of the object model takes place at the interface between element manager and network element during synchronisation.
In particular it may be provided that during synchronisation one, a plurality of, or all object instances, which in the object tree of the object model at the interface between element manager and network element below the object instance according to the object model at the interface between element manager and network element, corresponding to the reference instance according to the object model at the interface between network manager and element are also taken into consideration.
The method according to the invention in particular has the following advantages:
- the method defines a uniform, optimised mechanism for synchronising a plurality of alarms at the
EM level according to different processing thereof at the MM level. Both the processing output in the
agent (OMC) and the throughput of the NM-EM management interface is much improved.
- processing (can also be called a "mapping function"), which can be used for both communications
directions (i.e. from element manager to network manager and in the reverse direction from network
manager to element manager), of alarms while taking into consideration different object models in a
management hierarchy is used as the basis of the method.
The element manager according to the invention of a management system of a communications network for handling alarms is constructed in the management system of the communications system as one of at least two management systems of the management network at various management levels
such that, in its function as an agent, the element manager can be allocated a network manager. According to the invention, in the element manager there are
- means for mapping an alarm onto a functional object class while taking an object model into
consideration at the interface between network manager and element manager
- means for forwarding the alarm from the element manager to the network manager and
- means for synchronising the alarm status between network manager and element manager in the
element manager using an operation that is uniform for the interface between network manager and
element manager in the communications system after handling of the alarm in the network manager.
Means for at least intermittent storing of information relating to the content of the alarm incoming at the element manager and/or of the alarm mapped onto a functional object class while taking the object model into consideration at the interface between network manager and element manager can also be provided.
The element manager can also include means for sending alarms incoming at the element manager to the network manager.
The element manager can, in particular, comprise filtering devices that are adjustable and/or variable in terms of their activity.
Finally, the element manager can contain means for receiving an object instance as a reference instance for the functional object class, onto which the alarm was mapped while taking the object model into consideration at the interface between network manager and element manager, of the alarm handled in the network manager for synchronisation by means of the uniform operation by the network manager.
The element manager can be equipped with further means for carrying out the above-described method.
The communications system according to the invention for handling alarms via a management network comprising at least two management systems at various management levels is configured in such a way that at least one of the at least two management systems functions as an element manager and at least one of the at least two management systems functions as a network manager allocated to and of a higher order than the element manager in its function as an agent. It can comprise means for
carrying out the above-described method. In particular it can contain an element manager as described above.
The invention will be described in more detail hereinafter using embodiments and with reference to figures, in which:
Fig. 1 shows a block diagram of a management network for a communications system with agent-manager relationship between network elements, operation and maintenance centres and a network management centre,
Fig. 2 shows a schematic diagram of a management network detail for a communications system with agent-manager relationship between a network element, an operation and maintenance centre and a network management centre with alarm conversion between the interface between element manager and network element and the interface between network manager and element manager,
Fig. 3 shows an example of a flowchart of a uniform operation according to the invention for the interface between network manager and element manager in the communications system,
Fig. 4 shows an example of a hierarchical object tree structure and
Fig. 5 shows a schematic diagram of a management network detail for a communications system with agent-manager relationship between a network element, an operation and maintenance centre and a network management centre with synchronisation of alarms after handling thereof in the network manager.
Fig. 1 shows the block diagram of a management network for a mobile communications system with agent-manager relationship between operation and maintenance centres OMC1; OMC2 to OMCN and network elements NE on the one hand, and a network management centre NMC and the operation and maintenance centres OMCb OMC2 to OMCN on the other hand. Fig. 1 shows a diagram with three management levels NM LEVEL, EM LEVEL and NE LEVEL.
The EM LEVEL management level characterises the network element management level, in which operation and maintenance centres OMC1; OMC2 to OMCN in each case provide the manufacturer-specific management functionality for, by way of example, base station systems (for example BSSj to
BSSp with base station systems in a number from 1 to P) not shown in the NE LEVEL management level in Fig. 1.
The NM LEVEL management level characterises the network management level at which the network management centre NMC produces an integrated management functionality that is independent of the manufacturer. In principle there can be a plurality of network management centres NMC at the NM LEVEL management level. Defined interfaces for information transmission are provided between the elements of different management levels.
Operation and maintenance centres OMQ, OMC2 to OMCN are connected to the network management centre NMC via an (for example, real time) interface NM-EM. The network management centre NMC is logically connected to the NMC agents of the operation and maintenance centres OMCl5 OMC2 to OMCN. Each of the operation and maintenance centres OMC], OMC2 to OMCN also logically comprises an NE manager (shown in Fig. 2 but not in Fig. 1) for the interface EM-NE to the network elements NE. Filtering devices Filters for the transmission of alarm reports to the operation and maintenance centres OMC], OMC2 to OMCN can be provided in the network elements NE as shown in Fig. 1.
With regard to the method according to the invention, the alarm conversion between the interface EM-NE and the interface NM-EM, and Fig. 2 will be described hereinafter with reference to a specific example.
The handling of alarms (alarm surveillance), as one of the most important functions of network monitoring and control, takes place at the network management level (at NM level for example in the network management centre NMC) primarily with the aid of the alarm list. Firstly alarm information (insert original alarm) is stored in the logical part NE manager of the operation and maintenance centre OMC in an alarm list "Original alarm list". While taking into consideration the object model at the interface NM-EM, each operation and maintenance centre OMC must produce a Mapping function which converts all alarms relevant to the network management centre NMC from the network elements ("Original" alarm) to the respective corresponding functional object instance. Accurate information from the alarm that originally entered the operation and maintenance centre OMC, primarily with respect to the network resource that originally failed, is written from the operation Mapping function, as additional information, into the mapped or derived alarm list Mapped alarm list (for example in one of the standardised alarm parameters additionalText or additionallnformation),
storing of the mapped alarm in the alarm list Mapped alarm list of the NMC agent being indicated by the operation insert mapped alarm in Fig. 2. It may advantageously be provided that details on the object model, at the interface NM-EM, with respect to mapping by means of the Mapping function can be inferred from or stored in a Mapping table.
As the interface between NMC and the regional operation and maintenance centre OMC must be manufacturer-independent, the Information model of this management interface NM-ME contains only functional object classes (MOC Management Object Class) as follows: on the one hand these are what are known as logical object classes which model the functions of the telecommunications network. Examples of logical MOCs of this type in a GSM mobile communications network are BSC, BtsSiteManager or transcoder. On the other hand, a prerequisite of optimal network management is that there should also be information, such as alarms for the readiness for service of the hardware of the network units, at the network management centre NMC. This information should allow the NMC operator to correctly assess the significance of hardware failures for the functionality of an entire network unit in order to initiate appropriate repair measures. This applies primarily if the operation and maintenance centres OMC], OMC2 to OMCN are idle and the mobile communications network is only being monitored from the network management centre NMC.
To make network monitoring at a higher-order network management centre NMC possible (primarily during the time when operation and maintenance centres OMCl5 OMC2 to OMCN are idle, for example at night or at weekends), as already stated above, each manufacturer-specific operation and maintenance centre OMC must contain a Mapping function which converts all event reports, such as alarms from the network elements NE, relevant to the network management centre NMC into the respective corresponding functional object class according to the Information model of the OMC-NMC interface NM-EM. Accurate information from the original alarm report, generated in the network element NE (for example details about manufacturer-specific data, such as board type, board number, etc.), is contained as additional information (for example in the standardised parameters additionalText or additionallnformation) in the mapped alarm report (which can also be called a "mediated" alarm report).
The mapped or converted alarm reports are then routed onwards to the NMC's own filtering device EFD in the logical part of the NMC agent of the operation and maintenance centre OMC.
This is shown in Fig. 2 in a schematic diagram of the management network detail for a communications system with agent-management relationship between network elements NE, an operation and maintenance centre OMC and a network management centre NMC. This original alarm report from the network elements NE ("Original" alarm) is, for example, stored in the operation and maintenance centre OMC as an element manager, converted into functional object classes with the Mapping function and sent to the network management centre NMC as a mapped alarm by using the filtering device EFD that can be adjusted and/or varied in terms of its activity. The mapped alarm is stored in the network management centre in an alarm list Mapped alarm list of the network management centre NMC via the operation insert mapped alarm.
The different object trees (containment trees) shown in Fig. 2 in their differing structures at the interfaces EM-NE and NM-EM, form the basis for the conversion of alarms via the Mapping function. As at the interface EM-NE modelling of network resources must naturally be more detailed (manufacturer-specific resources are also managed here), the object tree of the interface EM-NE contains many more object classes than at the interface NM-EM. As a result the alarms are in most cases converted via an n ? 1 relationship, i.e. alarm reports of a plurality of object classes of a lower order in the EM-NE object tree hierarchy, can be converted into alarms of a single object class at the interface NM-EM.
At the network management level (NM LEVEL according to Fig. 1), the mapped alarms of NMC operators can be handled differently, for example as follows:
- the alarm is acknowledged (alarm acknowledgement), i.e. the alarm was acknowledged and repair
measures were optionally initiated. Accidental alarm acknowledgement can be cancelled in this case
by the same NMC operator (alarm unacknowledgement).
- the alarm is manually deactivated by the operator (alarm clearing), for example if the cause of an
alarm has been remedied, without it being possible for a corresponding event report to be generated
by the network element NE.
- comments (alarm comments) are allocated to an alarm, for example to make better coordination
between operators possible.
The status of alarms which were handled at the NM level (MM LEVEL), must subsequently be synchronised at the EM level (EM LEVEL). This automatic synchronisation is primarily important in the case of an OMC operator shift change (for example each morning, when the operation and maintenance centres OMC are busy again), so the OMC operators can obtain correct mapping of the alarm situation in the network.
The method according to the invention and described in more detail in the exemplary embodiment can basically be applied to all manager-agent interfaces. It will be described hereinafter by way of example with statements about a CMIP-based NMC-OMC interface NM-EM. However, the method can equally be used in an appropriately adjusted form when using other interface protocols (for example SNMP or CORBA).
In the process synchronising of alarms with multiple object selection will be looked at by way of example hereinafter and described in Fig. 3.
A uniform operation alignAlarmsStatus is carried out at the interface NM-EM for synchronising alarm statuses of various object instances (for example in a CMIP-based management interface with the aid of the M-ACTION service according to ITU-T X. 710 standard).
This uniform operation alignAlarmsStatus shown in its sequence in Fig. 3, includes at least two communications portions, namely a request portion (operation request) of the operation alignAlarmsStatus from the network management centre NMC to the operation and maintenance centre OMC and a response portion (operation response) of the operation alignAlarmsStatus from the operation and maintenance centre OMC to the network management centre NMC.
The operation request of the uniform operation alignAlarmsStatus is advantageously determined by the following parameters:
> operationType:
This parameter defines the type of alarm synchronisation required at the operation and maintenance centre OMC (ack, unack, clear, comment).
> baseMOI:
This parameter identifies a reference instance as a starting point in the object tree of the interface NM-EM for synchronising the alarm states. All alarms
sought are based on this reference instance and optionally - depending on the value of the subsequent parameter choice - on further instances that are of a lower-order in the object tree.
> choice:
This parameter, starting from the above-mentioned reference instance, specifies for which network resources, which are of a lower order in the object tree of the interface NM-EM, the alarm states in the OMC should be synchronised. The parameter can assume to following values:
- a value wholeSubtree:
The alarms originating from the reference instance and all objects subordinate to this instance in the object tree are considered.
- a value levelNumber.
Only those alarms which were generated by the objects subordinate to the reference instance at the level n are considered (note: the reference-object instance is defined, for example, as level 0 and each level present in the object tree with subordinate objects is given a natural number n in accordance with its level). This value can only be used if there are equivalent object classes at level n according to the value of the parameter levelNumber in both object trees at the interfaces NM-EM and EM-NE.
>• commentText:
This optional parameter (this is illustrated by the square brackets in Fig. 3) is only used if the above-mentioned parameter operationType has the value comment and specifies an operator note which should be allocated to the selected alarm.
The operation response of the uniform operation alignAlarmsStatus is advantageously determined by the following parameter:
> status:
This parameter contains the result of the execution of the alarm synchronisation at the operation and maintenance centre OMC.
The parameter choice of the operation request of the uniform operation alignAlarmsStatus can assume the values wholeSubtree_and levelNumber. Fig. 4 provides an example in this regard, a hierarchy of an object tree that is applicable to both interfaces NM-EM and EM-NE being shown. In principle, the object tree at the interface NM-EM is contained in the object tree at the interface EM-NE with the same hierarchy.
The hierarchy with the following increasing hierarchy levels is given in the example shown in Fig. 4:
? bssFunction (BSS Function instance)
? bsc (BSC instance)
? btsSiteManager (BTS SiteManager instance)
? bts (BTS instance)
? transceiver (Transceiver instance).
Assuming that the parameter baseMOI = btsSiteManager: 3 (i.e. BTS SiteManager instance with number 3) and the parameter choice = levelNumber (2) (i.e. only those alarms which were generated by the objects subordinate to the reference instance at level 2 are considered), for the illustrated embodiment this means that the alarms of all transceiver instances present in the object tree below the instance btsSiteManager: 3(BTS SiteManager instance with number 3) are considered in this example.
After receiving the request (Operation request) illustrated in Fig. 3 of the uniform operation alignAlarmsStatus, the status of all alarms selected at the network management centre NMC is synchronised in the operation and maintenance centre OMC both in the alarm list "Mapped alarm list" of the NMC agent and in the alarm list "Original alarm list" of the NE manager according to the parameter value operationType, with the following meanings:
• ack: all alarms are automatically set to the "acknowledged" state,
• unack: all alarms are automatically reset to the "unacknowledged" state,
• clear. all alarms are automatically "cleared". Those alarms which had already been
acknowledged are removed from the alarm list.
• comment: each alarm is allocated an operator note.
The agent subsequently sends a response (Operation response) to the manager (NMC) which contains the result of the execution.
In conjunction with Fig. 5 an application example for alarm synchronisation with alarm acknowledgement in the OMC is described hereinafter, the OMC synchronising the status of the alarm acknowledgement ("acknowledgementState").
It is assumed that a base station system (for example BSS Function Instance no. 17 'bssFunction: 17') is repaired and as a result a relatively large number of associated alarms is displayed at the network management centre NMC. The NMC operator (who knows the reason for the occurrence of these alarms) has selected and acknowledged all alarms originating from this BSS network element.
The NMC subsequently sends an operation request of the uniform operation alignAlarmsStatus to the operation and maintenance centre OMC monitoring said base station, with the following parameter values:
• operationType = ack
• baseMOI = bssFunction: 17
• choice = wholeSubtree
The optional parameter commentText is not used in this example.
In the operation and maintenance centre OMC, the NMC agent executes the following steps:
a) Alarms of which the object instance (parameter MOI) contains the component (what is known
as "relative distinguished name") bssFunction: 17 are sought in the alarm list "Mapped alarm list". In
each mapped alarm found, the object instance of the original BSS alarm (original MOIk) is
determined from the parameter additionalText (or additionallnformation).
b) All alarms found in the alarm list "Mapped alarm list" of the NMC agent are automatically
acknowledged. If a currently acknowledged alarm is no longer active, it is automatically removed
from the alarm list "Mapped alarm list" of the NMC agent.
c) Once all the original object instances of the alarm have been found, the NMC agent sends an internal command scopedAlarmsHandling to the NE manager in the operation and maintenance centre OMC, with the following parameter values:
- operationType'. ack
- objectlnstanceList:
This parameter specifies a sequence of object instances at the interface EM-NE, of which the alarms should be acknowledged (origMOI),..., origMOIn).
(A parameter comment could also optionally be provided for commenting).
After receiving the command scopedAlarmsHandling, the NE manager of the operation and maintenance centre OMC executes the following steps:
a) for each object instance origMOIk (k = 1.. .n): all alarms in the alarm list "Original alarm list"
of the NE manager, of which the object instance (parameter MOI) contains the "relative distinguished
name" value of the object instance origMOIk, are automatically acknowledged. This has the
following advantage: alarms from the object instance origMOIk, which had been intentionally filtered
out by the NMC's own filter (for example because these alarms are less relevant to the NMC
operator), are thus also acknowledged.
b) If an acknowledged alarm is no longer active, it is automatically removed from the alarm list
"Original alarm list" of the NE manager.
An alarm acknowledgement by the NMC operator was described above by way of example. The procedure applies analogously to other types of handling of a plurality of alarms at the network management centre NMC accordingly.



WE CLAIM;
1. Method for handling alarms via a management network of a communications system, the
management network comprising at least two management systems (NMC, OMC], OMC2, OMCN;
OMC) at various management levels, at least one of the at least two management systems functioning
as network elements (NE) of higher order element managers (OMC1, OMC2, OMCN; OMC) and at
least one of the at least two management systems functioning as network managers (NMC) allocated
to and of a higher order than the element manager (OMC1 OMC2, OMCN; OMC) in its function as an
agent, characterized in that an alarm is mapped onto a functional object class in the element manager
(OMC1, OMC2, OMCN; OMC) while taking an object model into consideration at the interface (NM-
EM) between network manager (NMC) and element manager (OMC1; OMC2, OMCN; OMC), in that
the alarm is forwarded from the element manager (OMCl5 OMC2, OMCN; OMC) to the network
manager (NMC), in that the alarm is handled in the network manager (NMC), in that a
synchronisation of the alarm status of the alarm, set by the network manager, between network
manager (NMC) and element manager (OMCb OMC2, OMCN; OMC) takes place in the element
manager (OMCls OMC2, OMCN; OMC) using an operation (alignAlarmsStatus) that is uniform for
the interface (NM-EM) between network manager (NMC) and element manager (OMCj, OMC2,
OMCN; OMC) in the communications system.
2. Method according to claim 1, characterized in that information relating to the content of the
alarm incoming at the element manager (OMC1, OMC2, OMCN; OMC) and/or of the alarm mapped
onto a functional object class while taking the object model into consideration at the interface (NM-
EM) between network manager (NMC) and element manager (OMQ, OMC2, OMCN; OMC) is at
least intermittently stored in the element manager (OMC1, OMC2, OMCN; OMC).
3. Method according to claim 2, characterized in that the at least intermittently stored
information includes an alarm list (Original alarm list) for alarms incoming at the element manager
(OMC1, OMC2, OMCN; OMC) and an alarm list (Mapped alarm list) for alarms mapped onto a
functional object class while taking the object model into consideration at the interface (NM-EM)
between network manager (NMC) and element manager (OMC], OMC2, OMCN; OMC).
4. Method according to either claim 2 or claim 3, characterized in that the information stored in
the element manager (OMC1, OMC2, OMCN; OMC) relating to the content of the alarm incoming at
the element manager (OMC1 OMC2, OMCN; OMC) and/or of the alarm mapped onto a functional
object class while taking the object model into consideration at the interface (NM-EM) between network manager (NMC) and element manager (OMC1, OMC2, OMCN; OMC) is at least partially used during synchronisation by means of the uniform operation (alignAlarmsStatus).
5. Method according to any one of claims 2, 3 or 4, characterized in that an object instance is
transmitted as a reference instance for the functional object class, onto which the alarm was mapped
while taking the object model into consideration at the interface (NM-EM) between network manager
(NMC) and element manager (OMC1, OMC2, OMCN; OMC), from the network manager (NMC) to
the element manager (OMC1, OMC2, OMCN; OMC) for synchronisation by means of the uniform
operation (alignAlarmsStatus) in the element manager (OMC1, OMC2, OMCN; OMC).
6. Method according to claim 5, characterized in that while taking into consideration the
information stored in the element manager (OMC1 OMC2) OMCN; OMC) relating to the content of
the alarm incoming at the element manager (OMC1, OMC2, OMCN; OMC) and/or of the alarm
mapped onto a functional object class while taking the object model into consideration at the interface
(NM-EM) between network manager (NMC) and element manager (OMC1, OMC2, OMCN; OMC),
return mapping onto an object instance of the object model takes place at the interface (ME-NE)
between element manager (OMC1; OMC2, OMCN; OMC) and network element (NE) during
synchronisation. . • • -
7. Method according to claim 6, characterized in that during synchronisation one, a plurality of,
or all object instances, which in the object tree of the object model at the interface (ME-NE) between
element manager (OMC1 OMC2, OMCN; OMC) and network element (NE) below the object instance
according to the object model at the interface (ME-NE) between element manager (OMC1, OMC2,
OMCN; OMC) and network element (NE), corresponding to the reference instance according to the
object model at the interface (NM-EM) between network manager (NMC) and element manager
OMC1, OMC2, OMCN; OMC), are also taken into consideration.
8. Element manager (OMC1, OMC2, OMCN; OMC) of a management system of a
communications network for handling alarms in the management system of the communications
network as one of at least two management systems (NMC, OMC1, OMC2, OMCN; OMC) of the
management network at various management levels, it being possible to allocate a network manager
(NMC) to the element manager (OMC1 OMC2, OMCN; OMC) in its function as an agent,
characterized in that there are means (Mapping function) for mapping an alarm onto a functional
object class while taking an object model into consideration at the interface (NM-EM)between network manager (NMC) and element manager (OMC1, OMC2, OMCN; OMC), in that means (EFD) for forwarding the alarm from the element manager (OMC1, OMC2, OMCN; OMC) to the network manager (NMC) are provided, and in that there are means (Mapping function) for synchronising the alarm status of the alarm, set by the network manager (NMC), between network manager (NMC) and element manager (OMC1, OMC2, OMCN; OMC) in the element manager (OMC1, OMC2, OMCN; OMC) using an operation (alignAlarmsStatus) that is uniform for the interface (NM-EM) between network manager (NMC) and element manager (OMC1; OMC2, OMCN; OMC) in the communications system after handling of the alarm in the network manager (NMC).
9. Element manager (OMC,, OMC2, OMCN; OMC) according to claim 8, characterized in that
there are means (Original alarm list, Mapped alarm list) for at least intermittent storing of
information relating to the content of the alarm incoming at the element manager (OMC1, OMC2,
OMCN; OMC) and/or of the alarm mapped onto a functional object class while taking the object
model into consideration at the interface (NM-EM) between network manager (NMC) and element
manager (OMC1, OMC2, OMCN; OMC).
10. Element manager (OMC1, OMC2, OMCN; OMC) according to claim 8, characterized in that
means (Original alarm list, Mapped alarm list) are provided for receiving an object instance as a
reference instance for the functional object class, onto which the alarm was mapped while taking the
object model into consideration at the interface (NM-EM) between network manager (NMC) and
element manager (OMC1, OMC2, OMCN OMC), of the alarm handled in the network manager
(NMC) for synchronisation by means of the uniform operation (alignAlarmStatus) by the network
manager (NMC).
11. Element manager (OMC1; OMC2, OMCN; OMC) according to either claim 8 or claim 9,
characterized in that the element manager (OMC,, OMC2, OMCN; OMC) includes means for carrying
out the method according to any one of claims 3, 4, 6 and 7.
12. Communications system for handling alarms via a management network comprising at least
two management systems (NMC, OMC,, OMC2, OMCN; OMC) at various management levels, at
least one of the at least two management systems functioning as an element manager (OMC,, OMC2,
OMCN; OMC) and at least one of the at least two management systems functioning as a network
manager (NMC) allocated to and of a higher order than the element manager (OMC,, OMC2, OMCN;
OMC) in its function as an agent, characterized in that means are provided for carrying out the method according to any one of claims 1 to 7.
13. Communications system according to claim 12, characterized in that it includes an element
manager (OMC1, OMC2, OMCN; OMC) according to claim 8, 9, 10 or 11.
14. Method for handling alarms via a management network of a communications system,
substantially as hereinbefore described with reference to the accompanying drawings.
15. Element manager, substantially as hereinbefore described with reference to the
accompanying drawings.
16. Communications system for handling alarms via a management network, substantially as
hereinbefore described with reference to the accompanying drawings.

Documents:

1520-delnp-2006-Abstract-(22-07-2013).pdf

1520-delnp-2006-abstract.pdf

1520-delnp-2006-Claims-(01-09-2014).pdf

1520-delnp-2006-Claims-(02-09-2014).pdf

1520-delnp-2006-Claims-(22-07-2013).pdf

1520-delnp-2006-claims.pdf

1520-delnp-2006-Correspondence Others-(01-09-2014).pdf

1520-delnp-2006-Correspondence Others-(02-09-2014).pdf

1520-delnp-2006-Correspondence-Others-(22-07-2013).pdf

1520-delnp-2006-correspondence-others-1.pdf

1520-delnp-2006-correspondence-others.pdf

1520-delnp-2006-description (complete).pdf

1520-delnp-2006-drawings.pdf

1520-delnp-2006-form-1.pdf

1520-delnp-2006-form-13.pdf

1520-delnp-2006-form-18.pdf

1520-delnp-2006-Form-2-(01-09-2014).pdf

1520-delnp-2006-Form-2-(02-09-2014).pdf

1520-delnp-2006-Form-2-(22-07-2013).pdf

1520-delnp-2006-form-2.pdf

1520-delnp-2006-Form-3-(22-07-2013).pdf

1520-delnp-2006-form-3.pdf

1520-delnp-2006-form-5.pdf

1520-delnp-2006-gpa.pdf

1520-delnp-2006-pct-304.pdf

1520-delnp-2006-Petition-137-(22-07-2013).pdf


Patent Number 263173
Indian Patent Application Number 1520/DELNP/2006
PG Journal Number 42/2014
Publication Date 17-Oct-2014
Grant Date 13-Oct-2014
Date of Filing 21-Mar-2006
Name of Patentee SIEMENS AKTIENGESELLSCHAFT
Applicant Address WITTELSBACHERPLATZ 2, 80333 MUNCHEN, GERMANY.
Inventors:
# Inventor's Name Inventor's Address
1 LUCIAN HIRSCH DRACHENSEETR. 3, 81373, MUNCHEN, GERMANY.
PCT International Classification Number H04L 12/24
PCT International Application Number PCT/EP2004/052297
PCT International Filing date 2004-09-24
PCT Conventions:
# PCT Application Number Date of Convention Priority Country
1 10345881.6 2003-09-30 Germany