CH686540A5 - Control and/or management system for network elements - Google Patents

Abstract

The system has the network elements (NE3) represented by objects entered in an object data bank (MO), with command displays (OIND) provided by an operating system (OS1,...OS3) processed by an object management device (OM) and the objects associated with the command displays activated for development of the commands. The condition variations for the network elements are indicated by condition variation displays (TIND) supplied to the object management device, for activation of the corresponding objects for matching to the momentary condition and forwarding of a command response to the operating system.

Description

5

10th

15

20th

25th

30th

35

40

45

50

55

60

65

CH 686 540 A5

description

The present invention relates to a method according to the preamble of claim 1 and an application thereof.

The management and control of networked systems, such as telecommunications systems, is becoming increasingly difficult in view of the increasingly complex systems. At the same time, the requirements for uniform and simple operation and maintenance are increasing, especially when different subsystems are to be operated by different manufacturers at the same time.

In telecommunications technology, a recommendation M.30 (CCITT Blue Book, Volume IV - Fasciole IV.1, IX, h Plenary Assembly, Geneva 1989) or Recommendation M.3010 (draft). This recommendation presents the general principles for planning, working and maintaining a TMN. A TMN has the basic task of managing individual network elements of a telecommunications system, such as a PDH (Plesiochronous Digital Hierachy) -, an SDH (Synchronous Digital Hierachy) - or an ATM (Asynchronous Transfer Mode) equipment. There are various administrative functions available in so-called operating systems (OS), in which, for example, network configurations, troubleshooting, quality tests in the individual network elements, cost calculations and access authorization definitions are carried out. Furthermore, various interfaces are described which are used on the one hand for communication between the individual operations control systems, and on the other hand for communication between the network elements and the operations control systems. For monitoring and for direct input of commands to the TMN, a user has a workstation available which, for example, consists of a screen alone, a small computer consisting of a keyboard and screen or a terminal connected to a mainframe.

The actual concept of a TMN is thus a defined network structure in which various operational control systems containing the administrative functions are linked to network elements of a telecommunication system through standardized protocols and interfaces. The interface provided between an operations control system and a network element is referred to as the Q3 interface and is defined in the CCITT recommendations of the X.700 series and in G.773. The information contained in the definition for the Q3 interface should preferably be implemented for all network elements of the telecommunications system. However, since the network elements and their functions and control options differ fundamentally not only due to the different forms of implementation of the manufacturers, but also because of the different tasks to be performed, each interface must, in addition to the more general requirements of the CCITT recommendation, also the specific ones specified by the network element meet specific requirements. Because of the diversity of the existing network elements and the large number of control functions available for each network element, an enormous effort has to be accepted when realizing a TMN and its interfaces. In particular, in the case of an interface implemented by means of telegrams, in which a telegram is generated for each function to be carried out in the network element or in the control system, the number of these telegrams required for communication becomes so great that the functioning of the interface becomes confusing and thus prone to errors.

The present invention is therefore based on the object of specifying a versatile method for simple control and administration of different network elements.

This object is achieved by the measures specified in the characterizing part of patent claim 1. Advantageous embodiments of the invention and an application are specified in further claims.

Based on the Q3 interface between an operational control system of a TMN and a network element of a telecommunication system described in the CCITT recommendations of the X.700 series and in G.773, an information model for a network element to be controlled is specified. This information model specifies the means and the way in which an operator can control the telecommunications system or the network element concerned via the TMN. Components of a network element are represented by objects via which the corresponding components are controlled by the operations control system and via which changes in the status of components of a network element are also displayed to the operations control system. The processing of command displays used for the control and for the status change displays emanating from a component takes place in a central object management unit, in which only the active objects referenced in the command display are present. The remaining objects are stored and managed separately in a so-called object database by the object management unit. A functional separation similar to that between the object database and the object management unit also exists between the remaining processing units - such as a selection unit, a log buffer and an interface unit. The separation of procedure2

5

10th

15

20th

25th

30th

35

40

45

50

55

60

65

CH 686 540 A5

steps, in particular the independence of the object management unit from the object database and the remaining units, makes it possible to use the object management unit in different applications. When changing applications, the object management unit does not have to be changed, but only the information stored in the objects in the object database. This basic structure of a Q3 interface can be used with all network elements used in a telecommunication system. Thus, the Q3 interfaces connected to the various network elements differ only in the content of the information stored in the object database and in the interface unit specific for the connected network element. The result is a universal solution for managing network elements, which can be applied to new or different specifications with minimal effort. In addition to managing network elements of a PDH (plesiochronous digital hierarchy) or an SDH (synchronous digital hierarchy) system, the method according to the invention can also be used as an ATM (asynchronous transfer mode) administrator or as an administrator of an entire telecommunications center will.

The invention is explained in more detail below with reference to drawings, for example. It shows

1 shows a basic structure of a telecommunications management network with a telecommunications system to be managed,

2 shows a schematic representation of possible illustrations of network elements on objects and vice versa,

3 shows a basic structure of a Q3 interface in which the method according to the invention runs,

4 shows a message sequence that takes place during an object creation on the basis of a sequence diagram,

5 shows a message sequence which takes place when an object is deleted on the basis of a sequence diagram and

6 shows a message sequence during the execution of a GET operation on an existing object using a sequence diagram.

1 shows a telecommunication system TCN managed by a telecommunication management network TMN, consisting of at least two end stations TT 1 and TT2 and different network elements NE1 to NEi. The network elements NE1 to NEi can be any devices such as transmission systems, coupling systems, multiplexers or signaling systems. For administration - i.e. for configuration, error determination, cost calculation, quality assessment, etc. - the telecommunication system TCN uses the telecommunication management network TMN connected to the network elements NE1 to NEi via Q3 interfaces, which consists of operating systems OS1 to OSn, workstations WS1 to WSk and a data network DCN. The data network DCN is intended for the transport of data between individual functional blocks and is therefore connected to the network elements NE1 to NEi, the workstations WS1 to WSk and the control systems OS1 to OSn. The actual management functions of the telecommunication management system TMN run in the operating control systems OS1 to OSn, and these can be monitored and triggered by users at the workstations WS1 to WSk, which for example consist of a terminal and / or a PC (personal computer).

The network elements NE1 to NEi are assigned both to the telecommunications management network TMN and to the telecommunications system TCN as shown in FIG. 1. This results from the fact that no clear dividing line can be drawn between the respective system parts. However, an adapter Q3A belonging to the network element NE3, in which the method according to the invention runs, can be viewed fully as belonging to the telecommunication system TCN. The adapter Q3A adapts the interface specific for a specific network element NE3 to the Q3 interface prescribed in a telecommunications management network TMN.

2, the dividing line indicated in the last section between the telecommunication management network TMN and the telecommunication system TCN (FIG. 1) is further explained. Components K1 to Kn of a network element NE are assigned to a number of objects 01 to Ok in various figures P1 to Pe. The illustrations P1 to Pe arise from the methods to be applied to the objects 01 to Ok or from the methods to the components K1 to Kn, a command being sent from an operating control system OS to a component K1 to Kn via the corresponding object 01 to Ok . In the same way, messages about the status of a component K1 to Kn of the network element NE are transmitted to the corresponding operations control system OS via the objects 01 to Ok concerned. From the operating control system OS, the individual components K1 to Kn can thus only be controlled indirectly via objects 01 to Ok. Direct access to one or more components K1 to Kn from an operating control system OS is not possible.

The illustrations P1 to Pe of components K1 to Kn on objects Ol to Ok and vice versa can be divided into different illustration categories. Each figure category is explained below using one of the figures P1 to P4:

3rd

5

10th

15

20th

25th

30th

35

40

45

50

55

60

65

CH 686 540 A5

In the figure P1, the object 01 represents exactly one component K1 of the network element NE. An object 01, for example belonging to a class “equipment”, represents, for example, a component K1 of a network element NE referred to as an assembly.

In the figure P2, several objects 02 and 03 represent a component K2 of the network element NE. This constellation is possible, for example, for a module with several VC12 interfaces (CCITT recommendation G.708): There is an object for each VC12 interface, even though all VC12 interfaces are on the same module.

Figure P3 covers two cases: In the first, an existing component K3 is not represented by an object. This applies, for example, to a subrack. In the second case, an object 04 does not represent a component of the network element NE. An example used here is an object used to initialize the Q3 interface.

In the illustration P4, several components K4 and K5 are represented by an object 05, as can be the case, for example, with a VC4 interface (CCITT recommendation G.708), which was distributed over several modules during its hardware implementation. The VC4 interface parts on the various modules referred to as components K4 and K5 are represented by object 05 alone.

Objects 01 to Ok with the corresponding methods to be applied to them and figures P1 to Pe together form the information model already mentioned, which is defined, for example, in ASN.1 syntax (CCITT recommendation X.208). The information model described in this way contains all functions of a network element NE that can be controlled from the operating control system OS in a compact form. The following is a section of a definition module containing the «equipment» object:

4th

5

10th

15

20th

25th

30th

35

40

45

50

55

60

65

CH 686 540 A5

equipment

DERIVED FROM

CHARACTERIZED BY

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

attributeValueChange, equipmentAlarm, objectCreation, objectDeletion, stateChange; ACTIONS

MANAGED OBJECT CLASS top equipmentPackage PACKAGE equipmentBehaviour;

G ET,

GET,

GET-REPLACE,

GET,

GET,

GET,

GET,

GET,

GET REPLACE

ADD REMOVE,

GET,

GET,

GET-REPLACE,

GET,

GET REPLACE. GET-REPLACE;

REGISTERED AS

{nkueMObjectClass 6};

equipment

BEHAVIOUR DEFINED AS

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

5

5

10th

15

20th

25th

30th

35

40

45

50

55

60

CH 686 540 A5

In addition to the data records stored under the keyword ATTRIBUTES, in which information about the module is stored, the corresponding functions that can be carried out by an operating system OS on the data record or on the object are specified. For example, the OS control system can only read the "alarmStatus", i.e. it can only fetch it using Operation GET. In contrast, the freely definable data record «userLabel» can be read (GET) and also changed (REPLACE) by the OS control system. How the individual data records are defined is not specified here. Special definition modules are provided for the definition of data records, in which the ASN.1 syntax is also used.

The NOTIFICATION keyword lists all messages that can be spontaneously sent by the object of the “equipment” class to the OS control system. For example, the "attributeValueChange" message is issued when the value of certain data records changes. In the same way, an «equipmentAlarm» message is issued in the event of an alarm if the object or the corresponding component (e.g. a module) is malfunctioning. As a further example, the messages "objectCreation" and "objectDeletion" are given, which are sent when an object is created (ie instantiated) or deleted during operation, for example, when a module is inserted or removed from the system corresponds to the subrack.

Functions which can be triggered by the operating control systems OS1 to OSn (FIG. 1) are listed under the keyword ACTIONS. No such functions are provided for the “equipment” object, which is why the corresponding position is empty.

With the registration of the object - initiated by the keyword REGISTERED AS - each object is clearly identified. This allows the operating control system OS to determine the functionality of the connected components K1 to Kn (FIG. 2).

Finally, the behavior of the object is described in detail in a text under the definition part introduced by the keywords BEHAVIOR DEFINED AS. In contrast to the formal parts initiated by the keywords ATTRIBUTES, NOTIFICATION, ACTIONS and REGISTERED AS, which are machine-readable, the description given under the keyword BEHAVIOUR DEFINED AS cannot be automatically converted into machine-executable form.

FIG. 3 shows the functional blocks of the Q3 interface with the operating control systems OS1 to OSn of the telecommunications management network TMN (FIG. 1) which are adjacent to them and the network element NE3 belonging to the telecommunications system TCN (FIG. 1). In this case, a command display OIND originating from an operating control system OS1 to OSn is transferred via a protocol buffer PS and a selection unit SMASE to a command processing unit CP located in an object management unit OM. In addition to the command processing unit CP, an object initialization unit O1, a message management unit ND and various information trees RT, IT, NBT and OIT are present in the object management unit OM. On the side of the telecommunications system TCN (FIG. 1), the object management unit OM communicates with the network element NE3 by means of status change indicators TIND and instructions TRESP via an interface unit TKI. Furthermore, the objects 01 to Ok (FIG. 2) are stored in an object database MO, which is accessed directly by the object management unit OM or by the command processing unit CP.

The object management unit OM is not only the central part because of its location between the telecommunication management network TMN (FIG. 1), the network element NE3 and the object database MO, but in particular is also the executing part in the adapter Q3A (FIG. 1). All command displays OIND and status change displays TIND are interpreted in this object management unit OM and all instructions TRESP and command responses ORESP to the control systems OS1 to OSn and to the network element NE3 are created. All requests of an operating control system OS1 to OSn to change data records under the keyword ATTRIBUTES or to execute a command under the keyword ACTIONS in the above-mentioned definition module are interpreted and executed by the object management unit OM. The various information trees RT, IT, NBT and OIT defined in the CCITT recommendations of the X.700 series are used to check the correctness of the commands to be applied to objects 01 to Ok.

The protocol buffer PS and selection unit SMASE, which are located between the operating control systems OS1 to OSn and the object management unit OM, are generally known from the CCITT recommendations X.710 and X.711 and therefore do not need to be explained further here. As is known, the interface unit TKI located between the network element NE3 and the object management unit OM can also be assumed, since it performs a function similar to that of the protocol buffer PS and also depends heavily on the network element NE3 to be controlled.

The object initialization unit OL is essentially responsible for creating and deleting objects 01 to Ok to be managed (FIG. 2) and for managing the information trees RT and NBT. A request comes from the command processing unit CP. If the request relates to the creation of an object 01 to Ok (FIG. 2), then a unique identification of the new object must be generated and sent back to the command processing unit CP, provided that

6

5

10th

15

20th

25th

30th

35

40

45

50

55

60

65

CH 686 540 A5

with the request a clear identification has not already been transmitted to the object initialization unit O1. The creation of a new object is finally confirmed by the notification management unit ND. If the request concerns deletion of one of the objects 01 to Ok (FIG. 2), the object concerned is deleted if it is found and if the deletion is permitted according to the information in the information tree OIT. The deletion of an object in the object database is in turn confirmed by the notification management unit ND, in which all notifications are checked. Further explanations are given in connection with information on FIGS. 4 to 6.

The command processing unit CP is used in particular for the communication with the managed objects 01 to Ok (FIG. 2) in the object database MO by the command displays OIND received from one of the operating control systems OS1 to OSn or the status change displays TIND received from the network element NE3 to the objects concerned 01 to Ok (Fig. 2) can be distributed. An affected object 01 to Ok can be active or passive: Active in this context means that an object 01 to Ok is already being used in another process. Passive therefore means that an object 01 to Ok is currently not required in any other process and is stored in the object database MO. The methods permitted according to the information in the respective definition module are applied to the activated objects in accordance with the OIND command displays or the TIND status change displays. After executing a method, the objects that are no longer required in any other process are put into the passive state by deactivation. Basically, only one activation method can be applied to a passive object.

4 to 6, various message sequences running in the object management unit OM are shown on the basis of sequence diagrams, only the units affected by messages being indicated.

FIG. 4 describes the message sequence of a command display OIND originating from an operating control system OS, which contains the command for creating a new object. The units involved in the creation of objects, such as the message management unit ND, the object initialization unit O1, the command processing unit CP and the respectively activated object AO, are specified in the sequence diagram, with one of the network elements NE1 to NEi being used instead of the operating control system OS (FIG. 1 ) can issue a corresponding display, namely a status change display TIND (FIG. 3), for creating a new object.

If the control system OS receives a command display OIND required to create an object 01 to Ok (FIG. 2) in the command processing unit CP, a creation request CRQ is sent to the object initialization unit O1. If there is still no clear identification for the object to be created, if a new object can be created, it is created in the object initialization unit OL and transmitted to the command processing unit CP in a creation response CRP. The command processing unit CP then creates a new, active object AO in the local memory of the object management unit OM (FIG. 3) and carries out a corresponding initialization by means of the object creation message CMO, which is correspondingly confirmed by the object AO by means of a creation response RMO. At the same time, the message management unit ND is informed of the successful creation of the new object AO by means of a message N, the arrival of which at the outgoing point is confirmed with the message NC. The calling operating control system OS is also reconfirmed by means of the ORESP command response also shown in FIG. 3. Finally, the new object AO is deactivated by a deactivation command DEAC by the command processing unit CP and stored in the object database MO (FIG. 3). The deactivation command DEAC issued by the command processing unit CP can also be omitted if the object AO is automatically deactivated after the ORESP command response has been sent.

Since all objects are controlled by the command processing unit CP, all messages from one object AO to other units are also sent via the command processing unit CP. This is illustrated in FIGS. 4 to 6 by a message interruption in the command processing unit CP, such as, for example, the message N triggered by the object AO and sent to the message management unit ND.

5, a message sequence for deleting one of the objects 01 to Ok (FIG. 2) in the object database MO (FIG. 3) is explained. If a command display OIND required to delete one of the objects 01 to Ok (FIG. 2) is received in the command processing unit CP by the operating control system OS, a request DRQ1 is made by the command processing unit CP to the object initialization unit Ol, in which it is checked whether more of the There are dependent objects to be deleted and whether these dependent objects should also be deleted. The result is returned to the command processing unit CP by means of a delete response DRSP. If the answer to the deletion of the object AO is positive, this passes on the original command display OIND to the object AO that is still to be activated. The notification management unit ND is informed with the message N before deleting the object AO. After receipt of a confirmation confirmation NC from the message management unit NC for the object AO, the object deletion is displayed to the operating control system OS sending the delete command by means of a response ORESP. Finally, the object deletion is communicated to the command processing unit CP with a last deletion display KRP starting from the object AO to be deleted, which sends a corresponding deletion display KRP to the

7

5

10th

15

20th

25th

30th

35

40

45

50

55

CH 686 540 A5

Object initialization unit passes on Ol. As already explained under FIG. 4, a deactivation command DEAC can also be omitted if the object AO has already been deactivated when the deletion indicator KRP has been issued.

6 shows a sequence diagram of a GET operation triggered by an operating control system OS, which is sent in a command display OIND to the command processing unit CP and is used to read a data record (attributes) of an object 01 to Ok (FIG. 3). The object AO affected by the GET operation is activated by an activation command ARQ from the command processing unit CP. A method required for reading the data record is then triggered in the object AO by sending a read request GRQ to the activated object AO. The ORESP command response is used to transmit the content of the read data record to the OS control system. Finally, the object AO is deactivated by the deactivation message DEAC issued by the command processing unit CP.

The examples given in FIGS. 4 to 6 can be applied analogously to the other operations, such as REPLACE, ADD, REMOVE, etc. Furthermore, the status change indications TIND or instructions TRESP (FIG. 3) transmitted between the command processing unit CP and the network element NE3 can also be specified analogously to the sequences shown in FIGS. 4 to 6.

Claims (11)

Claims 1. A method for controlling and / or managing network elements (NE1 NEi) by means of objects (01 Ok), at least one of which relates to at least one component (K1 Kn) of one or more network elements (NE1 NEi), characterized in that one of a Operating control system (OS, OS1, ..., OSn) outgoing command display (OIND) is processed in an object management unit (OM), whereby all objects affected by the command display (OIND) and stored in an object database (MO) are activated and activated contained in the command display (OIND) Commands are applied to the activated objects (Ol, .... Ok) and that with the command application on the objects (Ol, ..., Ok) corresponding instructions (TRESP) in the network elements (NE1, ..., NEi) be carried out if necessary. 2. The method according to claim 1, characterized in that status changes in network elements (NE1, ..., NEi) are reported by means of status change displays (TIND) to the object management unit (OM) in which all objects affected by the status changes (Ol Ok) are activated and be adapted to the current state and that the object management unit (OM) transmits these state changes in a command response (ORESP) to one or more operating control systems (OS, OS1, ..., OSn) if required. 3. The method according to claim 1 or 2, characterized in that the command displays (OIND) and the status change displays (TIND) are passed to at least one command processing unit (CP) contained in the object management unit (OM), that by the command display (OIND) and the status change display (TIND) affected objects (01 OK) already existing in the object database (MO) are activated by the command processing unit (CP), if they are not already in the active state, that in the command display (OIND) and in the status change display (TIND) commands that may be included trigger at least one method provided for an object (01, ..., Ok) that a command response (ORESP) to the operating system (OS, OS1 OSn) triggering the command display (OIND) or an instruction ( TRESP) is transmitted to the network element (NE1, ..., NEi) that triggers the status change indicator (TIND) and that the activated objects (01, ..., Ok) can then be deactivated. 4. The method according to claim 3, characterized in that a deletion and / or creation of an object (01 Ok) are also carried out in an object initialization unit (O1) also contained in the object management unit (OM), that the object initialization unit (O1) deletes or the creation of an object (01 OK) in at least one information tree (NBT, OIT, RT, IT) states that when creating a new object (01 Ok) an identification with Help of at least one information tree (NBT, OIT, RT, IT) is generated by the object initialization unit (Ol) and that this identification is recorded in at least one information tree (NBT, OIT, RT, IT) and transmitted to the command processing unit (CP). 5. The method according to claim 3 or 4, characterized in that all incoming and outgoing messages in the object management unit (OM) and internally exchanged in the object management unit (OM) are transmitted via a message management unit (ND). 6. The method according to claim 5, characterized in that notifications of objects (01 Ok) to the message management unit (ND) and vice versa via the command processing unit (CP). 7. The method according to any one of the preceding claims, characterized in that the command display (OIND) and / or the command response (ORESP) before processing in the object management unit (OM) in a protocol buffer (PS) and / or in a selection unit (SMASE) be preprocessed. 8. The method according to any one of the preceding claims, characterized in that the access 8th 5 10th 15 20th 25th 30th 35 40 45 50 55 60 65 CH 686 540 A5 Status change display (TIND) and / or the instruction (TRESP) are preprocessed in an interface unit (TKI) before processing in the object management unit (OM). 9. The method according to any one of the preceding claims, characterized in that the objects (01 Ok) are described using the ASN.1 syntax. 10. Application of the method according to claim 1 in an adapter (Q3A) for controlling and / or managing network elements (NE1, ..., NEi) of a telecommunications system (TCN). 11. Application of the method according to claim 10, characterized in that the telecommunications system (TCN) operates according to the asynchronous transfer mode. 9