DE10134126A1 - Verfahren zum gleichzeitigen Deaktivieren mehrerer Alarme - Google Patents

Verfahren zum gleichzeitigen Deaktivieren mehrerer Alarme

Info

Publication number
DE10134126A1
DE10134126A1 DE10134126A DE10134126A DE10134126A1 DE 10134126 A1 DE10134126 A1 DE 10134126A1 DE 10134126 A DE10134126 A DE 10134126A DE 10134126 A DE10134126 A DE 10134126A DE 10134126 A1 DE10134126 A1 DE 10134126A1
Authority
DE
Germany
Prior art keywords
alarm
alarms
cleared
active
network
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
DE10134126A
Other languages
English (en)
Inventor
Lucian Hirsch
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Siemens AG
Original Assignee
Siemens AG
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Siemens AG filed Critical Siemens AG
Priority to DE10134126A priority Critical patent/DE10134126A1/de
Publication of DE10134126A1 publication Critical patent/DE10134126A1/de
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/04—Network management architectures or arrangements
    • H04L41/046—Network management architectures or arrangements comprising network management agents or mobile agents therefor
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H04L41/0604—Management of faults, events, alarms or notifications using filtering, e.g. reduction of information by using priority, element types, position or time
    • H04L41/0613—Management of faults, events, alarms or notifications using filtering, e.g. reduction of information by using priority, element types, position or time based on the type or category of the network elements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Health & Medical Sciences (AREA)
  • Computing Systems (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Die Erfindung betrifft ein Verfahren zum gleichzeitigen Deaktivieren mehrerer Alarme mittels eines "multiple-cleared" Alarms in einem Telekommunikations-Management-Netzwerk mit einem Netzwerkmanager (1), wenigstens einem Elementmanager mit einem NMC-Agenten (2) und mehreren Netzwerkelementen. Der NMC-Agent (2) umfaßt einen Diskriminator (EFD), der bestimmte Alarmmeldungen filtert. Um zu verhindern, dass "multiple-cleared" Alarme gefiltert werden, wird vorgeschlagen, einem Feld des "multiple-cleared" Alarms einen Wert zuzuweisen, auf Grund dessen der "multiple-cleared" Alarm nicht gefiltert wird.

Description

  • Die Erfindung betrifft ein Verfahren zum gleichzeitigen Deaktivieren mehrerer Alarme in einem Telekommunikations- Management-Netz mittels einer einzigen "Multiple-Cleared"- Alarmmeldung gemäß dem Oberbegriff des Patentanspruchs 1.
  • Telekommunikations-Management-Netze TMN dienen der Verwaltung von Netzwerkelementen und umfassen mehrere Management-Ebenen, wobei jede Ebene eine Manager-Funktion für die nächst tiefere Ebene (wenn vorhanden) und eine Agent-Funktion für die nächst höhere Ebene (wenn vorhanden) erfüllt. Für diese Erfindung sind die ersten drei Management-Ebenen signifikant.
  • Wie in Fig. 1 gezeigt ist, befindet sich auf der obersten Hierarchiestufe, der sog. Netzwerk-Management-Ebene, ein Netzwerkmanager NMC (NMC: Network Management Center), der nur herstellerunabhängige Aspekte des Netzmanagements unterstützt und eine netzweite Integration unterschiedlicher (herstellerspezifischer) Netzwerkelemente NE ermöglicht.
  • Die Bezeichnung "Netzmanagement" umfasst dabei sämtliche Maßnahmen zur Steuerung, Wartung, Fehlererkennung, Konfiguration oder zum Test, etc. von Netzwerkelementen NE. In der Praxis wird insbesondere zwischen Fehlermanagement, Konfigurationsmanagement, Testmanagement und Performancemanagement unterschieden.
  • In der untersten Hierarchieebene des TMN 1 befinden sich die zu verwaltenden Netzwerkelemente (NE), wie beispielsweise Funknetz-Steuereinrichtungen SSS11-SSS1K (Switching-Sub- System) (z. B. Mobile Switching Centre MSC) oder Basisstationen BSSN1-BSSNP (Base-Station-System) (z. B. Base- Station-Controler BSC; Base-Transceiver-Station BTS).
  • In der mittleren Ebene des TMN 1, der sog. Netzwerkelement- Mangement-Ebene, befinden sich mehrere Elementmanager OMC (Operation and Maintenance Center), die sowohl funktionale als auch herstellerspezifische Eigenschaften der Netzwerkelemente NE verwalten können.
  • Im TMN sind die Netzressourcen üblicherweise als Instanzen verschiedener Objektklassen definiert. Unter dem Begriff "Netzressourcen" werden insbesondere sämtliche Hardwareeinrichtungen (Platinen, Schaltkreise, etc.) sowie Softwareprogramme (Z. B. die BSC/BTS-Funktionen) verstanden. Jede Ressource ist somit durch eine Adresse, bestehend aus der Objektklasse MOC und der Objektinstanz MOI, genau spezifiziert.
  • Das Fehler-Management (Fault-Management) ist einer der wichtigsten Bereiche in einem Telekommunikations-Management- Netzwerk TMN. Nach dem Auftreten eines Fehlers z. B. in einem Netzwerkelement wird ein entsprechender Alarm üblicherweise gemäß standardisierter Alarmmitteilungen, wie z. B. gemäß ITU- T X.710/X.721 als CMISE-standardisierte Alarmreports (ITU-T: International Telecommunications Union - Telecommunications standardisation; CMISE: Common Management Information Service Element) an den Elementmanager OMC und anschließend an den Netzwerkmanager NMC gesendet und dort registriert. Dabei ist es von wesentlicher Bedeutung, dass alle relevanten "aktiven" Alarme aus den untergeordneten Ebenen (OMC- und Netzwerkelement-Ebene) möglichst schnell an den Netzwerkmanager NMC weitergeleitet werden. "Aktive" Alarme sind dabei diejenigen Alarme, deren Ursache in den Netzwerkelementen noch nicht behoben ist.
  • Die Mitteilung von Fehlern aus unteren Netzwerkebenen an den Netzwerkmanager NMC erfolgt unter Normalbedingungen, d. h. wenn die Kommunikation zwischen Elementmanager (Agent) und Netzwerkmanager funktioniert, mittels eines sogenannten Event-Reporting-Mechanismus. Hierbei generiert ein Agent nach Erkennung eines Fehlers eine entsprechende Alarmmeldung und sendet diese an eventuell im Agenten vorhandene Event- Forwarding-Diskriminatoren, sogenannte EFDs. Die Aufgabe eines EFD ist es, nur diejenigen Event-Reports (Ereignismitteilungen) zum Manager weiterzuleiten, welche bestimmten Filterkriterien genügen. Der Manager ist in der Lage, die EFDs im Agenten einzurichten oder zu löschen und die Filterkriterien festzulegen. Dadurch kann der Netzwerkmanager jederzeit den Informationsfluß nach seinen individuellen Anforderungen steuern.
  • Erkennt der Agent, dass der Fehler behoben wurde, so generiert er eine "cleared" Alarmmeldung, welche ebenfalls zu den EFDs gesendet wird. Dadurch wird der zuvor aktive Alarm deaktiviert (d. h. "inaktiv" gesetzt).
  • Gemäß aktueller ITU-T Standards enthält ein Alarm standardisierte Parameter, von denen folgende eine besondere Bedeutung haben:
    • Notification Identifier
  • Dieser Parameter ist eine Art Referenznummer und dient der eindeutigen Spezifizierung einer Alarmmitteilung. Er kann in späteren Mitteilungen als Referenz verwendet werden. Der Parameterwert muß dabei für eine Objektinstanz eindeutig sein.
    • Correlated Notifications
  • Wenn dieser Parameter in "cleared" Alarmmeldungen vorhanden ist, enthält er eine Referenz, die sich auf eine oder mehrere vorherige "aktive" Alarme bezieht, die deaktiviert werden sollen. Jeder Verweis in der "cleared" Alarmmeldung auf eine vorherige "aktive" Alarmmeldung umfasst dabei folgende Werte:
    • - den Wert des Parameters Notification identifier (z. B. A1) und
    • - ggf. die Objektinstanz der alten Alarmmeldung A1, falls die aktuelle "cleared" Alarmmeldung von einer anderen Objektinstanz generiert wurde.
  • Wird beispielsweise ein Alarm von einer Objektinstanz MOI1 einer Objektklasse MOC1 auf Grund eines Fehlers in einem Netzwerkelement NE generiert, enthält die Alarmmeldung z. B. den Parameter Notification Indentifier A1. Entstehen auf Grund dieses ersten Fehlers weitere Fehler im Netz, werden wiederum entsprechende Alarmmeldungen von den betroffenen Objektinstanzen (z. B. MOC2/MOI2), z. B. mit einem Notification Identifier A2, generiert. Dies erfolgt auch dann, wenn die Objektinstanzen (bzw. die tatsächlichen Netzressourcen) eigentlich noch funktionsfähig sind, jedoch vom ersten Fehler beeinflußt werden. Der von der zweiten Objektinstanz (MOC2/MOI2) generierte Alarm enthält dann im Feld Correlated Notifications den Wert A1 als Hinweis auf die Ursache.
  • Das Verfahren zum Deaktivieren von Alarmen (Alarm clearing) wird in den ITU-T Standards X.733 und Q.821 wie folgt beschrieben:
    • Deaktivieren von Alarmen gemäß ITU-T X.733
  • Ein "cleared" Alarm, der von der gleichen Objektinstanz wie der vorherige "aktive" Alarm generiert wurde, enthält unter anderem folgende Parameter:
    • - ein Feld für die Bedeutung bzw. Wichtigkeit des Alarms, (Perceived Severity) mit dem Wert "cleared" und
    • - Felder für den Alarmtyp (Alarm type), die mögliche Ursache (Probable Cause) und ein Feld für spezifische Probleme (Specific Problems).
  • Ein aktiver Alarm wird gemäß dieser Norm dann deaktiviert, wenn die Werte in den Feldern Alarm type, Probable Cause und Specific Problems des "cleared" Alarms mit denjenigen Werten des "aktiven" Alarms übereinstimmen.
    • Deaktivieren von Alarmen gemäß ITU-T Q.821
  • In diesem Standard werden zwei Alternativen für einen "cleared" Alarm definiert, die sich durch einen Parameter Correlated Notifications unterscheiden:
    • - eine Alarmmeldung mit dem Parameter Perceived Severity = "cleared" und einem gesetzten Parameter Correlated Notifications deaktiviert diejenigen Alarme, deren Notification Identifier-Werte im Parameter Correlated Notifications enthalten sind.
    • - Eine Alarmmeldung mit dem Parameter Perceived Severity = "cleared" ohne Benutzung des Parameters Correlated Notifications deaktiviert diejenigen Alarme, deren Parameterwerte der Parameter Alarm type, Probable cause und Specific problems mit den entsprechenden Werten der "aktiven" Alarme übereinstimmen, also in gleicher Weise wie in ITU-T X.733 beschrieben ist.
  • Um die Verkehrslast über die OMC-NMC-Schnittstelle (Agent- Manager-Schnittstelle) zu reduzieren, ist es von Vorteil, wenn der Agent mehrere vorher "aktive" Alarme mit einem einzigen "cleared" Alarm deaktivieren kann. Diese Prozedur wird als Deaktivieren und nicht als Löschen bezeichnet, da ein Alarm üblicherweise erst dann gelöscht wird, wenn er deaktiviert ("cleared") und vom Operator oder vom Management- System selbst bestätigt ("acknowledged") worden ist.
  • Theoretisch lassen sich mehrere Alarme gleichzeitig unter Einhaltung der genannten Standards deaktivieren. Dabei können jedoch Fehler auftreten, wie die folgenden Beispiele zeigen:
  • a) Deaktivieren von mehreren Alarmen nach ITU-T Q.821 mit Benutzung des Parameters Correlated Notifications
    • - es wird angenommen, dass von einer Objektinstanz MOC1/MOI1 (MOC: Managed Object Class, MOI: Managed Object Instance) ein Alarm mit folgenden Parametern generiert wird: Alarm type = processingAlarm, Notification identifier = n1.
    • - infolge dieses ersten Alarms entsteht z. B. ein weiterer Alarm im Netz, der von einer Objektinstanz MOC2/MOI2 mit folgenden Parametern generiert wird:
      Alarm type = communicationAlarm, Notification identifier = n2, Correlated notifications = n1.
    • - außerdem wird ein dritter Alarm von einer Objektinstanz MOC3/MOI3 mit folgenden Parametern generiert:
      Alarmtype = qualityOfServiceAlarm, Notification identifier = n3.
  • Wenn der NMC-Agent im Elementmanager diese drei Alarme mit einem einzigen "cleared" Alarm deaktivieren soll, bestehen folgende Probleme:
    • - gemäß den Standards besteht grundsätzlich die Möglichkeit des gleichzeitigen Deaktivierens mehrerer Alarme, die Standards spezifizieren jedoch nicht, welche Objektinstanz und welcher Alarmtyp (dies sind obligatorische Parameter) im "cleared" Alarm stehen sollen. Es wird angenommen, dass der NMC-Agent für diese Parameter die gleichen Werte wie im ersten Alarm verwendet, also Objektinstanz = MOI1, Alarm type = processingAlarm. Zusätzlich enthält dieser "cleared" Alarm im Feld Correlated notifications folgende Verweise auf die "aktiven" Alarme (wie in ITU-T Q.821 angegeben ist): {n1}, {n2,MOI2}, {n3,MOI3}.
  • Falls der NMC-Manager nun einen Filter (EFD) benutzt, der alle Alarme von Typ processingAlarm ausfiltert, dann wird nicht nur der erste "aktive" Alarm (die beiden weiteren "aktiven" Alarme werden weitergeleitet), sondern auch der "cleared" Alarm ausgefiltert, da dieser den Alarmtyp processingAlarm aufweist. Damit werden die Alarme zwei und drei im Netzwerkmanager NMC nie deaktiviert!
  • Ein ähnliches Problem tritt auf, wenn z. B. Alarme mit bestimmten Werten für den Parameter Probable cause (dies ist ein obligatorischer Parameter) ausgefiltert werden sollen. Wenn der "cleared" Alarm einen dieser Werte für den Parameter Probable cause benutzt, obwohl weitere zu deaktivierende Alarme andere Probable cause-Werte aufweisen, wird der "cleared" Alarm vollständig ausgefiltert. Damit bleiben im Netzwerkmanager NMC weiterhin Alarme "aktiv", obwohl deren Ursache mittlerweile behoben wurde.
    • a) Deaktivieren von mehreren Alarmen ohne Benutzung des Parameters Correlated notifications.
  • Gemäß ITU-T Q.821 werden solche "aktiven" Alarme deaktiviert (cleared), die für die Parameter Alarm type, Probable cause und Specific problems gleiche Werte wie der "cleared" Alarm aufweisen. Dieses Verfahren gilt jedoch nur für eine und nicht für mehrere Objektinstanzen. Diese Einschränkung macht das Verfahren (d. h. das Deaktivieren von mehreren Alarmen ohne Benutzung des Parameters Correlated notifications) vor allem in großen Telekommunikationsnetzen sehr ineffizient.
  • Es ist daher die Aufgabe der vorliegenden Erfindung, ein Verfahren zu entwickeln, mit dem mehrere "aktive" Alarme mittels einer "cleared" Alarmmeldung zuverlässig und effizient deaktiviert werden können.
  • Gelöst wird diese Aufgabe durch die im Patentanspruch 1 angegebenen Merkmale. Weitere Ausgestaltungen der Erfindung sind Gegenstand von Unteransprüchen.
  • Der wesentliche Gedanke der Erfindung besteht darin, einem Feld des "multiple-cleared" Alarms einen Wert zuzuweisen, der das gleichzeitige Deaktivieren mehrerer aktiver Alarme kennzeichnet und aufgrund dessen der "multiple-cleared" Alarm von EFDs nicht gefiltert wird.
  • Vorzugsweise wird eine von Alarm generierenden Objektklassen (solche, die tatsächliche Ressourcen des Telekommunikationsnetzes modellieren) unabhängige Objektklasse (z. B. multipleAlarmHandling) für den "multiple-cleared" Alarm verwendet. Der "multiple-cleared" Alarm umfaßt vorzugsweise außerdem im Feld Alarm type bzw. Event type einen Wert, der auf das gleichzeitige Deaktivieren mehrerer Alarme hinweist, wie z. B. Event type = multipleclearing.
  • Gemäß einer bevorzugten Ausführungsform der Erfindung umfaßt der "multiple-cleared" Alarm ein Feld, das auf zu deaktivierende, "aktive" Alarme verweist, insbesondere das Feld Correlated notifications.
  • Dieses Feld umfaßt vorzugsweise mehrere Wertepaare, bestehend aus dem Parameter Notification identifier (nx) und der Objektinstanz, die den "aktiven" Alarm generiert hat (MOIx).
  • Gemäß einer bevorzugten Ausführungsform der Erfindung enthält jede "aktive" Alarmmeldung einen Parameter, der die Alarmmeldung genau spezifiziert, also z. B. eine eigene Referenznummer. Insbesondere enthält jede "aktive" Alarmmeldung den Parameter Notification identifier.
  • Sofern das Telekommunikations-Management-Netzwerk einen EFD (EFD: Event Forwarding Discriminator) enthält, ist dieser so eingestellt, dass ein "multiple-cleared" Alarm, welcher den genannten Parameterwert oder die unabhängige Objektklasse (multipleAlarmHandling) enthält, nicht ausgefiltert wird.
  • Nachdem der Netzwerkmanager NMC einen "multiple-cleared" Alarm empfangen hat, wählt er diejenigen "aktiven" Alarme aus einer Alarmliste aus, die durch den Parameter Notification identifier (Referenznummer) und die zugehörige Objektinstanz spezifiziert sind. Die ausgewählten Alarme werden dann entweder deaktiviert oder - falls sie vom Benutzer des Systems oder vom Systems selbst (automatisch) "bestätigt" wurden - gelöscht.
  • Die einzige Objektinstanz der unabhängigen Objektklasse (multipleAlarmHandling) wird vorzugsweise bei jedem Neustart des NMC-Agenten automatisch erzeugt.
  • Wenn der auf vorherige "aktive" Alarme verweisende Parameter (Correlated notifications) auf einen unbekannten "aktiven" Alarm verweist (z. B. weil der "aktive" Alarm durch den EFD ausgefiltert wurde) wird dieser Verweis vorzugsweise vom Netzwerkmanager NMC ignoriert.
  • Das beschriebene Verfahren eignet sich grundsätzlich auch für die Bestätigung (Acknowledgment) mehrerer Alarme mit einer einzigen Agent-Mitteilung. Eine solche Mitteilung könnte z. B. als Objektklasse MOC die gleiche Objektklasse (multipleAlarmHandling) aufweisen, wie beim gleichzeitigen Deaktivieren mehrerer "aktiver" Alarme. Ebenso kann eine andere unabhängige Objektklasse erzeugt werden. Als Alarm- bzw. Ereignistyp sollte ein Wert verwendet werden, der auf das gleichzeitige Bestätigen mehrerer Alarme hinweist, wie z. B. multipleAcknowledgment.
  • Eine solche Bestätigungsmitteilung sollte außerdem für jeden (vom Systembenutzer oder automatisch vom System) bestätigten Alarm folgende Informationen aufweisen:
    • - den Wert Notification identifier (nx)
    • - die Objektinstanz, die den "aktiven" Alarm generiert hat (MOIx) sowie
    • - die sogenannte "Acknowledgment History", d. h. insbesondere die Zeit, den Benutzernamen oder den Namen des Systems, an dem der Alarm bestätigt wurde.
  • Die Erfindung wird nachstehend anhand der beigefügten Zeichnungen beispielhaft näher erläutert. Es zeigen:
  • Fig. 1 den schematischen Aufbau eines Telekommunikations- Management-Netzwerks 1; und
  • Fig. 2 die Weiterleitung eines "multiple-cleared" Alarms an den Netzwerkmanager.
  • Bezüglich Fig. 1 wird auf die in der Beschreibungseinleitung gemachten Erläuterungen verwiesen.
  • Fig. 2 zeigt einen Ausschnitt aus einem Telekommunikations- Management-System 1 mit einem Netzwerkmanager (NMC) 2 und einem NMC-Agenten 3, der eine Schnittstellenkomponente eines Elementmanagers OMC ist.
  • Zum gleichzeitigen Deaktivieren bzw. Löschen mehrerer "aktiver" Alarme erzeugt der NMC-Agent 3 eine "multiple- cleared" Alarmmitteilung, deren Feld Event type den Wert multipleelearing aufweist. Dieser "multiple-cleared" Alarm wird in üblicher Weise einem Diskriminator EFD zugeleitet. Der Diskriminator EFD ist dabei so eingestellt, dass Alarme mit einer Objektklasse (multipleAlarmHandling), die von Alarm generierenden Objektklassen des Telekommunikationsnetzes unabhängig ist, nicht gefiltert werden.
  • Der "multiple-cleared" Alarm wird somit an den Netzwerkmanager 2 weitergeleitet. Dieser sucht (in Schritt 5) nach Empfang des "multiple-cleared" Alarms diejenigen Alarme aus einer Alarmliste 4 aus, die jeweils durch bestimmte Angaben, insbesondere durch das Wertepaar {nx, MOIx} eindeutig identifizierbar sind; dabei ist der Wert nx eine Referenznummer (Notification Identifier) des Alarms und MOIx die Objektinstanz der Alarmquelle. Diese Alarme werden schließlich deaktiviert oder gegebenenfalls - wenn sie schon bestätigt wurden - aus der Alarmliste 4 gelöscht.

Claims (12)

1. Verfahren zum gleichzeitigen Deaktivieren mehrerer aktiver Alarme mittels eines "multiple-cleared" Alarms in einem Telekommunikations-Management-Netzwerk (1) mit einem Netzwerkmanager (NMC; 2), wenigstens einem Elementmanager (OMC; 3) und mehreren Netzelementen (NE) dadurch gekennzeichnet, dass einem Feld des "multiple-cleared" Alarms ein Wert zugewiesen wird, der das gleichzeitige Deaktivieren mehrerer aktiver Alarme kennzeichnet.
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass der "multiple-cleared" Alarm aufgrund des speziellen Wertes nicht gefiltert wird.
3. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass der "multiple-cleared" Alarm eine von Alarmgenerierenden Objektklassen unabhängige Objektklasse (multipleAlarmHandling) aufweist.
4. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass der "multiple-cleared" Alarm für den Parameter "Alarmtyp" bzw. "Ereignistyp" (Event type) einen Wert aufweist, der das gleichzeitige Deaktivieren mehrerer aktiver Alarme anzeigt (z. B. multipleClearing).
5. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass der "multiple-cleared" Alarm ein Feld (Correlated notifications) aufweist, das alle zu deaktivierenden Alarme angibt.
6. Verfahren nach Anspruch 5, dadurch gekennzeichnet, dass das Feld (Correlated notifications) aus mehreren Wertepaaren, umfassend eine Alarm-Referenznummer (Notification Identifier), sowie die Objektinstanz, die den aktiven Alarm generiert hat, besteht.
7. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass jede "aktive" Alarmmeldung eine Alarm-Referenznummer, insbesondere den Parameter Notification Identifier, aufweist.
8. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die das gleichzeitige Deaktivieren mehrerer aktiver Alarme kennzeichnende Objektinstanz bei jedem Neustart des NMC-Agenten automatisch erzeugt wird.
9. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das Telekommunikations-Management-Netzwerk (1) einen Diskriminator (EFD) enthält, der so eingestellt ist, dass Alarmmeldungen mit dem speziellen Wert, insbesondere der unabhängigen Objektklasse nicht ausgefiltert werden.
10. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass der Netzwerkmanager (NMC) nach Empfang eines "multiple- cleared" Alarms aus einer Alarmliste (4) mit aktiven Alarmen diejenigen Alarme auswählt, die im "multiple-cleared" Alarm, insbesondere durch den Parameter Notification-Identifier und die Objektinstanz, spezifiziert sind.
11. Verfahren nach Anspruch 8, dadurch gekennzeichnet, dass die ausgewählten Alarme deaktiviert werden, oder gelöscht, falls sie schon bestätigt wurden.
12. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass der Netzwerkmanager (NMC; 2)) einen Verweis auf einen nicht in der Alarmliste enthaltenen Alarm ignoriert.
DE10134126A 2001-07-13 2001-07-13 Verfahren zum gleichzeitigen Deaktivieren mehrerer Alarme Withdrawn DE10134126A1 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
DE10134126A DE10134126A1 (de) 2001-07-13 2001-07-13 Verfahren zum gleichzeitigen Deaktivieren mehrerer Alarme

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE10134126A DE10134126A1 (de) 2001-07-13 2001-07-13 Verfahren zum gleichzeitigen Deaktivieren mehrerer Alarme

Publications (1)

Publication Number Publication Date
DE10134126A1 true DE10134126A1 (de) 2003-01-30

Family

ID=7691696

Family Applications (1)

Application Number Title Priority Date Filing Date
DE10134126A Withdrawn DE10134126A1 (de) 2001-07-13 2001-07-13 Verfahren zum gleichzeitigen Deaktivieren mehrerer Alarme

Country Status (1)

Country Link
DE (1) DE10134126A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2010148027A1 (en) * 2009-06-15 2010-12-23 Qualcomm Incorporated Method for configuration of a sensor in a network

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2010148027A1 (en) * 2009-06-15 2010-12-23 Qualcomm Incorporated Method for configuration of a sensor in a network
WO2010148026A1 (en) * 2009-06-15 2010-12-23 Qualcomm Incorporated Method for transmission of data in a sensor in a network
WO2010148029A1 (en) * 2009-06-15 2010-12-23 Qualcomm Incorporated Method for middleware of a sensor network
JP2012530466A (ja) * 2009-06-15 2012-11-29 クアルコム，インコーポレイテッド ネットワーク内のセンサ構成のための方法
US8427309B2 (en) 2009-06-15 2013-04-23 Qualcomm Incorporated Sensor network management
US8432288B2 (en) 2009-06-15 2013-04-30 Qualcomm Incorporated Sensors in communication devices
US9432271B2 (en) 2009-06-15 2016-08-30 Qualcomm Incorporated Sensor network management
US10075353B2 (en) 2009-06-15 2018-09-11 Qualcomm Incorporated Sensor network management

Similar Documents

Publication Publication Date Title
DE19801784C2 (de) Verfahren und Kommunikationssystem zur Behandlung von Alarmen durch ein mehrere Managementebenen aufweisendes Managementnetz
EP1034639B1 (de) Verfahren und kommunikationssystem zur behandlung von alarmen durch ein mehrere managementebenen aufweisendes managementnetz
DE19831825C2 (de) Verfahren und Kommunikationssystem zur Behandlung von Alarmen durch ein mehrere Managementebenen aufweisendes Managementnetz
WO2007144300A1 (de) Flexible änderung des zuständigkeitsbereiches eines operators für das netzwerkmanagement
DE19801785C2 (de) Verfahren und Kommunikationssystem zur Behandlung von Alarmen durch ein mehrere Managementebenen aufweisendes Managementnetz
EP1282991B1 (de) Aktualisierung von hersteller-spezifischen hardware-informationen an der hersteller-unabhängigen omc-nmc-schnittstelle im mobilfunk
EP1668822B1 (de) Verfahren zur synchronisierung von alarmen in einem managementsystem eines kommunikationsnetzes
EP1206883B1 (de) Generisches alignment-verfahren in einer multi-manager-umgebung
EP1730886B1 (de) Verfahren und einrichtungen zur verteilung von management-informationen in einem managementnetz eines kommunikationssystems
DE10134126A1 (de) Verfahren zum gleichzeitigen Deaktivieren mehrerer Alarme
EP1437859A1 (de) Verfahren zur Behandlung von Alarmen durch ein Managementnetz mit mehreren Ebenen in einem Kommunikationssystem
DE10337464A1 (de) Verfahren zur Behandlung von Alarmen in einem Managementsystem eines Kommunikationsnetzes
EP1304011B1 (de) Entstörungsprozedur für ein übergeordnetes nmc durch korrelation von alarmen mit ergebnissen von automatischen tests
EP1582030B1 (de) Verfahren zur behandlung von alarmen durch ein managementnetz mit mehreren ebenen in einem kommunikationssystem
EP1371236B1 (de) Verfahren zur selektiven und gesammelten weiterleitung von meldungen in einem tmn-netzwerk
EP1749369B1 (de) Verfahren und einrichtungen zum betreiben eines managementnetzes bei ausfall eines managers
EP1802031A1 (de) Netzwerkmanagement mit redundanter Konfiguration
EP1750391A1 (de) Überwachung eines Agenten in einem Managementsystem
EP1763937B1 (de) Verfahren zur gesicherten datenübertragung in einem managementsystem
DE10134125A1 (de) Kundenspezifische, dynamische Konfiguration einer OMC-NMC-Schnittstelle

Legal Events

Date Code Title Description
OP8 Request for examination as to paragraph 44 patent law
8139 Disposal/non-payment of the annual fee