[go: up one dir, main page]
More Web Proxy on the site http://driver.im/

DE19740718C2 - Realignment-Verfahren zwischen einem Betriebs- und Wartungszentrum und einem diesem übergeordneten Netzmanagementzentrum - Google Patents

Realignment-Verfahren zwischen einem Betriebs- und Wartungszentrum und einem diesem übergeordneten Netzmanagementzentrum

Info

Publication number
DE19740718C2
DE19740718C2 DE1997140718 DE19740718A DE19740718C2 DE 19740718 C2 DE19740718 C2 DE 19740718C2 DE 1997140718 DE1997140718 DE 1997140718 DE 19740718 A DE19740718 A DE 19740718A DE 19740718 C2 DE19740718 C2 DE 19740718C2
Authority
DE
Germany
Prior art keywords
interface
alarm
nmc
network management
base station
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.)
Expired - Fee Related
Application number
DE1997140718
Other languages
English (en)
Other versions
DE19740718A1 (de
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.)
Nokia Solutions and Networks GmbH and Co KG
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 DE1997140718 priority Critical patent/DE19740718C2/de
Publication of DE19740718A1 publication Critical patent/DE19740718A1/de
Application granted granted Critical
Publication of DE19740718C2 publication Critical patent/DE19740718C2/de
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/02Standardisation; Integration
    • H04L41/0213Standardised network management protocols, e.g. simple network management protocol [SNMP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/04Network management architectures or arrangements
    • H04L41/046Network management architectures or arrangements comprising network management agents or mobile agents therefor
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06Management of faults, events, alarms or notifications
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06Management of faults, events, alarms or notifications
    • H04L41/0654Management of faults, events, alarms or notifications using network fault recovery

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Description

Die Erfindung betrifft ein Realignment-Verfahren nach dem Oberbegriff des Anspruches 1.
Die Prinzipien des Telekommunikationsmanagementnetzes, die nach dem englischsprachigen Ausdruck "Telecommunications Ma­ nagement Network" auch als TMN-Prinzipien bezeichnet werden, definieren mehrere Ebenen für das Management eines Telekommu­ nikations-Netzes, wobei jede Ebene eine doppelte Funktion hat. Im managenden System ("managing system") hat jede Ebene außer der untersten eine Manager-Funktion für die darunter­ liegende Ebene. Im gemanagten System ("managed 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 Managements eines Telekommunikations-Netzes. Grund­ sätzlich spielt hier der Agent die aktive Rolle, indem er Fehler der eigenen Managementebene rechtzeitig und genau er­ kennt und an den Manager der nächsthöheren Ebene als spontane Ereignisse, sogenannte Alarmnotifikationen ("alarm notifica­ tions") in einer standardisierten Weise, üblicherweise unter Verwendung sogenannter M-EVENT-REPORT überträgt.
Die Übertragung von Alarmen vom Agent zum Manager ist unkri­ tisch, solange der Kommunikationsmechanismus zwischen diesen Systemen nicht gestört ist. Wenn die Verbindung zwischen den beiden Managementebenen, also zwischen Agent und Manager, für eine bestimmte Zeit nicht mehr gewährleistet ist, muß der Agent die während dieses Intervalls aufgetretenen Alarme zwi­ schenspeichern, um sicherzustellen, daß nach dem Wiederher­ stellen der Kommunikationsmöglichkeit dem Manager zum einen möglichst schnell eine Übersicht der z. Zt. aktiven Alarme (Liste aktiver Alarme nach dem englischsprachigen Ausdruck "Active Alarm List") zur Verfügung gestellt wird, und der Ma­ nager zum anderen eine möglichst lückenlose Alarmgeschichte ("Alarm history") sowohl der aktiven als auch der beendeten Alarme aufbauen kann.
Ein entsprechendes Alarmwiederanordnungsverfahren, das soge­ nannte "Alarm-Realignment"-Verfahren, kann bei jedem neuen Verbindungsaufbau zwischen Manager und Agenten ausgeführt werden. Aus der ITU-Empfehlung X.710, Geneva 1991, und der ITU-Empfehlung X.733, Geneva 1992, sind standardisierte Proze­ duren zum Fehlermanagement und zum Alarmabgleich bekannt. Des weiteren ist in dem Aufsatz "Konzepte für ein Network manage­ ment", ntz Bd. 45, 1992, Heft 8, Seiten 606 bis 615, ein Ver­ fahren zur Verwaltung von Telekommunikationsnetzen in mehre­ ren Ebenen bekannt, bei dem Manager und Agenten miteinander kommunizieren.
Die vorliegende Erfindung betrifft speziell das Management eines Mobilfunk-Telekommunikationsnetzes, das auch als Mobil­ funksystem bezeichnet wird.
Ein Mobilfunksystem ist ein hierarchisch gegliedertes System verschiedener Netzelemente, bei dem die unterste Hierarchie­ stufe von den Mobiltelefonen gebildet wird, die nach dem eng­ lischsprachigen Ausdruck "Mobile Station" auch mit MS be­ zeichnet werden. Diese Mobiltelefone kommunizieren über eine sogenannte Um Schnittstelle oder Funkschnittstelle mit die nächste Hierarchieebene bildenden Funkbasisstationen, die auch als Basisstation bzw. nach dem englischsprachigen Aus­ druck "Base Transceiver Station Equipment" mit BTSE bezeich­ net werden.
Zur Lenkung und Kontrolle des Datenverkehrs zwischen den Ba­ sisstationen, sind diese gebietsweise zusammengefaßt. Die hierzu vorgesehenen übergeordneten Netzelemente werden mit Basisstationssteuereinheit oder gemäß dem englischsprachigen Ausdruck "Base Station Controller" mit BSC bezeichnet. Die Basisstationen kommunizieren über eine sogenannte Abis- Schnittstelle mit den Basisstationssteuereinheiten. Einer Ba­ sisstationssteuereinheit kann gegebenenfalls zur Optimierung der Datenkommunikation eine Transcodier- und Ratenanpaßein­ heit zugeordnet sein, die nach dem englischsprachigen Aus­ druck "Transcoder and Rate Adapter Unit" auch mit TRAU be­ zeichnet wird. Die Transcodier- und Ratenanpaßeinheit kommu­ niziert mit der Basisstationssteuereinheit über eine soge­ nannte Asub-Schnittstelle. Die Basisstationen, die Basissta­ tionssteuereinheiten und die Transcodier- und Ratenanpaßein­ heiten bilden ein Basisstationssubsystem des Mobilfunksy­ stems, das nach dem englischsprachigen Ausdruck "Base Station Subsystem" auch mit BSS bezeichnet wird oder als Radiosubsy­ stem. Basisstationen, Basisstationssteuereinheiten und Tran­ scodier- und Ratenanpaßeinheiten sind hierbei Netzeinrichtun­ gen des Basisstationssubsystems.
Die Basisstationssteuereinheiten kommunizieren über sogenann­ te A Schnittstellen mit einer oder einigen wenigen Mobilver­ mittlungseinrichtungen, die nach dem englischsprachigen Aus­ druck "Mobile Switching Centers" auch mit MSC bezeichnet wer­ den und über die u. a. auch der Übergang in andere Telefonnet­ ze erfolgt. Die Mobilvermittlungseinrichtungen bilden gemein­ sam mit einigen Datenbanken das Vermittlungssubsystem, das nach dem englischsprachigen Ausdruck "Network Switching Sub­ system" auch mit NSS bezeichnet wird.
Neben den bisher beschriebenen Netzelementhierarchien steht ein Betriebs- und Wartungssystem, das gemäß dem englischspra­ chigen Ausdruck "Operation and Maintenance Subsystem" auch mit OMS bezeichnet wird. Das Betriebs- und Wartungssystem dient zum Konfigurieren und Überwachen aller Netzelemente. Überwachungsmaßnahmen und Konfigurierungsmaßnahmen werden hierzu meist von Betriebs- und Wartungszentren aus fernge­ steuert, die gemäß dem englischsprachigen Ausdruck "Operation and Maintenance Centers" auch mit OMC bezeichnet werden und sich üblicherweise im Bereich von Mobilvermittlungseinrich­ tungen befinden. Ein Betriebs- und Wartungszentrum oder OMC kommuniziert mit einer Basisstationssteuereinheit oder BSC über eine sogenannte O-Schnittstelle.
Eine der Aufgaben des Betriebs- und Wartungssystems ist die Durchführung eines Konfigurationsmanagements, das nach dem englischsprachigen Ausdruck "Configuration Management" auch mit CM bezeichnet wird und neben dem Fehlermanagement einen von fünf Managementfunktionsbereichen dargestellt, die die Telekommunikationsmanagementnetz-Prinzipien identifizieren. Das Konfigurationsmanagement definiert eine Reihe von Dien­ sten, die eine Änderung der Struktur und damit des Verhaltens eines Telekommunikationsnetzes durch den Bediener ermögli­ chen. Diese Dienste beziehen sich immer auf Instanzen von ge­ managten Objekten, die insgesamt die netzspezifische Manage­ mentinformationsbasis MIB bilden.
Ein gemanagtes Objekt im Sinne des Konfigurationsmanagements ist eine logische Abstraktion einer Ressource im Mobilfun­ knetz. Hierbei wird unterschieden zwischen hardwarebezogenen gemanagten Objekten, die eine herstellerspezifische Realisie­ rung einer Funktion beschreiben und zwischen funktionsbezoge­ nen gemanagten Objekten, bei denen es sich jeweils um die Ab­ straktion einer herstellerunabhängigen Funktionalität han­ delt. Gemanagten Objekte werden nach dem englischsprachigen Ausdruck "Managed Object" auch mit MO bezeichnet, wobei jede Objektkategorie auch mit Klasse gemanagter Objekte oder nach dem englischsprachigen Ausdruck "Managed Object Class" auch mit MOC bezeichnet wird. Zu jeder MOC gibt es mehrere Instan­ zen gemanagter Objekte, die jeweils einer spezifischen Funk­ tion oder Einrichtung zugeordnet sind.
Vorstehend wurden die Netzfunktionsebenen eines Mobilfunksy­ stems beschrieben. Für das Management eines Telekommunikati­ onsnetzes, auch eines Mobilfunk-Netzes, definieren die TMN- Prinzipien mehrere Ebenen ("Levels") des Telekommunikations­ netz-Managements wobei die vorliegende Erfindung für die drei Ebenen von Bedeutung ist, die nachfolgend unter Bezugnahme auf Fig. 2 erläutert werden.
Die Fig. 2 zeigt drei Ebenen des Telekommunikationsnetz- Managements für ein Mobilfunknetz. Die mit dem Bezugszeichen C gekennzeichnete Ebene ist die Netzelementebene ("Network Element Level"), üblicherweise mit den Hauptelementen BSS und MSC. In der Figur sind lediglich Basisstationssubsysteme BSS11, BSS12, BSS1N, BSS21, BSS22, BSS2M dargestellt. Das Be­ zugszeichen B kennzeichnet die Netzelementmanagementebene ("Network Element Management Level"), in der Betriebs- und Wartungszentren OMC1 und OMC2 jeweils die herstellerspezifi­ sche Managementfunktionalität einzelner Subsysteme BSS1 bzw. BSS2 darstellen. Das Bezugszeichen A kennzeichnet die Netzma­ nagementebene ("Network Management Level"), in der ein Netz­ managementzentrum, das nach dem englischsprachigen Ausdruck "Network Management Center " auch NMC genannt wird, eine inte­ grierte, vom Hersteller unabhängige Management-Funktionalität realisiert.
Radio-Subsysteme werden üblicherweise, um die vollständige Verfügbarkeit aller Funktionen zu gewährleisten, komplett von einem Hersteller bzw. Lieferanten bezogen. Solche proprietä­ ren Basisstationssubsysteme beinhalten oft neben der Funktion des Basisstationssubsystems auch die "Element Manager"- Funktionalität eines zugehörigen OMC. Die Schnittstelle zwi­ schen dem NMC und den überwachten OMC sollte jedoch standard­ gemäß implementiert werden, da das NMC Betriebs- und War­ tungszentren unterschiedlicher Hersteller überwachen können sollte.
Die Fig. 3 zeigt die funktionalen Einheiten der drei in Fig. 2 gezeigten Ebenen des Telekommunikationsnetz-Managements für ein Mobilfunknetz. Hierbei sind im Gegensatz zu Fig. 2 die einzelnen Netzelemente, nämlich die Basisstationssteue­ rungen BSC11, BSC1N, BSC21, BSC2M der Basisstationssubsysteme BSS11, BSS1N, BSS21, BSS2M aus Fig. 2 dargestellt und für das Basisstationssubsystem BSS11 außerdem stellvertretend ei­ ne Basisstation BTSE1 und eine Transcodier und Ratenanpaßein­ heit TRAU1.
Innerhalb des in Fig. 3 nur durch seine vorstehend erwähnten Netzelemente BSC11, BTSE1 und TRAU1 dargestellten Basisstati­ onssubsystems BSS11 kommunizieren die einzelnen Netzelemente BSC11, BTSE1 und TRAU1 durch sogenannte interne Schnittstel­ len miteinander bzw. mit Elementen der nächsthöheren Ebene.
Zwischen Wartungszentrum OMC1 und Basisstationssteuerungen BSC11 ist die O-Schnittstelle O1 vorgesehen. Zwischen Basis­ stationssteuerungen BSC11. und Basisstationen BTSE1 ist die Abis-Schnittstelle Abis1 vorgesehen und zwischen Basisstati­ onssteuerungen BSC11 und Transcodier- und Ratenanpaßeinheiten TRAU1 ist die Asub-Schnittstelle Asub1 vorgesehen.
Das NMC wird in einem Mobilfunknetz hauptsächlich für die Alarmüberwachung eingesetzt. Um im NMC jederzeit einen Über­ blick der Fehlersituation des gesamten Mobilfunknetzes si­ cherzustellen, müssen alle innerhalb eines Basisstationssub­ systems auftretenden Fehler vom OMC ans NMC übertragen wer­ den. Wenn eine der vorstehend erwähnten internen Schnittstel­ len vom Typ O, Abis oder Asub ausfällt, ist jedoch eine voll­ ständige Aktualisierung der Fehlersituation im NMC nicht mehr möglich. Im NMC müssen folglich alle Alarme, die sich auf Netzelemente beziehen, von denen aus das NMC über die ausge­ fallenen internen Schnittstelle zu erreichen ist, die also einen unsicheren Alarm-Bereich bilden, als unsichere Alarme gekennzeichnet werden. Dies geschieht beispielsweise durch einen Attributwert "Maybe".
Wenn beispielsweise die in Fig. 3 dargestellte O- Schnittstelle O1 ausfällt, müssen am NMC alle Alarme des ge­ samten Basisstationssubsystembereichs BSS11 als "Maybe"- Alarme gekennzeichnet werden. Wenn die Abis-Schnittstelle Abis1 ausfällt, müssen am NMC alle Alarme der Basisstation BTSE1, als unsichere Alarme, beispielsweise mit dem Attribut­ wert "Maybe" markiert werden.
Sobald eine ausgefallene interne Schnittstelle wieder be­ triebsbereit ist, wird zuerst zwischen Basisstationssubsystem BSS11 und dem OMC OMC1 eine Alarm-Wiederanordnungsprozedur, auch Realignment-Prozedur oder Realignment-Verfahren genannt, gestartet. Am Ende dieser Prozedur ist die Fehlersituation im OMC wieder aktualisiert.
Anschließend müßte ein Realignment-Verfahren zwischen OMC und dem übergeordneten NMC stattfinden. Erst wenn dieses Verfah­ ren erfolgreich beendet wäre, dürfte das NMC die Alarme aus dem vorher unsicheren Alarm-Bereich als gültig, beispielswei­ se durch einen Attributwert "Valid", kennzeichnen.
Etliche Basisstationssubsysteme sehen keine Realignment- Verfahren zwischen OMC und dem übergeordneten NMC bei Ausfall und Wiederherstellung interner Schnittstellen des BSS vor. Bei einigen bekannten Basisstationssubsystemen kann das NMC die im Rahmen eines solchen Realignment-Verfahrens üblicher­ weise erhaltene Information bedarfsweise abrufen.
Aufgabe der Erfindung ist es, eine Realignment-Prozedur zwi­ schen OMC und dem übergeordneten NMC bei Ausfall und Wieder­ herstellung interner Schnittstellen des BSS anzugeben.
Diese Aufgabe löst die Erfindung durch ein Verfahren mit den Merkmalen des Anspruches 1.
Die Erfindung betrifft eine Realignment-Prozedur zwischen ei­ nem Betriebs- und Wartungszentrum und einem diesem übergeord­ neten Netzmanagementzentrum bei Ausfall und Wiederherstellung einer internen Schnittstelle vom Typ O, Abis bzw. Asub eines vom Betriebs- und Wartungszentrum gemanagten Basisstations­ subsystems, wobei die in diesem Basisstationssubsystems auf­ tretenden aktiven Alarme im Betriebs- und Wartungszentrum ge­ speichert werden, eine Realignment-Prozedur zwischen einem Netzelement des Basisstationssubsystems, zu dem die internen Schnittstelle vom Typ O, Abis bzw. Asub ausgefallen war, und dem Betriebs- und Wartungszentrum durchgeführt wird, um nach Wiederherstellung der internen Schnittstelle die Liste der gespeicherten, dieses Netzelement betreffenden aktiven Alarme zu aktualisieren, und die aktualisierten gespeicherten Alarme an das Netzmanagementzentrum übermittelt werden. Erfindungs­ gemäß wird je eine eine Schnittstelle bezeichnende Alarmnoti­ fikation zum Anzeigen des Anfangs und des Endes eines Schnittstellenausfalls durch das Betriebs- und Wartungszen­ trum an das Netzmanagementzentrum übermittelt, und je eine ein über diese Schnittstelle vom Betriebs- und Wartungszen­ trum erreichbares Netzelement des Basisstationssubsystems be­ zeichnende, die Zuverlässigkeit von dieses Netzelement be­ treffenden gespeicherten Alarmnotifikationen angebende Zu­ standsänderungsmeldung am Anfang eines Schnittstellenausfalls und nach erfolgreichem Übermitteln der aktualisierten gespei­ cherten Alarme an das Netzmanagementzentrum übermittelt.
Durch das Übermitteln der Alarmnotifikationen wird das Netz­ managementzentrum unmittelbar beim Auftreten des Ereignisses von einem Schnittstellenstörfall bzw. von einem Schnittstel­ len-Restart unterrichtet. Das Netzmanagementzentrum kann folglich unmittelbar nach dem Auftreten eines Störfalls die als aktiv gespeicherten, das betroffene Netzelement bzw. Ba­ sisstationssubsystem betreffenden Alarme als unzuverlässig kennzeichnen. Durch das Übermitteln der Zustandsänderungsmel­ dungen, insbesondere nach erfolgreichem Übermitteln der ak­ tualisierten gespeicherten Alarme vom Betriebs- und Wartungs­ zentrum zum Netzmanagementzentrum, kann das Netzmanagement­ zentrum frühzeitig die als aktiv gespeicherten, das betroffe­ ne Netzelement bzw. Basisstationssubsystem betreffenden Alar­ me als gültig kennzeichnen, ohne selbst irgendwelche Prozedu­ ren zu veranlassen.
In einer Ausgestaltungsform eines erfindungsgemäßen Verfah­ rens vergleicht das Betriebs- und Wartungszentrum die Liste der im Betriebs- und Wartungszentrum gespeicherten aktiven Alarme mit der aktualisierten Liste der gespeicherten aktiven Alarme und übermittelt eine einen neu auftretenden Alarm be­ zeichnende Notifikation an das Netzmanagementzentrum für je­ den Alarm, der nur in der aktualisierten Liste gespeicherter Alarme enthalten ist. Darüberhinaus übermittelt das Betriebs- und Wartungszentrum eine einen beendeten Alarm bezeichnende Notifikation an das Netzmanagementzentrum für jeden Alarm, der nur in der nicht aktualisierten Liste enthalten ist.
Eine Weiterbildung eines erfindungsgemäßen Verfahrens sieht vor, daß die den Zustand einer O-Schnittstelle betreffenden Informationen vom Betriebs- und Wartungszentrum an das Netz­ managementzentrum auf der Grundlage eines diese Schnittstelle betreffenden funktionalen gemanagten Objektes übermittelt werden, mit
  • - einem Basisteil, der ein Attribut zum Definieren des be­ troffenen Betriebs- und Wartungszentrums und des von diesem über die O-Schnittstelle erreichbaren Basisstationssubsystems enthält und ein Attribut zum Angeben der Zuverlässigkeit der Aktualität von die O-Schnittstelle und dieses Basisstations­ subsystem betreffenden, im Netzmanagementzentrum gespeicher­ ten aktiven Alarmen,
  • - einem Alarmteil zum Generieren einer Alarmnotifikation zu Beginn und nach Beendigung des Ausfalls der O-Schnittstelle, und
  • - einem Attributänderungsmeldeteil zum Generieren einer Zu­ standsänderungsnotifikation bei einer Änderung eines Attri­ butwertes der O-Schnittstelle.
Durch Verwendung solcher die einzelnen internen Schnittstel­ len betreffender funktionaler gemanagter Objekte für das In­ formationsmodell der Schnittstelle zwischen Betriebs- und Wartungszentrum und Netzmanagementzentrum kann diese stan­ dardgemäß mit M-EVENT-REPORT betrieben werden. So können die Alarmnotifikation gemäß ITU-T X.733 als "Alarm-Notification" ausgeführt werden und die Zustandsänderungsnotifikation gemäß ITU-T X.730 als "AttributeValueChange-Notification".
Entsprechend kann eine Ausgestaltung eines erfindungsgemäßen Verfahrens für Abis-Schnittstellen vorsehen, daß die den Zu­ stand einer Abis-Schnittstelle betreffenden Informationen vom Betriebs- und Wartungszentrum an das Netzmanagementzentrum auf der Grundlage eines diese Schnittstelle betreffenden funktionalen gemanagten Objektes übermittelt werden, mit
  • - einem Basisteil, der ein Attribut zum Definieren des be­ treffenden Betriebs- und Wartungszentrums, der betreffenden Basisstationssteuerung und der von dieser über die Abis- Schnittstelle erreichbaren Basisstation enthält und ein At­ tribut zum Angeben der Zuverlässigkeit der Aktualität von die Abis-Schnittstelle und diese Basisstation betreffenden, im Netzmanagementzentrum gespeicherten aktiven Alarmen,
  • - einem Alarmteil zum Generieren einer Alarmnotifikation zu Beginn und nach Beendigung des Ausfalls der Abis- Schnittstelle, und
  • - einem Attributänderungsmeldeteil zum Generieren einer Zu­ standsänderungsnotifikation bei einer Änderung eines Attri­ butwertes der Abis-Schnittstelle.
Bezüglich einer Asub-Schnittstelle kann demgemäß eine günsti­ ge Ausgestaltung eines erfindungsgemäßen Verfahrens vorsehen, daß die den Zustand einer Asub-Schnittstelle betreffenden In­ formationen vom Betriebs- und Wartungszentrum an das Netzma­ nagementzentrum auf der Grundlage eines diese Schnittstelle betreffenden funktionalen gemanagten Objektes übermittelt werden, mit
  • - einem Basisteil, der ein Attribut zum Definieren des be­ treffenden Betriebs- und Wartungszentrums, der betreffenden Basisstationssteuerung und der von dieser über die Asub- Schnittstelle erreichbaren Transcodier- und Ratenanpaßeinheit enthält und ein Attribut zum Angeben der Zuverlässigkeit der Aktualität von die Asub-Schnittstelle und diese Transcodier- und Ratenanpaßeinheit betreffenden, im Netzmanagementzentrum gespeicherten aktiven Alarmen,
  • - einem Alarmteil zum Generieren einer Alarmnotifikation zu Beginn und nach Beendigung des Ausfalls der Asub- Schnittstelle, und
  • - einem Attributänderungsmeldeteil zum Generieren einer Zu­ standsänderungsnotifikation bei einer Änderung eines Attri­ butwertes der Asub-Schnittstelle.
Die Erfindung ermöglicht durch eine objektorientierte Model­ lierung der Schnittstellen vom Typ O, Abis und Asub im Infor­ mationsmodell zwischen OMC und NMC eine automatische, stan­ dardgemäße Realignment-Prozedur zwischen NMC und OMC. Die Er­ findung bietet hierbei folgende vorteilhafte Besonderheiten:
  • a) Die Initiative zum "Alarm-Realignment" geht immer vom OMC aus. Eine spezifische M-ACTION vom NMC ist, in Anlehnung an ITU-T Standard X.710 mit dem Titel "Common Management In­ formation Service Definition", nicht erforderlich.
  • b) Die Realignment-Prozedur kann vollständig über standar­ disierte M-EVENT-REPORT gemäß ITU-T Standard X.710 erfolgen.
  • c) Eine für das NMC spezifische Anfangs- bzw. Ende- Kennzeichnung der Realignment-Prozeduren zwischen Netzelement und OMC bzw. zwischen OMC und NMC ist nicht erforderlich.
Nachstehend wird die Erfindung anhand eines Ausführungsbei­ spieles unter Bezugnahme auf die Figuren näher erläutert.
Die Fig. 1 zeigt in Form eines schematisch dargestellten Ab­ laufdiagramms ein Ausführungsbeispiel eines erfindungsgemäßen Verfahrens.
Die Fig. 2 und 3 zeigen, wie oben erläutert, in Blockdar­ stellung drei Ebenen des Telekommunikationsnetz-Managements für ein Mobilfunknetz.
Gemäß einem Ausführungsbeispiel eines erfindungsgemäßen Rea­ lignment-Verfahrens werden im Informationsmodell der OMC-NMC- Schnittstelle drei nachfolgend beschriebene funktionsbezoge­ nen MOCs definiert.
Eine MOC mit der Bezeichnung oLink modelliert eine O- Schnittstelle und beinhaltet drei Hauptelemente:
Das erste Hauptelement ist ein Basisteil mit den Attributen,
  • - targetNEaddress zum Definieren des Basisstationssubsystems hinter der entsprechenden oLink-Instanz, bestehend aus den Werten omcNo zum Angeben des OMC und bscNo zum Angeben der Basisstationssteuerung des Basisstationssubsystems; und
  • - alignmentStatus zum Angeben des Aktualisierungszustandes. Dieses Attribut kann folgende Werte annehmen:
  • - notAligned (der Wert wird vom OMC jedesmal gesetzt, wenn eine O-Schnittstelle ausfällt);
  • - partlyAligned (der Wert wird vom OMC jedesmal gesetzt, wenn die Realignment-Prozedur nach Ausfall & Restart dieser oLink- Instanz zwar erfolgreich ausgeführt wurde, aber mindestens eine Abis- bzw. Asub-Schnitstelte innerhalb dieses Basissta­ tionssubsystems außer Betrieb ist); und
  • - Aligned (der Wert wird vom OMC jedesmal gesetzt, wenn die Realignment-Prozedur nach Ausfall und Restart dieser oLink- Instanz erfolgreich ausgeführt worden ist und alle Abis- bzw. Asub-Schnitstellen innerhalb dieses Basisstationssubsystems in Betrieb sind).
Das zweite Hauptelement ist ein Alarmteil, der das Generieren einer "Alarm-Notification" (gemäß ITU-T Standard X.733 - Alarm Reporting Function) beim Ausfall bzw. Restart der O- Schnittstelle bewirkt.
Das dritte Hauptelement ist ein Zustandsänderungsteilteil, der das Generieren einer "AttributeValueChange-Notification" (gemäß ITU-T Standard X.730 - Object Management Function) beim Ändern eines Attributwertes bewirkt.
Eine MOC mit der Bezeichnung abisLink modelliert eine Abis- Schnittstelle und beinhaltet drei Hauptelemente:
Das erste Hauptelement ist ein Basisteil mit den Attributen,
  • - targetNEaddress zum Definieren der Basisstation hinter der vorliegenden abisLink-Instanz, bestehend aus den Werten omcNo zum Angeben des OMC, bscNo zum Angeben der Basisstations­ steuerung und btseNo zum Angeben der Basisstation; und
  • - alignmentStatus zum Angeben des Aktualisierungszustandes. Dieses Attribut kann folgende Werte annehmen:
  • - notAligned (der Wert wird vom OMC jedesmal gesetzt, wenn eine Abis-Schnittstelle ausfällt); und
  • - Aligned (der Wert wird vom OMC jedesmal gesetzt, wenn die Realignment-Prozedur nach Ausfall und Restart dieser abis- Link-Instanz erfolgreich ausgeführt worden ist).
Das zweite Hauptelement ist ein Alarmteil, der das Generieren einer "Alarm-Notification" (gemäß ITU-T Standard X.733 - Alarm Reporting Function) beim Ausfall bzw. Restart der Abis- Schnittstelle bewirkt.
Das dritte Hauptelement ist ein Zustandsänderungsteilteil, der das Generieren einer "AttributeValueChange-Notification" (gemäß ITU-T Standard X.730 - Object Management Function) beim Ändern eines Attributwertes bewirkt.
Eine MOC mit der Bezeichnung asubLink modelliert eine Asub- Schnittstelle und beinhaltet drei Hauptelemente:
Das erste Hauptelement ist ein Basisteil mit den Attributen,
  • - targetNEaddress zum Definieren der TRAU hinter der vorlie­ genden asubLink-Instanz bestehend aus den Werten omcNo zum Angeben des OMC, bscNo zum Angeben der Basisstationssteuerung und trauNo zum Angeben der TRAU; und
  • - alignmentStatus zum Angeben des Aktualisierungszustandes. Dieses Attribut kann folgende Werte annehmen:
  • - notAligned (der Wert wird vom OMC jedesmal gesetzt, wenn eine Asub-Schnittstelle ausfällt); und
  • - Aligned (der Wert wird vom OMC jedesmal gesetzt, wenn die Realignment-Prozedur nach Ausfall und Restart dieser asubLink-Instanz erfolgreich ausgeführt worden ist).
Das zweite Hauptelement ist ein Alarmteil, der das Generieren einer "Alarm-Notification" (gemäß ITU-T Standard X.733 - Alarm Reporting Function) beim Ausfall bzw. Restart der Asub- Schnittstelle bewirkt.
Das dritte Hauptelement ist ein Zustandsänderungsteilteil, der das Generieren einer "AttributeValueChange-Notification" (gemäß ITU-T Standard X.730 - Object Management Function) beim Ändern eines Attributwertes bewirkt.
asubLink
Nachstehend wird der Ablauf einer erfindungsgemäßen Realign­ ment-Prozedur anhand eines Ausführungsbeispiels unter Bezug­ nahme auf Fig. 1 beschrieben für den Fall, daß die O- Schnittstelle O1 gemäß Fig. 2 ausfällt.
Wenn die O-Schnittstelle O1 ausfällt, wird im Betriebs- und Wartungszentrum OMC1 das Attribut alignmentStatus der MO- Instanz oLink auf den Wert notAligned gesetzt. Es wird je ei­ ne Meldung "Alarm-Notification" und "AttributValueChange- Notification" ans Netzmanagementzentrum NMC gesendet.
Der Parameter "Attribute identifier list" kann gemäß ITU-T Standard X.730 alle Attribute beinhalten, also auch target­ NEaddress, obwohl in dem Parameter "Attribut value change de­ finition" nur das Attribut alignmentStatus einen neuen Wert erhalten hat.
Anhand des Attributs targetNEaddress erkennt das Netzmanage­ mentzentrum NMC das Basisstationssubsystem BSS11 hinter der ausgefallenen O-Schnittstelle O1 (omcNo und bscNo), so daß alle das Basisstationssubsystem BSS11 betreffenden Alarme im Netzmanagementzentrum NMC als unzuverlässig mit dem Wert "Maybe" gekennzeichnet werden. Diese Kennzeichnung bleibt er­ halten, bis eine Realignment-Prozedur zwischen Betriebs- und Wartungszentrum OMC1 und dem Netzmanagementzentrum NMC er­ folgreich beendet wird.
Nach einiger Zeit ist die O-Schnittstelle O1 wieder betriebs­ bereit.
Das Betriebs- und Wartungszentrum OMC1 sendet zum Mitteilen des Beendens der Störung der O-Schnittstelle O1 eine "Ceased- Alarm-Notification" für die oLink-Instanz ans Netzmanagement­ zentrum NMC und beginnt eine Realignment-Prozedur mit dem entsprechenden Basisstationsubsystem BSS11.
Das Betriebs- und Wartungszentrum OMC1 vergleicht die eigene alte und neue "Active alarm list" und sendet ans Netzmanage­ mentzentrum NMC in Form von standardkonformen Nachrichten für jeden nur in der neuen "Active alarm list" des Betriebs- und Wartungszentrums OMC1 vorhandenen Alarm einen den aktiven Alarm mitteilenden M-EVENT-REPORT und für jeden nur in der alten "Active alarm list" vorhandenen Alarm einen den beende­ ten Alarm ("Ceased alarm") mitteilenden M-EVENT-REPORT.
Nachdem alle M-EVENT-REPORT vom Betriebs- und Wartungszentrum OMC1 ans Netzmanagementzentrum NMC erfolgreich übertragen wurden, wird im Betriebs- und Wartungszentrum OMC1 das Attri­ but alignmentStatus der MO-Instanz oLink auf den Wert Aligned gesetzt. Entsprechend wird eine "AttributValueChange- Notification" ans Netzmanagementzentrum NMC übertragen, wobei der Parameter "Attribute identifier list" wiederum alle At­ tribute, also auch targetNEaddress, beinhaltet.
Damit erkennt das Netzmanagementzentrum NMC das erfolgreiche Ende der Realignment-Prozedur für das im Attribut targetNEad­ dress angegebene Basisstationssubsystem BSS11 und kennzeich­ net alle BSS-bezogenen Alarme als gültig mit dem Wert "Valid".
Fig. 1 zeigt die beschriebene Realignment-Prozedur zwischen OMC und NMC anhand des Informationsflusses zwischen Netzele­ menten NE und dem Betriebs- und Wartungszentrum OMC bzw. zwi­ schen dem Betriebs- und Wartungszentrum OMC und dem Netzmana­ gementzentrum NMC.
Wenn die gleiche O-Schnittstelle O1 erneut ausfällt, während die Realignment-Prozedur zwischen OMC und NMC noch nicht ab­ geschlossen ist, bricht das OMC1 die Übertragung der M-EVENT- REPORT ans Netzmanagementzentrum NMC ab. Da das Attribut alignmentStatus der MO-Instanz oLink weiterhin den Wert notA­ ligned beibehält, bleiben die das Basisstationssubsystem BSS11 betreffenden Alarme im Netzmanagementzentrum NMC mit "Maybe" gekennzeichnet.
Wenn eine Abis-Schnittstelle innerhalb des gleichen Basissta­ tionssubsystem BSS11 ausfällt, während die Realignment- Prozedur zwischen OMC und NMC noch nicht abgeschlossen ist, wird eine Meldung "Alarm-Notification" entsprechend der abis- Link-Instanz ans Netzmanagementzentrum NMC gesendet. Außerdem wird eine Meldung "AttributValueChange-Notification" ans Netzmanagementzentrum NMC gesendet, da das Attribut align­ mentStatus der MO-Instanz abisLink im Betriebs- und Wartungs­ zentrum OMC1 auf den Wert notAligned gesetzt wird. Das Attri­ but targetNEaddress identifiziert hierbei eindeutig die BTSE1 hinter der ausgefallenen Abis-Schnittstelle Abis1.
Das Betriebs- und Wartungszentrum OMC1 setzt die Übertragung von M-EVENT-REPORT ans Netzmanagementzentrum NMC bezüglich der das Objekt oLink der O-Schnittstelle O1 betreffenden Rea­ lignment-Prozedur fort, wobei der BTSE-Bereich der BTSE11 entsprechend der gerade ausgefallenen Abis-Schnittstelle nicht mehr berücksichtigt wird. Nachdem die Übertragung für den restlichen Bereich des Basisstationssubsystems BSS11 er­ folgreich beendet wird, setzt das Betriebs- und Wartungszen­ trum OMC1 das Attribut alignmentStatus der MO-Instanz oLink auf den Wert partlyAligned. Das Netzmanagementzentrum NMC er­ kennt damit, daß innerhalb des aktuellen BSS-Bereichs Alarme von einigen Netzelementen NE nicht als aktualisiert betrach­ tet werden können. Mit Ausnahme der vorher identifizierten Basisstation BTSE1 werden alle anderen Alarme im Bereich des betreffenen Basisstationssubsystems BSS11 mit "Valid" gekenn­ zeichnet.
Wenn eine Asub-Schnittstelle, die am Anfang der BSS- Realignment-Prozedur ausgefallen war, während die Realign­ ment-Prozedur zwischen OMC und NMC noch nicht abgeschlossen ist in Betrieb geht, werden folgende Meldungen ans Netzmana­ gementzentrum NMC gesendet: Eine "CeasedAlarm-Notification" bezüglich der asubLink-Instanz und eine "AttributValueChange- Notification", da das Attribut alignmentStatus der MO-Instanz abisLink im Betriebs- und Wartungszentrum OMC1 auf den Wert Aligned gesetzt wird, wobei das Attribut targetNEaddress ein­ deutig die TRAU hinter der vorher ausgefallenen Asub- Schnittstelle identifiziert.
Das Netzmanagementzentrum NMC kann noch nicht die TRAU- bezogenen Alarme als gültig mit dem Wert "Valid" kennzeich­ nen, da der alignmentStatus des gesamten Bereichs des Basis­ stationssubsystem BSS11 der oLink-Instanz weiterhin notA­ ligned ist.
Das Betriebs- und Wartungszentrum OMC1 setzt die Übertragung von M-EVENT-REPORT ans Netzmanagementzentrum NMC bezüglich der die O-Schnittstelle O1 betreffenden Realignment-Prozedur fort, wobei ein Vergleich der alten und neuen "Active alarm list" für den TRAU-Bereich entsprechend der gerade wieder ge­ starteten Asub-Schnittstelle berücksichtigt werden muß. Nach­ dem alle M-EVENT-REPORT vom Betriebs- und Wartungszentrum OMC1 ans Netzmanagementzentrum NMC erfolgreich übertragen worden sind, wird im Betriebs- und Wartungszentrum OMC1 das Attribut alignmentStatus der MO-Instanz oLink auf den Wert Aligned gesetzt.
In der "AttributValueChange-Notification" erkennt das Netzma­ nagementzentrum NMC das erfolgreiche Ende der Realignment- Prozedur für das gesamte im Attribut targetNEaddress angege­ bene Basisstationssubsystem BSS11 und kennzeichnet alle ent­ sprechenden Alarme (d. h. auch die TRAU-bezogenen) mit dem Wert "Valid" als gültig.
Solange eine Asub- bzw. Abis-Schnittstelle Asub1, Abis1 in­ nerhalb eines Basisstationssubsystems BSS11 nicht betriebsbe­ reit ist, werden die Alarme der Netzelemente NE, also TRAU bzw. BTSE, hinter der ausgefallenen internen Schnittstelle Asub1, Abis1 beim Vergleich der alten und neuen "Active alarm list" im Betriebs- und Wartungszentrum OMC1 außer acht gelas­ sen.

Claims (5)

1. Realignment-Verfahren zwischen einem Betriebs- und War­ tungszentrum (OMC1) und einem diesem übergeordneten Netzmana­ gementzentrum (NMC) bei Ausfall und Wiederherstellung einer internen Schnittstelle (O1, Abis1, Asub1) eines vom Betriebs- und Wartungszentrum gemanagten Basisstationssubsystems (BSS11) durch Speichern der in diesem Basisstationssubsystems (BSS11) auftretenden aktiven Alarme im Betriebs- und War­ tungszentrum (OMC1), durch Durchführen einer Realignment- Prozedur zwischen einem Netzelement (NE, BSC1, BTSE1, TRAU1) des Basisstationssubsystems (BSS11), zu dem die internen Schnittstelle (O1, Abis1, Asub1) ausgefallen war und dem Be­ triebs- und Wartungszentrum (OMC1), um nach Wiederherstellung der internen Schnittstelle (O1, Abis1, Asub1) die Liste der gespeicherten, dieses Netzelement (NE, BSC1, BTSE1, TRAU1) betreffenden aktiven Alarme zu aktualisieren, und durch Über­ mitteln der aktualisierten gespeicherten Alarme an das Netz­ managementzentrum (NMC), gekennzeichnet durch das Übermitteln je einer eine Schnittstelle (O1, Abis1, Asub1) bezeichnenden Alarmnotifikation (alarm notif.) zum Anzeigen des Anfangs und des Endes eines Schnittstellenausfalls durch das Betriebs- und Wartungszentrum (OMC1) an das Netzmanagementzentrum (NMC) und durch das Übermitteln je einer ein über diese Schnitt­ stelle (O1, Abis1, Asub1) vom Betriebs- und Wartungszentrum (OMC1) erreichbares Netzelement (NE, BSC11, BTSE1, TRAU1) des Basisstationssubsystems (BSS11) bezeichnenden, die Zuverläs­ sigkeit von dieses Netzelement (NE, BSC1, BTSE1, TRAU1) be­ treffenden Alarmnotifikationen (alarm notif.) angebenden Zu­ standsänderungsmeldung (attrValChange notif.) am Anfang eines Schnittstellenausfalls und nach erfolgreichem Übermitteln der aktualisierten gespeicherten Alarme an das Netzmanagementzen­ trum (NMC).
2. Verfahren nach Anspruch 1, gekennzeichnet durch das Vergleichen der Liste der im Betriebs- und Wartungszentrum (OMC1) gespeicherten aktiven Alarme mit der aktualisierten Liste der gespeicherten aktiven Alarme durch das Betriebs- und Wartungszentrum (OMC1) und durch das Übermitteln einer einen neu auftretenden Alarm bezeichnenden Notifikation vom Betriebs- und Wartungszentrum (OMC1) an das Netzmanagement­ zentrum (NMC) für jeden Alarm, der nur in der aktualisierten Liste gespeicherter Alarme enthalten ist sowie durch das Übermitteln einer einen beendeten Alarm bezeichnenden Notifi­ kation an das Netzmanagementzentrum (NMC) für jeden Alarm, der nur in der nicht aktualisierten Liste enthalten ist.
3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, daß die den Zustand einer O-Schnittstelle (O1) betreffenden Informationen vom Betriebs- und Wartungszentrum (OMC1) an das Netzmanagementzentrum (NMC) auf der Grundlage eines diese Schnittstelle betreffenden funktionalen gemanagten Objektes übermittelt werden, mit
  • 1. einem Basisteil, der ein Attribut (targetNEadress) zum De­ finieren des betroffenen Betriebs- und Wartungszentrums (OMC1) und des von diesem über die O-Schnittstelle (O1) er­ reichbaren Basisstationssubsystems (BSS11) enthält und ein Attribut (alignmentStatus) zum Angeben der Zuverlässigkeit der Aktualität von die O-Schnittstelle (O1) und dieses Basis­ stationssubsystem (BSS11) betreffenden, im Netzmanagementzen­ trum (NMC) gespeicherten aktiven Alarmen,
  • 2. einem Alarmteil zum Generieren einer Alarmnotifikation (alarm notif.) zu Beginn und nach Beendigung des Ausfalls der O-Schnittstelle (O1), und
  • 3. einem Attributänderungsmeldeteil zum Generieren einer Zu­ standsänderungsnotifikation (attrValChange notif.) bei einer Änderung eines Attributwertes der O-Schnittstelle (O1).
4. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß die den Zustand einer Abis-Schnittstelle (Abis1) betreffenden Informationen vom Betriebs- und War­ tungszentrum (OMC1) an das Netzmanagementzentrum (NMC) auf der Grundlage eines diese Schnittstelle betreffenden funktio­ nalen gemanagten Objektes übermittelt werden, mit
  • 1. einem Basisteil, der ein Attribut (targetNEadress) zum De­ finieren des betreffenden Betriebs- und Wartungszentrums (OMC1), der betreffenden Basisstationsteuerung (BSC11) und der von dieser über die Abis-Schnittstelle (Abis1) erreichba­ ren Basisstation (BTSE1) enthält und ein Attribut (alignmentStatus) zum Angeben der Zuverlässigkeit der Aktua­ lität von die Abis-Schnittstelle (Abis1) und diese Basissta­ tion (BTSE1) betreffenden, im Netzmanagementzentrum (NMC) ge­ speicherten aktiven Alarmen,
  • 2. einem Alarmteil zum Generieren einer Alarmnotifikation (alarm notif.) zu Beginn und nach Beendigung des Ausfalls der Abis-Schnittstelle (Abis1), und
  • 3. einem Attributänderungsmeldeteil zum Generieren einer Zu­ standsänderungsnotifikation (attrValChange notif.) bei einer Änderung eines Attributwertes der Abis-Schnittstelle (Abis1).
5. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß die den Zustand einer Asub-Schnittstelle (Asub1) betreffenden Informationen vom Betriebs- und War­ tungszentrum (OMC1) an das Netzmanagementzentrum (NMC) auf der Grundlage eines diese Schnittstelle betreffenden funktio­ nalen gemanagten Objektes übermittelt werden, mit
  • 1. einem Basisteil, der ein Attribut (targetNEadress) zum De­ finieren des betreffenden Betriebs- und Wartungszentrums (OMC1), der betreffenden Basisstationsteuerung (BSC11) und der von dieser über die Asub-Schnittstelle (Asub1) erreichba­ ren Transcodier- und Ratenanpaßeinheit (TRAU1) enthält und ein Attribut (alignmentStatus) zum Angeben der Zuverlässig­ keit der Aktualität von die Asub-Schnittstelle (Asub1) und diese Transcodier- und Ratenanpaßeinheit (TRAU1) betreffenden, im Netzmanagementzentrum (NMC) gespeicherten aktiven Alarmen,
  • 2. einem Alarmteil zum Generieren einer Alarmnotifikation (alarm notif.) zu Beginn und nach Beendigung des Ausfalls der Asub-Schnittstelle (Asub1), und
  • 3. einem Attributänderungsmeldeteil zum Generieren einer Zu­ standsänderungsnotifikation (attrValChange notif.) bei einer Änderung eines Attributwertes der Asub-Schnittstelle (Asub1).
DE1997140718 1997-09-16 1997-09-16 Realignment-Verfahren zwischen einem Betriebs- und Wartungszentrum und einem diesem übergeordneten Netzmanagementzentrum Expired - Fee Related DE19740718C2 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
DE1997140718 DE19740718C2 (de) 1997-09-16 1997-09-16 Realignment-Verfahren zwischen einem Betriebs- und Wartungszentrum und einem diesem übergeordneten Netzmanagementzentrum

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE1997140718 DE19740718C2 (de) 1997-09-16 1997-09-16 Realignment-Verfahren zwischen einem Betriebs- und Wartungszentrum und einem diesem übergeordneten Netzmanagementzentrum

Publications (2)

Publication Number Publication Date
DE19740718A1 DE19740718A1 (de) 1999-09-23
DE19740718C2 true DE19740718C2 (de) 2000-03-09

Family

ID=7842535

Family Applications (1)

Application Number Title Priority Date Filing Date
DE1997140718 Expired - Fee Related DE19740718C2 (de) 1997-09-16 1997-09-16 Realignment-Verfahren zwischen einem Betriebs- und Wartungszentrum und einem diesem übergeordneten Netzmanagementzentrum

Country Status (1)

Country Link
DE (1) DE19740718C2 (de)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001095572A2 (en) * 2000-06-05 2001-12-13 Telefonaktiebolaget Lm Ericsson (Publ) Method, system, and agent for processing a network resource alarm update in a telecommunication management network
US6697970B1 (en) 2000-07-14 2004-02-24 Nortel Networks Limited Generic fault management method and system
GB2431067B (en) 2005-10-07 2008-05-07 Cramer Systems Ltd Telecommunications service management
GB2432992B (en) 2005-11-18 2008-09-10 Cramer Systems Ltd Network planning
GB2433675B (en) 2005-12-22 2008-05-07 Cramer Systems Ltd Communications circuit design
GB2435362B (en) 2006-02-20 2008-11-26 Cramer Systems Ltd Method of configuring devices in a telecommunications network
CN115225458A (zh) * 2022-07-12 2022-10-21 深圳壹账通智能科技有限公司 告警通知方法、装置、电子设备及存储介质

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
CCITT, Common Management Information Service Definition for CCITT, Application, Recommendation,X.710, Geneva, 1991 *
CCITT, Information Technology-Open System Inter- connection-Systems Management: Alarm Reporting Function, Recommendation X.733, Geneva, 1992 *

Also Published As

Publication number Publication date
DE19740718A1 (de) 1999-09-23

Similar Documents

Publication Publication Date Title
EP1034639B1 (de) Verfahren und kommunikationssystem zur behandlung von alarmen durch ein mehrere managementebenen aufweisendes managementnetz
DE19801784C2 (de) Verfahren und Kommunikationssystem zur Behandlung von Alarmen durch ein mehrere Managementebenen aufweisendes Managementnetz
EP0973342A2 (de) Verfahren und Kommunikationssystem zur Behandlung von Alarmen durch ein mehrere Managementebenen aufweisendes Managementnetz
DE69332927T2 (de) Gerät zur Verwaltung eines Elementverwalters für ein Fernmeldevermittlungssystem
EP1058983B1 (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
DE19740718C2 (de) Realignment-Verfahren zwischen einem Betriebs- und Wartungszentrum und einem diesem übergeordneten Netzmanagementzentrum
EP1668822B1 (de) Verfahren zur synchronisierung von alarmen in einem managementsystem eines kommunikationsnetzes
DE19813754C2 (de) Verfahren und Managementnetz zur Konfiguration eines Funk-Kommunikationsnetzes
DE69633448T2 (de) Universeller objekt-übersetzungsagent
EP1206883B1 (de) Generisches alignment-verfahren in einer multi-manager-umgebung
EP1810523B1 (de) Verfahren und produkte zum informationsabgleich zwischen manager und agent in einem managementnetz
DE19740713C2 (de) Konfigurierungsverfahren für ein Basisstationssubsystem
EP1145538B1 (de) Verfahren und kommunikationssystem zur behandlung von zustandsinformationen durch ein mehrere managementebenen aufweisendes managementnetz
DE19740716C2 (de) Verfahren zum Behandeln von in Kommunikationssystemen von einem hardwarebezogenen gemanagten Objekt generierten Alarmen
WO2001024448A1 (de) Konfigurieren eines telekommunikationsnetzes mit mehreren netzregionen
DE19720594C1 (de) Verfahren zum gegenseitigen Umsetzen von Instanznummern und symbolischen Namen in einem Mobilfunknetz und Mobilfunknetz
DE19720596C2 (de) Konfigurationsverfahren für ein Mobilfunksystem und Basisstationssteuereinheit zur Durchführung
EP1091596A2 (de) Erweiterter Management-Notification-Dienst zur Reduzierung der Kommunikation zwischen Agent und Manager
WO2004107790A1 (de) Verfahren zur behandlung von parameteränderungen in einem managementnetz eines zellularen kommunikationssystems und kommunikationssystem
EP1703667A1 (de) Netzwerkmanagement unter Verwendung eines Master-Replica-Verfahrens
EP1089576A1 (de) Netzwerkverwaltung
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
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