DE19801785A1 - Verfahren und Kommunikationssystem zur Behandlung von Alarmen durch ein mehrere Managementebenen aufweisendes Managementnetz - Google Patents
Verfahren und Kommunikationssystem zur Behandlung von Alarmen durch ein mehrere Managementebenen aufweisendes ManagementnetzInfo
- Publication number
- DE19801785A1 DE19801785A1 DE19801785A DE19801785A DE19801785A1 DE 19801785 A1 DE19801785 A1 DE 19801785A1 DE 19801785 A DE19801785 A DE 19801785A DE 19801785 A DE19801785 A DE 19801785A DE 19801785 A1 DE19801785 A1 DE 19801785A1
- Authority
- DE
- Germany
- Prior art keywords
- agent
- manager
- alarm data
- alarms
- sent
- 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.)
- Granted
Links
- 238000000034 method Methods 0.000 title claims abstract description 35
- 238000004891 communication Methods 0.000 title claims description 24
- 230000006854 communication Effects 0.000 title claims description 24
- 101150012763 endA gene Proteins 0.000 claims description 9
- 238000007726 management method Methods 0.000 description 59
- 230000005540 biological transmission Effects 0.000 description 14
- 238000010295 mobile communication Methods 0.000 description 7
- 230000000737 periodic effect Effects 0.000 description 7
- 230000001419 dependent effect Effects 0.000 description 6
- 230000000875 corresponding effect Effects 0.000 description 5
- 238000011161 development Methods 0.000 description 5
- 230000018109 developmental process Effects 0.000 description 5
- 230000015572 biosynthetic process Effects 0.000 description 4
- 238000005755 formation reaction Methods 0.000 description 4
- 230000002596 correlated effect Effects 0.000 description 3
- 238000010586 diagram Methods 0.000 description 3
- 238000012423 maintenance Methods 0.000 description 3
- NQLVQOSNDJXLKG-UHFFFAOYSA-N prosulfocarb Chemical compound CCCN(CCC)C(=O)SCC1=CC=CC=C1 NQLVQOSNDJXLKG-UHFFFAOYSA-N 0.000 description 3
- 101000864232 Euglena gracilis Delta(8)-fatty-acid desaturase Proteins 0.000 description 2
- 230000001276 controlling effect Effects 0.000 description 2
- 238000012937 correction Methods 0.000 description 2
- 108090000623 proteins and genes Proteins 0.000 description 2
- 230000004044 response Effects 0.000 description 2
- 241000251468 Actinopterygii Species 0.000 description 1
- 238000012935 Averaging Methods 0.000 description 1
- 240000008881 Oenanthe javanica Species 0.000 description 1
- 230000008901 benefit Effects 0.000 description 1
- 230000015556 catabolic process Effects 0.000 description 1
- 230000001413 cellular effect Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 238000007796 conventional method Methods 0.000 description 1
- 238000001514 detection method Methods 0.000 description 1
- 238000011156 evaluation Methods 0.000 description 1
- 230000002349 favourable effect Effects 0.000 description 1
- 230000000977 initiatory effect Effects 0.000 description 1
- 238000013507 mapping Methods 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 238000012544 monitoring process Methods 0.000 description 1
- 230000008569 process Effects 0.000 description 1
- 230000009467 reduction Effects 0.000 description 1
- 230000011664 signaling Effects 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
- 230000007704 transition Effects 0.000 description 1
- 230000001960 triggered effect Effects 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W24/00—Supervisory, monitoring or testing arrangements
-
- 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/042—Network management architectures or arrangements comprising distributed management centres cooperatively managing the network
-
- 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
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer And Data Communications (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Debugging And Monitoring (AREA)
- Monitoring And Testing Of Transmission In General (AREA)
- Mobile Radio Communication Systems (AREA)
Description
Die Erfindung betrifft ein Verfahren sowie ein entsprechendes
Kommunikationssystem zur Behandlung von Alarmen durch ein
mehrere Management ebenen aufweisendes Managementnetz, wobei
für einen Alarmdatenabgleich zwischen einem Agent einer Mana
gementebene und zumindest einem Manager einer nächsthöheren
Managementebene die Alarmdaten aktiver Alarme übertragen wer
den.
Die Prinzipien eines Managementnetzes, die auch als TMN-Prin
zipien (Telecommunications Management Network) bezeichnet
werden, definieren mehrere Managementebenen für das Manage
ment eines Kommunikationssystems - beispielsweise eines Mo
bil-Kommunikationssystems -, wobei jede Ebene eine doppelte
Funktion hat. Im managenden System hat jede Ebene außer der
untersten eine Manager-Funktion für die darunterliegende Ebe
ne. Im gemanagten System hat jede Ebene außer der obersten
eine Agenten-Funktion für die nächsthöhere Ebene.
Das Fehlermanagement ("Fault Management") ist ein wichtiger
Teil des TMN-Managements. Grundsätzlich spielt hier der Agent
die aktive Rolle, indem er Fehler der eigenen Managementebene
rechtzeitig und genau erkennt und an den Manager der nächst
höheren Ebene als Alarme überträgt. Die Übertragung von
Alarmdaten vom Agent zum Manager ist unkritisch, solange der
Kommunikationsmechanismus zwischen diesen Systemen nicht ge
stört ist. Wenn die Verbindung zwischen den beiden Manage
mentebenen, also zwischen Agent und Manager, für eine be
stimmte Zeit nicht mehr gewährleistet ist, muß der Agent die
während dieses Intervalls aufgetretenen Alarme zwischenspei
chern, um sicherzustellen, daß nach dem Wiederherstellen der
Kommunikationsmöglichkeit dem Manager zum einen möglichst
schnell eine Übersicht der z.Zt. aktiven Alarme - z. B. in
Form einer Liste - zur Verfügung gestellt wird, und der Mana
ger zum anderen eine möglichst lückenlose Alarmgeschichte
("alarm history") sowohl der aktiven als auch der beendeten
Alarme ("cleared alarms") aufbauen kann.
Zu diesem Zweck wird ein Alarmdatenabgleich (alarm realign
ment) zwischen Agent und Manager bei jedem neuen Verbindungs
aufbau nach einem Verbindungsabbruch oder nach einer Initia
lisierung des Agenten oder des Managers ausgeführt. Alle
Alarmdaten aktiver Alarme, zu denen Fehler im Agent noch
nicht behoben sind - erkennbar daran, daß sie nicht als
"cleared alarms" gekennzeichnet sind -, sind daher
schnellstmöglich und vollständig der nächsthöheren Managemen
tebene zur Verfügung zu stellen.
In der älteren Patentanmeldung P 197 52 614.4 sind ein derarti
ges Verfahren und Kommunikationssystem zur Behandlung von
Alarmen angegeben, die eine Basisfunktionalität für den Mana
ger zur Anforderung aller Alarme vom Agent beschrieben. Dabei
sendet der Agent die aktiven Alarme als Sequenz standardi
sierter M-EVENT-REPORTS, die in eine zu Anfang von dem Mana
ger initiierte M-ACTION-Request Anforderung und in eine zum
Ende von dem Agent initiierte M-ACTION-Response Antwort ein
gebettet ist. Dieses sind generische CMISE-standardisierte
(Common Management Information Service Element) Prozeduren,
die gemäß ITU-T X.710 definiert sind. Die ITU-T X.733 defi
niert den Inhalt einer standardisierten Alarmübertragung
(alarm report) die gemäß den M-EVENT-REPORT Services durch
geführt wird. Alle in Rahmen dieser M-ACTION definierten
M-EVENT-REPORTS sind zu der jeweiligen Anforderung durch Ver
wendung von Korrelationsinformationen eindeutig korreliert.
Dies erlaubt dem Manager, diese M-EVENT-REPORTS einer be
stimmten Anforderung zuzuordnen und darüber hinaus von ande
ren, "regulären" M-EVENT-REPORTS zu unterscheiden.
Aufgabe der Erfindung ist es, ein Verfahren und Kommunikati
onssystem zur Behandlung von Alarmen durch ein mehrere Mana
gementebenen aufweisendes Managementnetz anzugeben, durch das
ein Alarmdatenabgleich zwischen einem Agent und zumindest ei
nem Manager weiter verbessert wird.
Diese Aufgabe wird gemäß der Erfindung hinsichtlich des Ver
fahrens durch die Merkmale des Patentanspruchs 1 und hin
sichtlich des Kommunikationssystems durch die Merkmale des
Patentanspruchs 15 gelöst. Weiterbildungen der Erfindung sind
den Unteransprüchen zu entnehmen.
Die Erfindung geht davon aus, daß für einen Alarmdatenab
gleich zwischen einem Agent einer Managementebene und zumin
dest einem Manager einer nächsthöheren Management ebene die
Alarmdaten aktiver Alarme übertragen werden. Erfindungsgemäß
wird von dem Manager eine Nachricht zu dem Agent gesendet,
durch die ein automatischer, von dem Agent wiederholt initi
ierter Alarmdatenabgleich angefordert wird. Eine Korrela
tionsinformation für eine Zuordnung der jeweiligen Anforde
rung zu den vom Agent nachfolgend gesendeten Nachrichten mit
den Alarmdaten wird vom Manager empfangen. Den Alarmdatenab
gleich steuert der Manager abhängig von zumindest einem zum
Agent gesendeten Parameter.
Durch den Erfindungsgegenstand kann der Alarmdatenabgleich
vom Agent wiederkehrend automatisch gestartet werden, wobei
er für den Manager gegenüber der Basisfunktionalität parame
trisierbar ist, d. h. nicht mehr alle aktiven Alarme müssen
zwangsläufig vom Agent gesendet werden, sondern nur die durch
den übermittelten Parameter näher definierten. Durch die Pa
rameter ergibt sich für den Manager eine Auswahlfunktion für
eine Teilmenge aus allen Alarmen, die vom Agent in periodi
schen Zeitabständen von allein geliefert werden, ohne daß es
dafür eines Anstosses durch den Manager bedarf. Der Manager
wird einerseits in der Steuerung der Anforderungen entlastet,
andererseits besitzt er die Möglichkeit der steuernden Beein
flussung des Abgleichs durch Vergabe der Parameter und unter
Anwendung standardisierter Nachrichten zur Erhöhung der Fle
xibilität des Managers und Reduzierung des Nachrichten- und
Informationsflusses in erheblichem Maße. Erst durch die para
metrisierbare Alignment-Funktionalität gemäß der Erfindung
können beispielsweise eine Priorisierung der Alarme und/oder
eine aktive Steuerung der Reihenfolge der automatisch vom
Agent bereitgestellten Alarme erzielt werden. Besonders die
Kombination der Basisfunktionalität - Verwendung einer Korre
lationsinformation - mit der parametrisierbaren automatischen
Alignment-Funktionalität führt zu einem besonders effektiven
Verfahren und Kommunikationssystem, das eine optimale Nutzung
der Übertragungsressourcen auf der Schnittstelle der Agent-
Manager-Beziehung sowie ein schnellstmögliches periodisches
Bereitstellen nur der vom Manager gewünschten Alarmdaten ak
tiver Alarme für die nächsthöhere Managementebene durch den
Agent bewirkt.
Gemäß einer Weiterbildung der Erfindung werden von dem Mana
ger der oder die Parameter in der Nachricht zum Alarmdatenab
gleich zu dem Agent gesendet.
Gemäß einer anderen Weiterbildung der Erfindung wird die
Nachricht zum automatischen Alarmdatenabgleich von dem Mana
ger einzeln für jede Anforderung zu dem Agent gesendet. Auf
diese Weise generiert der Manager jedes Mal, wenn er ein au
tomatisches Liefern der Alarme in wiederkehrenden Zeitabstän
den durch den Agent wünscht, individuell die Anforderung.
Gemäß einer alternativen Weiterbildung der Erfindung wird die
Nachricht zum automatischen Alarmdatenabgleich von dem Mana
ger für mehrere Anforderungen gemeinsam zu dem Agent gesen
det. Dadurch erfolgt die vom Manager gewünschte Parametrisie
rung des automatischen Alarmdatenabgleichs einmalig für einen
längeren Zeitraum und die darin enthaltene Einstellung des
Managers hat Gültigkeit für den Agent.
Dabei wird vorzugsweise von dem Agent nach jedem durchgeführ
ten Alarmdatenabgleich - in einem gesamten automatischen
Alarmdatenabgleich mit mehreren Wiederholungen - eine Nach
richt zum Manager gesendet, mit der dem Manager das Ende des
einzelnen Alarmdatenabgleichs mitgeteilt wird.
Das periodische automatische Bereitstellen und Senden der
Alarme durch den Agent erfolgt anhand eines Startzeitpunkts
und eines Endezeitpunkt für den gesamten Alarmdatenabgleich
sowie eines Zeitintervalls zur Wiederholung des jeweiligen
Alarmdatenabgleichs, die alle von dem Manager in der Nach
richt zum Alarmdatenabgleich gesendet werden.
Um die Flexibilität des Managers zu erhöhen, wird vorzugswei
se von dem Manager zusätzlich eine Zustandsinformation zum
Agent gesendet, die zum Unterbrechen gesetzt und zum Fortse
tzen des automatischen Alarmdatenabgleichs rückgesetzt wird.
Gemäß weiterer vorteilhafter Weiterbildungen der Erfindung
kann die Parametrisierung mit einem oder mehreren der folgen
den, von dem Manager jeweils eingestellten Parameterwerten
erfolgen. Durch den Parameterwert werden vom Agent Alarme an
gefordert,
- - die von ausgewählten Agenteinheiten stammen,
- - für die eine Dringlichkeit angenommen wird,
- - anhand dessen der Agent eine Priorisierung beim Senden der angeforderten Alarme nach deren Dringlichkeit, vorzugsweise anhand unterschiedlicher Dringlichkeitswerte, vornimmt,
- - die innerhalb eines durch einen Anfangszeitpunkt und einen Endzeitpunkt definierten Zeitraum entstehen,
- - anhand dessen der Agent eine Priorisierung beim Senden der Alarme nach dem Entstehungszeitpunkt der Alarme vornimmt.
So sieht eine besonders günstige Ausgestaltung des Erfindungs
gegenstandes vor, daß von dem Agent die Alarmdaten der Alarm
mit kritischer Dringlichkeit, bei der die Funktionalität als
nicht mehr gegeben angenommen wird, zuerst und die Alarmdaten
der Alarme mit unkritischer Dringlichkeit, bei der die Funk
tionalität als nicht mehr gegeben angenommen wird, zuletzt
automatisch bereitgestellt und gesendet werden.
Mit der obigen Vorgehensweise kann der Manager die im Hin
blick auf die Funktionalität besonders kritischen und damit
für ihn wichtigen Alarme automatisch, periodisch vom Agent
gezielt abrufen lassen, und dabei die Schnittstelle zum Agent
durch den nur auf bestimmte Alarme eingeschränkten Informati
onsfluß gegenüber dem herkömmlichen Verfahren der Meldung al
ler Alarme wesentlich entlasten.
Nachstehend wird die Erfindung anhand von Ausführungsbeispie
len unter Bezugnahme auf die Figuren näher erläutert. Es zei
gen
Fig. 1 das Blockschaltbild eines Managementnetzes für
ein Mobil-Kommunikationssystem mit Agent-Manager-
Beziehung zwischen einem Betriebs- und Wartungs
zentrum und einem oder mehreren Netzmanagementzen
tren,
Fig. 2 das Blockschaltbild des Managementnetzes gemäß
Fig. 1 mit Agent-Manager-Beziehung zwischen ei
nem Basisstationssystem und einem Betriebs- und
Wartungszentrum zur Durchführung von zumindest
zwei Anwendungen für das Basisstationssystem,
Fig. 3 das Blockschaltbild von Agent und Manager zur Be
handlung der Alarme für parallel oder seriell ab
laufende Alarmdatenabgleiche,
Fig. 4 den Nachrichtenfluß zwischen dem Manager und dem
Agent zur parameterabhängigen Steuerung eines au
tomatischen Alarmdatenabgleichs individuell für
jede Anforderung,
Fig. 5 den Nachrichtenfluß nach Fig. 4 für einen perio
disch wiederkehrenden, automatischen Alarmdaten
abgleich bei Verwendung eines die Dringlichkeit
betreffenden Parameterwertes,
Fig. 6 den Nachrichtenfluß zwischen dem Manager und dem
Agent zur parameterabhängigen Steuerung des auto
matischen Alarmdatenabgleichs gemeinsam für meh
rere Anforderungen, und
Fig. 7 den Nachrichtenfluß nach Fig. 6 für den periodisch
wiederkehrenden, automatischen Alarmdatenabgleich
bei Verwendung des die Dringlichkeit betreffenden
Parameterwertes.
Das Ausführungsbeispiel beschreibt die Erfindung anhand eines
TMN-Konzepts für das Management eines Mobil-Kommunikationssy
stems, das beispielsweise Netzeinrichtungen eines Mobilfunk
netzes nach dem GSM-Standard aufweist. Die Erfindung ist aber
nicht auf Mobilfunknetze beschränkt, sondern läßt sich auf
Telekommunikationsnetze jeder Art, die ein TMN-Managementnetz
nutzen, anwenden.
Ein Mobil-Kommunikationssystem ist ein hierarchisch ge
gliedertes System verschiedener Netzeinrichtungen, bei dem
die unterste Hierarchiestufe von den Mobilstationen gebildet
wird. Diese Mobilstationen kommunizieren über eine Funk
schnitt stelle mit die nächste Hierarchieebene bildenden Funk
stationen, die als Basisstationen bezeichnet werden. Die bei
spielsweise Mobilstationen in einem Funkbereich einer Funk
zelle versorgenden Basisstationen sind vorzugsweise zur Ab
deckung eines größeren Funkgebiets zusammengefaßt und mit
übergeordneten Netzeinrichtungen, den Basisstationssteuerun
gen verbunden. Die Basisstationen und Basisstationssteuerun
gen gehören zu einem Basisstationssystem (Base Station Subsy
stem) des Mobil-Kommunikationssystems. Die Basisstations
steuerungen kommunizieren über definierte Schnittstellen mit
einer oder mehreren Vermittlungseinrichtungen, den Mobilver
mittlungsstellen, über die u. a. auch der Übergang zu anderen
Kommunikationsnetzen erfolgt. Die Mobilvermittlungsstellen
bilden gemeinsam mit einer Mehrzahl von Datenbanken das Ver
mittlungssystem (Switching Subsystem) des Mobil-Kommunikati
onssystems.
Neben den obigen Netzeinrichtungen existieren ein oder mehre
re Betriebs- und Wartungszentren (Operation and Maintenance
Centers), die u. a. zum Konfigurieren und Überwachen der Netz
einrichtungen dient. Überwachungsmaßnahmen und Konfigurie
rungsmaßnahmen werden hierzu meist vom Betriebs- und War
tungszentrum aus ferngesteuert, die üblicherweise im Bereich
der Mobilvermittlungsstellen angeordnet sind. Ein Betriebs- und
Wartungszentrum kommuniziert dabei jeweils mit einem Ba
sisstationssystem oder Vermittlungssystem über eine defi
nierte Schnittstelle. Eine weitere Aufgabe des Betriebs- und
Wartungssystems ist die Durchführung des Konfigurationsmana
gements (Configuration Management), das neben dem Fehlermana
gement einen von fünf Managementfunktionsbereichen darstellt,
die die TMN-Prinzipien identifizieren. Das Konfigurationsma
nagement definiert eine Reihe von Diensten, die eine Änderung
der Struktur und damit des Verhaltens eines Telekommunikati
onsnetzes durch den Bediener ermöglichen. Diese Dienste be
ziehen sich immer auf Instanzen von gemanagten Objekten, die
insgesamt die netzspezifische Managementinformationsbasis
bilden.
Ein gemanagtes Objekt im Sinne des Konfigurationsmanagements
ist eine logische Abstraktion einer Ressource im Mobil-Kommu
nikationssystem. Hierbei wird unterschieden zwischen hardwa
rebezogenen gemanagten Objekten, die eine herstellerspezifi
sche Realisierung einer Funktion beschreiben, und funktions
bezogenen gemanagten Objekten, bei denen es sich jeweils um
die Abstraktion einer herstellerunabhängigen Funktionalität
handelt.
Für das Management des Mobil-Kommunikationssystems definieren
die TMN-Prinzipien mehrere Ebenen ("Levels"), von denen im
vorliegenden Beispiel drei Ebenen unter Bezugnahme auf die
Fig. 1 und 2 nachfolgend erläutert werden.
Die Fig. 1 und 2 zeigen jeweils drei Ebenen A, B und C des
Managementnetzes, von denen die Managementebene C die Netz
einrichtungsebene ("Network Element Level") mit mehreren Ba
sisstationssystemen BSS11, BSS12 . . . BSS1N sowie BSS21, BSS22
. . . BSS2M enthält. Die Managementebene B kennzeichnet die
Netzeinrichtungsmanagementebene ("Network Element Management
Level"), in der Betriebs- und Wartungszentren OMC1 und OMC2
jeweils die herstellerspezifische Managementfunktionalität
für einzelne Subsysteme, wie im vorliegenden Beispiel das Be
triebs- und Wartungszentrum OMC1 für die Basisstationssysteme
BSS11, BSS12 . . . BSS1N und das Betriebs- und Wartungszentrum
OMC2 für die Basisstationssysteme BSS21, BSS22 . . . BSS2M, be
reitstellen. Die Managementebene A kennzeichnet die Netzmana
gementebene ("Network Management Level"), in der Netzmanage
mentzentren NMC1 und NMC2 jeweils eine integrierte, vom Her
steller unabhängige Management-Funktionalität realisieren.
Dabei können mehrere Netzmanagementzentren einen Zugriff zu
derselben Netzeinrichtung der nächstniedrigeren Managemen
tebene B haben, im vorliegenden Beispiel die Netzmanagement
zentren NMC1 und NMC2 der nächsthöheren Management ebene C zum
Betriebs- und Wartungszentrum OMC1 der nächstniedrigeren Ma
nagementebene B. Zwischen den Netzeinrichtungen unterschied
licher Managementebenen sind definierte Schnittstellen zur
Informationsübertragung vorgesehen.
Der Unterschied in den Darstellungen gemäß den Fig. 1 und
2 liegt darin, daß eine Agent-Manager-Beziehung zur Behand
lung von Alarmen für einen oder mehrere Alarmdatenabgleiche
in Fig. 1 zwischen dem Betriebs- und Wartungszentrum OMC1
(Agent) und einem Netzmanagementzentrum NMC1 (Manager) oder
mehreren - physikalisch getrennten - Netzmanagementzentren
NMC1, NMC2 (Manager) sowie in Fig. 2 zwischen dem Basissta
tionssystem BSS11 (Agent) und zwei verschiedenen Anwendungen
OF1 und OF2 (Manager) in dem Betriebs- und Wartungszentrum
OMC1 oder zwischen dem Betriebs- und Wartungszentrum OMC1
(Agent) und zwei verschiedenen Anwendungen NF1 und NF2 (Mana
ger) in dem Netzmanagementzentrum NMC1 besteht. Um in den
Netzmanagementzentren NMC1, NMC2 jederzeit einen Überblick
über die Fehlersituation sicherzustellen, werden vom Be
triebs- und Wartungszentrum OMC1 die - auf Grund von bei
spielsweise innerhalb der betreuten Basisstationssysteme
BSS11 . . . BSS1N auftretenden Fehlern - gespeicherten Alarmdaten
aktiver Alarme bereitgestellt und parallel zu beiden Managern
auf Anforderung gesendet. Dies erfolgt vorzugsweise nach ei
nem Verbindungsabbruch oder nach einer Initialisierung des
Agenten oder des Managers. Ebenso können mehrere Anforderun
gen auch hintereinander von einem einzelnen Manager, z. B. dem
Netzmanagementzentrum NMC1 an den Agent, z. B. dem Betriebs-
und Wartungszentrum OMC1, gerichtet werden. Fig. 1 zeigt die
Struktur für gemäß der Erfindung mehrfach ausgesendete Anfor
derungen zum Alarmdatenabgleich, die im vorliegenden Beispiel
parallel zwischen der Managementebene B, in der sich der
Agent in Form des Betriebs- und Wartungszentrums OMC1 befin
det, und der nächsthöheren Managementebene A, in der die Ma
nager von zumindest zwei Netzmanagementzentren NMC1, NMC2 ge
bildet werden, ablaufen.
Um auch in der Managementebene B, z. B. in dem Betriebs- und
Wartungszentrum OMC1 jederzeit einen Überblick über die Feh
lersituation sicherzustellen, werden vom Basisstationssystem
BSS11 die - auf Grund von beispielsweise innerhalb der be
treuten Basisstationen und Basisstationssteuerungen auftre
tenden Fehlern - gespeicherten Alarmdaten aktiver Alarme be
reitgestellt und parallel zu mindestens zwei Managern des Be
triebs- und Wartungszentrums OMC1 in Form der unterschiedli
chen Anwendungen OF1 und OF2, die beide von ein- und dersel
ben physikalischen Einrichtung OMC1 ausgeführt werden, gesen
det. Dies erfolgt ebenfalls vorzugsweise nach einem Verbin
dungsabbruch oder nach einer Initialisierung des Agenten oder
des Managers. Eine serielle Übertragung von mehrfach durch
einen einzelnen Manager, z. B. dem Betriebs- und Wartungs
zentrum OMC1, initiierten Anforderungen an den Agent, z. B.
dem Basisstationssystem BSS11, ist ebenfalls möglich. Alter
nativ oder zusätzlich kann eine Agent-Manager Beziehung auch
zwischen dem Betriebs- und Wartungszentrum OMC1 (ein Agent)
und dem Netzmanagementzentrum NMC1 (ein Manager) zum seriel
len Austausch von Anforderungen und Alarmdaten oder zum pa
rallelen Austausch von Anforderungen und Alarmdaten für min
destens zwei unterschiedliche Anwendungen NF1 und NF2 (zwei
Manager) im Netzmanagementzentrum NMC1 existieren. Fig. 2
zeigt die Struktur für gemäß der Erfindung parallel ablaufen
de Alarmdatenabgleiche zwischen der Managementebene B, in der
sich die Manager als Anwendungen OF1 und OF2 befinden, und
der nächstniedrigeren Managementebene C, in der sich der
Agent befindet.
Sobald eine in der Managementebene C ausgefallene interne
Schnittstelle wieder betriebsbereit ist, wird auf Anforderung
des Managers/der Manager der Alarmdatenabgleich, auch als
Realignment-Prozedur oder Realignment-Verfahren bezeichnet,
parameterabhängig gesteuert und automatisch vom Agent durch
wiederholtes Initiieren - vorzugsweise in periodischen Zeit
abständen, die vom Manager eingestellt und dem Agent mitge
teilt werden - ausgeführt. Dabei erfolgt der Alarmdatenab
gleich im vorliegenden Beispiel zuerst zwischen dem Basissta
tionssystem, z. B. BSS11, und den Anwendungen OF1, OF2 im Be
triebs- und Wartungszentrum OMC1 parallel und setzt sich an
schließend zwischen dem Betriebs- und Wartungszentrum OMC1
und den übergeordneten Netzmanagementzentren NMC1, NMC2 par
allel fort. Am Ende dieser Prozeduren ist die Fehlersituation
sowohl im OMC als auch in den NMC wieder aktualisiert. Das
Realignment-Verfahren kann selbstverständlich auf die Aktua
lisierung der Alarmdaten zwischen Agent und Managern in zwei
unmittelbar angrenzenden Managementebenen, z. B. Ebene B und
Ebene A, beschränkt sein.
Fig. 3 zeigt in schematischer Darstellung den Aufbau von
Agent AG und Manager MA1, MA2 mit den zur Durchführung simul
tan - bei zwei oder mehreren Managern - oder seriell - bei
nur einem Manager - ablaufender Realignment-Prozeduren erfor
derlichen Einrichtungen. Jeder Manager MA1, MA2 und Agent AG
verfügt über eine Steuereinrichtung M-CTR bzw. A-CTR, die
Nachrichten für den Alarmdatenabgleich generieren und auswer
ten können. Ebenso weisen sie - nicht näher dargestellte -
Sende/Empfangseinrichtungen für das Versenden und Empfangen
der Nachrichten sowie Speichereinrichtungen für das Speichern
der Alarmdaten und anderer Nutz- und Signalisierungsinforma
tionen auf.
Die Steuereinrichtungen M-CTR der Manager MA1, MA2 generieren
jeweils eine Nachricht, die zu dem Agent gesendet wird und
durch die ein automatischer, von dem Agent wiederholt initi
ierter Alarmdatenabgleich angefordert wird. Dabei enthalten
die Nachrichten im Nachrichtenfluß eine für die Zuordnung ei
ner Anforderung zu nachfolgend gesendeten Nachrichten benutz
te Korrelationsinformation, die eindeutig ist. Darüber hinaus
fügen die Einrichtungen M-CTR der Manager MA1, MA2 zur Steue
rung des automatischen Alarmdatenabgleichs einen oder mehrere
Parameter par entweder in eine Nachricht, die einzeln für je
de Anforderung individuell vom Manager erzeugt und ausgesen
det wird, oder in eine für mehrere Anforderungen gemeinsame
Nachricht ein. Durch die Angabe eines Start- und Endezeit
punkts für den gesamten Alarmdatenabgleich und eines Zeitin
tervalls zur Definition der Wiederholungszeitpunkte zur Über
mittlung von Alarmdaten wird der automatische Alarmdatenab
gleich vom Agent periodisch gestartet und durchgeführt. Das
zusätzliche Mitsenden eines oder mehrerer Parameter par mit
verschiedenen Parameterwerten ermöglicht dem Manager, be
stimmte Alarme gezielt vom Agent automatisch übertragen zu
lassen. Aus diesem Grund verfügt die Einrichtung A-CTR des
Agent AG über eine Funktion auto, mit der bei Erreichen des
übermittelten Startzeitpunkts ein Alarmdatenabgleich jeweils
begonnen und in den Zeitabständen des vorgegebenen Zeitinter
valls bis Erreichen des Endezeitpunkts wiederholt wird. Erst
durch die parametrisierbare Alignment-Funktionalität gemäß
der Erfindung können beispielsweise eine Priorisierung der
Alarme und/oder eine aktive Steuerung der Reihenfolge der
Alarme, die vom Agent automatisch übermittelt werden (Schedu
ling Funktionalität), erzielt werden.
Die Steuereinrichtung A-CTR des Agent AG empfängt die Nach
richt zum automatischen Alarmdatenabgleich mit den Parametern
par, wertet sie aus, und startet das Realignment zu den Mana
gern MA1, MA2 durch Rücksenden der von den Managern spezi
fisch angeforderten Alarme an den vom Manager gesetzten Zeit
punkten. Dabei kann zusätzlich eine Zustandsinformation
(administrative State) von der Einrichtung M-CTR des Managers
MA1, MA2 zum Agent AG gesendet werden, die entweder zum Un
terbrechen des Alarmdatenabgleichs gesetzt oder zum Fortset
zen des automatischen Alarmdatenabgleichs rückgesetzt ist.
Von der Einrichtung M-CTR des Managers MA1, MA2 wird darüber
hinaus eine eindeutige Korrelationsinformation zur Korrelati
on der jeweiligen Anforderungen generiert und zum Agent AG
gesendet. Eine Nachricht mit einer weiteren Korrelationsin
formation zur Zuordnung der nachfolgend vom Agent gesendeten
Nachrichten (alarm notifications) zu dem jeweils gestarteten
Realignment wird ebenfalls benutzt. Auch die weitere Korrela
tionsinformation ist eindeutig. Durch beide Korrelationsin
formationen ist eine eindeutige Zuordnung simultan oder seri
ell durchgeführter Realignments zu mehreren Managern oder ei
nem einzelnen Manager möglich.
Besonders die Kombination der Basisfunktionalität - Verwen
dung der Korrelationsinformationen - mit der parametrisierba
ren Alignment-Funktionalität für automatisches Bereitstellen
und Übermitteln von Alarmen führt zu einem besonders effekti
ven Verfahren und Kommunikationssystem, das eine optimale
Nutzung der Übertragungsressourcen auf der Schnittstelle der
Agent-Manager-Beziehung sowie ein schnellstmögliches Bereit
stellen nur der vom Manager gewünschten Alarmdaten aktiver
Alarme für die nächsthöhere Managementebene - an definierten
Zeitpunkten automatisch durch den Agent- bewirkt. Ressour
cenausnutzung, Zeitdauer und Flexibilität werden folglich in
dem erfindungsgemäß ausgestalteten Kommunikationssystem ge
genüber der Basisfunktionalität weiter optimiert.
Wahlweise können im Agent AG mehrere, jeweils den Managern
MA1, MA2 zuordenbare und von ihnen steuerbare Filterfunktio
nen EFD1, EFD2 (Event Forwarding Discriminators). mit Filter
kriterien für die vom Agent AG erzeugten Nachrichten mitbe
nutzt werden, sodaß die Nachrichten mit den Alarmdaten nur
bei Erfüllen der Filterkriterien zu den Managern MA1, MA2 ge
routet werden. Die Steuereinrichtung M-CTR des Managers ist
in der Lage, derartige Filterfunktionen im Agent AG einzu
richten, zu löschen und die Filterkriterien festzulegen, um
je nach seinen individuellen Anforderungen den Nachrichten
fluß steuern zu können. Daher kann der Fall auftreten, daß
die Filterfunktions-Einstellung von Manager zu Manager unter
schiedlich ist, sodaß durch die simultan ablaufenden Realign
ment-Prozeduren inhaltlich verschiedene Alarme mit zugehöri
gen Alarmdaten behandelt werden.
Fig. 4 zeigt den Nachrichtenfluß zwischen einem Agent AG -
im dargestellten Beispiel gemäß der Fig. 1 dem Betriebs- und
Wartungszentrum OMC1 oder im dargestellten Beispiel der Fig.
2 dem Basisstationssystem BSS11 - und dem Manager MA1, MA2 -
im Beispiel gemäß der Fig. 1 den unterschiedlichen Netzmana
gementzentren NMC1, NMC2 oder im Beispiel der Fig. 2 den
verschiedenen Applikationen OF1, OF2.
Der Nachrichtenfluß erfolgt vorzugsweise unter Verwendung
standardisierter M-EVENT-REPORT Nachrichten, der eine zu An
fang vom Manager initiierte M-CREATE Anforderung zum Einstel
len der Parameter für den automatischen Alarmdatenabgleich
vorangestellt ist. Die M-CREATE Anforderung muß vom Manager
jedes Mal wieder zum automatischen Alarmdatenabgleich mit
wiederkehrender Übermittlung von Alarmen an den definierten
Zeitpunkten initiiert und dem Agent bekannt gemacht werden.
Die Nachrichten folgen generischen CMISE-standardisierten
(Common Management Information Service Element) Prozeduren,
die gemäß ITU-T X.710 definiert sind. Die ITU-T X.733 defi
niert den Inhalt einer standardisierten Alarmübertragung
(alarm report), die gemäß den M-EVENT-REPORT Services durch
geführt wird. Die Korrelationsinformationen und Parameter
werden in die Nachrichten bzw. in bestimmte Nachrichtenfelder
eingetragen. Des weiteren versehen die Manager MA1, MA2 die
Parameter zur Steuerung des Alarmdatenabgleichs mit bestimm
ten Parameterwerten und tragen sie einzeln oder mehrfach in
die jeweilige Anforderungsnachricht ein. Das Beispiel in Fig.
4 zeigt den Nachrichtenfluß nur anhand beispielhafter
Nachrichten, wobei diese parallel zwischen dem Agent AG und
den Managern MA1, MA2 oder seriell zwischen dem Agent AG und
dem einzelnen Manager MA1 übertragen werden können.
Sobald nach einer Unterbrechung der Verbindung die Kommunika
tion zwischen dem Manager MA1, MA2 und dem Agent AG wieder
hergestellt ist, sendet jeder Manager MA1, MA2 die M-CREATE
Anforderung mit einer Nachricht alaAS (alarm Alignment Sche
duler) zum Agent AG, mit der zum automatischen Übermitteln
der Alarmdaten in periodischen Zeitabständen aufgerufen wird.
Zu diesem Zweck sendet der Manager einen Startzeitpunkt begT
und einen Endezeitpunkt endT für den gesamten Alarmdatenab
gleich sowie ein Zeitintervall int zur Wiederholung des je
weiligen Alarmdatenabgleichs. Zusätzlich wird eine vom Mana
ger MA1, MA2 definierte Korrelationsinformation alaAH (alarm
Alignment Handle) mitgesendet, die eine direkte Zuordnung der
aktuellen M-CREATE-Anforderung zu allen nachfolgenden Agent-
Nachrichten kennzeichnet. Damit ist bei mehreren Managern die
aktuelle Anforderung auch dem jeweiligen Manager zuordenbar,
sodaß die parallelen Realignments der Manager voneinander un
abhängig initiiert, durchgeführt und beendet werden können.
Des weiteren enthält die Nachricht alaAS auch eine Zustands
information admS für den Agent, die zuvor vom Manager zum Un
terbrechen des automatischen Alarmdatenabgleichs gesetzt und
zum Fortsetzen rückgesetzt werden kann.
Die Nachricht alaAS enthält optional auch die vom Manager
eingetragenen Parameterwerte für den nachfolgenden Funktions
ablauf. Damit wird eine individuelle Funktionsausführung
(Action) der parameterabhängigen periodischen Übermittlung
der Alarme vom Agent AG angefordert. Die Parametrisierung
kann vorzugsweise mit einem oder mehreren eingestellten Para
meterwerten relEN (related Entities), relPS (related percei
ved Severity), priSV (prio severity), relTI (related Time In
terval), priDT (prio Detection Time) erfolgen. Durch den spe
zifischen Parameterwert werden vom Agent Alarme angefordert,
- - die von ausgewählten Agenteinheiten stammen (relEN),
- - für die eine Dringlichkeit angenommen wird (relPS),
- - anhand dessen der Agent beim Senden eine Priorisierung der angeforderten Alarme nach deren Dringlichkeit, vorzugsweise anhand unterschiedlicher Dringlichkeitswerte (priSV), vor nimmt,
- - die innerhalb eines durch einen Startzeitpunkt und einen Endzeitpunkt definierten Zeitraums entstehen (relTI),
- - anhand dessen der Agent beim Senden eine Priorisierung der Alarme nach dem Entstehungszeitpunkt der Alarme vornimmt (priDT).
Die Parameterwerte relEN . . . sind in einem gemäß dem Standard
vorgegebenen Nachrichtenfeld der Nachricht alaAS enthalten,
um bereits vorhandene und definierte Felder für die Parame
trisierung mitbenutzen zu können. Eine günstige Variante un
ter Einbeziehung der Zeit besteht darin, daß von dem Agent
die Alarmdaten der Alarme mit den ältesten Entstehungszeit
punkten zuerst und die Alarmdaten der Alarme mit den jüngsten
Entstehungszeitpunkten zuletzt bereitgestellt und gesendet
werden. Eine besonders geeignete Variante der Kombination der
Parameterwerte bezüglich Zeit und Dringlichkeit besteht dar
in, daß von dem Agent die Alarmdaten der Alarme mit kriti
scher Dringlichkeit, bei der die Funktionalität als nicht
mehr gegeben angenommen wird, zuerst und die Alarmdaten der
Alarme mit unkritischer Dringlichkeit, bei der die Funk
tionalität als noch gegeben angenommen wird, zuletzt bereit
gestellt und gesendet werden.
Im Anschluß an die Auswertung der Parameter in der eingetrof
fenen Nachricht alaAS startet der Agent AG den Alarmdatenab
gleich durch Erzeugen einer Nachricht staAA (start Alarm
Alignment), sobald der vom Manager definierter Startzeitpunkt
begT erreicht ist. Einfügen einer vom Agent definierten Kor
relationsinformation aliNI (alignment Notification Id) zusam
men mit der Korrelationsinformation alaAH in die Nachricht
staAA ist der nächste Schritt. Die vom Agent AG generierte
Korrelationsinformation aliNI ermöglicht eine direkte Korre
lation nachfolgender Alarme zu dieser Nachricht staAA. Die
Korrelationsinformation aliNI ist beispielsweise in dem stan
dardisierten Nachrichtenfeld "notification Identifier" der
Nachricht staAA eingetragen. Beide Informationen alaAH, aliNI
werden gemeinsam in der Nachricht staAA vom Agent AG zu den
Managern MA1, MA2 ausgesendet. Dadurch können "alignment
bezogene" M-EVENT-REPORT Nachrichten verschiedener M-CREATE
Anforderungen voneinander unterschieden werden, aber auch von
regulären M-EVENT-REPORT Nachrichten, die mit dem Datenab
gleich nichts zu tun haben. Eine Alignment-Prozedur stoppt
nämlich nicht zwingend andere M-EVENT-REPORT Nachrichten, die
während der Alignment-Prozedur spontan auftreten und an den
oder die Manager gesendet werden.
Über die in der Nachricht alaAS mitgesendete Korrelationsin
formation alaAH lassen sich direkt die folgenden Nachrichten
staAA und alaAS korrelieren, da sie ebenfalls die Korrelati
onsinformation alaAH enthalten. Die Nachrichten alNO sind
über die Korrelationsinformation aliNI mit der Nachricht
staAA direkt korreliert. Der jeweilige Manager kann die Nach
richt alaAS mit den nachfolgenden Nachrichten alNO indirekt
über die beiden in der Nachricht staAA enthaltenen Korrelati
onsinformationen alaAH und aliNI korrelieren.
Im Anschluß an den Start des automatischen Alarmdatenab
gleichs erfolgt die sukzessive Übertragung der Alarme mit den
zugehörigen Alarmdaten in aufeinanderfolgenden Nachrichten
alNO (alarm notification) unter Verwendung des M-EVENT-REPORT
Service. Dabei weisen die einzelnen Nachrichten alNO jeweils
die Korrelationsinformation aliNI - beispielsweise in dem de
finierten Nachrichtenfeld "correlated Notifications" - auf.
Nach der letzten Meldung eines Alarms in einer Sequenz von
Nachrichten alNO erzeugt der Agent AG die Endenachricht endA
(end Alignment) gemäß dem M-EVENT-Service, die ebenfalls die
Korrelationsinformation aliNI enthält. Diese Korrelationsin
formation ist die vom Manager MA1, MA2 zuvor definierte Kor
relationsinformation. Für den Fall, daß zum jeweiligen durch
Scheduling" festgelegten Alignment-Zeitpunkt keine aktiven
Alarme gespeichert sind oder alle Alarme vom aktuellen Filter
EFD1, EFD2 gesperrt werden, initiiert der Agent die Nachricht
endA unmittelbar nach Erhalt der Nachricht staAA.
Die obige Prozedur des automatischen Alarmdatenabgleichs wird
bei jedem neu begonnenen Alignment - abhängig von dem mitge
teilten Zeitintervall int - wiederkehrend durchgeführt, bis
der Endezeitpunkt endT des gesamten Alignments erreicht ist.
Die Korrelationsinformationen alaAH, aliNI dienen der eindeu
tigen Zuordnung mehrerer Anforderungen - möglicher simultaner
Realignments zu mehreren Managern oder serieller Realignments
zu einem einzelnen Manager. Auch wenn das zu Fig. 4 bechriebe
ne Beispiel sich auf parallel Realignments zu mehreren Mana
gern bezieht, kann der Nachrichtenfluß selbstverständlich auf
mehrere, von einem einzigen Manager nacheinander ausgelöste
Anforderungen angewendet werden, mit dem Vorteil, daß durch
die eindeutige Zuordnung anhand der Korrelationsinformationen
für den einzelnen Manager die Möglichkeit besteht, die ein
treffenden Antworten des Agenten mit den Alarmdaten auch bei
Nichteinhalten der Reihenfolge eindeutig den Anforderungen
zuordnen zu können - beispielsweise unterschiedlichen Anwen
dungen im Manager. Nacheinander gesendete Anforderungen kön
nen sich gegebenenfalls gegenseitig überholen, beispielsweise
dann, wenn zwischen Agent und Manager ein Paketnetz durchlau
fen wird.
Fig. 5 zeigt den Nachrichtenfluß gemäß Fig. 4 für einen perio
disch wiederkehrenden, automatischen Alarmdatenabgleich am
Beispiel des die Dringlichkeit betreffenden Parameterwertes
priSV. Der Parameterwert priSV nimmt den Wert true an, was
dem Agent signalisiert, daß er bei der Sendereihenfolge der
Alarme nach unterschiedlichen Dringlichkeitswerten priorisie
ren soll. Für den Fall, daß der Parameterwert priSV einen an
deren Wert (z. B. false) annimmt, verzichtet der Agent auf die
Priorisierung nach Dringlichkeitswerten. Wird das optional
vorhandene Feld vom Manager zur Steuerung der angeforderten
Alarme erst gar nicht benutzt, werden alle aktive Alarme, die
eine angenommen Dringlichkeit aufweisen, übertragen (default-
Modus). Weitere Parameterwerte - siehe Fig. 4 - sind zusätz
lich vom Manager setzbar.
Im vorliegenden Beispiel weisen der Startzeitpunkt (Datum und
Zeit) begT den Wert "13.01.1998 12:00:00", der Endezeitpunkt
endT den Wert "14.01.1998 11:00:00" und das Zeitintervall int
den Wert "12h" auf. Dies bedeutet, daß gezielt nur die Alarme -
priorisiert nach deren Dringlichkeit (siehe obige Ausfüh
rungen) -, die zwischen "13.01.1998 12:00:00" und "14.01.1998
11:00:00" auftreten, gemäß dem automatischen Alignment,
das alle 12 Stunden vom Agent wiederholt initiiert wird, vom
Agent zur Verfügung gestellt und zum Manager gesendet werden.
Daher wird die Nachricht staAA vom Agent ab einem Zeitpunkt
evt (event Time) gesendet, sobald dieser den Wert "13.01.1998
12:00:00" erreicht. Die folgenden Nachrichten alNO enthalten
die Alarmdaten der ausgewählten Alarme unter Verwendung des
M-EVENT-REPORT Service. Die einzelnen Nachrichten alNO weisen
neben der Korrelationsinformation aliNI einen Wert für die
Dringlichkeit SV (perceived Severity) des Alarms auf. Die un
terschiedlichen Dringlichkeitswerte reichen von "kritisch"
cri (critical) über "wichtig" maj (major), "weniger wichtig"
min (minor) bis zu "unkritisch" war (warning). Als kritisch
wird ein Alarm aufgefasst, bei der die Funktionalität als
nicht mehr gegeben angenommen wird, während bei einem unkri
tischen Alarm die Funktionalität als noch gegeben betrachtet
wird. Empfängt der Manager den Dringlichkeitswert war, fasst
er diesen Alarm als Warnung bezüglich einer möglichen Beein
trächtigung der Funktionen des Agent auf.
Bei dem eingestellten Parameter priSV bezüglich der Dring
lichkeit ist der zuerst gemeldete Alarm mit entsprechenden
Alarmdaten in der Nachricht alNO als Alarm kritischer Dring
lichkeit, SV=cri, gekennzeichnet. Die nächstfolgenden Nach
richten alNO mit Alarmdaten enthalten einen Wert SV=maj zur
Kennzeichnung eines Alarms mit einer wichtigen Dringlichkeit
sowie einen Wert SV=min zur Kennzeichnung eines Alarms mit
einer weniger wichtigen Dringlichkeit. Die am Ende des auto
matischen Alignments gesendete Nachricht endA zeigt dem Mana
ger an, daß die Sequenz von Alarmdaten der im Agent gespei
cherten Alarme beendet ist. Dabei weist die Nachricht endA
die vom Agent zuvor zugewiesene Korrelationsinformation aliNI
auf.
Ein weiteres Mal startet der Agent automatisch einen Alarmda
tenabgleich, sobald der Zeitpunkt evt (event Time) den Wert
"13.01.1998 24:00:00" annimmt, d. h. das eingestellte Zeitin
tervall int="12h" für die Wiederholung erreicht. Im folgenden
sendet der Agent - analog zu obigen Beispielen - einige
Alarmdaten in den Nachrichten alNO, deren Sendereihenfolge
durch die Dringlichkeitswerte der vorhandenen Alarme bestimmt
ist. Das Ende des zweiten Alarmdatenabgleichs erkennt der Ma
nager an der ebenfalls zuletzt vom Agent gesendeten Nachricht
endA mit entsprechender Korrelationsinformation aliNI. Weite
re Abgleiche sind in dem durch die Werte begT, endT, int ein
gestellten beispielhaften Zeitfenster nicht vorgesehen.
Grundsätzlich können die vom Agent automatisch initiierten
Abgleiche in kürzeren Zeitabständen und damit in einer höhe
ren Anzahl je nach dem vom Manager bestimmten Zeitfenster
auftreten.
Im Gegensatz zu der Einstellung pro M-CREATE Anforderung
zeigt Fig. 6 den Nachrichtenfluß zwischen dem Manager und dem
Agent zur parameterabhängigen Steuerung des automatischen
Alarmdatenabgleichs durch eine einmalige Einstellung der
zeitbezogenen Werte begT, endT, int, die für mehrere an
schließende Anforderungen gemeinsam Gültigkeit behält. Damit
wird in vorteilhafter Weise ein periodisches Übertragen defi
nierter Alarme für den automatischen Alarmdatenabgleich er
zielt, ohne daß es jedes Mal einer Neueinstellung der obigen
zeitbezogenen Werte bedarf. Zu diesem Zweck ist der M-EVENT
REPORT Nachrichtensequenz - mit den Nachrichten staAA, alNO
und endA, siehe Beschreibung zu Fig. 4 - eine M-SET Anforde
rung vorangestellt, mit der eine Nachricht alaSC einschließ
lich der vom Manager optional einfügbaren Parameter relEN,
relPS, priSV, relTI, priDT als Auswahlkriterien für die vom
Agent zu übertragenden Alarme gesendet wird. Diese optionalen
Parameter können unabhängig von den zeitbezogenen Werten
begT, endT, int von dem Manager geändert werden. Den Parame
tern beigestellt ist die Korrelationsinformation alaAH. Er
findungsgemäß sind auch die Werte begT für den Startzeit
punkt, endT für den Endezeitpunkt sowie int für das Zeitin
tervall zum periodischen Wiederholen des Alarmdatenabgleichs
eingetragen. Das Setzen der Zustandsinformation admST zum Un
terbrechen des automatischen Alarmdatenabgleichs und das
Rücksetzen der Zustandsinformation admST zum späteren Fort
setzen des automatischen Alarmdatenabgleichs kann ebenfalls
vom Manager durchgeführt werden.
Fig. 7 zeigt den zur Vorgehensweise von Fig. 6 gehörigen Nach
richtenfluß bei Einstellung des zu Fig. 5 bereits beschriebe
nen Parameters priSV. Im Unterschied zu Fig. 5 werden das
durch den Anfangszeitpunkt begT und den Endezeitpunkt endT
sowie das Zeitintervall int festgelegte Zeitfenster und der
Parameter priSV - nur in diesem Zeitfenster sollen vom Agent
die Alarme nach Dringlichkeit priorisiert werden - vom Mana
ger in die Nachricht alaSC gemäß der M-SET Anforderung einge
fügt und vorab zum Agent gesendet. Die Einstellungen behalten
für alle darauffolgenden Anforderungsnachrichten ihre Gültig
keit, bis eine neue Setznachricht M-SET die bisherigen Para
meter und das alte Zeitfenster überschreibt oder für ungültig
erklärt. Ein weiterer Unterschied betrifft das Zeitfenster,
das durch den Startzeitpunkt begT="16.01.1998 12:00:00", den
Endezeitpunkt endT="16.01.1998 22:15:00" und das Zeitinter
vall int="6h" vom Manager definiert ist. Dies bedeutet, daß
gezielt nur die Alarme - priorisiert nach deren Dringlichkeit
(siehe obige Ausführungen) -, die zwischen "16.01.1998
12:00:00" und 16.01. 1998 22:15:00" auftreten, gemäß dem au
tomatischen Alignment, das alle 6 Stunden vom Agent wieder
holt initiiert wird, vom Agent zur Verfügung gestellt und zum
Manager gesendet werden.
Daher wird die Nachricht staAA vom Agent am Zeitpunkt
evt="16.01.1998 12:00:00" erstmalig gesendet. Die folgenden
Nachrichten alNO enthalten die Alarmdaten der ausgewählten
Alarme unter Verwendung des M-EVENT-REPORT Service. Die ein
zelnen Nachrichten alNO weisen neben der Korrelationsinforma
tion aliNI den Wert für die Dringlichkeit SV (perceived Seve
rity) des Alarms auf. Bei dem eingestellten Parameter priSV
bezüglich der Dringlichkeit ist der zuerst gemeldete Alarm
mit entsprechenden Alarmdaten in der Nachricht alNO als Alarm
kritischer Dringlichkeit, SV=cri, gekennzeichnet. Die nächst
folgende Nachrichten alNO mit Alarmdaten enthält den Wert
SV=min zur Kennzeichnung eines Alarms mit einer weniger wich
tigen Dringlichkeit. Der nächste vom Agent in der Nachricht
alNO gemeldete Alarm hat den Wert SV=war zur Kennzeichnung
eines Alarms mit lediglich einer Warnung, bei der die Funk
tionalität noch als gewährleistet angenommen ist. Die am Ende
des automatischen Alignments an den Manager gesendete Nach
richt endA weist die vom Agent zuvor zugewiesene Korrelati
onsinformation aliNI auf.
Ein weiteres Mal startet der Agent automatisch den Alarmda
tenabgleich, sobald der Zeitpunkt evt den Wert "16.01.1998
18:00:00" annimmt, d. h. das eingestellte Zeitintervall
int="6h" für die Wiederholung erreicht. Im folgenden sendet
der Agent - analog zu obigen Beispielen - einige Alarmdaten
in den Nachrichten alNO, deren Sendereihenfolge durch die
Dringlichkeitswerte der vorhandenen Alarme bestimmt ist. Das
Ende des zweiten Alarmdatenabgleichs erkennt der Manager an
der ebenfalls zuletzt vom Agent gesendeten Nachricht endA mit
entsprechender Korrelationsinformation aliNI. Weitere Abglei
che sind in dem durch die Werte begT, endT, int eingestellten
beispielhaften Zeitfenster nicht vorgesehen. Grundsätzlich
können die vom Agent automatisch initiierten Abgleiche in
kürzeren Zeitabständen und damit in einer höheren Anzahl je
nach dem vom Manager bestimmten Zeitfenster auftreten.
Claims (24)
1. Verfahren zur Behandlung von Alarmen in einem Kommunikati
onssystem durch ein mehrere Managementebenen (A, B, C) auf
weisendes Managementnetz, wobei für einen Alarmdatenabgleich
zwischen einem Agent (AG) einer Managementebene (B, C) und
zumindest einem Manager (MA1, MA2) einer nächsthöheren Mana
gementebene (A, B) die Alarmdaten aktiver Alarme übertragen
werden, bei dem
- - von dem Manager (MA1, MA2) eine Nachricht (alaAS, alaSC) zu dem Agent (AG) gesendet wird, durch die ein automatischer, von dem Agent (AG) wiederholt initiierter Alarmdatenabgleich angefordert wird,
- - von dem Manager (MA1, MA2) eine Korrelationsinformation (aliNI) für eine Zuordnung der Anforderung zu den vom Agent (AG) nachfolgend gesendeten Nachrichten (alNO) mit den Alarm daten empfangen wird, und
- - von dem Manager (MA1, MA2) der automatische Alarmdatenab gleich abhängig von zumindest einem zum Agent (AG) gesendeten Parameter (par) gesteuert wird.
2. Verfahren nach Anspruch 1, bei dem
von dem Manager (MA1, MA2) der oder die Parameter (par) in
der Nachricht (alaAS, alaSC) zum automatischen Alarmdatenab
gleich gesendet werden.
3. Verfahren nach Anspruch 1 oder 2, bei dem
die Nachricht (alaAS) zum automatischen Alarmdatenabgleich
von dem Manager (MA1, MA2) einzeln für jede Anforderung zu
dem Agent (AG) gesendet wird.
4. Verfahren nach Anspruch 1 oder 2, bei dem
die Nachricht (alaSC) zum automatischen Alarmdatenabgleich
von dem Manager (MA1, MA2) für mehrere Anforderungen gemein
sam zu dem Agent (AG) gesendet wird.
5. Verfahren nach einem der vorhergehenden Ansprüche, bei dem
von dem Agent (AG) nach jedem durchgeführten Alarmdatenab
gleich eine Nachricht (endA) zum Manager (MA1, MA2) gesendet
wird, mit der dem Manager (MA1, MA2) das Ende des jeweiligen
Alarmdatenabgleichs mitgeteilt wird.
6. Verfahren nach einem der vorhergehenden Ansprüche, bei dem
von dem Manager (MA1, MA2) in der Nachricht (alaAS, alaSC)
zum automatischen Alarmdatenabgleich ein Startzeitpunkt
(begT) und ein Endezeitpunkt (endT) für den gesamten Alarmda
tenabgleich sowie ein Zeitintervall (int) zur Wiederholung
des jeweiligen Alarmdatenabgleichs gesendet werden.
7. Verfahren nach Anspruch 6, bei dem
von dem Manager (MA1, MA2) zusätzlich eine Zustandsinfor
mation (admST) zum Agent (AG) gesendet wird, die zum Unterbre
chen des automatischen Alarmdatenabgleichs gesetzt und zum
Fortsetzen rückgesetzt wird.
8. Verfahren nach einem der vorhergehenden Ansprüche, bei dem
ein Parameter (par) von dem Manager (MA1, MA2) mit einem Pa
rameterwert (relEN) versehen wird, durch den vom Agent (AG)
Alarme angefordert werden, die von ausgewählten Agenteinhei
ten stammen.
9. Verfahren nach einem der vorhergehenden Ansprüche, bei dem
ein Parameter (par) von dem Manager (MA1, MA2) mit einem Pa
rameterwert (relPS) versehen wird, durch den vom Agent (AG)
Alarme angefordert werden, für die eine Dringlichkeit ange
nommen wird.
10. Verfahren nach Anspruch 9, bei dem
von dem Manager (MA1, MA2) ein zusätzlicher Parameterwert
(priPS) benutzt wird, anhand dessen der Agent (AG) eine Prio
risierung beim Senden der angeforderten Alarme nach deren
Dringlichkeit vornimmt.
11. Verfahren nach Anspruch 10, bei dem
der Agent (AG) die Priorisierung der zu dem Manager (MA1,
MA2) zu übertragenden Alarme nach unterschiedlichen Dring
lichkeitswerten (cri, maj, min, war) vornimmt.
12. Verfahren nach einem der vorhergehenden Ansprüche, bei
dem ein Parameter (par) von dem Manager (MA1, MA2) mit einem
Parameterwert (relTI) versehen wird, durch den vom Agent (AG)
Alarme angefordert werden, die innerhalb eines durch einen
Anfangszeitpunkt (inst) und einen Endzeitpunkt (inen) defi
nierten Zeitraum entstehen.
13. Verfahren nach einem der vorhergehenden Ansprüche, bei
dem von dem Manager (MA1, MA2) ein zusätzlicher Parameterwert
(priDT) benutzt wird, anhand dessen der Agent (AG) eine Prio
risierung beim Senden der Alarme nach dem Entstehungszeit
punkt (evT) der Alarme vornimmt.
14. Verfahren nach Anspruch 13, bei dem
von dem Agent (AG) die Alarmdaten der Alarme mit kritischer
Dringlichkeit, bei der die Funktionalität als nicht mehr ge
geben angenommen wird, zuerst und die Alarmdaten der Alarme
mit unkritischer Dringlichkeit, bei der die Funktionalität
als noch gegeben angenommen wird, zuletzt automatisch bereit
gestellt und gesendet werden.
15. Kommunikationssystem zur Behandlung von Alarmen durch ein
mehrere Managementebenen (A, B, C) aufweisendes Management
netz, wobei für einen Alarmdatenabgleich zwischen einem Agent
(AG) einer Managementebene (z. B. B) und zumindest einem Mana
ger (MA1, MA2) einer nächsthöheren Managementebene (z. B. A)
die Alarmdaten aktiver Alarme übertragen werden,
- - Einrichtungen (M-CTR) in dem Manager (MA1, MA2) für das Senden einer Nachricht (alaAS, alaSc) zu dem Agent (AG) ge sendet wird, durch die ein automatischer, von dem Agent (AG) wiederholt initiierter Alarmdatenabgleich angefordert wird,
- - Einrichtungen (M-CTR) in dem Manager (MA1, MA2) für das Empfangen einer Korrelationsinformation (aliNI) für eine Zu ordnung der jeweiligen Anforderung zu den vom Agent (AG) nachfolgend gesendeten Nachrichten (alNO) mit den Alarmdaten, und
- - Einrichtungen (M-CTR) in dem Manager (MA1, MA2) für eine Steuerung des Alarmdatenabgleich abhängig von zumindest einem zum Agent (AG) gesendeten Parameter (par).
16. Kommunikationssystem nach Anspruch 15, bei dem
die Einrichtungen (M-CTR) in dem Manager (MA1, MA2) den oder
die Parameter (par) in jede Anforderungsnachricht (repAA)
einfügen.
17. Kommunikationssystem nach Anspruch 15 oder 16, bei dem
die Einrichtungen (M-CTR) in dem Manager (MA1, MA2) die Nach
richt (alaAS) zum automatischen Alarmdatenabgleich einzeln
für jede Anforderung zu dem Agent (AG) senden.
18. Kommunikationssystem nach Anspruch 15 oder 16, bei dem
die Einrichtungen (M-CTR) in dem Manager (MA1, MA2) die Nach
richt (alaSC) zum automatischen Alarmdatenabgleich gemeinsam
für mehrere Anforderungen zu dem Agent (AG) senden.
19. Kommunikationssystem nach einem der Ansprüche 15 bis 18,
bei dem die Einrichtungen (M-CTR) in dem Manager (MA1, MA2)
in die Nachricht (alaAS, alaSC) zum automatischen Alarmdaten
abgleich einen Startzeitpunkt (begT) und einen Endezeitpunkt
(endT) für den gesamten Alarmdatenabgleich sowie ein Zeit in
tervall (int) zur Wiederholung des jeweiligen Alarmdatenab
gleichs einfügen.
20. Kommunikationssystem nach einem der Ansprüche 15 bis 19,
bei dem von dem Manager (MA1, MA2) ein Parameter (par) mit
einem Parameterwert (relEN) versehen ist, durch den vom Agent
(AG) Alarme angefordert werden, die von ausgewählten Agent
einheiten stammen.
21. Kommunikationssystem nach einem der Ansprüche 15 bis 20,
bei dem ein Parameter (par) von dem Manager (MA1, MA2) mit
einem Parameterwert (relPS) versehen ist, durch den vom Agent
(AG) Alarme angefordert werden, für die eine Dringlichkeit
angenommen wird.
22. Kommunikationssystem nach Anspruch 21, bei dem
von dem Manager (MA1, MA2) ein zusätzlicher Parameterwert
(priPS) benutzt ist, anhand dessen der Agent (AG) eine Prio
risierung beim Senden der angeforderten Alarme nach deren
Dringlichkeit vornimmt.
23. Kommunikationssystem nach einem der Ansprüche 15 bis 22,
bei dem ein Parameter (par) von dem Manager (MA1, MA2) mit
einem Parameterwert (relTI) versehen ist, durch den vom Agent
(AG) Alarme angefordert werden, die innerhalb eines durch ei
nen Anfangszeitpunkt (inst) und einen Endzeitpunkt (inen) de
finierten Zeitintervalls entstehen.
24. Kommunikationssystem nach einem der Ansprüche 15 bis 23,
von dem Manager (MA1, MA2) ein zusätzlicher Parameterwert
(priDT) benutzt ist, anhand dessen der Agent (AG) eine Prio
risierung beim Senden der Alarme nach dem Entstehungszeit
punkt (evT) der Alarme vornimmt.
Priority Applications (7)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
DE19801785A DE19801785C2 (de) | 1998-01-19 | 1998-01-19 | Verfahren und Kommunikationssystem zur Behandlung von Alarmen durch ein mehrere Managementebenen aufweisendes Managementnetz |
KR10-2000-7007887A KR100381799B1 (ko) | 1998-01-19 | 1999-01-14 | 다수의 관리 층을 가진 관리 네트워크를 사용한 알람 처리방법 및 통신 시스템 |
EP99928872A EP1058983B1 (de) | 1998-01-19 | 1999-01-14 | Verfahren und kommunikationssystem zur behandlung von alarmen durch ein mehrere managementebenen aufweisendes managementnetz |
PCT/DE1999/000072 WO1999037102A2 (de) | 1998-01-19 | 1999-01-14 | Verfahren und kommunikationssystem zur behandlung von alarmen durch ein mehrere managementebenen aufweisendes managementnetz |
CN99802239A CN1288622A (zh) | 1998-01-19 | 1999-01-14 | 利用一种具有多个管理级的管理网络处理告警的方法和通信系统 |
BR9907029-4A BR9907029A (pt) | 1998-01-19 | 1999-01-14 | Processo e sistema de comunicações para o tratamento de alarmes por intermédio de uma rede de administração que apresenta vários nìveis de gestão |
JP2000540682A JP2002510178A (ja) | 1998-01-19 | 1999-01-14 | 複数のマネージメントレベルを有するマネージメントネットワークによるアラームの処理のための方法及び通信システム |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
DE19801785A DE19801785C2 (de) | 1998-01-19 | 1998-01-19 | Verfahren und Kommunikationssystem zur Behandlung von Alarmen durch ein mehrere Managementebenen aufweisendes Managementnetz |
Publications (2)
Publication Number | Publication Date |
---|---|
DE19801785A1 true DE19801785A1 (de) | 1999-07-22 |
DE19801785C2 DE19801785C2 (de) | 2000-04-27 |
Family
ID=7855016
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
DE19801785A Expired - Fee Related DE19801785C2 (de) | 1998-01-19 | 1998-01-19 | Verfahren und Kommunikationssystem zur Behandlung von Alarmen durch ein mehrere Managementebenen aufweisendes Managementnetz |
Country Status (7)
Country | Link |
---|---|
EP (1) | EP1058983B1 (de) |
JP (1) | JP2002510178A (de) |
KR (1) | KR100381799B1 (de) |
CN (1) | CN1288622A (de) |
BR (1) | BR9907029A (de) |
DE (1) | DE19801785C2 (de) |
WO (1) | WO1999037102A2 (de) |
Cited By (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP1079566A2 (de) * | 1999-08-23 | 2001-02-28 | Motorola Ireland Limited | Systemverwaltung in einem Kommunikationsnetzwerk mit SNMP und CMIP Agenten |
WO2002007703A2 (de) * | 2000-07-24 | 2002-01-31 | Siemens Aktiengesellschaft | Entstörungsprozedur für ein übergeordnetes nmc durch korrelation von alarmen mit ergebnissen von automatischen tests |
EP1191803A1 (de) * | 2000-09-20 | 2002-03-27 | Lucent Technologies Inc. | Verfahren und System zur Erkennung von Netzzuständen eines hierarchisch strukturierten Netzes, dessen Netzelemente in mindestens zwei Ebenen angeordnet sind |
EP1195999A2 (de) * | 2000-10-06 | 2002-04-10 | Motorola, Inc. | Netzwerksteuerungssystem und Verwaltungssteuerungsverfahren in einem Kommunikationssystem |
EP1437859A1 (de) * | 2003-01-10 | 2004-07-14 | Siemens Aktiengesellschaft | Verfahren zur Behandlung von Alarmen durch ein Managementnetz mit mehreren Ebenen in einem Kommunikationssystem |
WO2004064322A1 (de) * | 2003-01-10 | 2004-07-29 | Siemens Aktiengesellschaft | Verfahren zur behandlung von alarmen durch ein managementnetz mit mehreren ebenen in einem kommunikationssystem |
WO2004107790A1 (de) * | 2003-05-31 | 2004-12-09 | Siemens Aktiengesellschaft | Verfahren zur behandlung von parameteränderungen in einem managementnetz eines zellularen kommunikationssystems und kommunikationssystem |
WO2005034428A2 (de) * | 2003-09-30 | 2005-04-14 | Siemens Aktiengesellschaft | Verfahren zur synchronisierung von alarmen in einem managementsystem eines kommunikationsnetzes |
US7047295B1 (en) | 1999-08-24 | 2006-05-16 | Siemens Aktiengellschaft | Generic alignment method in a multimanager environment |
EP1742415A1 (de) * | 2005-07-05 | 2007-01-10 | Siemens Aktiengesellschaft | Automatische Korrektur von Alarmlisten in Managementsystemen |
US7747714B1 (en) | 1999-11-09 | 2010-06-29 | Siemens Aktiengesellschaft | Method and communication system for managing a communication network |
DE10066463B4 (de) * | 1999-10-15 | 2016-09-15 | Fisher-Rosemount Systems, Inc. | Verfahren zur Kommunikation mit verzögerter Bestätigung und Alarmverwaltung |
Families Citing this family (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20020184368A1 (en) * | 2001-04-06 | 2002-12-05 | Yunsen Wang | Network system, method and protocols for hierarchical service and content distribution via directory enabled network |
DE502004005203D1 (de) * | 2004-06-29 | 2007-11-22 | Siemens Ag | Verfahren und Einrichtung zum Wechsel des Betriebsmodus eines Agenten eines Managementnetzes |
CN100421384C (zh) * | 2005-04-08 | 2008-09-24 | 华为技术有限公司 | 屏蔽处理瞬断通知事件的方法 |
DE102006036566B4 (de) * | 2006-08-04 | 2009-02-19 | Nokia Siemens Networks Gmbh & Co.Kg | Vorabinformation von Managern über die Itf-N Schnittstelle |
US9225587B2 (en) * | 2009-12-10 | 2015-12-29 | Nokia Solutions And Networks Oy | Mechanism for alarm management of Femto related systems to avoid alarm floods |
CN104427539B (zh) * | 2013-08-21 | 2018-05-11 | 中国移动通信集团公司 | 确定网关状态的方法及网关设备 |
EP3114538B1 (de) * | 2014-03-06 | 2019-10-16 | ABB Schweiz AG | Optimiertes verfahren zum sortieren von alarmen |
Family Cites Families (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2810171B2 (ja) * | 1989-12-18 | 1998-10-15 | 株式会社日立製作所 | ネットワークシステム及びこれを適用するネットワーク管理方法 |
JP2918088B2 (ja) * | 1994-02-10 | 1999-07-12 | 株式会社日立製作所 | 階層型ネットワーク管理システムおよびネットワーク管理情報の制御方法 |
JP3521955B2 (ja) * | 1994-06-14 | 2004-04-26 | 株式会社日立製作所 | 階層型ネットワーク管理システム |
JPH0895888A (ja) * | 1994-09-29 | 1996-04-12 | Fujitsu Ltd | ネットワーク制御・管理システム |
IT1271326B (it) * | 1994-12-23 | 1997-05-27 | Sits Soc It Telecom Siemens | Procedimento per il riallineamento automatico nel riporto di evento in un sistema di gestione e relativo sistema |
SE504072C2 (sv) * | 1995-02-08 | 1996-11-04 | Ericsson Telefon Ab L M | Anordning och förfarande vid kommunikationshantering och ett telekommunikationssystem med en hanterande anordning |
JPH08265317A (ja) * | 1995-03-20 | 1996-10-11 | Pfu Ltd | ネットワーク管理システム |
JP3282652B2 (ja) * | 1996-02-19 | 2002-05-20 | 日本電気株式会社 | Osiマルチレイヤ管理システム |
US5930476A (en) * | 1996-05-29 | 1999-07-27 | Sun Microsystems, Inc. | Apparatus and method for generating automatic customized event requests |
JP3161369B2 (ja) * | 1997-06-12 | 2001-04-25 | 日本電気株式会社 | ネットワーク管理情報収集方式 |
DE19752614C2 (de) * | 1997-11-27 | 2000-04-13 | Siemens Ag | Verfahren und Kommunikationssystem zur Behandlung von Alarmen durch ein mehrere Managementebenen aufweisendes Managementnetz |
-
1998
- 1998-01-19 DE DE19801785A patent/DE19801785C2/de not_active Expired - Fee Related
-
1999
- 1999-01-14 JP JP2000540682A patent/JP2002510178A/ja active Pending
- 1999-01-14 CN CN99802239A patent/CN1288622A/zh active Pending
- 1999-01-14 WO PCT/DE1999/000072 patent/WO1999037102A2/de active IP Right Grant
- 1999-01-14 KR KR10-2000-7007887A patent/KR100381799B1/ko not_active IP Right Cessation
- 1999-01-14 EP EP99928872A patent/EP1058983B1/de not_active Expired - Lifetime
- 1999-01-14 BR BR9907029-4A patent/BR9907029A/pt not_active Application Discontinuation
Cited By (21)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP1079566A3 (de) * | 1999-08-23 | 2003-06-18 | Motorola Ireland Limited | Systemverwaltung in einem Kommunikationsnetzwerk mit SNMP und CMIP Agenten |
EP1079566A2 (de) * | 1999-08-23 | 2001-02-28 | Motorola Ireland Limited | Systemverwaltung in einem Kommunikationsnetzwerk mit SNMP und CMIP Agenten |
US7047295B1 (en) | 1999-08-24 | 2006-05-16 | Siemens Aktiengellschaft | Generic alignment method in a multimanager environment |
DE10066463B4 (de) * | 1999-10-15 | 2016-09-15 | Fisher-Rosemount Systems, Inc. | Verfahren zur Kommunikation mit verzögerter Bestätigung und Alarmverwaltung |
US9667522B2 (en) | 1999-11-09 | 2017-05-30 | Siemens Aktiengesellschaft | Method and communication system for managing a communication network |
US8332533B2 (en) | 1999-11-09 | 2012-12-11 | Siemens Aktiengesellschaft | Method and communication system for managing a communication network |
US7747714B1 (en) | 1999-11-09 | 2010-06-29 | Siemens Aktiengesellschaft | Method and communication system for managing a communication network |
WO2002007703A2 (de) * | 2000-07-24 | 2002-01-31 | Siemens Aktiengesellschaft | Entstörungsprozedur für ein übergeordnetes nmc durch korrelation von alarmen mit ergebnissen von automatischen tests |
WO2002007703A3 (de) * | 2000-07-24 | 2002-08-15 | Siemens Ag | Entstörungsprozedur für ein übergeordnetes nmc durch korrelation von alarmen mit ergebnissen von automatischen tests |
EP1191803A1 (de) * | 2000-09-20 | 2002-03-27 | Lucent Technologies Inc. | Verfahren und System zur Erkennung von Netzzuständen eines hierarchisch strukturierten Netzes, dessen Netzelemente in mindestens zwei Ebenen angeordnet sind |
CN100433847C (zh) * | 2000-10-06 | 2008-11-12 | 摩托罗拉公司 | 电信网络及其节点、和管理电信系统的方法 |
EP1195999A3 (de) * | 2000-10-06 | 2003-08-06 | Motorola, Inc. | Netzwerksteuerungssystem und Verwaltungssteuerungsverfahren in einem Kommunikationssystem |
EP1195999A2 (de) * | 2000-10-06 | 2002-04-10 | Motorola, Inc. | Netzwerksteuerungssystem und Verwaltungssteuerungsverfahren in einem Kommunikationssystem |
DE10300709A1 (de) * | 2003-01-10 | 2004-08-05 | Siemens Ag | Verfahren zur Behandlung von Alarmen durch ein Managementnetz mit mehreren Ebenen in einem Kommunikationssystem |
WO2004064322A1 (de) * | 2003-01-10 | 2004-07-29 | Siemens Aktiengesellschaft | Verfahren zur behandlung von alarmen durch ein managementnetz mit mehreren ebenen in einem kommunikationssystem |
EP1437859A1 (de) * | 2003-01-10 | 2004-07-14 | Siemens Aktiengesellschaft | Verfahren zur Behandlung von Alarmen durch ein Managementnetz mit mehreren Ebenen in einem Kommunikationssystem |
WO2004107790A1 (de) * | 2003-05-31 | 2004-12-09 | Siemens Aktiengesellschaft | Verfahren zur behandlung von parameteränderungen in einem managementnetz eines zellularen kommunikationssystems und kommunikationssystem |
WO2005034428A2 (de) * | 2003-09-30 | 2005-04-14 | Siemens Aktiengesellschaft | Verfahren zur synchronisierung von alarmen in einem managementsystem eines kommunikationsnetzes |
WO2005034428A3 (de) * | 2003-09-30 | 2005-06-30 | Siemens Ag | Verfahren zur synchronisierung von alarmen in einem managementsystem eines kommunikationsnetzes |
CN101547121B (zh) * | 2003-09-30 | 2011-10-05 | 西门子公司 | 在通信网的管理系统中使警报同步的方法 |
EP1742415A1 (de) * | 2005-07-05 | 2007-01-10 | Siemens Aktiengesellschaft | Automatische Korrektur von Alarmlisten in Managementsystemen |
Also Published As
Publication number | Publication date |
---|---|
JP2002510178A (ja) | 2002-04-02 |
KR100381799B1 (ko) | 2003-04-26 |
EP1058983B1 (de) | 2005-03-23 |
BR9907029A (pt) | 2000-10-17 |
KR20010034223A (ko) | 2001-04-25 |
WO1999037102A2 (de) | 1999-07-22 |
DE19801785C2 (de) | 2000-04-27 |
CN1288622A (zh) | 2001-03-21 |
WO1999037102A3 (de) | 1999-10-07 |
EP1058983A2 (de) | 2000-12-13 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
DE19801784C2 (de) | Verfahren und Kommunikationssystem zur Behandlung von Alarmen durch ein mehrere Managementebenen aufweisendes Managementnetz | |
DE19752614C2 (de) | Verfahren und Kommunikationssystem zur Behandlung von Alarmen durch ein mehrere Managementebenen aufweisendes Managementnetz | |
DE19801785C2 (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 | |
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 | |
DE69128421T2 (de) | Verfahren zur automatischen ausführung von systemrekonfigurationen | |
EP1145538B1 (de) | Verfahren und kommunikationssystem zur behandlung von zustandsinformationen durch ein mehrere managementebenen aufweisendes managementnetz | |
EP1437859A1 (de) | Verfahren zur Behandlung von Alarmen durch ein Managementnetz mit mehreren Ebenen in einem Kommunikationssystem | |
EP1582030B1 (de) | Verfahren zur behandlung von alarmen durch ein managementnetz mit mehreren ebenen in einem kommunikationssystem | |
EP1749369B1 (de) | Verfahren und einrichtungen zum betreiben eines managementnetzes bei ausfall eines managers | |
DE19820215C1 (de) | Verfahren und Managementnetz zur Übertragung von Nachrichten | |
DE69023689T2 (de) | Übertragungsadapter für das Endgerät eines Fernwirksystems. | |
EP1750391A1 (de) | Überwachung eines Agenten in einem Managementsystem | |
DE10134126A1 (de) | Verfahren zum gleichzeitigen Deaktivieren mehrerer Alarme |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
OP8 | Request for examination as to paragraph 44 patent law | ||
D2 | Grant after examination | ||
8364 | No opposition during term of opposition | ||
8327 | Change in the person/name/address of the patent owner |
Owner name: NOKIA SIEMENS NETWORKS GMBH & CO.KG, 81541 MUE, DE |
|
8339 | Ceased/non-payment of the annual fee |