CH686540A5

CH686540A5 - Verfahren zum Steuern und Verwalten von Netzwerkelementen.

Info

Publication number: CH686540A5
Application number: CH99793A
Authority: CH
Inventors: Stephan Burgi; Pedro Martinez; Markus Schiesser; Karl-Heinz Loos
Original assignee: Siemens Schweiz Ag
Priority date: 1993-04-01
Filing date: 1993-04-01
Publication date: 1996-04-15

Description

5

10

15

20

25

30

35

40

45

50

55

60

65

CH 686 540 A5

Beschreibung

Die vorliegende Erfindung betrifft ein Verfahren nach dem Oberbegriff des Patentanspruchs 1 sowie eine Anwendung desselben.

Die Verwaltung und Steuerung von vernetzten Systemen, wie beispielsweise von Telekommunikationsanlagen, wird angesichts der immer komplexer werdenden Systeme zunehmend schwieriger. Gleichzeitig steigen die Anforderungen hinsichtlich einer einheitlichen und einfachen Bedienung und Wartung, insbesondere wenn verschiedene Teilsysteme von verschiedenen Herstellern gleichzeitig bedient werden sollen.

In der Fernmeldetechnik entstand unter dem Begriff Telekommunikationsverwaltungsnetzwerk (Télécommunication Management Network - TMN) eine von der internationalen Standardisierungsbehörde CCITT (Comité Consultatif International Télégraphique et Téléphonique) herausgegebene Empfehlung M.30 (CCITT Blue Book, Volume IV - Fasciole IV.1, IX,h Plenary Assembly, Geneva 1989) bzw. Empfehlung M.3010 (Entwurf). Diese Empfehlung präsentiert die generellen Prinzipien für die Planung, die Arbeitsweise und den Unterhalt eines TMN. Dabei hat ein TMN die grundsätzliche Aufgabe, einzelne Netzwerkelemente einer Telekommunikationsanlage, wie beispielsweise eine PDH-(Plesiochronous Digital Hierachy)-, eine SDH-(Synchronous Digital Hierachy)- oder eine ATM-(Asynchronous Transfer Mode)-Ausrüstung, zu verwalten. Dazu stehen verschiedene in sogenannten Betriebsleitsystemen (OS -Operating Systems) ablaufende Verwaltungsfunktionen zur Verfügung, in denen beispielsweise Netzkonfigurationen, Fehlerbehebungen, Qualitätsuntersuchungen in den einzelnen Netzwerkelementen, Kostenberechnungen und Zugriffsberechtigungsfestlegungen vorgenommen werden. Ferner sind verschiedene Schnittstellen beschrieben, die einerseits zur Kommunikation zwischen den einzelnen Betriebsleitsystemen, anderseits zur Kommunikation zwischen den Netzwerkelementen und den Betriebsleitsystemen verwendet werden. Zur Überwachung und zur direkten Eingabe von Befehlen an das TMN steht einem Benutzer eine Arbeitsstation zur Verfügung, die beispielsweise aus einem Bildschirm allein, aus einem Kleinrechner bestehend aus Tastatur und Bildschirm oder aus einem an einen Grossrechner angeschlossenen Terminal besteht.

Das eigentliche Konzept eines TMN ist somit eine definierte Netzwerkstruktur, in der verschiedene die Verwaltungsfunktionen enthaltende Betriebsleitsysteme durch standardisierte Protokolle und Schnittstellen mit Netzwerkelementen einer Telekommunikationsanlage verknüpft sind. Die zwischen einem Betriebsleitsystem und einem Netzwerkelement vorgesehene Schnittstelle wird dabei als Q3-Schnittstelle bezeichnet und ist in den CCITT-Empfehlungen der X.700-Reihe und in G.773 definiert. Die in der Definition für die Q3-Schnittstelle enthaltenen Angaben sollen vorzugsweise für sämtliche Netzwerkelemente der Telekommunikationsanlage implementiert werden. Da sich jedoch die Netzwerkelemente und deren Funktionen und Ansteuerungsmöglichkeiten nicht nur aufgrund der verschiedenen Realisierungsformen der anbietenden Hersteller, sondern auch wegen den unterschiedlich zu bewältigenden Aufgaben grundsätzlich unterscheiden, muss jede Schnittstelle neben den mehr allgemeinen Vorgaben der CCITT-Empfehlung auch die speziellen durch das Netzwerkelement vorgegebenen spezifischen Erfordernisse erfüllen. Wegen der Vielfalt der vorhandenen Netzwerkelemente und der für jedes Netzwerkelement vorhandenen grossen Anzahl an Steuerungsfunktionen muss bei der Realisierung eines TMN und deren Schnittstellen ein enormer Aufwand in Kauf genommen werden. Insbesondere wird bei einer mittels Telegrammen realisierten Schnittstelle, bei der für jede im Netzwerkelement bzw. im Betriebsleitsystem auszuführende Funktion ein Telegramm erzeugt wird, die Anzahl dieser zur Kommunikation benötigten Telegramme derart gross, dass die Funktionsweise der Schnittstelle unübersichtlich und somit fehleranfällig wird.

Der vorliegenden Erfindung liegt daher die Aufgabe zugrunde, ein vielseitig verwendbares Verfahren zum einfachen Steuern und Verwalten von unterschiedlichen Netzwerkelementen anzugeben.

Diese Aufgabe wird durch die im kennzeichnenden Teil des Patentanspruchs 1 angegebenen Massnahmen gelöst. Vorteilhafte Ausgestaltungen der Erfindung sowie eine Anwendung sind in weiteren Ansprüchen angegeben.

Ausgehend von den erwähnten in den CCITT-Empfehlungen der X.700-Reihe und in G.773 beschriebenen Q3-Schnittstelle zwischen einem Betriebsleitsystem eines TMN und einem Netzwerkelement einer Telekommunikationsanlage wird ein Informationsmodell für ein anzusteuerndes Netzwerkelement angegeben. In diesem Informationsmodell wird festgelegt, mit welchen Mitteln und auf welche Art ein Betreiber die betroffene Telekommunikationsanlage bzw. das Netzwerkelement über das TMN steuern kann. Dabei werden Komponenten eines Netzwerkelementes durch Objekte repräsentiert, über die die entsprechenden Komponenten vom Betriebsleitsystem gesteuert und über die auch Zustandsänderun-gen von Komponenten eines Netzwerkelementes an das Betriebsleitsystem angezeigt werden. Die Verarbeitung von für die Steuerung verwendeten Befehlsanzeigen sowie für die von einer Komponente ausgehenden Zustandsänderungsanzeigen erfolgt in einer zentralen Objektverwaltungseinheit, in der lediglich die in der Befehlsanzeige referenzierten aktiven Objekte vorhanden sind. Die restlichen Objekte werden in einer sogenannten Objektdatenbank separat von der Objektverwaltungseinheit abgelegt und verwaltet. Eine ähnliche funktionale Trennung wie zwischen der Objektdatenbank und der Objektverwaltungseinheit ist auch zwischen den restlichen Verarbeitungseinheiten - wie einer Auswahleinheit, einem Protokollzwischenspeicher und einer Schnittstelleneinheit - vorhanden. Die Trennung von Verfahrens2

5

10

15

20

25

30

35

40

45

50

55

60

65

CH 686 540 A5

schritten, insbesondere die Unabhängigkeit der Objektverwaltungseinheit von der Objektdatenbank und den restlichen Einheiten, ermöglicht es, die Objektverwaltungseinheit in verschiedenen Anwendungen zu verwenden. Bei einem Anwendungswechsel muss die Objektverwaltungseinheit nicht verändert werden, sondern lediglich die in den Objekten der Objektdatenbank abgelegten Informationen. Diese prinzipielle Struktur einer Q3-Schnittstelle lässt sich bei allen in einer Telekommunikationsanlage verwendeten Netzwerkelementen einsetzen. Somit unterscheiden sich die an die verschiedenen Netzwerkelemente angeschlossenen Q3-Schnittstellen lediglich durch den Inhalt der in der Objektdatenbank abgelegten Informationen und durch die für das angeschlossene Netzwerkelement spezifische Schnittstelleneinheit. Es ergibt sich somit eine zur Verwaltung von Netzwerkelementen universelle Lösung, die auf neue oder andere Spezifikationen mit minimalem Aufwand angewendet werden kann. So kann das erfindungsge-mässe Verfahren neben dem Verwalten von Netzwerkelementen eines PDH-(Plesiochronous Digital Hierachy)- oder eines SDH-(Synchronous Digital Hierarchy)-Systems auch als ATM-(Asynchronous Transfer Mode)-Verwalter oder als Verwalter einer ganzen Fernmeldezentrale eingesetzt werden.

Die Erfindung wird nachfolgend anhand von Zeichnungen beispielsweise näher erläutert. Dabei zeigt

Fig. 1 einen prinzipiellen Aufbau eines Telekommunikationsverwaltungsnetzwerkes mit einer zu verwaltenden Telekommunikationsanlage,

Fig. 2 eine schematische Darstellung von möglichen Abbildungen von Netzwerkelementen auf Objekte und umgekehrt,

Fig. 3 einen prinzipiellen Aufbau einer Q3-Schnittstelle, in der das erfindungsgemässe Verfahren abläuft,

Fig. 4 eine bei einer Objekterstellung ablaufende Meldungssequenz anhand eines Sequenzdiagramms,

Fig. 5 eine bei einer Objektlöschung ablaufende Meldungssequenz anhand eines Sequenzdiagramms und

Fig. 6 eine Meldungssequenz bei der Ausführung einer GET-Operation auf ein bestehendes Objekt anhand eines Sequenzdiagramms.

Fig. 1 zeigt eine durch ein Telekommunikationsverwaltungsnetzwerk TMN verwaltete Telekommunikationsanlage TCN bestehend aus mindestens zwei Endstationen TT 1 und TT2 und verschiedenen Netzwerkelementen NE1 bis NEi. Die Netzwerkelemente NE1 bis NEi können dabei beliebige Geräte wie beispielsweise Übertragungssysteme, Koppelsysteme, Mulitplexer oder Signalisierungssysteme sein. Zur Verwaltung - d.h. zum Konfigurieren, Fehlerermitteln, Kostenberechnen, Qualitätsabschätzen, usw. -der Telekommunikationsanlage TCN wird das über Q3 Schnittstellen mit den Netzwerkelementen NE1 bis NEi verbundene Telekommunikationsverwaltungsnetzwerk TMN verwendet, das aus Betriebsystemen OS1 bis OSn, aus Arbeitsstationen WS1 bis WSk und aus einem Datennetz DCN besteht. Das Datennetz DCN ist zum Transport von Daten zwischen einzelnen funktionellen Blöcken vorgesehen und ist aus diesem Grund mit den Netzwerkelementen NE1 bis NEi, den Arbeitsstationen WS1 bis WSk und den Betriebsleitsystemen OS1 bis OSn verbunden. In den Betriebsleitsystemen OS1 bis OSn laufen die eigentlichen Verwaltungsfunktionen des Telekommunikationsverwaltungssystems TMN ab, wobei diese durch Benutzer an den beispielsweise aus einem Terminal und/oder einem PC (Personal Computer) bestehenden Arbeitsstationen WS1 bis WSk überwacht und ausgelöst werden können.

Die Netzwerkelemente NE1 bis NEi sind gemäss der Darstellung in Fig. 1 sowohl dem Telekommuni-kationsverwaltungsnetzwerk TMN als auch der Telekommunikationanlage TCN zugeordnet. Dies ergibt sich aus der Tatsache, dass keine klare Trennlinie zwischen den jeweiligen Systemteilen gezogen werden kann. Jedoch kann ein zum Netzwerkelement NE3 gehörender Adapter Q3A, in dem das erfindungsgemässe Verfahren abläuft, voll als zur Telekommunikationsanlage TCN gehörend angesehen werden. Der Adapter Q3A nimmt die Anpassung der für ein bestimmtes Netzwerkelement NE3 spezifischen Schnittstelle an die in einem Telekommunikationsverwaltungsnetzwerk TMN vorgeschriebene Q3-Schnittstelle vor.

Anhand Fig. 2 wird die im letzten Abschnitt angedeutete Trennlinie zwischen dem Telekommunikati-onsverwaltungsnetzwerk TMN und der Telekommunikationsanlage TCN (Fig. 1) weiter erläutert. Dabei werden Komponenten K1 bis Kn eines Netzwerkelementes NE einer Anzahl von Objekten 01 bis Ok in verschiedenen Abbildungen P1 bis Pe zugeordnet. Die Abbildungen P1 bis Pe entstehen dabei aus den auf die Objekte 01 bis Ok bzw. aus den auf die Komponenten K1 bis Kn anzuwendenden Methoden, wobei ein von einem Betriebsleitsystem OS an eine Komponente K1 bis Kn gerichteter Befehl über das entsprechende Objekt 01 bis Ok erfolgt. In gleicher Weise werden Meldungen über den Zustand einer Komponente K1 bis Kn des Netzwerkelementes NE über die betroffenen Objekte 01 bis Ok dem entsprechenden Betriebsleitsystem OS übermittelt. Vom Betriebsleitsystem OS aus sind somit die einzelnen Komponenten K1 bis Kn nur indirekt über die Objekte 01 bis Ok ansteuerbar. Ein direktes Zugreifen auf eine oder mehrere Komponenten K1 bis Kn von einem Betriebsleitsystem OS aus ist nicht möglich.

Die Abbildungen P1 bis Pe von Komponenten K1 bis Kn auf Objekte Ol bis Ok und umgekehrt lassen sich in verschiedene Abbildungskategorien unterteilen. Im folgenden wird jede Abbildungskategorie anhand einer der Abbildungen P1 bis P4 erläutert:

3

5

10

15

20

25

30

35

40

45

50

55

60

65

CH 686 540 A5

Bei der Abbildung P1 repräsentiert das Objekt 01 genau eine Komponente K1 des Netzwerkelementes NE. Ein beispielsweise zu einer Klasse «equipment» gehörendes Objekt 01 stellt dabei beispielsweise eine als Baugruppe bezeichnete Komponente K1 eines Netzwerkelementes NE dar.

In der Abbildung P2 repräsentieren mehrere Objekte 02 und 03 eine Komponente K2 des Netzwerkelementes NE. Diese Konstellation ist beispielsweise bei einer Baugruppe mit mehreren VC12-Schnitt-stellen (CCITT-Empfehlung G.708) möglich: Für jede VC12-Schnittstelle ist ein Objekt vorhanden, obwohl sich alle VC12-Schnittstellen auf der gleichen Baugruppe befinden.

Mit der Abbildung P3 sind zwei Fälle abgedeckt: Im ersten wird eine vorhandene Komponente K3 durch kein Objekt repräsentiert. Dies triffl beispielsweise bei einem Baugruppenträger zu. Im zweiten Fall repräsentiert ein Objekt 04 keine Komponente des Netzwerkelementes NE. Als Beispiel sei hier ein zur Initialisierung der Q3-Schnittstelle verwendetes Objekt angegeben.

In der Abbildung P4 werden mehrere Komponenten K4 und K5 durch ein Objekt 05 repräsentiert, wie dies beispielsweise bei einer VC4-Schnittstelle (CCITT-Empfehlung G.708) der Fall sein kann, die bei dessen hardwaremässigen Realisierung über mehrere Baugruppen verteilt wurde. Die VC4-Schnittstellenteile auf den verschiedenen als Komponenten K4 und K5 bezeichneten Baugruppen werden durch das Objektes 05 allein dargestellt.

Die Objekte 01 bis Ok mit den entsprechenden auf diese anzuwendenden Methoden und die Abbildungen P1 bis Pe bilden zusammen das bereits erwähnte Informationsmodell, das beispielsweise in ASN.1-Syntax (CCITT-Empfehlung X.208) definiert wird. Das auf diese Art beschriebene Informationsmodell enthält alle vom Betriebsleitsystem OS aus steuerbaren Funktionen eines Netzwerkelementes NE in kompakter Form. Im folgenden wird ein Ausschnitt aus einem das Objektes «equipment» enthaltende Definitionsmodul dargestellt:

4

5

10

15

20

25

30

35

40

45

50

55

60

65

CH 686 540 A5

equipment

DERIVED FROM

CHARACTERIZED BY

BEHAVIOUR DEFINITION ATTRIBUTES equipmentlD operational State administrativeState alarmStatus locationName equipmentExpected equipmentActual replaceable physicalConnectorList currentProblemList implements userLabel availabilityStatus controlStatus alarmPesitenceTime NOTIFICATION

attributeValueChange, equipmentAlarm, objectCreation, objectDeletion, stateChange; ACTIONS

MANAGED OBJECT CLASS top equipmentPackage PACKAGE equipmentBehaviour;

G ET,

GET,

GET-REPLACE,

GET,

GET-REPLACE

ADD-REMOVE,

GET,

GET-REPLACE,

GET,

GET-REPLACE. GET-REPLACE;

REGISTERED AS

{nkueMObjectClass 6};

equipment

BEHAVIOUR DEFINED AS

The implementation relationships between functional objects (such as terminati-on points) and equipment objects is shown by the attribute ImplementedByPtr in the functional object....

5

10

15

20

25

30

35

40

45

50

55

60

CH 686 540 A5

Neben den unter dem Schlüsselwort ATTRIBUTES gespeicherten Datensätzen, in denen Informationen über die Baugruppe gespeichert werden, sind die entsprechenden von einem Betriebsleitsystem OS auf den Datensatz bzw. auf das Objekt ausführbaren Funktionen angegeben. So kann das Betriebsleitsystem OS zum Beispiel den «alarmStatus» nur lesen, d.h. es kann ihn nur mit Hilfe der Operation GET holen. Dagegen kann der frei definierbare Datensatz «userLabel» vom Betriebsleitsystem OS gelesen (GET) und auch verändert werden (REPLACE). Wie die einzelnen Datensätze definiert sind, ist an dieser Stelle nicht angegeben. Für die Definition von Datensätzen sind spezielle Definitionsmodule vorgesehen, in denen ebenfalls die ASN.1-Syntax verwendet wird.

Unter dem Schlüsselwort NOTIFICATION werden alle Meldungen aufgeführt, die von dem Objekt der Klasse «equipment» spontan an das Betriebsleitsystem OS gesendet werden können. Beispielsweise wird die Meldung «attributeValueChange» abgesetzt, wenn sich der Wert bestimmter Datensätze ändert. Analog dazu wird bei einem Alarm eine Meldung «equipmentAlarm» abgesetzt, wenn das Objekt bzw. die entsprechende Komponente (z.B. eine Baugruppe) ein Fehlverhalten aufweist. Als weiteres Beispiel sind die Meldungen «objectCreation» und «objectDeletion» angegeben, die jeweils abgesetzt werden, wenn ein Objekt im Betrieb entsteht (d.h. instanziert wird) bzw. gelöscht wird, was beispielsweise dem Einstecken bzw. Entfernen einer Baugruppe in den bzw. aus dem Baugruppenträger entspricht.

Unter dem Schlüsselwort ACTIONS sind von den Betriebsleitsystemen OS1 bis OSn (Fig. 1) auslösbare Funktionen aufgeführt. Beim Objekt «equipment» sind keine derartigen Funktionen vorgesehen, weshalb die entsprechende Stelle leer ist.

Mit der Registrierung des Objektes - eingeleitet durch das Schlüsselwort REGISTERED AS - wird jedes Objekt eindeutig identifiziert. Dadurch wird es dem Betriebsleitsystem OS erlaubt, die Funktionalität der angeschlossenen Komponenten K1 bis Kn (Fig. 2) zu bestimmen.

Schliesslich wird unter dem durch die Schlüsselwörter BEHAVIOUR DEFINED AS eingeleiteten Definitionsteil das Verhalten des Objektes im Detail in einem Text beschrieben. Im Gegensatz zum formalen, durch die Schlüsselwörter ATTRIBUTES, NOTIFICATION, ACTIONS und REGISTERED AS eingeleiteten Teile, die maschinenlesbar sind, kann die unter dem Schlüsselwort BEHAVIOUR DEFINED AS angeführte Beschreibung nicht automatisch in maschinenausführbare Form gebracht werden.

In Fig. 3 werden die funktionellen Blöcke der Q3-Schnittstelle mit den zu diesen angrenzenden Betriebsleitsystemen OS1 bis OSn des Telekommunikationsverwaltungsnetzwerkes TMN (Fig. 1) und dem zur Telekommunikationsanlage TCN (Fig. 1) gehörenden Netzwerkelement NE3 dargestellt. Dabei wird eine von einem Betriebsleitsystem OS1 bis OSn stammende Befehlsanzeige OIND über einen Protokollzwischenspeicher PS und eine Auswahleinheit SMASE an eine in einer Objektverwaltungseinheit OM befindlichen Befehlsverarbeitungseinheit CP übergeben. Neben der Befehlsverarbeitungseinheit CP sind in der Objektverwaltungseinheit OM eine Objektinitialisierungseinheit Ol, eine Mitteilungsverwal-tungseinheit ND und verschiedene Informationsbäume RT, IT, NBT und OIT vorhanden. Auf der Seite der Telekommunikationsanlage TCN (Fig. 1) kommuniziert die Objektverwaltungseinheit OM mittels Zu-standsänderungsanzeigen TIND und Anweisungen TRESP über eine Schnittstelleneinheit TKI mit dem Netzwerkelement NE3. Ferner sind die Objekte 01 bis Ok (Fig. 2) in einer Objektdatenbank MO abgelegt, auf die von der Objektverwaltungseinheit OM bzw. von der Befehlsverarbeitungseinheit CP direkt zugegriffen wird.

Die Objektverwaltungseinheit OM stellt nicht nur wegen deren Lage zwischen dem Telekommunikati-onsverwaltungsnetzwerk TMN (Fig. 1), dem Netzwerkelement NE3 und der Objektdatenbank MO den zentralen Teil dar, sondern ist insbesondere auch der ausführende Teil im Adapter Q3A (Fig. 1). Sämtliche Befehlsanzeigen OIND und Zustandsänderungsanzeigen TIND werden in dieser Objektverwaltungseinheit OM interpretiert und alle Anweisungen TRESP und Befehlsantworten ORESP an die Betriebsleitsysteme OS1 bis OSn und an das Netzwerkelement NE3 erstellt. Alle Aufforderungen eines Betriebsleitsystems OS1 bis OSn zur Änderung von unter dem Schlüsselwort ATTRIBUTES stehenden Datensätzen oder zur Ausführung eines unter dem Schlüsselwort ACTIONS stehenden Befehls im oben angegebenen Definitionsmodul werden durch die Objektverwaltungseinheit OM interpretiert und ausgeführt. Dabei werden die verschiedenen in den CCITT-Empfehlungen der X.700-Reihe definierten Informationsbäume RT, IT, NBT und OIT dazu verwendet, um die Richtigkeit der auf die Objekte 01 bis Ok anzuwendenden Befehle zu überprüfen.

Die zwischen den Betriebsleitsystemen OS1 bis OSn und der Objektverwaltungseinheit OM liegenden Einheiten Protokollzwischenspeicher PS und Auswahleinheit SMASE sind allgemein aus den CCITT-Empfehlungen X.710 bzw. X.711 bekannt und müssen aus diesem Grund an dieser Stelle nicht weiter erläutert werden. Als bekannt kann auch die zwischen dem Netzwerkelement NE3 und der Objektverwaltungseinheit OM liegenden Schnittstelleneinheit TKI vorausgesetzt werden, da diese eine ähnliche Funktion wie der Protokollzwischenspeicher PS ausübt und zudem stark von dem zu steuernden Netzwerkelement NE3 abhängt.

Die Objektinitialisierungseinheit Ol ist im wesentlichen mit dem Erstellen und Löschen von zu verwaltenden Objekten 01 bis Ok (Fig. 2) sowie mit dem Verwalten der Informationbäume RT und NBT beauftragt. Eine Aufforderung kommt dabei jeweils von der Befehlsverarbeitungseinheit CP. Betrifft die Aufforderung die Erstellung eines Objektes 01 bis Ok (Fig. 2), so muss eine eindeutige Identifikation des neuen Objektes erzeugt und an die Befehlsverarbeitungseinheit CP zurückgesandt werden, sofern

6

5

10

15

20

25

30

35

40

45

50

55

60

65

CH 686 540 A5

mit der Aufforderung nicht bereits eine eindeutige Identifikation an die Objektinitialisierungseinheit Ol übermittelt wurde. Die Erstellung eines neuen Objektes wird schliesslich durch die Mitteilungsverwal-tungseinheit ND bestätigt. Betrifft die Aufforderung eine Löschung eines der Objekte 01 bis Ok (Fig. 2), so wird das betroffene Objekt gelöscht, falls es gefunden wird und falls die Löschung gemäss den Angaben im Informationsbaum OIT erlaubt ist. Die Löschung eines Objektes in der Objektdatenbank wird wiederum durch die Mitteilungsverwaltungseinheit ND bestätigt, in der sämtliche Mitteilungen überprüft werden. Weitere Erläuterungen sind im Zusammenhang mit Angaben zu den Fig. 4 bis 6 aufgeführt.

Die Befehlsverarbeitungseinheit CP wird insbesondere für die Kommunikation mit den verwalteten Objekten 01 bis Ok (Fig. 2) in der Objektdatenbank MO verwendet, indem die von einem der Betriebsleitsysteme OS1 bis OSn erhaltenen Befehlsanzeigen OIND oder die vom Netzwerkelement NE3 erhaltenen Zustandsänderungsanzeigen TIND an die betroffenen Objekte 01 bis Ok (Fig. 2) verteilt werden. Dabei kann ein betroffenes Objekt 01 bis Ok aktiv oder passiv sein: Aktiv bedeutet in diesem Zusammenhang, dass ein Objekt 01 bis Ok bereits in einem anderen Prozess verwendet wird. Passiv bedeutet demzufolge, dass ein Objekt 01 bis Ok in keinem anderen Prozess zur Zeit benötigt wird und in der Objektdatenbank MO abgelegt ist. Auf die aktivierten Objekte werden die gemäss den Angaben im jeweiligen Definitionsmodul zugelassenen Methoden entsprechend den Befehlsanzeigen OIND bzw. den Zustandsänderungsanzeigen TIND angewendet. Nach dem Ausführen einer Methode werden die in keinem weiteren Prozess mehr benötigten Objekte durch Deaktivierung in den passiven Zustand versetzt. Grundsätzlich kann auf ein passives Objekt lediglich eine Methode zur Aktivierung angewendet werden.

In den Fig. 4 bis 6 werden verschiedene in der Objektverwaltungseinheit OM ablaufende Meldungssequenzen anhand von Sequenzdiagrammen dargestellt, wobei nur die von Meldungen betroffenen Einheiten angegeben sind.

Fig. 4 beschreibt die Meldungssequenz einer von einem Betriebsleitsystem OS ausgehenden Befehlsanzeige OIND, die den Befehl zur Erstellung eines neuen Objektes beinhaltet. Die zum Erstellen von Objekten betroffenen Einheiten, wie die Mitteilungsverwaltungseinheit ND, die Objektinitialisierungseinheit Ol, die Befehlsverarbeitungseinheit CP und das jeweils aktivierte Objekt AO, sind im Sequenzdiagramm angegeben, wobei anstelle des Betriebsleitsystems OS auch eines der Nekwerkele-mente NE1 bis NEi (Fig. 1) eine entsprechende Anzeige, nämlich eine Zustandsänderungsanzeige TIND (Fig. 3), zur Erstellung eines neuen Objektes abgeben kann.

Wenn vom Betriebsleitsystem OS eine zur Erstellung eines Objektes 01 bis Ok (Fig. 2) benötigte Befehlsanzeige OIND in der Befehlsverarbeitungseinheit CP empfangen wird, wird eine Erstellungsanfrage CRQ an die Objektinitialisierungseinheit Ol abgesandt. Falls noch keine eindeutige Identifikation für das zu erstellende Objekt vorhanden ist, wird diese, falls ein neues Objekt kreiert werden kann, in der Objektinitialisierungseinheit Ol erstellt und in einer Erstellungsantwort CRP an die Befehlsverarbeitungseinheit CP übermittelt. Anschliessend erzeugt die Befehlsverarbeitungseinheit CP ein neues, aktives Objekt AO im lokalen Speicher der Objektverwaltungseinheit OM (Fig. 3) und führt eine entsprechende Initialisierung mittels der Objekterstellungsmeldung CMO aus, die vom Objekt AO durch eine Erstellungsantwort RMO entsprechend bestätigt wird. Gleichzeitig wird die Mitteilungsverwaltungseinheit ND über das erfolgreiche Erstellen des neuen Objektes AO mittels einer Meldung N informiert, dessen Eintreffen an die abgehende Stelle mit der Meldung NC rückbestätigt wird. Auch an das rufende Betriebsleitsystem OS erfolgt eine Rückbestätigung mittels der auch in Fig. 3 dargestellten Befehlsantwort ORESP. Schliesslich wird das neue Objekt AO durch eine Deaktivierungsbefehl DEAC durch die Befehlsverarbeitungseinheit CP deaktiviert und in der Objektdatenbank MO (Fig. 3) gespeichert. Der von der Befehlsverarbeitungseinheit CP abgegebene Deaktivierungsbefehl DEAC kann auch weggelassen werden, wenn das Objekt AO nach dem Absenden der Befehlsantwort ORESP automatische deaktiviert wird.

Da sämtliche Objekte von der Befehlsverarbeitungseinheit CP kontrolliert werden, erfolgen auch alle Meldungen von einem Objekt AO an andere Einheiten über die Befehlsverarbeitungseinheit CP. Dies ist in den Fig. 4 bis 6 durch einen Meldungsunterbruch bei der Befehlsverarbeitungseinheit CP dargestellt, wie beispielsweise bei der durch das Objekt AO ausgelösten an die Mitteilungsverwaltungseinheit ND abgesandten Meldung N.

Anhand Fig. 5 wird eine Meldungssequenz zum Löschen eines der Objekte 01 bis Ok (Fig. 2) in der Objektdatenbank MO (Fig. 3) erläutert. Wenn vom Betriebsleitsystem OS eine zum Löschen eines der Objekte 01 bis Ok (Fig. 2) benötigte Befehlsanzeige OIND in der Befehlsverarbeitungseinheit CP empfangen wird, wird eine Anfrage DRQ1 durch die Befehlsverarbeitungseinheit CP bei der Objektinitialisierungseinheit Ol vorgenommen, in der überprüft wird, ob weitere vom zu löschenden Objekt AO abhängige Objekte vorhanden sind und ob diese abhängigen Objekte ebenfalls gelöscht werden sollen. Das Resultat wird mittels einer Löschantwort DRSP an die Befehlsverarbeitungseinheit CP zurückgegeben. Diese gibt bei positiver Antwort zur Löschung des Objektes AO die ursprünglicher Befehlsanzeige OIND an das noch zu aktivierende Objekt AO weiter. Vor dem Löschen des Objektes AO wird die Mitteilungsverwaltungseinheit ND mit der Meldung N informiert. Nach dem Eingang einer Rückbestätigungsmel-dung NC von der Mitteilungsverwaltungseinheit NC beim Objekt AO wird die Objektlöschung dem den Löschbefehl sendenden Betriebsleitsystem OS mittels einer Antwort ORESP angezeigt. Schliesslich wird die Objektlöschung mit einer letzten, vom zu löschenden Objekt AO ausgehenden Löschanzeige KRP der Befehlsverarbeitungseinheit CP mitgeteilt, welche eine entsprechende Löschanzeige KRP an die

7

5

10

15

20

25

30

35

40

45

50

55

CH 686 540 A5

Objektinitialisierungseinheit Ol weitergibt. Ein Deaktivierungsbefehl DEAC kann - wie bereits unter Fig. 4 erläutert - auch weggelassen werden, falls eine Deaktivierung des Objektes AO bereits mit dem Abgeben der Löschanzeige KRP vorgenommen wurde.

Fig. 6 zeigt ein Sequenzdiagramm einer durch ein Betriebsleitsystem OS ausgelösten GET-Operati-on, die in einer Befehlsanzeige OIND an die Befehlsverarbeitungseinheit CP gesandt und zum Lesen eines Datensatzes (Attribute) eines Objektes 01 bis Ok (Fig. 3) verwendet wird. Durch einen von der Befehlsverarbeitungseinheit CP ausgehenden Aktivierungsbefehl ARQ wird das von der GET-Operation betroffene Objekt AO aktiviert. Daraufhin wird im Objekt AO eine für das Lesen des Datensatzes benötigte Methode durch Übersenden einer Leseaufforderung GRQ an das aktivierte Objekt AO ausgelöst. Mit der Befehlsantwort ORESP wird der Inhalt des gelesenen Datensatzes an das Betriebsleitsystem OS übermittelt. Schliesslich wird das Objekt AO durch die von der Befehlsverarbeitungseinheit CP abgegebenen Deaktivierungsmeldung DEAC deaktiviert.

Die in den Fig. 4 bis 6 angegebenen Beispiele können analog auf die anderen Operationen, wie beispielsweise REPLACE, ADD, REMOVE, etc., angewendet werden. Ferner können auch die zwischen der Befehlverarbeitungseinheit CP und dem Netzwerkelement NE3 übermittelten Zustandsänderungsanzeigen TIND bzw. Anweisungen TRESP (Fig. 3) analog zu den in den Fig. 4 bis 6 dargestellten Sequenzen angegeben werden.

Claims

Patentansprüche

1. Verfahren zum Steuern und/oder Verwalten von Netzwerkelementen (NE1 NEi) mittels Objekten (01 Ok), von denen sich mindestens eines auf mindestens eine Komponente (K1 Kn) eines oder mehrerer Netzwerkelemente (NE1 NEi) bezieht, dadurch gekennzeichnet, dass eine von einem

Betriebsleitsystem (OS, OS1, ..., OSn) ausgehende Befehlsanzeige (OIND) in einer Objektverwaltungseinheit (OM) verarbeitet wird, wobei alle von der Befehlsanzeige (OIND) betroffenen, in einer Objektdatenbank (MO) abgelegten Objekte (01 Ok) aktiviert und in der Befehlsanzeige (OIND) enthaltene

Befehle auf die aktivierten Objekte (Ol, .... Ok) angewendet werden und dass mit der Befehlsanwendung auf die Objekte (Ol, ..., Ok) entsprechende Anweisungen (TRESP) in den Netzwerkelementen (NE1, ..., NEi) ausgeführt werden, falls dies erforderlich ist.

2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass Zustandsänderungen in Netzwerkelementen (NE1, ..., NEi) mittels Zustandsänderungsanzeigen (TIND) an die Objektverwaltungseinheit (OM) gemeldet werden, in der alle von den Zustandsänderungen betroffenen Objekte (Ol Ok) aktiviert und dem momentanen Zustand angepasst werden und dass die Objektverwaltungseinheit (OM) diese Zustandsänderungen in einer Befehlsantwort (ORESP) bei Bedarf an ein oder mehrere Betriebsleitsysteme (OS, OS1, ..., OSn) übermittelt.

3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass die Befehlsanzeigen (OIND) und die Zustandsänderungsanzeigen (TIND) an mindestens eine in der Objektverwaltungseinheit (OM) enthaltene Befehlverarbeitungseinheit (CP) übergeben werden, dass die durch die Befehlsanzeige (OIND) und die Zustandsänderungsanzeige (TIND) betroffenen, bereits in der Objektdatenbank (MO) existierenden Objekte (01 Ok) durch die Befehlsverarbeitungseinheit (CP) aktiviert werden, falls diese nicht schon im aktiven Zustand sind, dass die in der Befehlsanzeige (OIND) und in der Zustandsänderungsanzeige (TIND) gegebenenfalls enthaltenen Befehle mindestens eine für ein Objekt (01, ..., Ok) vorgesehene Methode auslösen, dass eine Befehlsantwort (ORESP) an das die Befehlsanzeige (OIND) auslösende Betriebsleitsystem (OS, OS1 OSn) bzw. eine Anweisung (TRESP) an das die Zustandsänderungsanzeige (TIND) auslösende Netzwerkelement (NE1, ..., NEi) übermittelt wird und dass die aktivierten Objekte (01, ..., Ok) anschliessend deaktiviert werden.

4. Verfahren nach Anspruch 3, dadurch gekennzeichnet, dass eine Löschung und/oder eine Erstellung eines Objekts (01 Ok) in einer ebenfalls in der Objektverwaltungseinheit (OM) enthaltenen Objektinitialisierungseinheit (Ol) vorgenommen werden, dass die Objektinitialisierungseinheit (Ol) die Löschung bzw. die Erstellung eines Objekts (01 Ok) in mindestens einem Informationsbaum (NBT,

OIT, RT, IT) festhält, dass bei der Erstellung eines neuen Objektes (01 Ok) eine Identifikation mit

Hilfe mindestens eines Informationsbaumes (NBT, OIT, RT, IT) von der Objektinitialisierungseinheit (Ol) erzeugt wird und dass diese Identifikation in mindestens einem Informationsbaum (NBT, OIT, RT, IT) festgehalten und der Befehlsverarbeitungseinheit (CP) übermittelt wird.

5. Verfahren nach Anspruch 3 oder 4, dadurch gekennzeichnet, dass sämtliche in der Objektverwaltungseinheit (OM) ankommenden und abgehenden sowie in der Objektverwaltungseinheit (OM) intern ausgetauschten Mitteilungen über eine Mitteilungsverwaltungseinheit (ND) übermittelt werden.

6. Verfahren nach Anspruch 5, dadurch gekennzeichnet, dass Mitteilungen von Objekten (01 Ok)

an die Mitteilungsverwaltungseinheit (ND) und umgekehrt über die Befehlsverarbeitungseinheit (CP) erfolgen.

7. Verfahren nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass die Befehlsanzeige (OIND) und/oder die Befehlsantwort (ORESP) vor der Verarbeitung in der Objektverwaltungseinheit (OM) in einem Protokollzwischenspeicher (PS) und/oder in einer Auswahleinheit (SMASE) vorverarbeitet werden.

8. Verfahren nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass die Zu-

8

5

10

15

20

25

30

35

40

45

50

55

60

65

CH 686 540 A5

standsänderungsanzeige (TIND) und/oder die Anweisung (TRESP) vor der Verarbeitung in der Objektverwaltungseinheit (OM) in einer Schnittstelleneinheit (TKI) vorverarbeitet werden.

9. Verfahren nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass die Objekte (01 Ok) mit Hilfe der ASN.1-Syntax beschrieben werden.

10. Anwendung des Verfahrens nach Anspruch 1 in einem Adapter (Q3A) zur Steuerung und/oder Verwaltung von Netzwerkelementen (NE1, ..., NEi) einer Telekommunikationsanlage (TCN).

11. Anwendung des Verfahrens nach Anspruch 10, dadurch gekennzeichnet, dass die Telekommunikationsanlage (TCN) nach dem Asynchronen Transfermodus arbeitet.

9