DE19740716C2 - Verfahren zum Behandeln von in Kommunikationssystemen von einem hardwarebezogenen gemanagten Objekt generierten Alarmen - Google Patents

Description

Die Erfindung betrifft ein Verfahren zum Behandeln von in Kommunikationssystemen von einem hardwarebezogenen gemanagten Objekt generierten Alarmen nach dem Oberbegriff des Anspru­ ches 1. Insbesondere betrifft sie das Behandeln solcher Alarme innerhalb des Basisstationssubsystems eines Mobilfunk­ systems.

Aus der WO 94/11970 A1 ist ein Management-System für Einrichtungen innerhalb eines Netzwerkes, insbesondere eines Telekommunikations-Netzwerkes, bekannt, bei dem die Einrichtungen von einem Equipmentmanager mittels eines Equipment-Kontrollers überwacht und kontrolliert werden.

Aus der WO 94/23514 A1 ist ein allgemeines Modell für das Management von Objekten eines Netzwerkes (Local area network LAN) mit einem angeschlossenen Elementmanager im Zusammenhang mit Routern und Protokollen bekannt, wobei ein Netzwerk- Manager einem Benutzer des Systems erlaubt, einen Router durch Anweisungen beim Netzwerkmanager zu kontrollieren und Informationen zu Status, Konfiguration und/oder Leistung zu betrachten.

Aus diesen Dokumenten kann ein Verfahren zum Behandeln eines Alarms abgeleitet werden, welcher in einem Kommunikations­ system von einer Instanz eines hardwarebezogenen gemanagten Objekts generiert wird, wenn durch den Alarm Statusänderungen mehrerer Instanzen gemanagter Objekte bedingt sind, wobei das Auftreten des Alarms durch einen Fehlerereignisreport gemeldet wird an eine übergeordnete Netzeinrichtung, welcher auch die durch den Alarm bedingten Statusänderungen mitgeteilt werden.

Gemäß der ITU-T Recommendation X.733 mit dem Titel "Systems Management: Alarm Reporting Function" ist ein Alarm ein Feh­ ler oder anormale Bedingungen betreffendes spontanes Ereig­ nis. Für das Management von Telekommunikations-Netzen wie zum Beispiel Mobilfunknetzen definieren die ITU-T Recommendatio­ nen der Serie X.73x unterschiedliche Systemmanagementfunktio­ nen, sogenannte "Systems Management Functions", die von Applikationsprozessen in einer zentralisierten oder dezentra­ lisierten Managementumgebung benutzt werden können. So wie die Recommendation ITU-T X.733 sich mit dem Behandeln von Alarmreportfunktionen beschäftigt, empfiehlt die Recommenda­ tion ITU-T X.731 mit dem Titel "Systems Management: State Management Function" das Behandeln von Statusmanagementfunk­ tionen.

Da die vorliegende Erfindung sich insbesondere für Mobilfunk­ systeme empfiehlt und weiter unten auch an Hand eines Subsy­ stems eines Mobilfunksystems beschrieben wird, werden zuerst die Besonderheiten eines Mobilfunksystems, also eines Mobil­ funknetzes am Beispiel eines GSM-Netzes gemäß dem ETSI-Stan­ dard GSM beschrieben. Ein Mobilfunksystem ist ein hierar­ chisch gegliedertes System verschiedener Netzelemente, bei dem die unterste Hierarchiestufe von den Mobiltelefonen geb­ ildet wird, die nach dem englischsprachigen Ausdruck "Mobile Station" auch mit MS bezeichnet werden. Diese Mobiltelefone kommunizieren über eine sogenannte Um-Schnittstelle oder Funkschnittstelle mit die nächste Hierarchieebene bildenden Funkbasisstationen, die auch als Basisstation bzw. nach dem englischsprachigen Ausdruck "Base Transceiver Station Equip­ ment" mit BTSE bezeichnet werden.

Zur Steuerung des Datenverkehrs zwischen den Basisstationen, sind diese gebietsweise zusammengefaßt. Die hierzu vorgesehe­ nen übergeordneten Netzelemente werden mit Basisstations­ steuereinheit oder gemäß dem englischsprachigen Ausdruck "Base Station Controller" mit BSC bezeichnet. Die Basissta­ tionen kommunizieren über eine sogenannte Abis-Schnittstelle mit den Basisstationssteuereinheiten. Einer Basisstations­ steuereinheit kann gegebenenfalls zur Optimierung der Daten­ kommunikation eine Transcodier- und Ratenanpaßeinheit zuge­ ordnet sein, die nach dem englischsprachigen Ausdruck "Transcoder and Rate Adapter Unit" auch mit TRAU bezeichnet wird. Die Basisstationen, die Basisstationssteuereinheiten und die Transcodier- und Ratenanpaßeinheiten bilden ein Ba­ sisstationssubsystem des Mobilfunksystems, das nach dem eng­ lischsprachigen Ausdruck "Base Station Subsystem" auch mit BSS bezeichnet wird oder als Radiosubsystem. Basisstationen, Basisstationssteuereinheiten und Transcodier- und Ratenan­ paßeinheiten sind hierbei Netzeinrichtungen des Basissta­ tionssubsystems.

Die Basisstationssteuereinheiten kommunizieren über soge­ nannte A-Schnittstellen mit einer oder einigen wenigen Mobil­ vermittlungseinrichtungen, die nach dem englischsprachigen Ausdruck "Mobile Switching Centers" auch mit MSC bezeichnet werden und über die u. a. auch der Übergang in andere Telefon­ netze erfolgt. Die Mobilvermittlungseinrichtungen bilden ge­ meinsam mit einigen Datenbanken das Vermittlungssubsystem, das nach dem englischsprachigen Ausdruck "Network Switching Subsystem" auch mit NSS bezeichnet wird.

Da die vorliegende Erfindung zwar auf standardisierten Rege­ lungen aufbaut, ein erfindungsgemäßes Verfahren jedoch, wie später zu erkennen ist, nur im Bereich von Netzelementen ein­ gesetzt werden kann, die zur Durchführung des Verfahrens mo­ difiziert sind, bietet sich die Anwendung in Mobilfunknetzen deshalb an, weil diese in Subsysteme gegliedert sind, wobei üblicherweise ein Subsystem immer komplett eingerichtet wird und ggf. auch noch von einem Lieferanten bezogen wird. Die Steuerabläufe und Protokolle können folglich auch innerhalb eines bestehenden Mobilfunksystem in einem Subsystem, bei­ spielsweise einem Basisstationssubsystem derart ausgestaltet sein, daß das Behandeln der von einem hardwarebezogenen gema­ nagten Objekt generierten Alarme innerhalb des Subsystems ge­ mäß der nachstehend noch zu beschreibenden Erfindung und in Bezug zum Gesamtsystem oder zu anderen Subsystemen gemäß in­ ternationalen Standards erfolgt.

Neben den bisher beschriebenen Netzelementhierarchien steht ein Betriebs- und Wartungssystem, das gemäß dem englischspra­ chigen Ausdruck "Operation and Maintenance Subsystem" auch mit OMS bezeichnet wird. Das Betriebs- und Wartungssystem dient zum Konfigurieren und Überwachen aller Netzelemente. Überwachungsmaßnahmen und Konfigurierungsmaßnahmen werden hierzu meist von Betriebs- und Wartungszentren aus fernge­ steuert, die gemäß dem englischsprachigen Ausdruck "Operation and Maintenance Centers auch mit OMC bezeichnet werden und sich üblicherweise im Bereich von Mobilvermittlungseinrich­ tungen befinden.

Aufgabe des Betriebs- und Wartungssystems ist die Durch­ führung des Kommunikationsnetzmanagements einschließlich ei­ nes Konfigurationsmanagements, das nach dem englischspra­ chigen Ausdruck "Configuration Management" auch mit CM be­ zeichnet wird und einen von fünf Managementfunktionsbereichen dargestellt, die die Telekommunikationsmanagementnetz- Prinzipien identifizieren. Das Konfigurationsmanagement defi­ niert eine Reihe von Diensten, die eine Änderung der Struktur und damit des Verhaltens eines Telekommunikationsnetzes durch den Bediener ermöglichen. Diese Dienste beziehen sich immer auf Instanzen von gemanagten Objekten, die insgesamt die netzspezifische Managementinformationsbasis MIB bilden.

Ein gemanagtes Objekt im Sinne des Kommunikationsnetzmanage­ ments ist eine logische Abstraktion einer Ressource im Kommu­ nikationsnetz, beispielsweise im Mobilfunknetz. Hierbei wird unterschieden zwischen hardwarebezogenen gemanagten Objekten, die eine herstellerspezifische Realisierung einer Funktion beschreiben und zwischen funktionsbezogenen gemanagten Ob­ jekten, bei denen es sich jeweils um die Abstraktion einer herstellerunabhängigen Funktionalität handelt. Gemanagten Objekte werden nach dem englischsprachigen Ausdruck "Managed Object" auch mit MO bezeichnet, wobei jede Objektkategorie auch mit Klasse gemanagter Objekte oder nach dem englischsprachigen Ausdruck "Managed Object Class" auch mit MOC bezeichnet wird. Zu jeder MOC gibt es mehrere Instanzen gemanagter Objekte, die jeweils einer spezifischen Funktion oder Einrichtung zugeordnet sind und auch nach dem englischsprachigen Ausdruck "Managed Object Instance" mit MOI bezeichnet werden. Nachstehend werden Klassen bzw. Instanzen hardwarebezogener gemanagter Objekte mit HW-bezogene MOC bzw. HW-bezogene MOI bezeichnet. Entsprechend werden Klassen bzw. Instanzen funktionsbezogener gemanagter Objekte mit funk­ tionsbezogene MOC bzw. funktionsbezogene MOI bezeichnet.

Die Recommendation ITU-T X.710 mit dem Titel "Common Management Information Service definition for CCITT Applications", definiert den Managementnotifikationsdienst (Management Notification Service) M-EVENT-REPORT, der sowohl innerhalb von Basisstationssubsystemen als auch zwischen Ba­ sisstationssubsystem und Wartungszentren von Betriebs- und Wartungssystemen eingesetzt wird für die Übermittlung von spontane Ereignisse, wie Alarme betreffende Information in Form von Fehlerereignisreports, die auch (nach dem englisch­ sprachigen Ausdruck "Failure Event Report") FER genannt werden bzw. für die Übermittlung von Statusänderungen in Form von Statusänderungsereignisreports, die auch (nach dem eng­ lischsprachigen Ausdruck "Changed State Event Reports") CSER genannt werden.

In Basisstationssubsystemen werden die Alarme fast aus­ schließlich von hardwarebezogenen gemanagten Objekten, d. h. durch Hardwarefehler, generiert. Zur Behandlung eines solchen Fehlers werden mehrere Notifikationen übermittelt. So gene­ riert die dem Hardwarefehler zugeordnete MO-Instanz, also die ursprüngliche HW-bezogene MOI einen Fehlerereignisreport (FER). Da sich der Status dieser HW-bezogenen MO-Instanz än­ dert, generiert die gleich MO-Instanz auch einen Statusän­ derungsereignisreports (CSER). Die funktionsbezogene MOI, die die vom Hardwarefehler beeinträchtigte Funktionalität model­ liert, generiert wegen der eigenen Statusänderung einen eige­ nen CSER. Ggf. können weitere HW-bezogene MO-Instanzen, die von der ursprünglichen, fehlerhaften HW-bezogenen MO-Instanz abhängig sind, eigene CSER generieren.

Im Fehlerfall einer als MO modellierten Hardwarekomponente werden folglich ein FER und mindestens 2 CSER generiert und an die übergeordnete Netzeinheit übertragen. Das Übermitteln dieser Notifikationen erhöht wesentlich die Last über die in­ ternen Schnittstellen, also die 0-Schnittstellen, die Abis- Schnittstellen und die Asub-Schnittstellen eines Basissta­ tionssubsystems und kann in bestimmten Fällen, z. B. bei Aus­ fall mehreren Hardwarekomponenten in kurzen Zeitabständen zu Überlastproblemen führen.

Aufgabe der Erfindung ist es, ein Verfahren zum Behandeln von in Kommunikationssystemen von einem hardwarebezogenen gema­ nagten Objekt generierten Alarmen anzugeben, das die system­ internen Schnittstellen weniger stark belastet.

Diese Aufgabe löst die Erfindung durch ein Verfahren mit den Merkmalen des Anspruches 1.

Ein erfindungsgemäßes Verfahren zum Behandeln eines in einem Kommunikationssystem von einer Instanz eines hardwarebezogenen gemanagten Objekts generierten Alarms, wenn durch den Alarm eine Statusänderung mehrerer Instanzen gemanagter Objekte wie zum Beispiel eine Statusänderung der den Alarm generierenden Instanz eines hardwarebezogenen gemanagten Objekts sowie einer diese modellierenden Instanz eines funktionsbezogenen gemanagten Objekts bedingt sind, meldet das Auftreten des Alarms und die dadurch bedingten Statusänderungen mehrerer gemanagter Objekte durch einen Fehlerereignisreport an eine übergeordnete Netzeinrichtung. Der hierzu verwendete Fehlerereignisreport enthält unter anderem die Parameter:

• - Quellenidentifizierung, die anzeigt, ob eine Statusänderung als Folge einer internen Operation oder durch ein benutzerbe­ zogenes Managementkommando erfolgt,
• - Attributidentifizierungsliste, die den Satz von sich für das hardwarebezogene gemanagte Objekt geänderten Statusattri­ buten identifiziert, und
• - Statusänderungsdefinitionsliste, die für alle mitzuteilen­ den, durch den Alarm bedingten Statusänderungen unterschied­ licher Instanzen gemanagter Objekte die Statusänderungen definiert.

In einer Weiterbildung des Erfindungsaspektes kann vorgesehen sein, daß in der Statusänderungsdefinitionsliste des Fehler­ ereignisreports für die durch den Alarm bedingten Statusände­ rungen der Instanzen gemanagter Objekte, die den Alarm nicht generiert haben, nur die Statusänderungen bezüglich der Para­ meter Attributidentifizierung [gemäß ITU-T. X.731 "Attribute identifier"] und Neuer Attribut-Wert [gemäß ITU-T. X.731 "New Attribute value"] definiert werden. Diese Parameter sind gemeinsam mit den übrigen Parametern eines erfindungsgemäßen Fehlerereignisreports ausreichend, um aus dem FER auch die üblicherweise zusätzlich zu übertragenden CSER in der übergeordneten Netzeinrichtung zu generieren.

Eine vorzugsweise Weiterbildung eines erfindungsgemäßen Ver­ fahrens sieht in dem generierte Fehlerereignisreport außerdem die Parameter "Notification identifier" (Notifikations­ identifizierung), "correlated notifications" (Korrellierte Notifikationen), "Additional text" (Zusatztext) und "Additional information" (Zusatzinformation) gemäß ITU-T X.731 bzw. ITU-T X.733 vor. Diese Parameter sind nämlich üblicherweise sowohl in einem standardmäßigen FER als auch in einem standardmäßigen CSER gemeinsam, so daß die den erfin­ dungsgemäßen FER empfangende Netzkomponente, beispielsweise eins Basisstation, eine Basisstationssteuerung oder eine Transcodier- und Ratenanpaßeinrichtung eines Basisstations­ subsystems, auf einfache Weise die nicht übertragenen CSER rekonstruieren kann, um beispielsweise eine nachgeordnete Behandlung des den FER generierenden Alarms standardmäßig auf der Grundlage von FER und CSER auszuführen.

In einer besonders günstigen, weil weitgehend mit den übli­ chen Vorschriften kompatiblen Ausgestaltungsform eines erfin­ dungsgemäßen Verfahrens enthält der generierte Fehlerereig­ nisreport Parameter gemäß ITU-T X.731 bzw. ITU-T X.733, nämlich die Parameter "invoke identifier", "Mode", "Managed object class", "Managed object instance", "Event type", "Event time", "Event information" mit "Probable cause", "Specific problems", "Perceived severity", "Back-up Status", "Back-up object", "Trend indication", "Threshold information", "Notification identifier", "correlated notifications" sowie "Source indicator", in der Statusänderungsdefinitionsliste die Parameter "Managed object class", "Managed object instance", "Attribute identifier list", "Attribute identifier", "New Attribute value", sowie die Parameter "Monitored Attributes", "proposed repair actions", "Additional text" und "Additional information", sowie "Current time", "Event reply" und "Errors".

Die Figur zeigt eine Parametertabelle eines FER gemäß diesem Ausführungsbeispiel.

Nachstehend wird die Erfindung an Hand eines Ausführungsbei­ spiels mit einer Parameterliste gemäß der Tabelle der Figur für den Anwendungsfall in einem Basisstationssubsystem eines Mobilfunksystems näher erläutert.

Die gemäß der Parametertabelle der Figur für den Transfer von Alarmen bzw. Zustandsänderungen benutzten M-EVENT-REPORTs un­ terscheiden sich von standardmäßigen FER nur in der Ausge­ staltung der Parametergruppe "Event information".

Innerhalb dieser generischen Parametergruppe sind drei Kate­ gorien von Feldern zu unterscheiden.

Die erste Kategorie enthält Felder von "Event information", die sowohl für Alarmreportfunktionen als auch für Zustandsän­ derungsreportfunktionen gemeinsam sind, nämlich die Parameter "Notification identifier", "Correlated notifications", "Additional text" und "Additional information".

Die zweite Kategorie enthält für Zustandsänderungsreportfunk­ tionen spezifische Felder von "Event information", und zwar "Source indicator", das angibt, ob die Zustandsänderung als Folge einer internen Operation oder durch ein Benutzerabhän­ giges Management-Kommando erfolgt ist. Außerdem "Attribute identifier list", das für die aktuelle MO-Instanz den Satz von Zustandsattributen identifiziert, deren Werte sich geän­ dert haben. Beide Felder sind in einem standardgemäßen FER nicht enthalten, müssen also zum Erstellen eines erfindungs­ gemäßen FER gemäß dem beschriebenen Ausführungsbeispiel zu­ sätzlich generiert werden.

Die dritte Kategorie betrifft das Feld "State change defini­ tion" in "Alarm reporting". Dieses definiert in einem stan­ dardgemäßen FER nur eine Zustandsänderung für die den Alarm generierende HW-bezogene MO-Instanz und muß um Parametersätze für alle üblicherweise (nicht erfindungsgemäß) einen CSER ge­ nerierenden MO-Instanzen erweitert werden.

Dabei werden in einer besonders günstigen Ausgestaltungsform des beschriebenen Ausführungsbeispiels jeweils nur die gemäß ITU-T. X.731 als "mandatory", d. h. zwingen erforderlich gekennzeichneten, den jeweiligen Zustand betreffenden Werte "Attribute identifier" und "New Attribute value" benutzt.

Im Vergleich zu einem standardisierten FER enthält ein FER mit Parametern gemäß der Tabelle der Figur demnach folgende Zusatzinformationen:

• - "Source indicator", der für alle aus dem FER gemäß dem Aus­ führungsbeispiel zu generierenden CSER den Wert "resource operation" enthält;
• - "State change definition list" (die Statusänderungs­ definitionsliste), einer Parameterliste, die den Satz von Zustandsattributen identifiziert, deren Werte sich geändert haben, und aus je einer Sequenz von fünf Feldern für jedes zu generierende CSER besteht entsprechend den Instanzen "ursprüngliches HW-bezogenes MO", dem damit zusammenhängenden "funktionsbezogenen MO" und aller weiteren, als vom ursprüng­ lichen HW-bezogenen MO abhängig (dependent) definierten Instanzen von "HW-bezogenen MO".

Das Ende der "State change definition list" wird von der übergeordneten, den FER empfangenden Netzeinheit dadurch erkannt, da das letzte MO in dieser Liste dem ursprünglichen defekten HW-bezogenen MO entspricht. Dies bedeutet, daß die letzten MOC und MOI der Parameter 17 und 18 gleiche Werte haben wie die MOC und MOI der Parameter 3 und 4.

Nachstehend wird der Unterschied zwischen dem standardmäßigen Behandeln von Alarmen nach dem Stand der Technik und dem erfindungsgemäßen Behandeln von Alarmen am Beispiel einer Basisstation eines Basisstationssubsystems eines Mobilfunksytion die hardwarebezogene MOI TPU2 einer MOC TPU als ur­ sprüngliche hardwarebezogene MO-Instanz ausfällt.

In einer bekannten Lösung nach den erwähnten Standards gene­ riert und sendet die Basisstation vier Notifikationen an eine ihr übergeordnete Basisstationssteuerung, und zwar ein FER für die ursprüngliche hardwarebezogene MO-Instanz TPU2, ein CSER für diese hardwarebezogene MO-Instanz TPU2 mit der Anga­ be "Betriebszustand ist ausgefallen" (bzw. nach dem eng­ lischsprachigen Ausdruck Operational State OST = disabled) und einer Angabe, daß die CSER sich auf den Zustand einer bezüg­ lich des Alarms ursprünglichen hardwarebezogenen MO-Instanz handelt (AST = failed). Außerdem sendet sie ein CSER für eine funktionsbezogene MO-Instanz TRX2 (mit den Angaben OST dis­ abled, AST dependency) und ein CSER für eine hardwarebezogene MO-Instanz PA 2 der MOC PA, die von der MO-Instanz TPU2 ab­ hängig ("dependent") ist (mit den Angaben OST disabled, AST dependency).

In einem erfindungsgemäßen Verfahren erzeugt die Basisstation nur einen einzigen erfindungsgemäßen FER und sendet diesen zur Basisstationssteuerung. Die Basisstationssteuerung kann dann daraus die vier vorher beschriebenen Einzelreports gene­ rieren.

Die Struktur des FER nach der vorliegenden Erfindung, der von der Basisstation und der Basisstationssteuerung übertragen wird, ist folgendermaßen (Siehe auch die Tabelle der Figur):

• - Die Parameter 1, 2, 6, 14, 15 und 24 bis 28 bleiben wie in einem standardgemäßen FER der TPU2 unverändert und werden von der Basisstationssteuerung sowohl zum Generieren der FER als auch der einzelnen CSER verwendet.
• - Der Parameter 5 kennzeichnet den FER durch einen eindeuti­ gen Wert als erfindungsgemäßen FER, so daß die Basisstations­ steuerung veranlaßt wird, die enthaltenen CSER zu extrahieren.
• - Die Parameter 3, 4, 7 bis 13, 22 und 23 entsprechen denen eines standardgemäßen FER der MOI TPU2 (MOC = TPU, MOI = 2) und werden von der Basisstationssteuerung nur zum Generieren der FER verwendet.
• - Der Parameter 16 wird von der Basisstationssteuerung nur zum Generieren der einzelnen CSER verwendet und hat gemäß ITU-T. X.731 immer den Wert "resource operation".
• - Die Parameter 17 bis 21 werden von der Basisstationssteue­ rung nur zum Generieren der einzelnen CSER verwendet und be­ stehen aus drei Sequenzen mit je sieben Werten, die nach­ folgend angegeben werden:
  Managed object class: TRX
  Managed object instance: 2
  Attribute identifier list: OST, AVS (Operational State, Availability State)
  Attribute identifier: OST (Operational State)
  New Attribute value: disabled (nicht betriebsfähig)
  Attribute identifier: AVS (Availability State)
  New Attribute value: dependency (Abhängigkeit)
  Managed object class: PA
  Managed object instance: 2
  Attribute identifier list: OST, AVS (Betriebszustand, Verfügbarkeitszustand)
  Attribute identifier: OST
  New Attribute value: disabled
  Attribute identifier: AVS
  New Attribute value: dependency
  Managed object class: TPU (letzte Sequenz, gleiche MOC- und MOI-Werte wie die Parameter 3 und 4)
  Managed object instance: 2
  Attribute identifier list: OST, AVS
  Attribute identifier: OST
  New Attribute value: disabled
  Attribute identifier: AVS
  New Attribute value: failed.

Aus dem derart strukturierten FER kann die Basisstations­ steuerung die obengenannten vier standardgemäßen Reports generieren.

Claims (4)

1. Verfahren zum Behandeln eines in einem Kommunikations­ system von einer Instanz eines hardwarebezogenen gemanagten Objekts generierten Alarms, wenn durch den Alarm Statusänderungen mehrerer Instanzen gemanagter Objekte bedingt sind, wobei das Auftreten des Alarms durch einen Fehlerereignisreport gemeldet wird an eine übergeordnete Netzeinrichtung, der auch die durch den Alarm bedingten Statusänderungen mitgeteilt werden, gekennzeichnet durch das Generieren des Fehlerereignisreports, unter anderem mit den Parametern

• - Quellenidentifizierung (16), die anzeigt, ob eine Statusänderung als Folge einer internen Operation (resource operation) oder durch ein benutzerbezogenes Managementkommando erfolgt,
• - Attributidentifizierungsliste (19), die den Satz von sich für das hardwarebezogene gemanagte Objekt geänderten Statusattributen identifiziert, und
• - Statusänderungsdefinitionsliste (17, 18, 19, 20, 21), die für alle mitzuteilenden, durch den Alarm bedingten Statusänderungen unterschiedlicher Instanzen gemanagter Objekte die Statusänderungen definiert.

2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß in der Statusänderungsdefinitionsliste (17, 18, 19, 20, 21) des Fehlerereignisreports für die durch den Alarm bedingten Statusänderungen der Instanzen gemanagter Objekte, die den Alarm nicht generiert haben, die Statusänderungen bezüglich der Parameter Attributidentifizierung (20) und Neuer Attribut-Wert (21) definiert werden.

3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, daß der generierte Fehlerereignisreport außerdem die Parameter "Notification identifier" (14), "correlated notifications" (15), "Additional text" (24) und "Additional information" (25) gemäß ITU-T X.731 bzw. ITU-T X.733 enthält.

4. Verfahren nach Anspruch 1, 2 oder 3, dadurch gekennzeichnet, daß der generierte Fehlerereignisreport Parameter gemäß ITU-T X.731 bzw. ITU-T X.733 enthält, nämlich die Parameter "invoke identifier" (1), "Mode" (2), "Managed object class" (3), "Managed object instance" (4), "Event type" (5), "Event time" (6), "Event information" mit "Probable cause" (7), "Specific problems" (8), "Perceived severity" (9), "Back-up Status" (10), "Back-up object" (11), "Trend indication" (12), "Threshold information" (13), "Notification identifier" (14), "correlated notifications" (15) sowie "Source indicator" (16), in der Statusänderungs­ definitionsliste die Parameter "Managed object class" (17), "Managed object instance" (18), "Attribute identifier list" (19), "Attribute identifier" (20), "New Attribute value" (21), sowie die Parameter "Monitored Attributes" (22), "proposed repair actions" (23), "Additional text" (24) und "Additional information" (25), sowie "Current time" (26), "Event reply" (27) und "Errors" (28).