WO2001035576A2 - Verfahren und kommunikationssystem zum verwalten eines kommunikationsnetzes - Google Patents

Verfahren und kommunikationssystem zum verwalten eines kommunikationsnetzes Download PDF

Info

Publication number
WO2001035576A2
WO2001035576A2 PCT/DE2000/003894 DE0003894W WO0135576A2 WO 2001035576 A2 WO2001035576 A2 WO 2001035576A2 DE 0003894 W DE0003894 W DE 0003894W WO 0135576 A2 WO0135576 A2 WO 0135576A2
Authority
WO
WIPO (PCT)
Prior art keywords
manufacturer
omc
dependent
nmc
information
Prior art date
Application number
PCT/DE2000/003894
Other languages
English (en)
French (fr)
Other versions
WO2001035576A3 (de
Inventor
Lucian Hirsch
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 EP00981163A priority Critical patent/EP1228599B1/de
Priority to JP2001537205A priority patent/JP4460812B2/ja
Priority to US10/129,540 priority patent/US7747714B1/en
Priority to CA002390347A priority patent/CA2390347C/en
Priority to DE50010996T priority patent/DE50010996D1/de
Publication of WO2001035576A2 publication Critical patent/WO2001035576A2/de
Publication of WO2001035576A3 publication Critical patent/WO2001035576A3/de
Priority to US12/347,043 priority patent/US8332533B2/en

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/50—Testing arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • 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/22—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks comprising specially adapted graphical user interfaces [GUI]

Definitions

  • the invention relates to a method for managing a communication network, in particular for generating tests at a higher-level network management center, and a communication system for carrying out the method.
  • information for example voice, image information, or other data
  • information is transmitted between transmitting and receiving using electromagnetic waves via a radio interface
  • Radio station base station or mobile station transmitted.
  • the electromagnetic waves are emitted at carrier frequencies that lie in the frequency band provided for the respective system.
  • GSM Global System for Mobile Communication
  • the carrier frequencies are in the range of 900, 1800 and 1900 MHz.
  • UMTS Universal Mobile Telecommunication System
  • 3rd generation systems frequencies in the frequency band of approx. 2000 MHz are provided.
  • Telecommunications Management Network The principles of a general management network, also referred to as TMN principles (TMN: Telecommunications Management Network), define several management levels for the management of one
  • Communication system - for example a mobile communication system - where each level has a double function.
  • each level except the lowest has a managerial function for the one below Level.
  • each level except the top one has an agent function for the next higher level.
  • each agent functionality is accordingly provided by a specific object that is available as a managed object (or object instance MOI) of an object class.
  • the object arises as a result of a modeling activity in which, in addition to functionality, the parameters and framework conditions are defined, and is known to both the manager and the executing agent at the corresponding interface.
  • the interface can e.g. in the case of a mobile radio network, the so-called O interface between an operating and maintenance center (OMC in FIG. 1) and a base station system (BSS).
  • OMC operating and maintenance center
  • BSS base station system
  • An object instance of a certain managed class A which is also referred to as a managed object class, can have more
  • a relationship between object classes which specifies that an object instance of one class is or can be defined as a superordinate (SUPERIOR) object for objects of another class, is also referred to as a name binding or "NAME BINDING".
  • a hierarchical assignment of objects in which the hierarchy is organized on the basis of NAME-BINDING relationships is generally referred to as a naming tree.
  • OMC Operation and Maintenance Center
  • LMT Local Maintenance Terminal
  • Such network units are, in a mobile radio network, for example a base station subsystem BSC, a base station receiver / transmitter station BTSE (BTSE: Base Transceiver Station Equipment), which models or takes into account the hardware there, or a transcoder and rate adapter unit TRAU.
  • BSC base station subsystem
  • BTSE Base Transceiver Station Equipment
  • TRAU transcoder and rate adapter unit
  • the telecommunications network is divided into several network regions, as can also be seen from FIG. 1.
  • the entire network contains hardware from different manufacturers, both the network elements and the management systems listed above are usually supplied by the same manufacturer within each of these network regions, since the management at the OMC operating and maintenance center and at local maintenance data terminals are all manufacturer-specific Hardware properties must take into account. In particular, this also includes testing the functionality of individual components.
  • NMC Network Management Center
  • Network elements are e.g. the base stations BSS, which are managed by an OMC in a network region.
  • the operator of the network management center NMC In order to avoid unpredictable events, e.g. a failure of certain hardware components to be able to react quickly, the operator of the network management center NMC must be able to start appropriate tests. However, unlike operators of the OMC operations and maintenance centers, the operators of the network management center have no system-specific knowledge of the hardware of a particular manufacturer. This means that no manufacturer-specific tests can be carried out.
  • the object of the invention is to propose an improved method for managing a communication network, in particular to enable automatic test functionality in a communication network from a higher-level, manufacturer-independent network management center.
  • manufacturer-independent functional management object classes on the one hand and manufacturer-specific, hardware-related management object classes on the other hand is solved in that manufacturer-specific hardware tests are automatically generated at the network management center. This is preferably both targeted, i.e. after receiving alarms as a result of hardware errors, as well as generic, i.e. as a periodic preventive measure.
  • the tests automatically generated at the NMC network management center can be both dedicated, e.g. after the occurrence of errors of a certain hardware board, as well as preventive, e.g. for the entire hardware of a network unit.
  • Fig. 2 shows schematically the sequence of a
  • FIG. 3 schematically shows the sequence of manufacturer-specific tests in such a communication network.
  • Exemplary process sequences for hardware-specific testing of network devices from the network management center NMC are shown in FIGS. 2 and 3.
  • management object classes MOCs to control the interfaces between the NMC network management center and the regional operating and maintenance centers OMCs. Since these interfaces have to be manufacturer-independent, the information model of such a management interface only contains functional management object classes MOCs.
  • the following total equipment management object classes MOC are defined for the radio part of a mobile radio network, which consists of the network units base station control device BSC, base station receiver / transmitter station BTSE and transcoder and rate adapter unit TRAU:
  • the management object class bscEquipment concerns the
  • Equipment features of the base station control device btsEquipment relates to the equipment features of the base station receiver / transmitter station and trauEquipment relates to the equipment features of the transcoder and rate adapter unit. If a hardware error occurs in a specific hardware module, for example in FIG. 2 in a board 1 of the type TPU (TPU: Transceiver Power Unit), this being seen only as an example of a hardware board, in a rack or rack no. 2 of the BTSE unit 8, this network unit generates an alarm notification or alarm notification with the parameters:
  • TPU Transceiver Power Unit
  • - Object class MOC TPU (hardware-related MOC on the manufacturer-specific OMC-BSS interface) and - Object instance MOI: ... -8-2-1 (sequence of relatively distinguishable names, so-called relative distinguished names, according to the designation tree ).
  • This notification is forwarded as a manufacturer-specific alarm report via the network unit base station control device BSC to the regional operation and maintenance center OMC.
  • each manufacturer-specific operation and maintenance center OMC is given a so-called mediation function.
  • Mediation function converts all event reports relevant to the NMC network management center from the telecommunications network to the corresponding functional management object class, according to the information model of the OMC-NMC interface. This procedure is also referred to as a so-called mapping or mapping procedure and is outlined in FIG. 2.
  • alarm messages after hardware errors are converted by the mediation function into alarms from functional, overall equipment management objects and then in the form of manufacturer-independent Alarm reports forwarded to the NMC network management center.
  • the original hardware-related alarm message is mapped or mapped according to ITU-T X.733 ("Systems Management: Alarm Reporting Function") in a functional, standardized alarm message with, for example, the following parameters:
  • btsEquipment models the functionality of the hardware in a network unit BTSE
  • the manufacturer-specific information that uniquely identifies the original faulty hardware is thus defined by the mediation function in the Additional Information field.
  • the additional information of the alarm message sent to the NMC network management center is defined as follows in accordance with the ITU-T X.710 standard "Open Systems Interconnection - Common Management Information Service Definition":
  • the NMC software of the network management center NMC recognizes from the object class ("equipment-summary" btsEquipment) that this is a manufacturer-specific hardware error.
  • the network management center NMC To examine the error in more detail, i.e. To determine whether it is a transient or a permanent error, whether the board should be replaced, etc., the network management center NMC must start a test specific to the current board (TPU). This should preferably be done automatically. For this, the NMC software evaluates the "Additional information" field and, together with the object class and instance of the mediated alarm message, can clearly determine and emulate the address of the faulty board.
  • the network management center NMC thus, as outlined in FIG. 3, generates a management action "M-ACTION" standardized in accordance with ITU-T X.745 (Systems Management: Test Management Function), in which the hardware to be tested using the so-called “nonSpecificForm” is defined.
  • the parameter is the "toBeTestedMORTs" field or boards to be tested.
  • the 1st byte defines the frame or Rack number in which the board to be tested or a circuit board to be tested is located.
  • the 2nd byte defines the board type, i.e. In the present example TPU and the 3rd byte defines the PCB or board number, here 1.
  • the management action M-ACTION is carried out by the
  • Network management center NMC sent via the interface to the operation and maintenance center OMC, whereby the recipient is always a management object of the overall equipment type ("equipment-summary" object). In the present case, this is the btsEquipment instance 8.
  • the mediation function converts this management action request (M-ACTION request) into a test request according to the manufacturer-specific information model of the OMC-BSS interface. Based on the 1: 1 assignment between the real base station receiver / transmitter station device BTSE and the overall equipment instance btsEquipment and the parameter value "toBeTestedMORTs", the mediation function can clearly define the address of the board to be tested in the real telecommunications network.
  • the test request advantageously also contains the identifier of the manufacturer-specific test predefined for the current board.
  • test results returned by the network unit are in turn converted by the mediation function in the OMC operations and maintenance center in accordance with the information model of the OMC-NMC interface and with the previous NMC test request from the network management center
  • NMC clearly correlated with the help of the standardized parameter "test call ID" or "testlnvocationld”.
  • the OMC sends a "response” after the standardized NMC test command, which contains the parameter value "testlnvocationld” so that a test process is clearly identified.
  • the same value is inserted by the OMC operations and maintenance center in the testResultNotification for the NMC network management center after the end of the test.
  • the displayed or mediated test results can also be used by the NMC software for the automatic creation of so-called error forms or "trouble tickets" so that appropriate repair measures can be initiated on site.
  • the definition of the OMC-NMC interface additionally and / or alternatively also enables the automatic
  • the network management center NMC can assign a special value for the Use the testing board in the attribute "toBeTestedMORTs".
  • the mediation function can interpret this command, for example, as a test request for the entire network unit that is modeled by the recipient of the test request. In the present example, this is the btsEquipment instance 8. Accordingly, the mediation function generates a number of individual test commands that are specific to each hardware board and are sent to the BTSE 8 network unit in succession.
  • testResultNotification standardized according to ITU-T X.745.

Abstract

Um in Kommunikationsnetzen eine automatische Test-Funktionalität von einem übergeordneten hersteller-unabhängig verwaltenden Netzmanagementzentrum (NMC) aus zu ermöglichen, beispielsweise zu Zeiten, an denen untergeordnete, herstellerspezifische Betriebs- und Wartungszentren (OMC) nicht besetzt sind, wird vorgeschlagen, beim Austausch einer Alarm-Nachricht zumindest eine hersteller-abhängige Information zu übermitteln und am Netzmanagementzentrum hersteller-spezifische Harware-Tests automatisch zu erzeugen. Dabei muß das Informations-Modell der OMC-NMC- Schnittstelle keine hersteller-spezifische Objektklassen kennen. Die am Netzmanagementzentrum NMC automatisch generierten Tests können sowohl dediziert, also z.B. nach dem Auftreten von Fehlern eines bestimmten Hardware-Board, als auch präventiv, z.B. für die gesamte Hadware einer Netzeinheit, getriggert werden.

Description

Beschreibung
Verfahren und Kommunikationssystem zum Verwalten eines Kommunikationsnetzes
Die Erfindung betrifft ein Verfahren zum Verwalten eines Kommunikationsnetzes, insbesondere zum Erzeugen von Tests an einem übergeordneten Netzmanagementzentrum bzw. ein Kommunikationssystem zum Durchführen des Verfahrens.
In Funk-Kommunikationssystemen werden Informationen (beispielsweise Sprache, Bildinformationen, oder andere Daten) mit Hilfe von elektromagnetischen Wellen über eine Funkschnittstelle zwischen sendender und empfangender
Funkstation (Basisstation bzw. Mobilstation) übertragen. Das Abstrahlen der elektromagnetischen Wellen erfolgt dabei mit Trägerfrequenzen, die in dem für das jeweilige System vorgesehenen Frequenzband liegen. Beim GSM (Global System for Mobile Communication) liegen die Trägerfrequenzen im Bereich von 900, 1800 bzw. 1900 MHz. Für zukünftige Mobilfunknetze mit CDMA- oder TD/CDMA-Übertragungsverfahren über die Funkschnittstelle, beispielsweise das UMTS (Universal Mobile Telecommunication System) oder andere Systeme der 3. Generation sind Frequenzen im Frequenzband von ca. 2000 MHz vorgesehen.
Die Prinzipien eines allgemeinen Managementnetzes, die auch als TMN-Prinzipien (TMN: Telecommunications Management Network) bezeichnet werden, definieren mehrere Managementebenen für das Management eines
Kommunikationssystems - beispielsweise eines Mobil- KommunikationsSystems -, wobei jede Ebene eine doppelte Funktion hat. Im managenden System hat jede Ebene außer der untersten eine Managerfunktion für die darunterliegende Ebene. Im gemanagten System hat jede Ebene außer der obersten eine Agentenfunktion für die nächst höhere Ebene.
In einer objekt-orientierten Umgebung gibt es eine Vielzahl von Objekten, die Netzressources mit jeweils einer bestimmten Funktionalität darstellen. Bei der objekt-orientierten
Umgebung, wie sie typischerweise zwischen Manager und Agent in einem Mobilfunknetz besteht, wird entsprechend jede Agent- Funktionalität von einem bestimmten Objekt bereitgestellt, das als gemanagtes Objekt (bzw. Objektinstanz MOI) einer Objektklasse verfügbar ist.
Das Objekt entsteht als Ergebnis einer Modellierungs- Tätigkeit, bei der neben der Funktionalität u.a. die Parameter und Rahmenbedingungen definiert werden, und ist sowohl dem Manager als auch dem ausführenden Agent an der entsprechenden Schnittstelle bekannt. Die Schnittstelle kann z.B. bei einem Mobilfunknetz die sogenannte O-Schnittstelle zwischen einem Betriebs- und WartungsZentrum (OMC in Fig. 1) und einem Basisstationssystem (BSS) sein.
Eine Objektinstanz einer bestimmten gemanagten Klasse A, die auch als managed object class bezeichnet wird, kann weitere
Objektinstanzen derselben oder anderer Klassen enthalten.
Eine solche Beziehung zwischen Objektinstanzen - nicht
Klassen - wird in der Modellierung auch als
Einschließungsbeziehung bzw. "Containment relationship" bezeichnet.
Eine Beziehung zwischen Objektklassen, die spezifiziert, daß eine Objektinstanz einer Klasse als übergeordnetes (SUPERIOR) Objekt für Objekte einer anderen Klasse definiert ist oder definiert sein kann, wird auch als Bezeichnungsbindung bzw. "NAME BINDING" bezeichnet. Eine hierarchische Zuordnung von Objekten, in der die Hierarchie auf Grundlage von NAME- BINDING-Beziehungen organisiert ist, wird allgemein als Bezeichnungsbaum bzw. "naming tree" bezeichnet. In einem Telekommunikationsnetz, z.B. einem Mobilfunknetz, erfolgt die Netzuberwachung und -kontrolle dabei üblicherweise von zwei Managerseiten aus: einerseits zentral von einem Betriebs- und WartungsZentrum OMC aus (OMC: Operation and Maintanance Centre) , was einem Element-Manager entspricht, und andererseits vor Ort von einer lokalen Wartungs-Datenendstation LMT aus (LMT: Local Maintenance Terminal) , die an verschiedenen Netzeinheiten angeschlossen werden kann. Solche Netzeinheiten sind m einem Mobilfunknetz beispielsweise ein Basisstations-Untersystem BSC, eine Basιsstatιons-Empfanger-/Senderstatιon BTSE (BTSE: Base Transceiver Station Equipment) , die die dortige Hardware modelliert bzw. berücksichtigt, oder eine Transcoder- und Raten-Adapteremheit TRAU.
Ein gesamtes, von einem Diensteanbieter gemanagtes
Telekommunikationsnetz wird aus betrieblicher Sicht m mehrere Netzregionen unterteilt, wie dies auch aus Fig. 1 ersichtlich ist. Obwohl das gesamte Netz Hardware von verschiedenen Herstellern enthalt, werden innerhalb jeder dieser Netzregionen sowohl die Netzelemente, als auch die vorstehend aufgeführten Managementsysteme üblicherweise vom gleichen Hersteller geliefert, da das Management am Betriebs- und WartungsZentrum OMC und an lokalen Wartungs- Datenendstationen alle hersteller-spezifischen Eigenschaften der Hardware berücksichtigen muß. Dazu gehören insbesondere auch die Tests der Funktionalltat einzelner Komponenten.
Wahrend der Nacht, der Feiertagen und am Wochenende wird das Mobilfunknetz einerseits von einem übergeordneten NetzmanagementZentrum überwacht, das üblicherweise als „Network Management Centre" (NMC) bezeichnet wird, da die regionalen Betriebs- und Wartungszentren OMCs zu diesen Zeiten unbesetzt sind. Anderseits muß die Schnittstelle zwischen dem Netzmanagementzentrum NMC und den regionalen Betriebs- und WartungsZentren OMCs hersteller-unabhangig bleiben, um eine funktionale Integration hersteller- spezifischer Netzregionen unter einem einheitlichen NetzmanagementZentrum NMC zu ermöglichen.
Diese Herstellerunabhängigkeit der OMC-NMC-Schnittstelle kann in einer objekt-orientierten Managementumgebung durch die exklusive Verwendung sogenannter funktionaler Objektklassen, insbesondere Management-Objektklassen (functional-related MOC) erfolgen. Die funktionalen Objekte modellieren dabei die Netzressourcen eines Telekommunikationsnetzes aus einer funktionalen, herstellerunabhängigen Sicht. Im Gegensatz dazu kennt die hersteller-spezifische Schnittstelle zwischen
Betriebs- und WartungsZentrum OMC und den Netzelementenauch sogenannte hardware-bezogene Management-Objektklassen (equipment-related MOC) , die von Hersteller zu Hersteller unterschiedlich sind. Netzelemente sind dabei z.B. die Basisstationen BSS, die in einer Netzregion von einem OMC gemanaged werden.
Um auf unvorhersehbare Ereignisse, z.B. einen Ausfall von bestimmten Hardwarekomponenten, rasch reagieren zu können, muß der Operator des Netzmanagementzentrums NMC in der Lage sein, entsprechende Tests zu starten. Allerdings haben die Operatoren des Netzmanagementzentrums im Unterschied zu Operatoren der Betriebs- und Wartungszentren OMC keine system-spezifische Kenntnisse über die Hardware eines bestimmten Herstellers. Dadurch können keine hersteller- spezifischen Tests durchgeführt werden.
Die Aufgabe der Erfindung besteht darin, ein verbessertes Verfahren zum Verwalten eines Kommunikationsnetzes vorzuschlagen, insbesondere in Kommunikationsnetzen eine automatische Test-Funktionalität von einem übergeordneten, hersteller-unabhängigen NetzmanagementZentrum aus zu ermöglichen.
Diese Aufgabe wird durch das Verfahren mit den Merkmalen des Anspruchs 1 und das Funk-Kommunikationssystem mit den Merkmalen des Anspruchs 13 gelöst. Vorteilhafte Weiterbildungen sind Gegenstand von Unteransprüchen.
Der Konflikt zwischen der Handhabung von einerseits hersteller-unabhängigen funktionalen Management-Objektklassen und andererseits hersteller-spezifischen, hardware-bezogenen Management-Objektklassen wird dadurch gelöst, daß am Netzmanagementzentrum hersteller-spezifische Hardware-Tests automatisch erzeugt werden. Dies erfolgt vorzugsweise sowohl gezielt, d.h. nach Empfang von Alarmen als Folge von Hardwarefehlern, als auch generisch, d.h. als periodische präventive Maßnahme.
Somit ist die automatische Erzeugung von herstellerspezifischen Hardwaretests von einem Netzmanagementzentrum NMC aus möglich, obwohl das Informations-Modell der OMC-NMC- Schnittstelle keine hersteller-spezifische Objektklassen kennt .
Die am NetzmanagementZentrum NMC automatisch generierten Tests können sowohl dediziert, also z.B. nach dem Auftreten von Fehlern eines bestimmten Hardware-Board, als auch präventiv, z.B. für die gesamte Hardware einer Netzeinheit, getriggert werden.
Nachfolgend wird ein Ausführungsbeispiel anhand der Zeichnung näher erläutert. Es zeigen:
Fig. 1 ein übliches, in mehrere Netzregionen unterteiltes Kommunikationsnetz,
Fig. 2 schematisch den Ablauf einer
Alarmübertragungsprozedur in einem solchen Kommunikationsnetz und Fig. 3 schematisch den Ablauf hersteller-spezifischer Tests in einem solchen Kommunikationsnetz. Beispielhafte Verfahrensabläufe zum hardware-spezifischen Testen von Netzeinrichtungen vom NetzmanagementZentrum NMC aus sind in den Fig. 2 und 3 dargestellt.
Zur Steuerung der Schnittstellen zwischen Netzmanagementzentrum NMC und den regionalen Betriebs- und Wartungszentren OMCs gibt es verschiedene Management- Objektklassen MOCs. Da diese Schnittstellen herstellerunabhängig sein müssen, enthält das Informations-Modell einer solchen Management-Schnittstelle nur funktionale Management- Objektklassen MOCs.
Um in diesem Informations-Modell eine hersteller-spezifische Hardware zu integrieren, werden vorzugsweise die gesamten Hardware-Baugruppen, d.h. alle sogenannten Boards, auf der Ebene einer Netzeinheit als eine generische Gesamtausstattungs-Management-Objektklasse MOC (equipment summary MOC) definiert.
Zum Beispiel werden für den Radioteil eines Mobilfunk-Netzes, das aus den Netzeinheiten Basisstations-Steuereinrichtung BSC, Basisstations-Empfänger-/Senderstation BTSE und Transcoder- und Raten-Adaptereinheit TRAU besteht, folgende Gesamtausstattungs-Management-Objektklassen MOC definiert:
bscEquipment btsEquipment trauEquipment .
Die Management-Objektklasse bscEquipment betrifft die
Ausstattungsmerkmale der Basisstations-Steuereinrichtung, btsEquipment betrifft die Ausstattungsmerkmale der Basisstations-Empfänger-/Senderstation und trauEquipment betrifft die Ausstattungsmerkmale der Transcoder- und Raten- Adaptereinheit. Beim Auftreten eines Hardwarefehlers in einer spezifischen Hardware-Baugruppe, z.B. bei Fig. 2 in einem Board 1 vom Typ TPU (TPU: Transceiver Power Unit) , wobei dies nur als ein Beispiel eines Hardware-Boards zu sehen ist, in Gestell- bzw. Rack-Nr. 2 der BTSE-Einheit 8, generiert diese Netzeinheit eine Alarm-Notification bzw. Alarm-Benachrichtigung mit den Parametern:
- Objektklasse MOC: TPU (hardware-bezogene MOC an der hersteller-spezifischen OMC-BSS-Schnittstelle) und - Objektinstanz MOI: ... -8-2-1 (Folge von relativ unterscheidbaren Namen, sogenannten Relative Distinguished Names, gemäß dem Bezeichnungsbaum) .
Diese Benachrichtigung wird als hersteller-spezifische Alarmmeldung (alarm report) über die Netzeinheit Basisstations-Steuereinrichtung BSC an das regionale Betriebs- und WartungsZentrum OMC weitergeleitet.
Um die Netzüberwachung an einem übergeordneten Netzmanagementzentrum NMC während der Zeit mit unbesetzten Betriebs- und Wartungszentren OMCs zu ermöglichen, erhält jedes hersteller-spezifische Betriebs- und WartungsZentrum OMC eine sogenannte Mediationsfunktion. Die
Mediationsfunktion wandelt alle für das Netzmanagementzentrum NMC relevanten Ereignismeldungen (event reports) aus dem Telekommunikationsnetz auf die jeweils entsprechende funktionale Management-Objektklasse um, und zwar gemäß dem Informations-Modell der OMC-NMC-Schnittstelle. Diese Vorgehensweise wird auch als sogenannte Abbildungs- bzw. Mapping-Prozedur bezeichnet und ist in Fig. 2 skizziert.
Mit anderen Worten, Alarmmeldungen nach Hardware-Fehlern, d.h. hardware-bezogene, hersteller-spezifische Alarme, werden von der Mediationsfunktion in Alarme von funktionalen, Gesamtausstattungs-Managementobjekten umgewandelt und anschließend in Form von hersteller-unabhängigen Alarmberichten an das Netzmanagementzentrum NMC weitergeleitet. Die ursprüngliche hardware-bezogene Alarmmeldung wird gemäß ITU-T X.733 („Systems Management: Alarm Reporting Function" ) in eine funktionale, standardisierte Alarmmeldung mit z.B. folgenden Parametern „gemapped" bzw. abgebildet:
- Objektklasse: btsEquipment (modelliert die Funktionalität der Hardware in einer Netzeinheit BTSE)
- Objektinstanz: ...-8.
Hinsichtlich der Objektinstanz gibt es an der OMC-NMC- Schnittstelle eine 1 : 1-Zuordnung zwischen den tatsächlichen Netzeinheiten BTSE und den funktionalen, generischen Instanzen der Objektklasse btsEquipment.
Beim in Fig. 2 dargestellten Beispiel wird die zum Betriebs- und WartungsZentrum OMC übertragene ursprüngliche
Alarmmeldung mit "MOC = TPU" und "MOI = 1" auf eine abgebildete Alarmmeldung mit den Informationen "MOC = btsEquipment", "MOI = 8" und "Zusatzinformation (standardisierter Parameter "Additional Information" ) = [rack 2, TPU 1]" abgebildet.
Die hersteller-spezifische Information, die die ursprüngliche fehlerhafte Hardware eindeutig kennzeichnet, wird von der Mediationsfunktion somit im Feld Zusatzinformation definiert. Die Zusatzinformation der an das Netzmanagementzentrum NMC gesendeten Alarmmeldung ist beim vorliegenden Beispiel gemäß dem Standard ITU-T X.710 „Open Systems Interconnection - Common Management Information Service Definition" wie folgt definiert:
- Rack-Nummer: 2, weil die BTSE-Hardware hier in mehreren Racks untergebracht ist,
- Board-Typ: TPU und
- Board-Nummer: 1. Nach dem Empfang des mediierten Alarmberichts erkennt die NMC-Software des Netzmanagementzentrums NMC anhand der Objektklasse ("equipment-summary" btsEquipment), daß es sich hier um einen hersteller-spezifischen Hardwarefehler handelt.
Um den Fehler näher zu untersuchen, d.h. festzustellen, ob es ein transienter oder ein permanenter Fehler ist, ob das Board ersetzt werden soll etc., muß das Netzmanagementzentrum NMC einen für das aktuelle Board (TPU) spezifischen Test starten. Dies sollte vorzugsweise automatisch erfolgen. Dafür wertet die NMC-Software das Feld "Zusatzinformation" aus und kann, zusammen mit der Objektklasse und -instanz der mediierten Alarmmeldung, die Adresse des fehlerhaften Board eindeutig bestimmen und nachbilden.
Damit generiert das Netzmanagementzentrum NMC, wie in Fig. 3 skizziert, eine gemäß ITU-T X.745 (Systems Management: Test Management Function) standardisierte Managementaktion "M- ACTION", in der die zu testende Hardware mit Hilfe der sogenannten "nonSpecificForm" definiert ist. Parameter ist dabei das Feld "toBeTestedMORTs" bzw. zu testende Boards. Beim vorliegenden Beispiel definiert das 1. Byte die Gestellbzw. Rack-Nummer, in dem sich das zu testende Board bzw. eine zu testende Leiterplatte befindet. Das 2. Byte definiert den Board-Typ, d.h. im vorliegenden Beispiel TPU und das 3. Byte definiert die Leiterplatten- bzw. Board-Nummer, hier 1.
Die Managementaktion M-ACTION wird von dem
Netzmanagementzentrum NMC über die Schnittstelle an das Betriebs- und WartungsZentrum OMC gesendet, wobei der Empfänger immer ein Managementobjekt vom Gesamtausstattungstyp ("equipment-summary" object) ist. Dies ist im vorliegenden Fall die btsEquipment-Instanz 8.
Im Betriebs- und WartungsZentrum OMC wandelt die Mediationsfunktion diese Managementaktionsanforderung (M- ACTION Request) in eine Test-Anforderung gemäß dem hersteller-spezifischen Informations-Modell der OMC-BSS- Schnittstelle um. Anhand der 1 : 1-Zuordnung zwischen der realen BasisStations-Empfänger-/SenderStations-Einrichtung BTSE und der Gesamtausstattungs-Instanz btsEquipment und dem Parameterwert "toBeTestedMORTs", kann die Mediationsfunktion die Adresse des zu testenden Boards im realen Telekommunikationsnetz eindeutig definieren. Die Test- Anforderung enthält dabei vorteilhafterweise auch die Kennung des für das aktuelle Board vordefinierten, hersteller- spezifischen Tests.
Die von der Netzeinheit, hier BTSE 8, zurückgesendeten Testergebnisse werden von der Mediationsfunktion im Betriebsund WartungsZentrum OMC wiederum gemäß dem Informations- Modell der OMC-NMC-Schnittstelle umgewandelt und mit der vorherigen NMC-Test-Anforderung des Netzmanagementzentrums
NMC mit Hilfe des standardisierten Parameters "Testaufruf-ID" bzw. "testlnvocationld" eindeutig korreliert. Dabei sendet das OMC nach dem standardisierten NMC-Testkommando eine "Response", die den Parameterwert "testlnvocationld" enthält, damit ein Testvorgang eindeutig gekennzeichnet ist. Der gleiche Wert wird vom Betriebs- und WartungsZentrum OMC nach Testende in die testResultNotification für das Netzmanagementzentrum NMC eingefügt.
Die abgebildeten bzw. mediierten Testergebnisse können von der NMC-Software auch zur automatischen Erstellung von sogenannten Fehlerformularen bzw. „Trouble tickets" verwendet werden, damit entsprechende Reparaturmaßnahmen vor Ort eingeleitet werden können.
Die Definition der OMC-NMC-Schnittstelle ermöglicht zusätzlich und/oder alternativ auch die automatische
Generierung von periodischen, präventiven Hardware-Tests an dem NetzmanagementZentrum NMC. In der gemäß ITU-T X.745 standardisierten Test-Anforderung kann das NetzmanagementZentrum NMC einen speziellen Wert für das zu testende Board im Attribut "toBeTestedMORTs" verwenden. Die Mediationsfunktion kann dieses Kommando z.B. als Test- Anforderung für jene gesamte Netzeinheit interpretieren, die vom Empfänger der Test-Anforderung modelliert wird. Im vorliegenden Beispiel ist dies die btsEquipment-Instanz 8. Demzufolge erzeugt die Mediationsfunktion mehrere einzelne, für jedes Hardware-Board spezifische Testkommandos, die an die Netzeinheit BTSE 8 hintereinander gesendet werden.
Nach jedem Test werden die einzelnen Testergebnisse von der Mediationsfunktion gesammelt, „gemapped" und als eine gemäß ITU-T X.745 standardisierte Testergebnisse-Benachrichtigung bzw. sogenannte "testResultNotification" an das übergeordnete NetzmanagementZentrum NMC übertragen.

Claims

Patentansprüche
1. Verfahren zum Verwalten eines Kommunikationsnetzes mit
- zumindest einer übergeordneten funktionalen, insbesondere hersteller-unabhängigen Einrichtung (NMC) und
- zumindest einer davon überwachten und/oder gesteuerten untergeordneten Einrichtung (OMC) ,
- zwischen denen Nachrichten über den Zustand zumindest einer nicht funktionalen, insbesondere hersteller-abhängigen Einrichtung (OMC, BSC, BTSE, TRAU) des Kommunikationsnetzes ausgetauscht werden, dadurch gekennzeichnet, daß beim Austausch einer Nachricht zumindest eine nicht funktionale, insbesondere hersteller-abhängige Information übermittelt wird.
2. Verfahren nach Anspruch 1, bei dem die Nachricht mit der hersteller-abhängigen Information zyklisch und/oder auf Anforderung und/oder nach einem Fehler in der zumindest einen hersteller-abhängigen Einrichtung (OMC, BSC, BTSE, TRAU) übermittelt wird.
3. Verfahren nach Anspruch 1 oder 2, bei dem die Nachricht an die hersteller-unabhängige übergeordnete Einrichtung (NMC) übermittelt wird.
4. Verfahren nach einem vorstehenden Anspruch, bei dem mit der Nachricht eine hersteller-abhängige Information über den Zustand zumindest einer bestimmten hersteller-abhängigen Einrichtung (OMC, BSC, BTSE, TRAU) übermittelt wird.
5. Verfahren nach einem vorstehenden Anspruch, bei dem in der untergeordneten Einrichtung (OMC) eine Umwandlung der hersteller-abhängigen Information zu einer hersteller- abhängigen Zusatzinformation für die hersteller-unabhängige Nachricht an die hersteller-unabhängige übergeordnete Einrichtung (NMC) durchgeführt wird.
6. Verfahren nach Anspruch 1 oder 2, bei dem eine Nachricht, insbesondere Test-Anforderungsnachricht mittels der hersteller-abhängigen Information von der hersteller-unabhängigen übergeordneten Einrichtung (NMC) aus zu einer oder mehreren bestimmten der hersteller-abhängigen Einrichtungen (OMC, BSC, BTSE, TRAU) übermittelt wird.
7. Verfahren nach Anspruch 1, 2 oder 6, bei dem durch die Übermittlung der Nachricht der Zustand zumindest einer hersteller-abhängigen Einrichtung (OMC, BSC, BTSE, TRAU) überprüft oder abgefragt wird, insbesondere herstellerspezifische Tests aktiviert werden.
8. Verfahren nach einem vorstehenden Anspruch, bei dem in der untergeordneten Einrichtung (OMC) eine Umwandlung einer hersteller-abhängigen Zusatzinformation der herstellerunabhängigen Nachricht zu einer hersteller-abhängigen Information für die hersteller-abhängige Einrichtung (OMC, BSC, BTSE, TRAU) durchgeführt wird.
9. Verfahren nach einem vorstehenden Anspruch, bei dem die Information als Zusatzinformation, mittels insbesondere standardisierter Nachrichten übermittelt wird.
10. Verfahren nach einem vorstehenden Anspruch, bei dem über eine Schnittstelle zwischen der zumindest einen hersteller-unabhängigen übergeordneten Einrichtung (NMC) und der zumindest einen untergeordneten Einrichtung (OMC) die Nachrichten gemäß einem Informations-Modell der Schnittstelle (OMC-NMC) übermittelt werden, wobei das Informations-Modell nicht für hersteller-abhängige Informationen ausgelegt ist.
11. Verfahren nach Anspruch 10, bei dem das Informations-Modell objektorientiert aufgebaut ist und keine hersteller-abhängigen Objektklassen kennt.
12. Verfahren nach einem vorstehenden Anspruch, bei dem die hersteller-abhängige Information als Zusatzinformation in einer üblichen, insbesondere standardisierten Nachricht übermittelt wird.
13. Kommunikationssystem, insbesondere Funk- KommunikationsSystem, zum Durchführen eines vorstehenden Verfahrens .
14. Kommunikationssystem nach Anspruch 13, bei dem die hersteller-unabhängige übergeordnete Einrichtung (NMC) ein Netzmanagementzentrum ist.
15. Kommunikationssystem nach Anspruch 13 oder 14, bei dem die zumindest eine untergeordnete Einrichtung ein Betriebs- und Wartungszentrum (OMC) von einer aus insbesondere einer Vielzahl von Netzregionen ist.
PCT/DE2000/003894 1999-11-09 2000-11-07 Verfahren und kommunikationssystem zum verwalten eines kommunikationsnetzes WO2001035576A2 (de)

Priority Applications (6)

Application Number Priority Date Filing Date Title
EP00981163A EP1228599B1 (de) 1999-11-09 2000-11-07 Verfahren und System zur hierarchischen Kommunikationsnetzverwaltung
JP2001537205A JP4460812B2 (ja) 1999-11-09 2000-11-07 通信ネットワークを管理する方法および通信システム
US10/129,540 US7747714B1 (en) 1999-11-09 2000-11-07 Method and communication system for managing a communication network
CA002390347A CA2390347C (en) 1999-11-09 2000-11-07 Method and communication system for managing a communication network
DE50010996T DE50010996D1 (de) 1999-11-09 2000-11-07 Verfahren und System zur hierarchischen Kommunikationsnetzverwaltung
US12/347,043 US8332533B2 (en) 1999-11-09 2008-12-31 Method and communication system for managing a communication network

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE19953877A DE19953877A1 (de) 1999-11-09 1999-11-09 Verfahren und Kommunikationssystem zum Verwalten eines Kommunikationsnetzes
DE19953877.8 1999-11-09

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US12/347,043 Continuation US8332533B2 (en) 1999-11-09 2008-12-31 Method and communication system for managing a communication network

Publications (2)

Publication Number Publication Date
WO2001035576A2 true WO2001035576A2 (de) 2001-05-17
WO2001035576A3 WO2001035576A3 (de) 2001-11-29

Family

ID=7928425

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/DE2000/003894 WO2001035576A2 (de) 1999-11-09 2000-11-07 Verfahren und kommunikationssystem zum verwalten eines kommunikationsnetzes

Country Status (8)

Country Link
US (3) US7747714B1 (de)
EP (1) EP1228599B1 (de)
JP (2) JP4460812B2 (de)
CN (1) CN1179517C (de)
CA (3) CA2390347C (de)
DE (2) DE19953877A1 (de)
ES (1) ES2244483T3 (de)
WO (1) WO2001035576A2 (de)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7797425B2 (en) 2005-12-22 2010-09-14 Amdocs Systems Limited Method, system and apparatus for communications circuit design
CN102740342A (zh) * 2012-06-08 2012-10-17 大唐移动通信设备有限公司 网管设备性能的模拟测试方法和系统

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10134125A1 (de) * 2001-07-13 2003-07-10 Siemens Ag Kundenspezifische, dynamische Konfiguration einer OMC-NMC-Schnittstelle
EP1365616B1 (de) * 2002-07-22 2003-12-03 Evolium S.A.S. Verfahren zum Bereitstellen von Dienstverwaltung für Netzelemente eines zelluraren Kommunikationsnetzwerkes
US8817803B2 (en) * 2003-01-08 2014-08-26 Nokia Corporation Method and hierarchical radio network operations system for controlling a mobile communications network
DE10337450A1 (de) * 2003-05-31 2004-12-23 Siemens Ag Verfahren zur Behandlung von Parameteränderungen in einem Managementnetz eines zellularen Kommunikationssystems und Kommunikationssystem
DE10337464A1 (de) * 2003-06-01 2004-12-23 Siemens Ag Verfahren zur Behandlung von Alarmen in einem Managementsystem eines Kommunikationsnetzes
DE10349005C5 (de) * 2003-10-17 2013-08-22 Nec Europe Ltd. Verfahren zur Überwachung eines Netzwerks
CN100341357C (zh) * 2004-07-07 2007-10-03 华为技术有限公司 基站日志上报系统及方法
CN100349417C (zh) * 2004-12-14 2007-11-14 中兴通讯股份有限公司 级联网管监控系统流量控制方法
CN101277218B (zh) * 2008-05-04 2010-12-29 中兴通讯股份有限公司 一种网络告警的动态分析系统和方法
US8200849B1 (en) * 2008-06-06 2012-06-12 The Mathworks, Inc. Model based network communications
CN103392315B (zh) * 2011-03-23 2016-09-28 松下电器产业株式会社 站、目标设备和启动设备
EP2904493A4 (de) * 2012-10-08 2016-06-22 Robustes hardwarefehlerverwaltungssystem, verfahren und rahmen für unternehmensvorrichtungen
CN105306252A (zh) * 2015-09-19 2016-02-03 北京暴风科技股份有限公司 一种自动判别服务器故障的方法

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0810755A2 (de) * 1996-05-31 1997-12-03 Hewlett-Packard Company Verfahren zur Verbesserung des Betriebs einer Netzwerk-Verwaltungsstation

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS59161879A (ja) 1983-03-04 1984-09-12 Sumitomo Electric Ind Ltd シヨツトキゲ−ト電界効果トランジスタ
US5608720A (en) 1993-03-09 1997-03-04 Hubbell Incorporated Control system and operations system interface for a network element in an access system
JP2776301B2 (ja) * 1994-08-30 1998-07-16 日本電気株式会社 回線予約装置および方法、回線予約受付装置および方法
DE69728079T2 (de) * 1996-05-03 2005-01-20 Agilent Technologies, Inc. (n.d.Ges.d.Staates Delaware), Palo Alto Verfahren und Einrichtung zum Verfolgen der Änderung des Identifizierungskodes in einem mobilen Kommunikationssystem
EP0851700B1 (de) 1996-12-11 2005-08-24 Agilent Technologies, Inc. (a Delaware corporation) Verfahren zur Erkundung von zellularen Mobilfunknetzen und Gerät hierfür
US5909682A (en) * 1996-12-30 1999-06-01 Mci Worldcom, Inc. Real-time device data management for managing access to data in a telecommunication system
US6055493A (en) 1997-01-29 2000-04-25 Infovista S.A. Performance measurement and service quality monitoring system and process for an information system
US6012100A (en) * 1997-07-14 2000-01-04 Freegate Corporation System and method of configuring a remotely managed secure network interface
US6425005B1 (en) * 1997-10-06 2002-07-23 Mci Worldcom, Inc. Method and apparatus for managing local resources at service nodes in an intelligent network
DE19801785C2 (de) 1998-01-19 2000-04-27 Siemens Ag Verfahren und Kommunikationssystem zur Behandlung von Alarmen durch ein mehrere Managementebenen aufweisendes Managementnetz

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0810755A2 (de) * 1996-05-31 1997-12-03 Hewlett-Packard Company Verfahren zur Verbesserung des Betriebs einer Netzwerk-Verwaltungsstation

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
"INFORMATION TECHNOLOGY - OPEN SYSTEMS INTERCONNECTION - SYSTEMS MANAGEMENT: ALARM REPORTING FUNCTION. INTERNATIONAL STANDARD" INTERNATIONAL STANDARD ISO/IEC,XX,XX, 1992, Seiten FIRSTPAGE,II-IV,1-18, XP000869752 in der Anmeldung erw{hnt *
ERICSSON: "Alarm IRP and GUI Launch IRP presentation" 3RD GENERATION WORKING GROUP, [Online] 20. - 22. Juli 1999, Seiten 1-18, XP002172243 Gefunden im Internet: <URL:http://www.3gpp.org/ftp/tsg_sa/WG5_TM /TSGS5_05/docs/s5-99134.pdf> [gefunden am 2001-07-17] *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7797425B2 (en) 2005-12-22 2010-09-14 Amdocs Systems Limited Method, system and apparatus for communications circuit design
CN102740342A (zh) * 2012-06-08 2012-10-17 大唐移动通信设备有限公司 网管设备性能的模拟测试方法和系统

Also Published As

Publication number Publication date
CA2660067A1 (en) 2001-05-17
CN1421082A (zh) 2003-05-28
JP4460812B2 (ja) 2010-05-12
CA2390347A1 (en) 2001-05-17
EP1228599B1 (de) 2005-08-17
CA2660067C (en) 2013-12-31
JP2003527792A (ja) 2003-09-16
CN1179517C (zh) 2004-12-08
ES2244483T3 (es) 2005-12-16
DE50010996D1 (de) 2005-09-22
CA2390347C (en) 2009-11-03
JP2008092598A (ja) 2008-04-17
CA2660092A1 (en) 2001-05-17
US7747714B1 (en) 2010-06-29
US8332533B2 (en) 2012-12-11
WO2001035576A3 (de) 2001-11-29
EP1228599A2 (de) 2002-08-07
US20090182861A1 (en) 2009-07-16
US9667522B2 (en) 2017-05-30
US20090182870A1 (en) 2009-07-16
DE19953877A1 (de) 2001-05-23

Similar Documents

Publication Publication Date Title
US9667522B2 (en) Method and communication system for managing a communication network
EP1282991B1 (de) Aktualisierung von hersteller-spezifischen hardware-informationen an der hersteller-unabhängigen omc-nmc-schnittstelle im mobilfunk
EP1520433A1 (de) Erkennung von dienst-minderleistungen in einem kommunikationsnetz
DE102005010609B3 (de) Freischalten von IRPs (Integration Reference Points)
EP1730886B1 (de) Verfahren und einrichtungen zur verteilung von management-informationen in einem managementnetz eines kommunikationssystems
WO2001024448A1 (de) Konfigurieren eines telekommunikationsnetzes mit mehreren netzregionen
EP1304011B1 (de) Entstörungsprozedur für ein übergeordnetes nmc durch korrelation von alarmen mit ergebnissen von automatischen tests
DE19740716C2 (de) Verfahren zum Behandeln von in Kommunikationssystemen von einem hardwarebezogenen gemanagten Objekt generierten Alarmen
DE102004039214B4 (de) Kommunikationsverfahren in einem Managementnetz zur Information über Attributsveränderungen
EP1617592A1 (de) Verfahren zur Auswahl eines Objektmodells für die Manager-Agent Kommunikation
EP1371236A1 (de) Verfahren zur selektiven und gesammelten weiterleitung von meldungen in einem tmn-netzwerk
EP1749369B1 (de) Verfahren und einrichtungen zum betreiben eines managementnetzes bei ausfall eines managers
EP1407622B1 (de) Kundenspezifische, dynamische konfiguration einer omc-nmc-schnittstelle
EP1525757A1 (de) Bereitstellung von netzelementen in einem kommunikationssystem
EP1841131A1 (de) Konfigurationsmanagement mit zusätzlichen Operationen
DE102004039215B4 (de) Netzwerkmanagement mit erweitertem Objektmodell
EP1750391A1 (de) Überwachung eines Agenten in einem Managementsystem
WO2008019998A2 (de) Referenzierung von subattributen für das netzwerkmanagement

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): CA CN JP US

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
AK Designated states

Kind code of ref document: A3

Designated state(s): CA CN JP US

AL Designated countries for regional patents

Kind code of ref document: A3

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR

WWE Wipo information: entry into national phase

Ref document number: 2000981163

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2390347

Country of ref document: CA

ENP Entry into the national phase

Ref country code: JP

Ref document number: 2001 537205

Kind code of ref document: A

Format of ref document f/p: F

WWE Wipo information: entry into national phase

Ref document number: 008182353

Country of ref document: CN

WWE Wipo information: entry into national phase

Ref document number: 10129540

Country of ref document: US

WWP Wipo information: published in national office

Ref document number: 2000981163

Country of ref document: EP

WWG Wipo information: grant in national office

Ref document number: 2000981163

Country of ref document: EP