WO2004002172A1 - Verfahren und netzwerkelement zum verwalten von ressourcen eines netzwerkelementes - Google Patents

Verfahren und netzwerkelement zum verwalten von ressourcen eines netzwerkelementes Download PDF

Info

Publication number
WO2004002172A1
WO2004002172A1 PCT/DE2003/001819 DE0301819W WO2004002172A1 WO 2004002172 A1 WO2004002172 A1 WO 2004002172A1 DE 0301819 W DE0301819 W DE 0301819W WO 2004002172 A1 WO2004002172 A1 WO 2004002172A1
Authority
WO
WIPO (PCT)
Prior art keywords
database
central
network element
mdb
decentralized
Prior art date
Application number
PCT/DE2003/001819
Other languages
English (en)
French (fr)
Inventor
Wolfgang Krille
Original Assignee
Siemens Aktiengesellschaft
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 Aktiengesellschaft filed Critical Siemens Aktiengesellschaft
Priority to EP03760550A priority Critical patent/EP1514434A1/de
Publication of WO2004002172A1 publication Critical patent/WO2004002172A1/de

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/02—Standardisation; Integration
    • H04L41/0213—Standardised network management protocols, e.g. simple network management protocol [SNMP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q3/00—Selecting arrangements
    • H04Q3/0016—Arrangements providing connection between exchanges
    • H04Q3/0062—Provisions for network management
    • 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/02—Standardisation; Integration
    • H04L41/0233—Object-oriented techniques, for representation of network management data, e.g. common object request broker architecture [CORBA]
    • 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/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H04L41/0806—Configuration setting for initial configuration or provisioning, e.g. plug-and-play
    • 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/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H04L41/0813—Configuration setting characterised by the conditions triggering a change of settings
    • H04L41/082—Configuration setting characterised by the conditions triggering a change of settings the condition being updates or upgrades of network functionality

Definitions

  • a management agent is implemented in the network elements, which processes the commands of the central network management system (e.g. reading and setting configuration data or administrative information) and which independently monitors the current operating status of the respective network element and, if necessary, messages about changes in status - for example by means of Alarms - transmitted to the central network management system.
  • the agent usually configured as a software application in the respective network element provides the central network management system with an abstract model of the physical and logical resources of the network element - also referred to as MIB or Management Information Base.
  • the central network management system can access the physical and logical resources of the respective network element or the administrative information representing these resources - also referred to as MO or "Managed Objects *" - via a special management protocol of the network element.
  • the network elements arranged in current communication networks generally represent distributed software systems with several modules. The functions of each module are monitored and controlled by a separate processor. The corresponding physical and logical resources (managed objects) of the network element are distributed among the modules of the network element - also referred to as sub-resources.
  • the management agent of the respective network element In order to enable central administration of the resources or partial resources provided by the network elements, the management agent of the respective network element must execute the commands transmitted by the central network management system and to execute the management agent-specific monitoring functions on the physical and logical components distributed in the system Access resources or partial resources via the interface system (problem 1).
  • Another problem with the central management of the resources or sub-resources provided by the network elements is that when executing configuration or Administrative actions created by the central network management system represent administrative information which represent the configuration or the state of the managed objects or physical and logical resources distributed in the respective network element. This administrative information must be stored semi-permanently in the central network element so that the network element can resume its functions after a restart or after a module change without external configuration measures.
  • the administration and semi-permanent storage of the configuration data or administration information is generally carried out on a central assembly of the respective network element (e.g. on a monitoring assembly), so that the administration information for further central system functions such as e.g. B. Backup, restore and audits are available (problem 2).
  • the management agent and a correspondingly assigned central database are implemented on a central assembly of the network element.
  • the above-mentioned problem 2 can be solved since the management agent and the central database are assigned to a control unit or a processor and are implemented on the same central assembly.
  • the above problem 1 is solved by introducing system interfaces via which the connection between the management agent (or other functionally similar, central software subsystems) and the software subsystems distributed in the network element is realized, the
  • Subsystems are responsible for the control or monitoring of the physical and logical resources of the network element (e.g. device driver).
  • the central implementation of the management agent has the disadvantage of the dependency between the central agent implementation (the management agent represents the managed objects or partial resources or resources of the network element) and changes in the partial resources by, for example, changing the configuration of the network element. Extensions or changes to the configuration of the network element (eg by inserting a new module type) are only possible if the centrally implemented management agent, the central database and the respective system interfaces are adapted accordingly. The introduction of a new module or a new module type into the network element is therefore disadvantageously generally associated with an update or an upgrade of the software implemented in the central module, which increases the technical and economic outlay for the implementation and for configuring the software.
  • Decentralized implementation of the management agent in the network element :
  • the management agent is implemented distributed over the modules of the network element.
  • the associated database is implemented on a central assembly of the network element.
  • the decentralized agent implementation implements the sub-agent components where the associated sub-resources or managed objects of the network element are also located.
  • new sub-resources can be included in the network element, which have no effects on the centrally implemented management agents - also known as master agents.
  • the master agents only have to forward the management commands to the sub-agents, which means that the above-mentioned disadvantage of central implementation, i.e. the disadvantageous dependency between central agent implementation and changes in partial resources or managed objects is avoided.
  • the forwarding function of the master agent (problem 1) that is now required is implemented here on the basis of identifiers or on the basis of identification information in the application layer (application layer) of the management protocol.
  • management protocols are "SISA-QD2 * and" SNMP ', with “SISA-QD2 * the FG and FE number and” SNMP "the respective object identifier as identification information for the application layer Will be provided.
  • the forwarding function of the master agent can be expanded dynamically with the help of the management protocols and the respective identification information of the application layer.
  • the application layer protocols are transported to the decentralized subagent and processed there, which usually results in a close link to the management protocol.
  • the change of the management protocol or the support of additional management protocols can only be realized with increased effort.
  • a database consisting of a collection of subagent-specific databases (files) can only support central system functions such as backup, restore and audis with difficulty.
  • the invention is therefore based on the object of enabling simple, centrally controlled management of resources or partial resources arranged in network elements, in particular the problems mentioned above being avoided.
  • the object is achieved on the basis of a method and a network element according to the features of the preamble of claims 1 and 19 by their characterizing features.
  • the resources comprise at least one partial resource provided in the network element.
  • the essential aspect of the method according to the invention is that at least one central database that manages the resources of the network element and at least one decentralized database that manages the at least one partial resource is provided in the network element.
  • the central database is logically designed in the form of a tree structure such that the at least one decentralized database is simultaneously a component of the tree structure. Structure of the higher-level central database forms, the distribution of the partial resources in the network element being represented by the tree structure.
  • the decentralized database of the at least one partial resource is accessed via the tree structure of the higher-level central database.
  • the main advantage of the method according to the invention is that two functions are implemented by using the central database according to the invention.
  • management commands are forwarded in the network element to, for example, subagents representing the partial resources, and additional administrative information is stored centrally in a central database - also referred to as the master database.
  • the central database according to the invention advantageously enables the use of a uniform interface (database synchronization) for the communication of central and decentralized administration agents or software objects.
  • the management of data or information using databases which are in the form of a
  • Tree structure is an easy to solve and supported by standard components programming task, so that the inventive method can be implemented with minimal technical and economic effort. This further reduces the effort in general for the maintenance and further development of applications coordinated with the central database according to the invention, as well as the effort for introducing new modules or module types, for changing the management protocol or for implementing further management protocols ,
  • the at least one decentralized database simultaneously forms part of the tree structure of the superordinate central database (MDB, SDB ⁇ 1 ... 3) in the form of a
  • This advantageous further development makes a particularly simple definition a decentralized database as a subset of the central database.
  • the method according to the invention in particular the synchronization of central and decentralized databases, can be implemented in a particularly simple and thus inexpensive manner.
  • FIG. 3 shows an illustration of the data structure (tree structure) of the database arranged centrally in the network element.
  • FIG. 4 shows an abstract model of the physical and logical resources provided by the network element.
  • FIG. 1 shows in a block diagram an application scenario implementing the method according to the invention, consisting of an in a communication network KN - e.g. a subscriber line network or “access network *” arranged network element NE, through which subscriber lines TA or subscriber TLN are connected to a switching device VE via the standardized switching protocol V5.2.
  • a number of different types of assemblies BG1 ... 3 are arranged in the network element NE, the first assembly BG1 for connecting analog subscribers - "Pots Line Card * - the second assembly for connecting digital subscribers -" ISDN Line Card * - and the third Assembly as LAN
  • Each of the three modules BG1 ... 3 thus realizes a part of the Network element NE in total provided resources POTS, ISDN, El, whereby for the management of the respective partial resources POTS, ISDN, El of each assembly BG1 ... 3 a decentralized database SDB1 ... 3 - also referred to as "slave database *" assigned.
  • a central module ZBG is also arranged in the network element NE, which is assigned a central database MDB which manages the entire resources of the network element NE and is designed in the form of a tree structure.
  • a central agent A which controls the management of the resources of the network element NE, is assigned to the central database MDB - also referred to as the “master database *”.
  • the decentralized data bases SDB1 ... 3 are stored on the respective assembly BG1 ... 3.
  • the slave databases SDBl ... 3 or the information stored therein are also stored (for example as a copy) in the central assembly ZBG, the slave databases or the copies of these slave databases - in FIG. 1 as SDB , 1 ... 3 marked - form part of the tree structure of the central master database MDB, ie each form a subtree of the master database MDB.
  • the management model for the administration of V5.2 network elements NE is defined in the ETSI standards ITS 300-377-1 and ITS 300-376-1, whereby an implementation variant of the management model in the form of a block diagram using the 2 is shown in the nomenclature used in the standards mentioned.
  • the model shown in FIG. 2 forms the basis for the internal data model of the application scenario shown in FIG. 1 and thus determines the data structure of the central master database MDB arranged in the network element NE.
  • the modifications result from the described structure of the network element - equipment hierarchy - which is used as the basic structure for the internal data model.
  • the modified data model is shown in FIG. 3.
  • the V5 protocol processing is implemented on the central assembly ZBG, on which the master database MDB is also implemented.
  • 3 shows the three module types arranged in the network element NE - El Line Unit, Pots Line Card and ISDN Line Card -, the modules - also shown in FIG. 3 as PluglnUnit - in slotl ... 3 plug devices in one Network element NE provided assembly bracket SHELF are arranged.
  • the agent A arranged in the central assembly ZBG of the network element NE provides the central administration device NMS with the abstract model of the physical and logical resources of the network element NE shown in FIG.
  • This abstract model is also called MIB or Management Information Base.
  • the central administration device NMS can access the physical and logical resources or managed objects of the network element using a management protocol.
  • the "SNMP * - Simple Network Management Protocol - assumed - illustrated by a dashed double arrow - is assumed as an external management protocol - but other management protocols can also be used.
  • FIG. 4 shows the basic structure of a V5 MIB module in a block diagram.
  • the managed objects of the management model of the above-mentioned ETSI standards can also be found in this block diagram. However, their arrangement corresponds to the registration hierarchy for SNMP.
  • the managed objects for the equipment are also managed by a standard MIB module (also referred to as an entity MIB).
  • the basic component of the method according to the invention is the central database MDB, which is arranged in the central assembly ZBG and designed in the form of a tree structure and has the following properties:
  • the data records or management information (managed objects) stored in the central database MDB are managed in one or more tree structures. Each data record is uniquely identified by a key.
  • 25 represents a managed physical or logical resource (managed objects) or the summary of similar resources.
  • the central database MDB is advantageously designed as a type-neutral database.
  • Type neutrality is achieved in that only references to the respective data records or administrative information that are only stored in external memory blocks are managed within the central database MDB. Only the software users
  • Goods objects such as agents know the structure of the data records; if necessary, the. can also be created using a simple formal description notation for data records Access to individual elements of a data record are supported by database functions.
  • the central database or master database MDB is assigned at least one update function, which is designed in such a way that when one of the managed objects POTS, ISDN, El arranged in the central tree structure is changed or when the the management object MO representing the managed object, the respective corresponding slave database SDB1 ... 3 or the corresponding management information MO stored in the slave database SDBl ... 3 are updated with regard to the changes.
  • at least one update function can be assigned to the slave databases SDB1 ... 3, which is designed in such a way that when one of the managed objects POTS, ISDN stored in the slave databases SDB1 ... 3 is changed , El, or in the event of a change in the management information representing the managed object, the master database MDB or the corresponding administration information stored in the master database MDB are updated with regard to the changes.
  • the update functions assigned to the master database MDB and / or the slave databases SDBl ... 3 provide, for example, functions for registration and for change notification, that is to say local software objects, ie locally on the respective module ZBG, BG1 ... 3 arranged functions and / or processes such as sub-agents can register for certain data records or administrative information of the respective database MDB, SDBl ... 3 and receive a message indicating the change every time the registered data records are changed the central database MDB or from the respective slave database SDB1 ... 3. Depending on the message transmitted, further functions are carried out by the respective software objects.
  • the central database MDB continues to provide functions for the synchronization of slave databases SDB1 ...
  • a slave database SDB1 ... 3 can be registered for a specific subtree of the master database MDB. If there are changes within the subtree of the master database MDB, the respective slave database SDB1 ... 3 is updated via the synchronization function - also referred to as “slave synchronization *. Conversely, a change in the slave database SDB1 ... 3 within the registered subtree leads to an update of the data record in the master database MDB - also called master synchronization.
  • the slave databases SDB1 ... 3 can also be arranged hierarchically on several levels, i.e. for one
  • Subtree of a slave database can register another slave database.
  • a master-slave relationship is again established between these two databases.
  • the central database MDB supports two data record references per data record key: a "temporary * and a" committed * reference to support type "TRY * and" Rollback * functions.
  • the database provides special "Remote Access * functions.
  • the following method for decentralized agent implementation in the network element NE is defined with a database MDB configured as a basic component in accordance with the above statements:
  • the physical and logical resources of the network element NE are managed as managed objects corresponding to their container relationships in the tree structure of the master database MDB on the central module ZBG of the network element.
  • managed objects corresponding to their container relationships in the tree structure of the master database MDB on the central module ZBG of the network element.
  • the following arrangement of managed objects is shown as an example, using the nomenclature of the ETSI standards mentioned:
  • NE Network element
  • SHELF EquipmentHolder
  • Slot EquipmentHolder
  • the slave databases SDB1 ... 3 of the respective modules BG1 ... 3 register for a subtree of the master database MDB with the associated "PluginUnit * data record as a top element.
  • the slave databases of external equipment register a subtree with the associated "equipment * data record as a top element.
  • the Slave databases SDB1 ... 3 are loaded with the current data records or management information from the master database MDB. If the subtree does not yet exist in the MDB master database, i.e. the module has not yet been configured, the module (or the external equipment) generates the required data records with preset values or default data (also as an auto) -Provisioning). Since the MDB master database is type-neutral, new data record types and new subtree structures can also be created, whereby the expansion is possible at runtime.
  • the subagents arranged locally in the modules BG1 ... 3 register as local software objects for the change notification function and configure the local resources according to the data in the MDB database.
  • Commands transmitted from the central administration device NMS to the network element NE via SNMP protocol are routed to the associated data record of the master database MDB using a “key translation function * based on the object identifier values of the command telegram (reading or writing records).
  • a write or set command With a write or set command, the corresponding data record is changed in the master database MDB. This change is sent to the responsible subagent via the synchronization and change notification function.
  • Reports of changes in the state of the subagent reach the master database MDB in the opposite way and are converted to corresponding messages or telegrams by an "inverse key translation function *" - also referred to as trap or notification telegrams - and sent to the central one Administrative facility sent NMS.
  • the data or data records of the network element NE are structured in the master database MDB and can be from central system functions such as B. semi-permanent storage, backup, restore and audits can be used.
  • the central database MDB which is designed in the form of a tree structure.
  • the type neutrality the dynamic expandability of the central master database MDB and the use of an independent internal data model, the known disadvantages of the known solutions mentioned at the outset do not occur and the decoupling of functions of the central assembly ZBG and the managed objects of the decentralized becomes Assemblies BG1 ... 3 and a better decoupling of management protocol and application software (such as agent implementations achieved.
  • Another advantage is the use of a uniform interface - here the database synchronization - for the communication of central and decentralized software objects, such as for the communication between a central agent A and the decentralized ones implemented in the respective modules BG1 ... 3 agents.
  • the application scenario shown in this exemplary embodiment is not limited to the described communication of central (master) agents and decentralized (sub) agents, but can be expanded as desired and thus the otherwise common message handler subsystems of the application Replace software in whole or in part.
  • the use of the tree structure in the MDB master database generally reduces the effort required to maintain and further develop the application software, such as the maintenance of agents or subagents used in the network element. It is advantageous for communication between the master database MDB with the respective slave databases SDB1 ... 3 with each other and for communication with the respective software goods objects of the application software use the transport protocol IP (Internet Protocol) and / or UTP. This means that an “application system * can be implemented on a single personal computer or distributed over any number of personal computers.
  • IP Internet Protocol

Abstract

In einem Netzwerkelement (NE) sind zumindest eine die Ressourcen des Netzwerkelementes verwaltende zentrale Datenbasis (MDB) und zumindest eine jeweils eine Teilressource (ISDN, POTS, E1) verwaltende dezentrale Datenbasis (SDB1 3) vorgesehen. Die zentrale Datenbasis (MDB, SDB'1 3) ist logisch in Art und Weise in Form einer Baumstruktur ausgestaltet, dass die zumindest eine dezentrale Datenbasis (SDB1 3) gleichzeitig einen Bestandteil der Baumstruktur der übergeordneten zentralen Datenbasis bildet (MDB, SDB'1 3), wobei durch die Baumstruktur die Verteilung der Teilressourcen in dem Netzwerkelement wiedergegeben ist. Im Rahmen der Verwaltung der Ressourcen erfolgt der Zugriff auf die dezentrale Datenbasis (SDB1 3) der zumindest einen Teilressource über die Baumstruktur der zentralen Datenbasis (MDB, SDB'1 3). Vorteilhaft werden im Netzwerkelement Management-Kommandos an beispielsweise die Teilressourcen repräsentierende Subagenten weitergeleitet sowie Verwaltungsinformationen zentral in der zentralen Datenbasis abgespeichert.

Description

Beschreibung
Verfahren und Netzwerkelement zum Verwalten von Ressourcen eines Netzwerkelementes
In aktuellen Kommunikationsnetzen werden darin angeordnete Kommunikationsnetzeinrichtungen bzw. Netzwerkelemente bzw. durch diese bereitgestellte Übertragungsressourcen durch zentrale Ressourcen-Verwaltungssysteme bzw. Netzwerkmanage- mentsysteme (NMS) überwacht und gesteuert. In den Netzwerkelementen ist hierzu ein Management-Agent implementiert, der die Kommandos des zentralen Netzwerkmanagementsystems verarbeitet (z. B. Lesen und Setzen von Konfigurationsdaten bzw. Verwaltungsinformationen) und der selbständig den aktuellen Betriebszustand des jeweiligen Netzwerkelements überwacht und gegebenenfalls Meldungen über Zustandsänderungen - beispielsweise mittels Alarme - an das zentrale Netzwerkmanagementsystem übermittelt. Der üblicherweise als Software-Applikation ausgestaltete Agent in dem jeweiligen Netzwerkelement stellt dem zentralen Netzwerkmanagementsystem ein abstraktes Modell der physikalischen und logischen Ressourcen des Netzwerkelementes zur Verfügung - auch als MIB bzw. Management Information Base - bezeichnet. Auf die physikalischen und logischen Ressourcen des jeweiligen Netzwerkelementes bzw. auf die die- se Ressourcen repräsentierenden Verwaltungsinformationen - auch MO bzw. „Managed Objects* bezeichnet - kann das zentrale Netzwerkmanagementsystem über ein spezielles Managementprotokoll des Netzwerkelementes zugreifen. Die in aktuellen Kommunikationsnetzen angeordneten Netzwerkelemente stellen in der Regel verteilte Software-Systeme mit mehreren Baugruppen dar. Die Funktionen jeder Baugruppe werden durch einen separaten Prozessor überwacht und gesteuert. Die entsprechenden physikalischen und logischen Ressourcen (Managed Objects) des Netzwerkelementes sind auf die Baugruppen des Netzwerkele- mentes verteilt - auch als Teilressourcen bezeichnet. Um eine zentrale Verwaltung der durch die Netzwerkelemente bereitgestellten Ressourcen bzw. Teilressourcen zu ermöglichen, muss der Management-Agent des jeweiligen Netzwerkelementes zur Ausführung der vom zentralen Netzwerkmanagementsystem übermittelten Kommandos und zur Ausführung der manage- mentagent-spezifischen Überwachungsfunktionen auf die im System verteilten physikalischen und logischen Ressourcen bzw. Teilressourcen über Schnittstellensystem zugreifen können (Problem 1) .
Ein weiteres Problem bei der zentralen Verwaltung der durch die Netzwerkelemente bereitgestellten Ressourcen bzw. Teilressourcen stellen die bei der Ausführung von Konfigurationsbzw. Verwaltungshandlungen durch das zentrale Netzwerk anage- mentsystem entstehenden Verwaltungs-Informationen dar, welche die Konfiguration oder den Zustand der im jeweiligen Netzwerkelement verteilten Managed Objects bzw. physikalischen und logischen Ressourcen repräsentieren. Diese Verwaltungs- Informationen müssen an zentraler Stelle semi-permanent in dem jeweiligen Netzwerkelement gespeichert werden, damit das Netzwerkelement nach einem Neustart oder nach einem Baugruppenwechsel ohne externe Konfigurationsmaßnahmen seinen Funktionen wieder aufnehmen kann. Die Verwaltung und die semipermanente Speicherung der Konfigurationsdaten bzw. Verwal- tungs-Informationen erfolgt in der Regel auf einer zentralen Baugruppe des jeweiligen Netzwerkelementes (z.B. auf einer Überwachungsbaugruppe) , so dass die Verwaltungs-Informationen für weitere zentrale Systemfunktionen wie z. B. Backup, Restore und Audits zur Verfügung stehen (Problem 2) .
Bisher sind zwei Realisierungsvarianten bekannt, bei welchen eine zentrale Verwaltung von durch dezentrale Netzwerkelemente bereitgestellte Ressourcen bzw. Teilressourcen unter Berücksichtigung der beiden oben genannten Probleme ermöglicht wird. Zentrale Implementierung eines Management-Agenten in einem Netzwerkelement:
Bei dieser Ausgestaltungsvariante (zentrale Implementierung) wird der Management-Agent und eine entsprechend zugeordnete zentrale Datenbasis auf einer zentralen Baugruppe des Netzwerkelementes implementiert. Das oben genannte Problem 2 kann gelöst werden, da der Management-Agent und die zentrale Datenbasis einer Steuerungseinheit bzw. einem Prozessor zuge- ordnet und auf der selben zentralen Baugruppe implementiert sind. Das oben genannte Problem 1 wird durch Einführung von Systemschnittstellen gelöst, über die die Verbindung zwischen dem Management-Agent (oder anderen funktional ähnlichen, zentralen Software-Subsystemen) und den im Netzwerkelement verteilten Software-Subsystemen realisiert ist, wobei die
Subsysteme für die Steuerung oder Überwachung der physikalischen und logischen Ressourcen des Netzwerkelements zuständig sind (z. B. Device Driver) .
Die zentrale Implementierung des Management-Agenten hat den Nachteil der Abhängigkeit zwischen der zentralen Agenten- Implementierung (der Management-Agent repräsentiert die Managed Objects bzw. Teilressourcen bzw. Ressourcen des Netzwerkelementes) und Veränderungen der Teilressourcen durch bei- spielsweise Veränderung der Bestückung des Netzwerkelementes. Erweiterungen oder Veränderungen der Bestückung des Netzwerkelementes (z. B. durch Einfügen eines neuen Baugruppentyps) sind nur möglich, wenn der zentral implementierte Management- Agent, die zentrale Datenbasis und die jeweiligen System- schnittsteilen entsprechend angepasst werden. Somit ist nachteilig die Einführung einer neuen Baugruppe bzw. eines neuen Baugruppen-Typen in das Netzwerkelement in der Regel mit einer Aktualisierung bzw. einem Upgrade der in der zentralen Baugruppe implementierten Software verbunden, was einen erhöhten technischen uns somit auch wirtschaftlichen Aufwand für die Implementierung und für die Konfigurierung der Software zu Folge. Dezentrale Implementierung des Management-Agenten im Netzwerkelement:
Bei dieser Ausgestaltungsvariante wird der Management-Agent verteilt auf den Baugruppen des Netzwerkelementes implementiert. Die dazugehörige Datenbasis wird wie bei der zentralen Implementierung auf einer zentralen Baugruppe des Netzwerkelementes implementiert. Durch die dezentrale Agentenimplementierung werden die Sub-Agenten-Komponenten dort implemen- tiert, wo sich auch die zugehörigen Teilressourcen bzw. Managed Objects des Netzwerkelementes befinden. Dadurch können neue Teilressourcen in das Netzwerkelement aufgenommen werden, welche keine Auswirkungen auf die zentral implementierten Management-Agenten - auch als Master-Agent bezeichnet - zur Folge haben. Die Master-Agenten haben bei dieser Ausgestaltungsvariante nur noch das Weiterleiten der Management- Kommandos an die Sub-Agenten zu leisten, wodurch der oben genannte Nachteil der zentralen Implementierung, d.h. die nachteilige Abhängigkeit zwischen zentraler Agenten- Implementierung und Veränderungen der Teilressourcen bzw. Managed Objects vermieden wird. Die nunmehr erforderliche Wei- terleitungsfunktion des Master-Agenten (Problem 1) wird hierbei auf Basis von Identifizierern bzw. auf Basis von Identifizierungsinformationen in der Anwendungsebene (Application- Layer) des Management-Protokolls realisiert. Beispiele für Management-Protokolle sind „SISA-QD2* und „SNMP', wobei bei „SISA-QD2* die FG- und FE-Nummer und bei „SNMP' der jeweilige Object-Identifier als Identifizierungsinformation für den Ap- plication-Layer zur Verfügung gestellt werden. Mit Hilfe der Management-Protokolle und der jeweiligen Identifizierungsinformationen der Application-Layer ist die Weiterleitungsfunk- tion des Master-Agenten dynamisch erweiterbar.
Das oben genannte Problem 2 kann beispielsweise dadurch ge- löst werden, dass Sub-Agenten ihre semi-permanenten Konfigu- rations- bzw. Verwaltungs-Informationen als Datenfiles in einem Filesystem der zentralen Baugruppe ablegen. Die dezentrale Implementierung des Management-Agenten weist Nachteile auf:
Durch die dezentrale Agenten-Implementierung werden die Ap- plication-Layer-Protokolle bis zu dem dezentralen Subagenten transportiert und dort verarbeitet, woraus in der Regel eine enge Bindung an das Management-Protokoll entsteht. Der Wechsel des Management-Protokolls oder die Unterstützung zusätzlicher Management-Protokolle ist nur mit einem erhöhten Auf- wand zu realisieren.
Des weiteren kann eine aus einer Sammlung von subagenten- spezifischen Datenbasen (Files) bestehenden Datenbasis nur schwer zentrale Systemfunktionen wie beispielsweise Backup, Restore und Audis unterstützen.
Der Erfindung liegt somit die Aufgabe zugrunde, eine einfache, zentral gesteuerte Verwaltung von in Netzwerkelementen angeordneten Ressourcen bzw. Teilressourcen zu ermöglichen, wobei insbesondere die oben genannten Probleme vermieden werden sollen. Die Aufgabe wird ausgehend von einem Verfahren und einem Netzwerkelement gemäß den Merkmalen des Oberbegriffs der Patentansprüche 1 und 19 durch deren kennzeichnende Merkmale gelöst.
Beim erfindungsgemäßen Verfahren zum Verwalten von Ressourcen von zumindest einem in einem Kommunikationsnetz anordenbaren Netzwerkelement umfassen die Ressourcen zumindest eine in dem Netzwerkelement vorgesehene Teilressource. Der wesentliche Aspekt des erfindungsgemäßen Verfahrens besteht darin, dass in dem Netzwerkelement zumindest eine die Ressourcen des Netzwerkelementes verwaltende zentrale Datenbasis und zumindest eine jeweils die zumindest eine Teilressource verwaltende dezentrale Datenbasis vorgesehen ist. Erfindungsgemäß ist die zentrale Datenbasis logisch in der Art und Weise in Form einer Baumstruktur ausgestaltet, dass die zumindest eine dezentrale Datenbasis gleichzeitig einen Bestandteil der Baum- Struktur der übergeordneten zentralen Datenbasis bildet, wobei durch die Baumstruktur die Verteilung der Teilressourcen in dem Netzwerkelement wiedergegeben ist. Im Rahmen der Verwaltung der Ressourcen erfolgt der Zugriff auf die dezentrale Datenbasis der zumindest einen Teilressource über die Baumstruktur der übergeordneten zentralen Datenbasis.
Der wesentliche Vorteil des erfindungsgemäßen Verfahrens besteht darin, dass durch erfindungsgemäßen Einsatz der zentra- len Datenbasis zwei Funktionen realisiert sind. Erfindungsgemäß werden im Netzwerkelement Management-Kommandos an beispielsweise die Teilressourcen repräsentierende Subagenten weitergeleitet und zusätzlich Verwaltungsinformationen zentral in zentraler Datenbasis - auch als Master-Datenbasis be- zeichnet - abgespeichert. Die erfindungsgemäße zentrale Datenbasis ermöglicht auf vorteilhafte Weise die Verwendung einer einheitlichen Schnittstelle (Datenbasissynchronisation) für die Kommunikation von zentralen und dezentralen Verwaltungsagenten bzw. Software-Objekten. Die Verwaltung von Daten bzw. Informationen mittels Datenbasen, welche in Form einer
Baumstruktur ausgestaltet sind, stellt eine einfach zu lösende und durch Standardkomponenten unterstützte Programmieraufgabe dar, so dass das erfindungsgemäße Verfahren mit minimalen technischen und wirtschaftlichen Aufwand realisierbar ist. Somit reduziert sich weiterhin der Aufwand allgemein für die Pflege und Weiterentwicklung von auf die erfindungsgemäße zentrale Datenbasis abgestimmten Anwendungen, sowie der Aufwand bei der Einführung neuer Baugruppen, bzw. Baugruppentypen, beim Wechsel des Management-Protokolls oder bei der Imp- lementierung weiterer Management-Protokolle.
Gemäß einer vorteilhaften Weiterbildung des erfindungsgemäßen Verfahrens bildet die zumindest eine dezentrale Datenbasis gleichzeitig einen Bestandteil der Baumstruktur der überge- ordneten zentralen Datenbasis (MDB, SDBΛ1...3) in Form eines
Teilbaums der Baumstruktur - Anspruch 2. Durch diese vorteilhafte Weiterbildung wird eine besonders einfache Definition einer dezentralen Datenbasis als Untermenge der zentralen Datenbasis ermöglicht. Durch die Verwendung von Teilbäumen kann das erfindungsgemäße Verfahren, insbesondere die Synchronisierung von zentralen und dezentralen Datenbasen, besonders einfach und somit kostengünstig implementiert werden.
Weitere vorteilhafte Ausgestaltungen des erfindungsgemäßen Verfahrens sowie ein Netzwerkelement zur Durchführung des Verfahrens sind den weiteren Ansprüchen zu entnehmen.
Im folgenden wird das erfindungsgemäße Verfahren an Hand mehrerer Zeichnungen näher erläutert. Dabei zeigen
FIG 1 ein Anwendungs-Szenario des erfindungsgemäßen Verfah- rens
FIG 2 ein Management-Modell für die Verwaltung von V5.2-
Netzwerkelementen FIG 3 eine Abbildung der Datenstruktur (Baumstruktur) der zentral im Netzwerkelement angeordneten Datenbasis FIG 4 die Abbildung eines abstrakten Modells der durch das Netzwerkelement bereitgestellten physikalischen und logischen Ressourcen.
FIG 1 zeigt in einem Blockschaltbild ein das erfindungsgemäße Verfahren realisierendes Anwendungs-Szenario bestehend aus einem in einem Kommunikationsnetz KN - z.B. ein Teilnehmeranschlussnetzwerk bzw. „Access Network* - angeordneten Netzwerkelement NE, durch welches über das standardisierte Vermittlungs-Protokoll V5.2 Teilnehmeranschlüsse TA bzw. Teil- nehmer TLN an eine Vermittlungseinrichtung VE angebunden werden. In dem Netzwerkelement NE sind mehrere verschiedenartige Baugruppen BG1...3 angeordnet, wobei die erste Baugruppe BG1 zum Anschluss von analogen Teilnehmern - „Pots Line Card* - die zweite Baugruppe zum Anschluss von digitalen Teilnehmern - „ISDN Line Card* - und die dritte Baugruppe als LAN-
Anschluss - „ El Line Unit* - ausgestaltet ist. Jede der drei Baugruppen BG1...3 realisiert somit einen Teil der durch das Netzwerkelement NE insgesamt bereitgestellten Ressourcen POTS, ISDN, El, wobei für die Verwaltung der jeweiligen Teilressourcen POTS, ISDN, El jeder Baugruppe BG1...3 eine dezentrale Datenbasis SDB1...3 - auch als „Slave-Datenbasis* be- zeichnet- zugeordnet ist. In dem Netzwerkelement NE ist des weiteren eine zentrale Baugruppe ZBG angeordnet, welche eine zentrale, die gesamten Ressourcen des Netzwerkelementes NE verwaltende, in Form einer Baumstruktur ausgestaltete Datenbasis MDB zugeordnet ist. Der zentralen Datenbasis MDB - auch als „Master-Datenbasis* bezeichnet - ist ein die Verwaltung der Ressourcen des Netzwerkelementes NE steuernder zentraler Agent A zugeordnet. In diesem Ausführungsbeispiel sind die dezentralen Datenbasen SDB1...3 auf der jeweiligen Baugruppe BG1...3 gespeichert. Erfindungsgemäß sind die Slave-Datenbasen SDBl...3 bzw. die darin gespeicherten Informationen auch (z.B. als Kopie) in der zentralen Baugruppe ZBG gespeichert, wobei die Slave-Datenbasen bzw. die Kopien dieser Slave-Datenbasen - in FIG 1 als SDB,1...3 gekennzeichnet - einen Bestandteil der Baumstruktur der zentralen Master-Datenbasis MDB bilden, d.h. jeweils einen Teilbaum der Master-Datenbasis MDB bilden.
Das Management-Modell für die Verwaltung von V5.2 Netzwerkelementen NE ist in den ETSI-Standards ITS 300-377-1 und ITS 300-376-1 definiert, wobei eine Realisierungsvariante des Ma- nagement-Modells in Form eines Blockschaltbildes unter Anwendung der in den genannten Standards verwendeten Nomenklatur in FIG 2 dargestellt ist. Das in FIG 2 dargestellte Modell bildet mit kleinen Modifikationen die Basis für das interne Datenmodell des in FIG 1 dargestellten Anwendungs-Szenarios und bestimmt somit die Datenstruktur der im Netzwerkelement NE angeordneten, zentralen Master-Datenbasis MDB. Die Modifikationen ergeben, sich aus dem beschriebenen Aufbau des Netzwerkelementes - Equipment-Hierarchie -, welcher als Basisstruktur für das interne Datenmodell verwendet wird. Das mo- difizierte Datenmodell ist in FIG 3 dargestellt. Die zu verwaltenden Teilressourcen POTS, ISDN, El - auch als „Managed Objects* bezeichnet - des aus den oben genannten ETSI- Standards abgeleiteten Management-Modells wurden in das interne Datenmodell so eingefügt, dass eine Zuordnung der Managed Objects zu den physikalischen und logischen Ressourcen (POTS, ISDN, El), die sie repräsentieren, und den Baugruppen BG1...3, auf denen sie sich befinden, möglich ist. Für das Ausführungsbeispiel sei angenommen, dass die V5-Protokoll- Verarbeitung auf der zentralen Baugruppe ZBG realisiert ist, auf welcher auch die Master-Datenbasis MDB implementiert ist. In FIG 3 sind wiederum die drei im Netzwerkelement NE ange- ordneten Baugruppentypen - El Line Unit, Pots Line Card und ISDN Line Card - dargestellt, wobei die Baugruppen - in FIG 3 auch als PluglnUnit gekennzeichnet - in Steckvorrichtungen slotl...3 einer im Netzwerkelement NE vorgesehenen Baugruppen- halterung SHELF angeordnet sind.
Der in der zentralen Baugruppe ZBG des Netzwerkelementes NE angeordnete Agent A stellt der zentralen Verwaltungseinrichtung NMS das in FIG 3 dargestellte abstraktes Modell der physikalischen und logischen Ressourcen des Netzwerkelementes NE bereit. Dieses abstrakte Modell wird auch als MIB bzw. Management Information Base bezeichnet. Mit Hilfe des zentralen Agenten A kann die zentrale Verwaltungseinrichtung NMS mittels eines Management-Protokolls auf die physikalischen und logischen Ressourcen bzw. Managed Objects des Netzwerkelemen- tes zugreifen. Als externes Management-Protokoll sei in diesem Ausführungsbeispiel das Protokoll „SNMP* - Simple Network Management Protocol - angenommen - durch einen strichlierten Doppelpfeil verdeutlicht -, es können jedoch auch andere Management-Protokolle verwendet werden.
FIG 4 zeigt in einem Blockschaltbild den prinzipiellen Aufbau eines V5-MIB-Moduls. Die Managed Objects des Management- Modells der oben genannten ETSI-Standards sind auch in diesem Blockschaltbild wiederzufinden. Ihre Anordnung entspricht je- doch der Registrierungs-Hierarchie für SNMP. Für Managed Objects des Typs „ElPhysPathTP* findet sich im V5-MIB-Modul kein zugehöriges SNMP-Objekt. Dafür wird das SNMP-Objekt - „dsxlConfigTable* der DS1-MIB (RFC1406) verwendet. Die Managed Objects für die Gerätebestückung werden ebenfalls durch ein Standard-MIB-Modul (auch als Entity-MIB bezeichnet) verwaltet.
Basiskomponente des erfindungsgemäßen Verfahrens stellt die in der zentralen Baugruppe ZBG angeordnete, in Form einer Baumstruktur ausgestaltete, zentrale Datenbasis MDB dar, welche folgende Eigenschaften aufweist:
10
- Die in der zentralen Datenbasis MDB gespeicherten Datensätze bzw. Verwaltungsinformationen (Managed Objects) werden in einer oder mehreren Baumstrukturen verwaltet. Jeder Datensatz wird eindeutig durch einen Schlüssel identifi-
15 ziert, der sich durch die Aneinanderreihung der relativen Identifizierungsinformationen - auch als Identifier bezeichnet - der Datensätze des Pfades, beginnend mit dem o- bersten Datensatz - auch als Top-Datensatz bezeichnet - der Baumstruktur ergibt. Durch diese erfindungsgemäße An-
20 Ordnung der Datensätze (als Teilbaum) in der Baumstruktur der zentralen Datenbasis MDB sollen die physikalischen o- der logischen Beziehungen - auch als Containment-Beziehung bezeichnet - der verwalteten Systemressourcen POTS, ISDN, El verdeutlicht bzw. nachgebildet werden. Jeder Datensatz
25 repräsentiert eine verwaltete physikalische oder logische Ressource (Managed Objects) oder die Zusammenfassung gleichartiger Ressourcen.
- Vorteilhaft ist die zentrale Datenbasis MDB als typneutra- 30 le Datenbasis ausgestaltet. Die Typneutralität wird dadurch erreicht, dass innerhalb der zentralen Datenbasis MDB nur Referenzen auf die jeweiligen Datensätze bzw. Verwaltungsinformationen, die in externen Speicherblöcken nur abgelegt sind, verwaltet werden. Nur die nutzenden Soft-
3.5 ware-Objekte wie z.B. die Agenten kennen die Struktur der Datensätze; gegebenenfalls kann mittels einer einfachen formalen Beschreibungsnotation für Datensätze auch der Zugriff auf einzelne Elemente eines Datensatzes durch Datenbasisfunktionen unterstützt werden.
- Der zentralen Datenbasis bzw. Master-Datenbasis MDB ist zumindest eine Aktualisierungsfunktion zugeordnet, welche in der Art und Weise ausgestaltet ist, dass bei einer Änderung von einen der in der zentralen Baumstruktur angeordneten Managed Objects POTS, ISDN, El bzw. bei einer Änderung der die Managed Object repräsentierenden Verwal- tungsinformationen MO die jeweils entsprechende Slave- Datenbasis SDB1...3 bzw. die entsprechenden in der Slave- Datenbasis SDBl...3 gespeicherten Verwaltungsinformationen MO hinsichtlich der Änderungen aktualisiert werden. Ebenso können den Slave-Datenbasen SDBl...3 jeweils zumindest eine Aktualisierungsfunktion zugeordnet sein, welche in der Art und Weise ausgestaltet ist, dass bei einer Änderung von einen der in den Slave-Datenbasen SDB1...3 gespeicherten Managed Objects POTS, ISDN, El bzw. bei einer Änderung der die Managed Object repräsentierenden Verwaltungsinformati- onen die Master-Datenbasis MDB bzw. die entsprechenden, in der Master-Datenbasis MDB gespeicherten Verwaltungsinformationen hinsichtlich der Änderungen aktualisiert werden.
- Durch die der Master-Datenbasis MDB und/oder den Slave- Datenbasen SDBl...3 zugeordneten Aktualisierungsfunktionen werden beispielsweise Funktionen zur Registrierung und zur Change-Notifikation bereitgestellt, das heißt lokale Software-Objekte, d.h. lokal auf der jeweiligen Baugruppe ZBG, BG1...3 angeordnete Funktionen und/oder Prozesse wie bei- spielsweise Sub-Agenten können sich für bestimmte Datensätze bzw. Verwaltungsinformationen der jeweiligen Datenbasis MDB, SDBl...3 registrieren und erhalten bei jeder Änderung der registrierten Datensätze eine die Änderung anzeigende Meldung von der zentralen Datenbasis MDB oder von der jeweiligen Slave-Datenbasis SDB1...3. In Abhängigkeit von der übermittelten Meldung werden weitere Funktionen durch die jeweiligen Software-Objekte durchgeführt. - Die zentrale Datenbasis MDB stellt weiterhin Funktionen zur Synchronisation von Slave-Datenbasen SDB1...3 bzw. einer Master-Datenbasis MDB bereit, das heißt die Synchronisati- onsfunktionen erlauben es, die Slave-Datenbasen SDB1...3 selbst wieder in Form einer Baumstruktur auszugestalten, wobei die Master-Datenbasis MDB jeweils an der Spitze der jeweiligen Slave-Datenbasen SDB1...3 angeordnet ist. Eine Slave-Datenbasis SDB1...3 kann sich für einen bestimmten Teilbaum der Master-Datenbasis MDB registrieren lassen. Bei Änderungen innerhalb des Teilbaumes der Master- Datenbasis MDB wird die jeweilige Slave-Datenbasis SDB1...3 über die Synchronisationsfunktion aktualisiert - auch als „Slave-Synchronisation* bezeichnet. Umgekehrt führt eine Änderung in der Slave-Datenbasis SDB1...3 innerhalb des registrierten Teilbaums zur Aktualisierung des Datensatzes in der Master-Datenbasis MDB - auch Master-Synchronisation bezeichnet. Es sei angemerkt, dass bei der Registrierung einer Slave-Datenbasis für einen Teilbaum der Master- Datenbasis die Datensätze des Teilbaums auf die Slave- Datenbasis übertragen werden. Die jeweiligen Software- Objekte (Master-, Sub-Agent) arbeiten daher immer mit lokal in der jeweiligen Baugruppe BG1...3 gespeicherten Daten bzw. Verwaltungsinformationen. Die Konsistenz der Daten bzw. Verwaltungsinformationen von Slave- und Master- Datenbasis MDB, SDBl...3 wird durch die Synchronisations- Funktion erreicht.
- Die Slave-Datenbasen SDB1...3 können ebenfalls hierarchisch in mehreren Ebenen angeordnet werden, das heißt für einen
Teilbaum einer Slave-Datenbasis kann sich eine weitere Slave-Datenbasis registrieren lassen. Zwischen diesen beiden Datenbasen entsteht wieder eine Master-Slave- Beziehung.
Der zentralen Datenbasis MDB können weitere Funktionen zugeordnet werden, wie beispielsweise die Erzeugung neuer Datensätze, das Löschen von Datensätzen und die Registrierung und Deregistrierung für die Change-Notifikation- und die Synchronisations-Funktion zur Laufzeit.
- Für bestimmte Szenarien unterstützt die zentrale Datenbasis MDB zwei Datensatz-Referenzen per Datensatz-Schlüssel: eine „temporary* und eine „commited* Referenz zur Unterstützung von Typ „TRY*- und „Rollback* -Funktionen.
- Zur Unterstützung von einzelnen Kommunikationsbeziehungen, die nicht der Baumstruktur der Master-Datenbasis MDB folgen, stellt die Datenbasis spezielle „Remote Access*- Funktionen zur Verfügung.
Mit einer gemäß den obigen Ausführungen ausgestalteten Datenbasis MDB als Basiskomponente wird das folgende Verfahren für die dezentrale Agentenimplementierung im Netzwerkelement NE definiert:
Die physikalischen und logischen Ressourcen des Netzwerkelementes NE werden als Managed Objects entsprechenden ihrer Containent-Beziehungen in der Baumstruktur der Master- Datenbasis MDB auf der zentralen Baugruppe ZBG des Netzwerkelementes verwaltet. Beispielhaft sei zur Verdeutlichung der Containment-Beziehung folgende Angliederung von Managed Objects dargestellt, wobei die Nomenklatur der genannten ETSI- Standards verwendet wird:
Networkelement (NE) => Equipment => EquipmentHolder (SHELF) => EquipmentHolder (Slot) => PluglnUnit
Die Slave-Datenbasen SDB1...3 der jeweiligen Baugruppen BG1...3 registrieren sich für einen Teilbaum der Master-Datenbasis MDB mit dem zugehörigen „PluginUnit* -Datensatz als Top- Element. Die Slave-Datenbasen von externem Equipment registrieren für sich einen Teilbaum mit dem zugehörigen „Equip- ment*-Datensatz als Top-Element. Bei der Registrierung der Slave-Datenbasen SDB1...3 werden diese mit den aktuellen Datensätzen bzw. Verwaltungsinformationen der Master-Datenbasis MDB geladen. Sollte in der Master-Datenbasis MDB der Teilbaum noch nicht existieren, das heißt die Baugruppe ist noch nicht konfiguriert, so erzeugt die Baugruppe (bzw. das externe E- quipment) die erforderlichen Datensätze mit voreingestellten Werten bzw. Default-Daten (auch als Auto-Provisioning bezeichnet) . Da die Master-Datenbasis MDB typneutral ist, können dabei auch neue Datensatz-Typen und neue Teilbaumstruktu- ren erzeugt werden, wobei die Erweiterung zur Laufzeit möglich ist.
Die lokal in den Baugruppen BG1...3 angeordneten Subagenten registrieren sich als lokale Software-Objekte für die Change- Notifikation-Funktion und konfigurieren die lokalen Ressourcen entsprechend den Daten der Datenbasis MDB.
Über SNMP-Protokoll von der zentralen Verwaltungseinrichtung NMS an das Netzwerkelement NE übermittelte Kommandos werden mittels einer „Key-Translation-Funktion* auf Basis der Ob- ject-Identifier-Werte des Kommando-Telegramms zum dazugehörigen Datensatz der Master-Datenbasis MDB geleitet (Lesen oder Schreiben von Datensätzen) . Bei einem Schreib- bzw. Set- Kommando wird der entsprechende Datensatz in der Master- Datenbasis MDB geändert. Über die Synchronisations- und Chan- ge-Notifikation-Funktion gelangt diese Änderung zum zuständigen Subagenten. Meldungen von Zustandsänderungen der Subagenten gelangen auf dem umgekehrten Weg zur Master-Datenbasis MDB und werden mittels einer „inversen Key-Translation- Funktion* zu entsprechenden Mitteilungen bzw. Telegrammen - auch als Trap- bzw. Notifikations-Telegramme bezeichnet - umgewandelt und an die zentrale Verwaltungseinrichtung NMS gesendet.
Die Daten bzw. Datensätze des Netzwerkelementes NE liegen in der Master-Datenbasis MDB strukturiert vor und können von zentralen Systemfunktionen wie z. B. semi-permanente Speicherung, Backup, Restore und Audits genutzt werden.
Wie bereits erläutert wird durch die in Form einer Baumstruk- tur ausgestaltete zentrale Datenbasis MDB zwei Funktionen realisiert. Zum einen die Weiterleitung von Management- Kommandos und zum anderen die zentrale Ablage von Daten bzw. Verwaltungsinformationen in der Master-Datenbasis MDB. Wegen der Typneutralität, der dynamischen Erweiterbarkeit der zent- ralen Master-Datenbasis MDB und der Verwendung eines unabhängigen internen Datenmodells treten die bekannten Nachteile der eingangs genannten bekannten Lösungen nicht auf und es wird die Entkopplung von Funktionen der zentralen Baugruppe ZBG und den Managed Objects der dezentralen Baugruppen BG1...3 sowie eine bessere Entkopplung von Management-Protokoll und Applikations-Software (wie z.B. Agenten-Implementierungen erreicht.
Ein weiterer Vorteil ist die Verwendung einer einheitlichen Schnittstelle - hier die Datenbasis-Synchronisation - für die Kommunikation von zentralen und dezentralen Software- Objekten, wie z.B. für die Kommunikation zwischen einem zentralen Agenten A und den in den jeweiligen Baugruppen BG1...3 realisierten dezentralen Agenten. Die in diesem Ausführungs- beispiel gezeigte Anwendungs-Szenario ist nicht auf die geschilderte Kommunikation von zentralen (Master-) Agenten und dezentralen (Sub-) Agenten beschränkt, sondern kann beliebig erweitert werden und somit die sonst üblichen Message- Handler-Subsysteme der Applikations-Software ganz oder teil- weise ersetzen. Durch die Verwendung der Baumstruktur in der Master-Datenbasis MDB reduziert sich der Aufwand allgemein für die Pflege und Weiterentwicklung der Applikations- Software, wie beispielsweise die Pflege von in den Netzwerkelement eingesetzten Agenten bzw. Subagenten. Vorteilhaft wird zur Kommunikation zwischen der Master- Datenbasis MDB mit den jeweiligen Slave-Datenbasen SDB1...3 untereinander sowie zur Kommunikation mit dem jeweiligen Soft- ware-Objekten der Applikations-Software das Transportprotokoll IP (Internet Protokoll) und/oder UTP genutzt. Damit kann ein „Applikations-System* auf einem einzigen Personalcomputer oder verteilt auf beliebig vielen Personalcomputern realisiert werden.

Claims

Patentansprüche
1. Verfahren zum Verwalten von Ressourcen von zumindest einem in einem Kommunikationsnetz (KN) anordenbaren Netzwerkelement (NE) , wobei die Ressourcen (POTS, ISDN, El) zumindest eine in dem Netzwerkelement (NE) vorgesehene Teilressource (POTS, ISDN, El) umfassen, d a d u r c h g e k e n n z e i c h n e t , dass in dem Netzwerkelement (NE) — zumindest eine die Ressourcen des Netzwerkelementes (NE) verwaltende zentrale Datenbasis (MDB) , und
- zumindest eine jeweils die zumindest eine Teilressource (POTS, ISDN, El) verwaltende dezentrale Datenbasis (SDB1...3) vorgesehen ist,
- dass die zentrale Datenbasis (MDB) logisch in der Art und Weise in Form einer Baumstruktur ausgestaltet ist, dass die zumindest eine dezentrale Datenbasis (SDBl...3) gleichzeitig einen Bestandteil der Baumstruktur der übergeordneten zent- ralen Datenbasis (MDB, SDBλ1...3) bildet, wobei durch die
Baumstruktur die Verteilung der Teilressourcen (POTS, ISDN, El) in dem Netzwerkelement (NE) wiedergegeben ist, und
- dass im Rahmen der Verwaltung der Ressourcen der Zugriff auf die dezentrale Datenbasis (SDB1...3) der zumindest einen Teilressource (POTS, ISDN, El) über die Baumstruktur der ü- bergeordneten zentralen Datenbasis (MDB, SDB 1...3) erfolgt.
2. Verfahren nach Anspruch 1, d a d u r c h g e k e n n z e i c h n e t , dass die zumindest eine dezentrale Datenbasis (SDB1...3) gleichzeitig einen Bestandteil der Baumstruktur der übergeordneten zentralen Datenbasis (MDB, SDBλ1...3) in Form eines Teilbaums der Baumstruktur bildet.
3. Verfahren nach Anspruch 1 oder 2, d a d u r c h g e k e n n z e i c h n e t , dass die Datenbasen (MDB, SDB1...3) jeweils individuell konfigurierbare Verwaltungsinformationen (MO) der jeweils zu ver- waltenden Teilressource (POTS, ISDN, El) umfassen.
4. Verfahren nach Anspruch 3, d a d u r c h g e k e n n z e i c h n e t , dass die jeweiligen Verwaltungsinformationen (MO) sowohl in der zentralen Datenbasis (MDB, SDBΛ1...3) als auch in der entsprechenden dezentralen Datenbasis (SDB1...3) gespeichert sind.
5. Verfahren nach Anspruch 3 oder 4, d a d u r c h g e k e n n z e i c h n e t , - dass die zumindest eine dezentrale Datenbasis (SDBΛ1...3) und/oder die entsprechenden Verwaltungsinformationen (MO) mittels einer innerhalb der Baumstruktur eindeutigen Identifizierungsinformation in der zentralen Datenbasis (MDB) identifizierbar sind, - dass beim Verwalten der zumindest einen Teilressource
(POTS, ISDN, El) die entsprechende dezentrale Datenbasis (SDBX1...3) und/oder die entsprechenden Verwaltungsinformationen (MO) mittels der Identifizierungsinformation in der Baumstruktur der zentralen Datenbasis (MDB) ermittelt wer- den, wobei der Verwaltungszugriff auf die ermittelte dezentrale Datenbasis (SDB1...3) und/oder auf die ermittelten Verwaltungsinformationen (MO) erfolgt.
6. Verfahren nach einem der Ansprüche 5, d a d u r c h g e k e n n z e i c h n e t , dass bei einer zentral gesteuerten Verwaltung der Ressourcen von einer zentralen Verwaltungseinheit (NMS) eine die jeweils zu verwaltende Teilressource (POTS, ISDN, El) des Netzwerkelementes (NE) repräsentierende Ressourcen-Information an das jeweilige Netzwerkelement (NE) übermittelt und aus der übermittelten Ressourceninformation die entsprechende Identifizierungsinformation abgeleitet wird.
7. Verfahren nach einem der vorherigen Ansprüche, d a d u r c h g e k e n n z e i c h n e t ,
- dass der zumindest einen Teilressource (POTS, ISDN, El) zumindest eine weitere Teilressource zugeordnet ist, für wel- ehe zumindest eine jeweils die zumindest eine weitere Teilressource repräsentierende weitere dezentrale Datenbasis vorgesehen ist,
- dass die zumindest eine dezentrale Datenbasis (SDB 1...3, SDB1...3) logisch in der Art und Weise in Form einer Baum- Struktur ausgestaltet ist, dass die zumindest eine weitere dezentrale Datenbasis gleichzeitig einen Bestandteil der Baumstruktur der übergeordneten dezentralen Datenbasis (SDB 1...3, SDB1...3) bildet.
8. Verfahren nach einem der vorherigen Ansprüche, d a d u r c h g e k e n n z e i c h n e t , dass die Teilressourcen (POTS, ISDN, El) jeweils zu verwaltende logische und/oder physikalische Ressourcen repräsentieren.
9. Verfahren nach Anspruch 8, d a d u r c h g e k e n n z e i c h n e t , dass die logischen und/oder physikalischen Ressourcen auf in dem Netzwerkelement (NE) angeordnete Baugruppen (BG1...3) ver- teilt sind.
10. Verfahren nach Anspruch 9, d a d u r c h g e k e n n z e i c h n e t , dass die zumindest eine dezentrale Datenbasis (SDB1...3) auf der entsprechenden Baugruppe (BG1...3) angeordnet ist.
11. Verfahren nach einem der vorherigen Ansprüche, d a d u r c h g e k e n n z e i c h n e t , dass die zumindest eine zentrale Datenbasis (MDB) auf zumin- dest einer in dem Netzwerkelement (NE) angeordneten zentralen Baugruppe (ZBG) angeordnet ist.
12. Verfahren nach einem der vorherigen Ansprüche, d a d u r c h g e k e n n z e i c h n e t , dass anstelle der zumindest einen dezentralen Datenbasis (3DBλ1...3) - jeweils eine typneutrale Referenz auf diese dezentrale Datenbasis (SDB1...3), oder - jeweils eine typneutrale Referenz auf eine Kopie dieser dezentralen Datenbasis (SDBΛ1...3) den Bestandteil der Baumstruktur der übergeordneten, zentra- len Datenbasis (MDB) bildet.
13. Verfahren nach einem der Ansprüche 3 bis 12, d a d u r c h g e k e n n z e i c h n e t , dass der zentralen Datenbasis (MDB) eine Aktualisierungsfunk- tion zugeordnet ist, durch welche bei einer Änderung der in einer der in der Baumstruktur angeordneten dezentralen Datenbasen (SDBX1...3) gespeicherten Verwaltungsinformationen (MO) die jeweiligen in der entsprechenden dezentralen Datenbasis (SDBl...3) gespeicherten Verwaltungsinformationen (MO) hin- sichtlich der Änderungen aktualisiert werden.
14. Verfahren nach einem der Ansprüche 3 bis 13, d a d u r c h g e k e n n z e i c h n e t , dass der zumindest einen dezentralen Datenbasis (SDB1...3) eine Aktualisierungsfunktion zugeordnet ist, durch welche bei einer Änderung der in der zumindest einen dezentralen Datenbasis (SDBl...3) gespeicherten Verwaltungsinformationen (MO) die entsprechenden in der den Bestandteil der Baumstruktur der zentralen Datenbasis (MDB) bildenden dezentralen Datenbasis (SDB,1...3) gespeicherten Verwaltungsinformationen (MO) aktualisiert werden
15. Verfahren nach Anspruch 13 oder 14, d a d u r c h g e k e n n z e i c h n e t , - dass zu zumindest einem Teil der in der zumindest einen dezentralen Datenbasis (SDB1...3) gespeicherten Verwaltungsin- formationen (MO) zumindest eine dezentrale Funktion und/oder zumindest ein dezentraler Prozess zuordenbar ist,
- dass die der zentralen Datenbasis (MDB) und/oder die der zumindest einen dezentralen Datenbasis (SDB1...3) zugeordnete Aktualisierungsfunktion derart ausgestaltet ist, dass bei einer Änderung zumindest eines Teils der in der zumindest einen dezentralen Datenbasis (SDB1...3) und/oder in der zentralen Datenbasis (MDB) gespeicherten Verwaltungsinformationen (MO) die entsprechende zumindest eine zugeordnete de- zentrale Funktion und/oder der entsprechende zumindest eine zugeordnete dezentrale Prozess über die Änderung jeweils informiert wird.
16. Verfahren nach einem der Ansprüche 13 bis 15, d a d u r c h g e k e n n z e i c h n e t ,
- dass zu zumindest einem Teil der in der zentralen Datenbasis (MDB) gespeicherten Verwaltungsinformationen (MO) zumindest eine zentrale Funktion und/oder zumindest ein zentraler Prozess zuordenbar ist - dass die der zentralen Datenbasis (MDB) und/oder die der zumindest einen dezentralen Datenbasis (SDB1...3) zugeordnete Aktualisierungsfunktion derart ausgestaltet ist, dass bei einer Änderung zumindest eines Teils der in der zentralen Datenbasis (MDB) und/oder in der zumindest einen dezentra- len Datenbasis (SDB1...3) gespeicherten Verwaltungsinformationen (MO) die entsprechende zumindest eine zugeordnete zentrale Funktion und/oder der entsprechende zumindest eine zugeordnete zentrale Prozess über die Änderung jeweils informiert wird.
17. Verfahren nach einem der Ansprüche 10 bis 16, d a d u r c h g e k e n n z e i c h n e t , dass die zu dem zumindest einem Teil der in der zumindest einen dezentralen Datenbasis (SDB1...3) gespeicherten Verwal- tungsinformationen (MO) zugeordnete zumindest eine dezentrale Funktion und/oder der zumindest eine zugeordnete dezentrale Prozess auf der jeweiligen Baugruppe (BG1...3) angeordnet ist.
18. Verfahren nach einem der Ansprüche 11 bis 17, d a d u r c h g e k e n n z e i c h n e t , dass die zu dem zumindest einem Teil der in der zentralen Datenbasis (MDB) gespeicherten Verwaltungsinformationen (MO) zugeordnete zumindest eine zentrale Funktion und/oder der zumindest eine zugeordnete zentrale Prozess auf einer zentralen Baugruppe (ZBG) angeordnet ist.
19. In einem Kommunikationsnetz (KN) anordenbares Netzwerk- element (NE) mit durch das Netzwerkelement (NE) bereitgestellte Ressourcen (POTS, ISDN, El), welche zumindest eine in dem Netzwerkelement (NE) vorgesehene Teilressource (POTS, ISDN, El) umfassen d a d u r c h g e k e n n z e i c h n e t , - dass in dem Netzwerkelement (NE)
— zumindest eine die Ressourcen des Netzwerkelementes (NE) verwaltende zentrale Datenbasis (MDB) , und
— zumindest eine jeweils die zumindest eine Teilressource (POTS, ISDN, El) verwaltende dezentrale Datenbasis (SDB1...3) vorgesehen ist,
- dass die zentrale Datenbasis (MDB) logisch in der Art und Weise in Form einer Baumstruktur ausgestaltet ist, dass die zumindest eine dezentrale Datenbasis (SDB1...3) gleichzeitig einen Bestandteil der Baumstruktur der übergeordneten zentralen Datenbasis (MDB, SDBλ1...3) bildet, wobei durch die Baumstruktur die Verteilung der Teilressourcen (POTS, ISDN, El) in dem Netzwerkelement (NE) wiedergegeben ist, und
- dass Zugriffsmittel zum Zugriff auf die zentrale Datenbasis (MDB) im Rahmen der Verwaltung der Ressourcen vorgesehen sind , wobei die Zugriffsmittel derart ausgestaltet sind, dass der Zugriff auf die dezentrale Datenbasis (SDB1...3) der zumindest einen Teilressource (POTS, ISDN, El) über die Baumstruktur der übergeordneten zentralen Datenbasis (MDB, SDBΛ1...3) erfolgt.
20. Netzwerkelement nach Anspruch 19, d a d u r c h g e k e n n z e i c h n e t , dass die zentrale Datenbasis (MDB) derart ausgestaltet ist, dass die zumindest eine dezentrale Datenbasis (SDB1...3) gleichzeitig einen Bestandteil der Baumstruktur der übergeordneten zentralen Datenbasis (MDB, SDBΛ1...3) in Form eines Teilbaums der Baumstruktur bildet.
21. Netzwerkelement nach Anspruch 19 oder 20, d a d u r c h g e k e n n z e i c h n e t , dass die Datenbasen (MDB, SDB1...3) derart ausgestaltet sind, dass diese jeweils individuell konfigurierbare Verwaltungsinformationen (MO) der jeweils zu verwaltenden Teilressourcen (POTS, ISDN, El) umfassen.
22. Netzwerkelement nach einem der Ansprüche 19 bis 21, d a d u r c h g e k e n n z e i c h n e t , dass die Teilressourcen (POTS, ISDN, El) jeweils zu verwal- tende logische und/oder physikalische Ressourcen des Netzwerkelementes (NE) repräsentieren.
23. Netzwerkelement nach Anspruch 22, d a d u r c h g e k e n n z e i c h n e t , dass die logischen und/oder physikalischen Ressourcen auf in dem Netzwerkelement (NE) angeordnete Baugruppen (BG1...3) verteilt sind.
24. Netzwerkelement nach Anspruch 23, d a d u r c h g e k e n n z e i c h n e t , dass die zumindest eine dezentrale Datenbasis (SDBl...3) auf der entsprechenden Baugruppe (BG1...3) angeordnet ist.
25. Netzwerkelement nach einen der Ansprüche 19 bis 24, d a d u r.c h g e k e n n z e i c h n e t , dass die zumindest eine zentrale Datenbasis (MDB) auf zumindest einer in dem Netzwerkelement (NE) angeordneten zentralen Baugruppe (ZBG) angeordnet ist.
26. Netzwerkelement nach Anspruch 25, d a d u r c h g e k e n n z e i c h n e t , dass auf der zumindest eine zentralen Baugruppe (ZBG) Aktua- lisierungsmittel vorgesehen sind, durch welche bei einer Änderung der in der den Bestandteil der Baumstruktur der zent- ralen Datenbasis (MDB) bildenden dezentralen Datenbasis
(SDBX1...3) gespeicherten Verwaltungsinformationen (MO) die jeweiligen in der entsprechenden dezentralen Datenbasis (SDBl...3) gespeicherten Verwaltungsinformationen (MO) hinsichtlich der Änderungen aktualisiert werden.
27. Netzwerkelement nach einem der Ansprüche 23 bis 26, d a d u r c h g e k e n n z e i c h n e t , dass auf der zumindest einen Baugruppe (BG1...3) Aktualisierungsmittel vorgesehen sind, durch welche bei einer Änderung der in der zumindest einen dezentralen Datenbasis (SDB1...3) gespeicherten Verwaltungsinformationen (MO) die entsprechenden in der den Bestandteil der Baumstruktur der zentralen Datenbasis (MDB) bildenden dezentralen Datenbasis (SDB 1...3) gespeicherten Verwaltungsinformationen (MO) aktualisiert werden
28. Netzwerkelement nach Anspruch 27, d a d u r c h g e k e n n z e i c h n e t ,
- dass auf der zumindest einen Baugruppe (BG1...3) zumindest eine baugruppenindividuelle Funktion und/oder zumindest ein baugruppenindividueller Prozess realisiert ist,
- dass die auf der zumindest einen Baugruppe (BG1...3) vorgesehenen Aktualisierungsmittel derart ausgestaltet sind,
- dass zumindest ein Teil der baugruppenindividuellen Funktionen und/oder der zumindest eine baugruppenindividuelle Prozess zu zumindest einen Teil der auf der jeweiligen
Baugruppe (BG1...3) gespeicherten Verwaltungsinformationen (MO) zuordenbar ist, — dass bei einer Änderung zumindest eines Teils der auf der zumindest einen Baugruppe (BG1...3) gespeicherten Verwaltungsinformationen (MO) eine die Änderung anzeigende Information der zumindest einen jeweils zugeordneten bau- gruppenindividuellen Funktion und/oder dem zumindest einen zugeordneten baugruppenindividuellen Prozess übermittelt wird.
29 . Netzwerkelement nach einem der Ansprüche 25 bis 28 , d a d u r c h g e k e n n z e i c h n e t ,
— dass auf der zumindest einen zentralen Baugruppe (ZBG) zumindest eine baugruppenindividuelle Funktion und/oder zumindest ein baugruppenindividueller Prozess realisiert ist,
— dass die auf der zumindest einen zentralen Baugruppe (ZBG) vorgesehenen Aktualisierungsmittel derart ausgestaltet sind,
— dass zumindest ein Teil der baugruppenindividuellen Funktionen und/oder der zumindest eine baugruppenindividuelle Prozess zu zumindest einen Teil der auf der zentralen Bau- gruppe (ZBG) gespeicherten Verwaltungsinformationen (MO) zuordenbar ist,
— dass bei einer Änderung zumindest eines Teils der auf der zumindest einen zentralen Baugruppe (ZBG) gespeicherten Verwaltungsinformationen (MO) eine die Änderung anzeigende Information der zumindest einen jeweils zugeordneten baugruppenindividuellen Funktion und/oder dem zumindest einen zugeordneten baugruppenindividuellen Prozess übermittelt wird.
PCT/DE2003/001819 2002-06-20 2003-06-02 Verfahren und netzwerkelement zum verwalten von ressourcen eines netzwerkelementes WO2004002172A1 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP03760550A EP1514434A1 (de) 2002-06-20 2003-06-02 Verfahren und netzwerkelement zum verwalten von ressourcen eines netzwerkelementes

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE10227556.4 2002-06-20
DE10227556 2002-06-20

Publications (1)

Publication Number Publication Date
WO2004002172A1 true WO2004002172A1 (de) 2003-12-31

Family

ID=29795834

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/DE2003/001819 WO2004002172A1 (de) 2002-06-20 2003-06-02 Verfahren und netzwerkelement zum verwalten von ressourcen eines netzwerkelementes

Country Status (2)

Country Link
EP (1) EP1514434A1 (de)
WO (1) WO2004002172A1 (de)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7729286B2 (en) 2005-10-07 2010-06-01 Amdocs Systems Limited Method, system and apparatus for telecommunications service management
US7797425B2 (en) 2005-12-22 2010-09-14 Amdocs Systems Limited Method, system and apparatus for communications circuit design
US8082335B2 (en) 2005-11-18 2011-12-20 Amdocs Systems Limited Method and system for telecommunications network planning and management
US8380833B2 (en) 2006-02-20 2013-02-19 Amdocs Systems Limited Method of configuring devices in a telecommunications network

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1158720A2 (de) * 2000-05-25 2001-11-28 Alcatel USA Sourcing, L.P. System und Verfahren zur Verwaltung von Netzwerkknoten unter Verwendung von Proxies über erweiterbare agents

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1158720A2 (de) * 2000-05-25 2001-11-28 Alcatel USA Sourcing, L.P. System und Verfahren zur Verwaltung von Netzwerkknoten unter Verwendung von Proxies über erweiterbare agents

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
DANIELE M ET AL: "Agent Extensibility (AgentX) Protocol Version 1", IETF RFC 2741, January 2000 (2000-01-01), pages 1 - 91, XP002247971 *

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7729286B2 (en) 2005-10-07 2010-06-01 Amdocs Systems Limited Method, system and apparatus for telecommunications service management
US8082335B2 (en) 2005-11-18 2011-12-20 Amdocs Systems Limited Method and system for telecommunications network planning and management
US7797425B2 (en) 2005-12-22 2010-09-14 Amdocs Systems Limited Method, system and apparatus for communications circuit design
US8380833B2 (en) 2006-02-20 2013-02-19 Amdocs Systems Limited Method of configuring devices in a telecommunications network

Also Published As

Publication number Publication date
EP1514434A1 (de) 2005-03-16

Similar Documents

Publication Publication Date Title
EP0525432B1 (de) Verfahren zur Änderung von Systemkonfigurationsdatensätzen in einem Fernmeldevermittlungssystem
DE60215002T2 (de) Verfahren und system für effiziente verteilung von netzwerk-ereignisdaten
EP0825524B1 (de) Verfahren zur Verwaltung der Benennung von Objekten
DE69832946T2 (de) Verteiltes System und Verfahren zur Steuerung des Zugriffs auf Netzmittel und Ereignismeldungen
EP3402152B1 (de) Anlagenspezifisches, automatisiertes zertifikatsmanagement
DE4125389C1 (de)
DE60306932T2 (de) Schnelle Datenbankreplikation
EP1040623A2 (de) Verfahren zur koordination von netzwerkkomponenten
DE60220375T2 (de) Spezifischer Datenregistrierungsserver in einem Bedien- und Verwaltungszentrum für ein Telekommunikationssystem
EP0807883A2 (de) Kommunikationssystem mit Mitteln zum Austausch von Softwareprozessen
EP2198352A1 (de) Verfahren zum konfigurieren einer anordnung zum schützen, steuern oder überwachen einer elektrischen schalt- oder energieversorgungsanlage
EP1430369A1 (de) Dynamischer zugriff auf automatisierungsressourcen
DE112012003778T5 (de) Computernetzwerk-Management-Tools
DE10251911B4 (de) Verfahren für das Konfigurationsmanagement und Netzwerk
EP1227616B1 (de) Verfahren, Programm und Anordnung zur Synchronisierung von einem Network Manager mit einem Network Agenten
DE102004030781A1 (de) SCADA-System und Verfahren zum Betreiben eines solchen Systems
EP1514434A1 (de) Verfahren und netzwerkelement zum verwalten von ressourcen eines netzwerkelementes
DE102005014775B4 (de) Verfahren, Kommunikationsanordnung und Kommunikationseinrichtung zur Steuerung des Zugriffs auf zumindest eine Kommunikationseinrichtung
EP1655974A1 (de) Verfahren und Vorrichtungen zum Informationsabgleich zwischen Manager und Agent in eiem Managementnetz
EP1536328B1 (de) Datenverarbeitungssystem mit automatisierbarer Verwaltung und Verfahren zur automatisierten Verwaltung eines Datenverarbeitungssystems
CH686540A5 (de) Verfahren zum Steuern und Verwalten von Netzwerkelementen.
WO1999022491A1 (de) Anordnung zum anschliessen von netzelementen von kommunikationsanlagen an ein telekommunikationsverwaltungsnetzwerk
DE10318292B4 (de) Verfahren zur Parametrierung und Projektierung von Kommunikationsnetzwerken und Kommunikationsnetzwerk zur Implementierung eines solchen Verfahrens in der Automatisierungstechnik
DE60303106T2 (de) Kommandozeilenschnittstellen Prozessor mit dynamischer Aktualisierung von Attributabhängigkeiten
DE10229879A1 (de) Datenverarbeitungssystem mit Diensten zur Bereitstellung von Funktionalitäten

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): CN US

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PT RO SE SI SK TR

DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 2003760550

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 2003760550

Country of ref document: EP

WWW Wipo information: withdrawn in national office

Ref document number: 2003760550

Country of ref document: EP