WO2004004214A1

WO2004004214A1 - Network management method for the configuration and the interface description of network elements by means of xml

Info

Publication number: WO2004004214A1
Application number: PCT/EP2002/007235
Authority: WO
Inventors: Meinrad Niemoeller; Ralph Wilhelm
Original assignee: Siemens Aktiengesellschaft
Priority date: 2002-07-01
Filing date: 2002-07-01
Publication date: 2004-01-08
Also published as: CN1640055A; CN100531042C; AU2002321152A1

Abstract

According to the invention, efficient maintenance is achieved by means of an operation and maintenance device (OMC 1/LMT 12) for a cellular mobile radio network comprising at least one configuration data bank (6) which is stored in a memory and signals the configuration of a type of transmission device (NODE-B-Typ-XYZ) to the common air interface of the mobile radio network in an XML-based structure.

Description

description

"Network management procedure for the configuration and interface description of network elements using XML"

The invention relates to methods and devices for configuring a transmission device (NODE-B) of a cellular mobile radio network from an operating and monitoring device (OMC).

In mobile radio networks, a large number of network elements (agents) are controlled by a control and mode network element (Operation & Management Center, OMC for short).

An OMC communicates in particular with a multiplicity of base stations (called NodeB in UMTS networks) in one

Mobile network (e.g. in a UMTS mobile network).

Technical problems are shown below as examples for the communication between an OMC and NodeB network elements, but in principle they arise in all

Networks controlled by management systems.

The logical interface between an OMC and a NodeB. is described by a so-called information model. The entirety of all objects that can be controlled in the NodeB is referred to as the Management Information Base (MIB) and implements the possibility to create or remove certain object instances in the NodeB from an OMC, to set or query attributes of the objects and to trigger certain actions. For this remote mode, the OMC sets an operator a graphical user interface (GUI) and / or

Command line interface (CLI) available.

To understand the technical problem, it is important to differentiate the transport layers and protocols on the one hand from the information model as the logical interface on the other. An OMC and a NodeB communicate e.g. via a CORBA protocol in the sense of remote procedure calls. The semantics of remote calls, i.e. The information model describes which classes and instances of Managed Objects (MO) can be called with which operations and which attributes.

The information model defines a name tree for managed objects for different types of NodeB base stations. The mapping of the information model in software for NodeB base stations is realized in such a way that the interface for O&M is independent of the specific NodeB type and only one software package has to be kept.

The static framework of an information model with the description of the managed object classes (MOC) and their attributes is used during commissioning and also during the

Configured the runtime of a base station of a certain NodeB type by instantiating managed objects and assigning values to attributes.

The instantiation or configuration can be implemented via individual, sequential commands of the CORBA interface mentioned above or the configuration Information is summarized in a file or database, transmitted and evaluated by the base station.

Information models for network management are known from the "Guidelines for the Description of Managed Objects" (GDMO) (known to the person skilled in the art).

The invention is intended to solve two important problems in communication between network elements:

a) With suitable formats and methods, the logical interface referred to as the information model can be described in such a way that both software implementations and documentation can be derived or generated automatically from the description. b) With suitable formats and methods, a file or database for the configuration of a network element can be described in such a way that simple parsing is possible at runtime, versioning can be ensured and tools for manipulating the database are readily available to the operator can be put.

Since both problems are closely linked, both problems should be solved using similar formats or procedures.

Previous approaches known to those skilled in the art: The problem of describing the information model (see problem a)) has been solved to date by methods which are known as "Guidelines for the Description of Managed Objects" (GDMO) are specified and closely related to data formatting in the so-called ASN.l standard.

GDMO / ASN.l has been developed and expanded over the years. In addition, tools (tokits) were developed with which information models can be described in GDMO / ASN.l and which also allow the generation of software for implementing the protocol in a network element.

Approaches based on GDMO / ASN.l have the following disadvantages:

• Toolkits do not support a CORBA-based transport layer. At the same time, the object-oriented transport model CORBA is gaining ground in the area of distributed data processing and increasingly in telecommunications.

• The description of an information model in GDMO / ASN.l is relatively complex.

• For GDMO / ASN.l based descriptions it is difficult to develop generators that use parts of the information model e.g. implement in C ++ code.

So far, configuration files or databases (see problem b)) have either been stored in binary format or formatted as text files, the format of which was very much based on the corresponding configuration commands.

With simple text formatting, the commands required for configuration or instantiation are written to a file sequentially, ie line by line, in a language known as "Advanced Command Language". The commands are independent of each other in the lines in the same form as an operator would enter these commands on a Command Line Interface (CLI). There are significant disadvantages associated with the binary file approach:

• The configuration data must be edited with a hex editor. This is very time-consuming, error-prone and can no longer be expected of today's users.

There are significant disadvantages associated with the line-oriented approach of ACL files:

• The ACL files also quickly become very large and confusing.

• Except for simple text editors, there is no support for creating ACL files. • The tree structures typical for managed objects cannot be represented with the ACL format.

So far, the two problems mentioned have been dealt with using completely different approaches. It has therefore not been possible to reuse methods and tools between the two problem classes.

The object of the invention is to enable a configuration of transmission devices (air interface transmission devices such as NODE-B) of a cellular mobile radio network to be carried out efficiently and as ergonomically as possible. The object is achieved in each case by the subject matter of the independent claims.

The use of XML for the specification of

Information models and configuration databases fundamentally break with the usual procedures and methods of Telecommunications in the past decades. The use of

XML-based configuration databases enable very efficient configuration management. The representation in XML is relatively clear. In addition, XML documents can be configured relatively easily in the

Transmission device NODE-B C ++ code to be executed (or another program code) are implemented. Furthermore, creating documentation is relatively easy

(Documentation in e.g. Winword etc.) possible from a configuration defined in XML. One advantage of XML is that it is comfortable for XML, some of which are freely available

Editors there.

According to the invention, a database is used for the configuration, which is also referred to below as nbdatabase.

The nbdatabase is transferred from the OMC to the NodeB base stations using a file transfer protocol (FTP). There is a special nbDatabase for each NodeB type, which contains a so-called "containment tree", which describes the instances of the Managed Objects (MOI) in a tree structure. In addition, the nbdatabase allows persistent storage of a specific configuration of a NodeB type.

Further features and advantages of the invention result from the subclaims and the following description of an exemplary embodiment with reference to the drawing. It shows:

Fig. 1 shows schematically the communication between one

Operation and maintenance device OMC and a transmission device to be configured NODE-B, 2 schematically shows a configuration according to the invention of a transmission device NODE-B of a -

Operation and maintenance facility OMC at

Use of an XML-based database for transmission devices of the type NODE-B type XYZ

(Database NB-Database),

3 from an XML-based configuration database for transmission devices of a type that can be generated information on a GDMO-ASN.1 basis, on a C ++ code basis in NODE-B and as documentation,

4 schematically shows an overview of the interfaces between operating and maintenance devices OMC / LMT and a NODE-B,

5 an example of a name tree (“namingtree”) in XML,

6 shows an example of a “containment tree” of a configuration database for a type of transmission device,

7 an example of a “header file” of a transmission device (NODE-B),

8 shows an example of a “DTD file”

Configuration database (NB database),

FIG. 9 shows an “nbatabase” file of a configuration database, FIG. 10 shows a log file in ASCII format

Fig. 1 shows schematically an operating and

Maintenance facility (OMC = Operation and maintenance center or LMT = local maintenance terminal) 1 with a graphical user interface (GUI) or Command line interface (CLI) designed surface 2 for an operator of a (known, not shown here) cellular mobile radio network, which uses only schematically indicated transport layers (transport layer) 3 and using a known Corba

Protocol 4 for remote procedure calls with an air interface transmission device (NODE-B etc.) 5 of a mobile radio network for its (5) configuration,

Monitoring, maintenance, control, etc. communicated. Here, the logical interface between the OMC 1 and the

Transmission device 5 uses an information model in which the semantics of remote calls (which classes and instances of managed objects can be called and which operations and which attributes are possible) are defined. The entirety of all objects that can be controlled in NODE-B is referred to as the Management Information Base MIB and implements the possibility of creating and removing certain object instances in the operating and maintenance facility (NODE-B) from an operating and maintenance center OMC via remote maintenance,

Set or query attributes of the objects and trigger certain actions.

To understand the technical problem, it is important to differentiate the transport layers and protocols on the one hand from the information model as the logical interface on the other. An OMC and a NodeB communicate using a CORBA protocol in the sense of remote procedure calls. The information model describes the semantics of remote calls, ie which classes and instances of Managed Objects (MO) with which operations and which attributes can be called. The information model defines a name tree of

Managed objects for different types of NodeB

Base stations. The illustration of the information model in

Software for NodeB base stations is implemented in such a way that the interface for O&M is independent of the specific one

NodeB type and only one software package has to be kept.

The static framework of an information model with the description of the Managed Object Classes (MOC) and their

Attributes are configured during commissioning and also during the runtime of a base station of a certain NodeB type by instantiating managed objects and assigning values to attributes.

The instantiation or configuration can be implemented via individual, sequential commands of the above-mentioned CORBA interface or the configuration information is summarized in a file or database, transmitted and evaluated by the base station NodeB.

According to the invention, a database is used for the configuration, which is also referred to below as nbdatabase. The nbdatabase is transferred from the OMC to the NodeB base stations using a file transfer protocol (FTP).

FIG. 2 shows an operating and maintenance device 1 according to the invention, which uses a stored configuration database “nbdatabase” 6 according to the invention for configuring a transmission device 5 of a certain type (here a certain type of NODE-B with the type NODE-B type XYZ), a NODE-B to configure this type XYZ or to trigger actions there or to monitor it or to create or remove object instances in NODE-B or to set or query attributes of objects. A transfer protocol (file transfer protocol = FTP) is used to transfer a configuration database nbdatabase 6 from an operating and maintenance facility (OMC or alternatively LMT) to a transfer facility NODE-B 5 of type XYZ. The transport layer 3 can be formed in a conventional manner. The configuration database (6) specifies the configuration of a type of transmission device (NODE-B type XYZ 5) of the air interface of the mobile radio network XML-based, that is to say through data and structures in XML such as DTD tags etc.

There is a special nbDatabase for each NodeB type, which contains a so-called "containment tree", which describes the instances of the Managed Objects (MOI) in a tree structure. In addition, the nbdatabase allows persistent storage of a specific configuration of a NodeB type.

Problems a) and b) described at the outset are solved by using the "eXtensible Markup Language" (XML).

The XML language is related to the markup languages SGML and HTML. The basic idea of all markup languages is to add information with the so-called "tags". The tags carry information that, for example, represents a document in special formatting (SGML) or presents it as a web page (HTML). In contrast to SGML and HTML has been the XML language from the start as a very simple though extensible language has been defined. XML allows -im

In contrast to HTML and SGML, not only the use of predefined tags for graphic display, but tags can also be defined in a so-called document type definition (DTD) and thus carry any semantic information.

XML supports the storage of information in tree structures particularly well. Relationships of a tree structure (as descriptive: father-child or root-leaf) are typical both for the static structures of managed object classes and attributes in the information model and for the configuration information to be interpreted dynamically at runtime in the nbdatabase.

Due to the flexibility of XML, an information model in a GDMO-like form can be specified for the problem mentioned at the beginning. A great advantage over a pure GDMO solution is, however, that information can also be inserted using tags that go beyond the description of the logical interface between OMC and NodeB. For example, the DTD can be used to define tags that are used to automatically generate C ++ code in NodeB, that specify the persistence of certain attributes, or that are used to automatically convert the XML information into

Text files such as Allow Microsoft WinWord files for (customer) documentation.

This also shows another advantage of an XML-based information model:

There is only one source defined in XML from which various other formats are derived by automatic generation. This advantage is particularly evident in one Long product life typical for network elements is important: Changes due to new types, new versions or releases only have to be entered at one point; expensive transmission errors are avoided from the outset.

FIG. 3 shows that from a configuration database according to the invention with an XML-based information model in XML from the files Infomodell .xml and Infomodell .dtd (reference symbol 8), a wide variety of others for the configuration or documentation or control of

Files that can be used for transmission devices can be generated simply and efficiently, such as naming trees in GDMO / ASM.l for an operating and maintenance device OMC / LMT, C ++ code (10) to be executed in a transmission device NODE-B, and documentation (for example customer documentation) ) 11 for example in MS Winword.

Similar to the information model, a definition of a configuration file or database in XML also offers a solution to the problem b) mentioned at the beginning.

The concrete instantiation of Managed Object Instances (MOI) and the assignment of their attributes with certain values can also be represented very well by the tree structure of XML files. In contrast to the XML-based information model, the information stored in the configuration database is not translated into C ++ code, but read in and evaluated by a parser at runtime. It is a great advantage that XML is very widespread and that third-party software can also be used, for example, to parse the XML files. The concrete implementation of a configuration database can consist of one XML file or of several XML files. Alternatively, the database can be divided into different, domain-specific parts. Different specialists, for example for domains such as equipment or transport management, can be independently controlled

Bring in configurations that are only later combined into a common database.

In the specific embodiment in the figures

Database as a whole downloaded by file transfer from OMC to NodeB. This database is then only read in and evaluated for starting up or for completely changing the configuration. However, it is also conceivable that individual commands from the OMC to the NodeB are not transported as CORBA messages, but are sent as XML-formatted text messages. From this it also becomes clear that the same approach to problems a) and b) leads to interesting synergies.

Further advantages for both problem solutions result from the widespread use of XML. There are now a large number of editors that not only support the entry of XML texts, but also make the tree structure visible and allow the validation of an XML document.

In addition to the editors, there are also software libraries (SAX, DOM parsers, etc.), some of which are free of charge, that can be easily integrated into your own programs. These libraries are often part of development tools that, in addition to their own software, also offer tools with standardized interfaces and can be expanded as required. Almost all current programming languages also offer interfaces for the use of XML, so that dedicated solutions can be created relatively easily.

Since products are created for the world market today, file formats should also enable the use of non-Western characters. XML has the great advantage that it is based on the Unicode standard and can therefore process practically all important character sets in the world.

A fundamental feature of the invention is the novel use of principles of data or document processing in the field of telecommunications and in particular in problem areas of network management.

The use of XML for the specification of information models and configuration databases breaks radically with established procedures and methods of telecommunications, which have been in use for decades

Standardization bodies have been developed, but are often too complex for specific applications.

A basic insight of the invention is that both the information contained in the information model and in the configuration database are based on tree structures which can be optimally specified using XML.

Another fundamental principle is the balance between the use of standard to customized

Solutions: The extensibility of XML allows in principle a precise focus on the problem with the information model and the configuration database and still enables the use of a variety of "off-the-shelf" XML editors, generators and parsers etc.

In the specific exemplary embodiment, parts of the NodeB C ++ code are generated from the information model specified in XML. In principle, however, images of the XML information in any language are conceivable.

The nbdatabase is configured by operators at the OMC or by maintenance personnel using a Local Maintenance Terminal (LMT) and loaded onto a specific NodeB. There are ready-made databases for certain NödeB types, which then only have to be assigned specific values.

The invention is used in the so-called Radio Access Network (RAN) for UMTS mobile radio. There is an Itf-B interface (shown in FIG. 4) for operation and maintenance between the management system OMC (also called RadioCommander) and base stations called NodeB.

Fig. 4 shows interfaces between an NMC (National Maintenance Center = national operating and maintenance center) and an operating and maintenance facility OMC, between the operating and maintenance facility OMC (via an RNC) and a transmission facility (NODE-B) and between one Operating and maintenance facility in the form of a mobile usable LMT (local maintenance terminal) and a transmission facility NODE-B. FIG. 5 shows an example of a namingtree that can be used for several types of NODE-B transmission devices. 6 shows an example of a “containment tree” of a stored configuration database.

FIG. 7 shows an example of an “nbdatebase-header-file” of a configuration database. FIG. 8 shows an example of a “DTD” file of a configuration database (NB databäse).

9 shows an example of an “nbdatabase file” (a configuration database).

10 shows an example of a log file which, during the maintenance of a transmission device (NODE-B etc) by an operating and maintenance device (OMC etc.), specifies further data on an error (CPU failure of basebendcard) in ASCII format.

BESTATIGUNGSKOPIE

Claims

claims

1. Operation and maintenance device (OMC 1 / LMT 12) for a cellular mobile radio network with at least one memory with a stored configuration database (6), which (6) the configuration of a type of transmission devices (NODE-B-type-XYZ 5) Air interface of the cellular network indicates XML-based.

2. Operating and maintenance device according to claim 1, characterized in that the XML-based structure contains XML-DTD definition (XML-DTD tags) for the configuration of properties of a type of transmission device.

3. Operation and maintenance device according to one of the preceding claims, characterized in that the XML-based structure contains XML-DTD definitions (XML-DTD tags), which the automatic generation of program code (C ++ - code 10) in a transmission device (5) can initiate.

4. Operating and maintenance device according to one of the preceding claims, characterized in that the XML-based structure contains XML-DTD definition (XML-DTD tags), which the automatic conversion of XML-based structure information (8) into customer Documentation (11) can cause.

5. Operation and maintenance device (1) according to one of the preceding claims, characterized in that in the i

Configuration database (nbdatabase 6) information is stored (FIG. 5), in particular information relating to managed object classes and attributes

Properties of a type (Fig.2, NODE-B type XYZ) of

Transmission facilities (5).

6. Operating and maintenance device (1) according to one of the preceding claims, characterized in that the operating and maintenance device (OMC / LMI) has an interface for transmitting a configuration database (nbdatabase / NODE-B type XYZ) to a transmission device (5) with a file transfer protocol (FTP).

7. Method of configuring a transmission facility

(NODE-B 5) of a cellular mobile radio network from an operating and monitoring device (OMC 1 / LMT 12), an XML-based configuration database (NB database) representing at least the configuration of the type (NODE-B type XYZ) of this transmission device for NODE-B type XYZ) from the operating and

Monitoring device (OMC 1 / LMT 12) is sent to the transmission device (NODE-B 5).

8. The method according to claim 7, characterized in that several parts of one

Configuration database (NB database for NODE-B type XYZ) for various aspects of a telecommunications network are provided.

9. The method according to any one of claims 7 or 8, characterized in that a configuration database (6), which relates to several different transmission device types (NODE-B type XYZ and others) on a transmission device (NODE-B 5) from the operating and maintenance device (1) is downloaded.

10.The method according to any one of claims 7-9, characterized in that after downloading a

Configuration database (6) to a

Transmission device (NODE-B 5) this

Configuration database (6) for starting up the transmission device (5) and / or for changing the

Configuration of the transmission device (5) in the

Transmission device (5) is read in and evaluated.

11. The method according to any one of claims 7-10, characterized in that at least one command is sent from an operating and maintenance device (OMC 1 / LMT 12) to a transmission device (NODE-B 5) indicating this (5), what it should do using the configuration database (6) already available to it, in particular whether it should boot up or change its configuration.

12. The method according to claim 11, characterized in that the command in XML formulated is sent.

13.The method according to any one of claims 8-12, characterized in that the XML-based structure of the configuration database uses definitions of properties of a type of transmission devices executed as XM1-DTD.

14. The method according to any one of claims 8-13, characterized in that the XML-based structure contains XML-DTD definitions which cause the automatic generation of program code in a transmission device (5).

15. The method according to any one of claims 8-14, characterized in that the XML-based structure contains XML-DTD definitions, which cause the automatic conversion of XML-based structure information in documentation.

16. The method according to any one of claims 8-15, characterized in that in one

Configuration database information is stored in tree structures, in particular information about managed object classes and attributes relating to properties of a type of transmission equipment (NODE-B type XYZ).

17.The method according to any one of claims 8-16, characterized in that the transmission of the

Configuration database (6) from an operating and maintenance facility (OMC 1) to one Transfer device (NODE-B 5) with a file transfer protocol (FTP 7).

18. The method according to any one of claims 8-17, characterized in that a managed object of a configuration database (6) formulated in XML relates to a hardware element or a functionality in the transmission device (5).