KR20040034177A - Conversion adapter and method from non-standardized fault message to standardized fault message - Google Patents

Abstract

PURPOSE: A device for converting a non-standard failure message into a standard message and a conversion method therefor are provided to convert a failure message of a non-standardized network device into a single-standardized message, thereby reducing cost and efforts for developing the message conversion device. CONSTITUTION: An external network interface server(21) receives failure messages from non-standard network configuration factors. A failure message token separating server(22) and a failure message conversion server(23) convert the received non-standard failure messages into standard messages according to pre-agreed message protocols. A failure message basic protocol setup file manager(24) generates a message protocol for converting into standard failure messages by analyzing/converting description files, stores the generated message protocol, and supplies the message protocol at the request of the failure message token separating server(22) and the failure message conversion server(23).

Description

Conversion adapter and method from non-standardized fault message to standardized fault message}

The present invention relates to a message conversion device and a conversion method, and more particularly, to a message conversion device and a conversion method for converting a failure message of a non-standardized network device into a single standardized message form.

Recognition and processing of fault messages output from network devices including transmission equipment is one of the most basic functions in network operation or monitoring system construction.

However, due to the flooding of numerous device manufacturing suppliers, the failure messages are not unified at all, and even in the field of transport where standards such as the Telecommunication Management Network system (TMN) have long been established, Does not provide a fully standardized message format, and in many cases there are many differences. Even devices built by the same manufacturer don't have a uniform message.

In addition, when a communication service company that purchases devices is difficult to establish a network for effective use of standardized devices, for example, a router installed in a LAN network in which TMN devices can be accommodated does not support OSI 7 hierarchy. Even if a device that satisfies the standard specification is introduced, it will eventually be forced to monitor the failure by collecting an unfamiliar non-standard message.

In other words, in the field of transmission, the development of Q3 protocol standard message adapters has been actively conducted for the purpose of simply monitoring TMH network components that are not supported by TMN. However, the use of such adapters is limited to PDH networks. It can be said that the situation can be applied to almost all devices in reality.

Of course, other forms of network element interfaces, such as CORBA, have been proposed and implemented internationally, but in the end it is almost impossible to have a completely unified message protocol in the midst of a keen understanding among device manufacturing suppliers. This is especially important for fault monitoring of many devices already in use.

Therefore, the development of adapters for the conversion of non-standard messages to standard messages is still an important alternative to the telecommunications service company that purchases devices, and to use them as a smooth network management method when introducing new devices from leading domestic and overseas manufacturers. have.

1 to 3 are diagrams illustrating a structure of an adapter system for converting a nonstandard failure message output from a conventional nonstandard network component into a standardized form and delivering the same to a network component manager.

The adapter system in FIG. 1 includes a message conversion adapter 12 consisting of a standardized network component manager 11, a conversion result generation adapter 13, and a fault message conversion module 14, RS-232, RS-422, and LAN. It is composed of various types of non-standard network components 16, the network connection interface 15, and is the most visible form of the conventional message conversion adapter structure.

Non-standard messages output from each non-standard network component 16 are applied to the message conversion adapter 12 via the corresponding network connection interface 15, and the message conversion adapter 12 converts them into standardized messages, thereby standardizing the network. Converts it into a form of message that the Component Manager can recognize.

However, the adapter system of such a structure has an increasing number of newly introduced devices, and as the number of device types increases, the number of adapter system processes increases, resulting in considerable overhead. In addition, each time a new device is introduced, the adapter developer must continue to implement new conversion modules, which is very expensive and time-consuming.

FIG. 2 reconstructs the failure message conversion module 17 into one integrated form in the conversion adapter that existed for each non-standard network component in the adapter system of FIG. 1 and converts the conversion result generation adapters 13 into their respective independent processes. It is a structure separated by.

Unlike the adapter system of FIG. 1, the adapter system of FIG. 2 integrates the fault message translation module 17 into one to minimize the overhead caused by the message translation modules 14 and independently process the conversion procedure. The advantage of being able to scale up is the advantage, but the added cost of new developments and the increased process and overhead of adapters that generate conversion results remain a problem.

In order to minimize the execution of these processes, it is possible to have a process manager so that the execution and termination of the process can be automatically handled through appropriate procedures.However, as the number of adapters increases, additional modifications of the process manager must naturally be followed. Investing costs is inevitable.

3 is a structure of a message conversion adapter system proposed by a device manufacturing supplier in order to minimize the development cost in the above-described adapter system, by designing and adding a common interface 18 to the non-standard network components 16 and converting adapter 19 allows you to send and receive messages through the interface.

That is, the message conversion adapter 19 issues information requests or control commands to the non-standard network component 16 according to the protocol required by the common interface 18 and is installed directly on the non-standard network component 16. ) Converts such a procedure into a network component-specific message format and forwards it to the network component 16.

In addition, when the network component 16 outputs a fault message, the network component 16 converts the error message back into a form that can be understood by the message conversion adapter through a common interface, and finally delivers it to the standardized network component manager 11.

The advantage of such a system is that if the non-standard network component 16 adopts a common interface, the message conversion adapter used previously can be used as it is. Therefore, only the network connection with the common interface 18 is appropriately handled by the communication service company. The cost and effort required for development is low.

However, it is not only difficult to induce a large number of competing device manufacturers to have all the common interfaces in common, but also to create problems that can arise when they are combined with internal and external interfaces designed by each manufacturer's unique technology. It is not so large that it can be practically applied.

In addition to the above-described adapter system, most conventional conversion adapters reduce the cost of conversion performance and usage period by presenting a system structure of a workstation or PC server equipped with a conversion adapter or an ROM-based adapter. It is primarily important, but does not consider scalability or ease of further development.

Accordingly, an object of the present invention for solving the above-mentioned problems is to easily accommodate a new device or an existing device that is additionally introduced, thereby reducing the cost and effort required in developing a message conversion adapter and efficiently integrating a network monitoring system. To build it.

1 to 3 are diagrams illustrating embodiments of a conventional adapter system for converting a non-standard failure message into a standardized form and delivering it to a network component manager.

4 is a block diagram showing the configuration of a message conversion apparatus according to the present invention.

5 is a flowchart illustrating a process of converting a non-standardized failure message into a standardized failure message by using the message conversion apparatus according to the present invention.

6 is a flow chart illustrating in more detail the operation of step 505 of FIG.

The message conversion device of the present invention for achieving the above object is an external network interface server for receiving non-standard failure messages from a plurality of non-standard network components, token separation of the received non-standard failure message according to the predetermined token separation protocol If the token separation is not possible, the failure message token separation server that performs the token separation of the failure message by requesting and providing a message protocol for token separation of the failure message from the failure message basic protocol configuration file manager. Converts the token-separated non-standard fault message into a standard fault message according to the contracted message conversion protocol. If the token-separated fault message cannot be converted, the fault message default protocol setting file manager converts the fault message. Message protocol request for token separation and message conversion for specific non-standard network components from failure message conversion server and failure message token separation server and failure message conversion server that request and receive message protocol for client to perform translation of corresponding failure message. It is provided with a failure message basic protocol configuration file manager that provides the corresponding message protocol upon receiving.

In the message conversion method of the present invention, the first step of receiving a non-standardized fault message together with information on the non-standard network element from the non-standard network element, converts the non-standard fault message from the non-standard network element into a standard fault message. In the second step of determining whether or not it is possible, if the message can be converted, the received fault message is converted according to a preset conversion method, and if the message cannot be converted, information about the received non-standard network component is transmitted to a predetermined external device. A third step of requesting a message protocol for converting a fault message of a non-standard network component; and a fourth step of converting a non-standardized fault message received from a non-standard network component into a standardized fault message by receiving a message protocol from an external device. It includes.

Prior to the description of the present invention, in order to convert the message according to the present invention, it is necessary to first understand the common requirements in the non-standard message.

No matter how specific the event itself is, even if it is a nonstandard message, the fault message output from all devices must have a common format that contains the minimum information required by the standard fault message, so that the fault output from each nonstandard network component You can map messages to fault messages required by standard network component managers.

As described above, the present invention needs to create a description file for mapping the message format required by the standard network component manager by analyzing a message block commonly applied to a failure message output from a non-standard network component.

In general, non-standard messages can exist in two main forms.

The first is a Byte-Oriented message, which consists of hexadecimal values and usually improves the performance of the EMS or Operational User Interface (GUI) supplied by the device manufacturer. This is an internal information message used for the purpose.

Since non-standard network components using byte-based messages support operation by activating multiple connection ports, data exchange is possible by connecting one of them to the message conversion adapter of the present invention.

For such byte-based messages, the important thing in message token separation is the pointer and size of the location where information such as the header and total length of the message, the message output board ID field, the message output component ID, the message type, and the serial number are located. It is specified.

When reconstructing a byte-based message into a description language, it can be expressed in the following format:

Set StarByte (PTR) 0

Set StarByte (LENGTH) 4

Set Length (PTR) 4

Set Length (LENGTH) 4

Set DestinationID (PTR) 12

Set DestinationID (LENGTH) 8

That is, since the pointer position of the start byte is 0 and the total length of the start byte is 4 bytes, the corresponding byte-based message can be accepted and the start byte length can be disconnected to determine whether the device is an input device type or an output device type. You can find the last point value of the data by measuring the length in binary data using the length pointer value and the length value.

The second is a text-based text message. Since text-based text messages such as TL / 1 are composed of plain text characters, they can be easily identified by the human eye and can be easily selected for simple operation. Currently supports message formats such as TL / 1.

In the case of a message such as TL / 1, the basic separator of each line includes "0x0D" and "OxOA", and the ";" between messages. Since there is a separator for notifying the end, such as the general form, the present invention creates a description file accordingly.

In addition, in case of alarm message, common data such as unit ID value, alarm occurrence location, alarm level, and alarm item will exist even if it is non-standard data. Therefore, it is necessary to specify this in the description language file.

For example, the unit ID value in charge of the message output can be defined in the following form. When the message output board ID is "0xO7" as the result of the message token analysis, the unit ID is designated as TP1U_2 and converted.

Set TABLE_PROC (DCU) 0x01

Set TABLE_PROC (MPU) 0x02

Set TABLE_PROC (TP1U_1) 0x06

Set TABLE_PROC (TP1U_2) 0x07

Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the accompanying drawings.

4 is a block diagram showing the configuration of a message conversion apparatus according to the present invention.

The message conversion device of the present invention largely separates a failure message token for converting a failure message token from an external network interface server 21 for receiving a failure message from non-standard network components into a standard message according to a predetermined message protocol. Analyzing / converting the server 22, the fault message conversion server 23, and the description file to generate and store a message protocol for conversion into a standard fault message, the fault message token separation server 22 and the fault message conversion server 23 It consists of a failure message basic protocol configuration file manager 24, which provides a message protocol upon request.

In more detail the function of these components,

The external network interface server 21 controls the communication between the message conversion device 20 and the respective non-standard network components 16 of the present invention, and each RS-232, RS-422, Connected to various network interfaces 15 such as X.25 and LAN, non-standardized fault messages from each non-standard network component 16 and basic information about the non-standard network component 16 (device type and device ID, etc.) ) Is sent.

The external network interface server 21 is connected to a plurality of non-standard network components 16 in one integrated type network connection module.

The failure message token separation server 22 connects with the external network interface server 21 to provide basic information including the device type and device ID for each non-standard network component 16 from the external network interface server 21 and the non-standardized information. Receives a fault message and separates tokens from non-standard fault messages using a message protocol stored in memory (not shown).

In this case, when a failure message token separation server 24 receives a nonstandard failure message that cannot be supported, the failure message basic protocol setting described below describes the device type and device ID of the corresponding nonstandard network component 16 using TCP / IP. The file manager 23 and the failure message conversion server 23 are transmitted. Then, the failure message basic protocol configuration file manager 23 requests a message protocol for token separation of the nonstandard failure message.

The failure message conversion server 23 receives a failure message separated in token form from the failure message token separation server 22 and converts the non-standard failure message into a standardized failure message according to a predetermined conversion protocol, thereby standardizing network components. Transfer to the manager (11).

At this time, the failure message conversion server 23 receives the device type and device ID of the specific non-standard network component 16 from the failure message token separation server 22 to the failure message basic protocol setting file manager 23 corresponding non-standard failure. Request a message protocol to convert a message into a standardized fault message.

Fault message The basic protocol setting file manager 24 reads the description file written by the operator using the protocol file analyzer 25 to check the grammar of whether the file is correctly written and to check the fault message of the non-standard network components 16. It checks whether the minimum necessary information for token separation and message conversion is included, and if there is no error, converts it to a certain data structure. Fault message The basic protocol setting file manager 24 generates the data converted by the protocol file analyzer 25 as a forwarding message having the device type and device ID of the corresponding non-standard network component 16 as a basic header and storing the data on the disk. And set the file protocol index for each forwarded message.

This file protocol index has a reference pointer as a file handler and forms a tube with the file protocol index, which forms the tube from the fault message token separation server 22 and the fault message translation server 23. This is a unique key used when requesting a message protocol.

Since the above-mentioned fault message conversion server 23, fault message token separation server 22, and fault message basic protocol setting file manager 24 are each operated by independent server processes, data transmission between them depends on the TCP / IP port connection. Proceed according to Message Pasing.

5 is a flowchart illustrating a process of converting a non-standardized failure message into a standardized failure message by using the message conversion apparatus according to the present invention.

Token Separation and Message Conversion for the operator having an understanding of non-standard network components 16 and document information document to convert non-standardized failure messages from non-standard network components 16 into standardized failure messages. Once the description file is created, the protocol file analyzer 25 of the failure message basic protocol configuration file manager 24 reads the description file (step 501).

The protocol file analyzer 25 checks that the description file contains a grammar check that the file was written correctly and contains the minimum necessary information for token separation and message conversion for fault messages from non-standard network components 16. (Step 502).

If it is confirmed that an incorrect or necessary information is not included, an error is generated. If no error is found, information for message conversion and token separation in the description file is converted into a certain data structure (step 503). ).

The failure message basic protocol setting file manager 24 reconstructs the data converted by the protocol file analyzer 25 into a forwarding message format using the device type and device ID of the corresponding non-standard network component 16 as a basic header, and writes the data to the disk. Save and set a file protocol index for each delivery message (step 504).

This file protocol index has a reference pointer as a file handler and the fault message basic protocol configuration file manager 24 forms a tube, which is a key used in the message protocol request with the file protocol index.

The failure message conversion server 23 and the failure message token separation server 22 respectively transmit a message protocol for message conversion and token separation generated in the failure message basic protocol configuration file manager 24 in step 504 through the TCP / IP port. It is stored in its own memory and then used to convert the nonstandard failure message from each nonstandard network component 16 into a standardized failure message (step 505).

That is, the failure message token separation server 22 generates a failure message along with its device type and device ID when the non-standard network components 16 have a problem, and configures the corresponding non-standard network through the external network interface server 21. Upon receiving the device type, device ID, and fault message of element 16, the token is separated from the fault message using a protocol for token separation previously stored in memory (not shown), and then transmitted to the fault message conversion server 23. do.

The failure message conversion server 23 converts a non-standard failure message in the form of a token received from the failure message token separation server 22 into a standardized failure message according to a message conversion protocol previously stored in a memory (not shown), and then standardized network. It is sent to the component manager 11 so that the operator can check it.

6 is a flowchart illustrating the operation of step 505 of FIG. 5 in more detail.

In the above-described process, a non-standard network component 16-1 that outputs a non-standard failure message not previously stored in the memory of the failure message token separation server 22 and the failure message conversion server 23 may be newly introduced and used.

As such, when the newly introduced device 16-1 among the non-standard network components transmits a failure message together with its device type and device ID through the external network interface server 21, the failure message token separation server ( 22) does not have a message protocol for the corresponding non-standard network component 16-1 in memory and thus no token separation.

Therefore, the failure message token separation server 22 checks whether the non-standard failure message received through the device type and device ID of the corresponding non-standard network component received through the external network interface server 21 is a message that it can support. (Step 601).

If support is available, the received nonstandard failure message is converted to a standard failure message by the process of step 505 described above (step 602).

However, if the received failure message is a non-standard failure message that cannot be supported, the failure message token separation server 22 is connected to the failure message conversion server 23 and the failure message basic protocol configuration file manager 24 to display the corresponding nonstandard network component 16. A message protocol that transmits the device type and device ID received from -1) and can support token separation from the failure message for the non-standard network component 16-1 to the failure message basic protocol configuration file manager 24. Request (step 603).

The failure message conversion server 23, which has received the device type and device ID for the specific non-standard network component 16-1 from the failure message token separation server 22, also sends the corresponding non-standard to the failure message basic protocol configuration file manager 24. Request a message protocol capable of converting a nonstandard failure message for network component 16-1 into a standard failure message.

The failure message basic protocol setting file manager 24, which has received the message protocol request from the failure message token separation server 22 and the failure message conversion server 23, compares the tube values and refers to the indexed file pointer to the corresponding device on the disk. Check if there is message protocol setting information for the type (step 604).

As a result of the check, if the message protocol exists in the disk, the message protocol is transmitted to the failure message token separation server 22 and the failure message conversion server 23, respectively (step 605).

The failure message token separation server 22 received the message protocol causes the external network interface server 21 to resume communication with the nonstandard network component 16-1, thereby reconnecting the nonstandard network component 16-1. When the fault message is received from the fault message, the token is separated from the fault message by using the message protocol additionally transmitted from the fault message basic protocol setting file manager 24 and transmitted to the fault message conversion server 23. The failure message conversion server 23 that receives the failure message in the form of a token also converts the non-standard failure message into a standard failure message using the message protocol received from the failure message basic protocol setting file manager 24, and then configures the standardized network. Send to element manager 11 (step 606).

When the message conversion is completed, the flow returns to step 505 to repeat the message conversion unless a separate instruction to stop the operation.

In step 604, if the failure message basic protocol configuration file manager 24 does not have a message protocol for the non-standard network component 16-1, the failure message token separation server 22 may not respond to the message protocol request. Notify and generate an error log after generating an error (step 607).

The failure message token separation server 22 then instructs the external network interface server 21 to terminate communication with the corresponding nonstandard network component 16-1.

If the message conversion device 20 operator analyzes the error log according to the occurrence of the error and then creates a description file for the non-standard network component 16-1 (step 608), the protocol file analyzer 25 performs the above-described steps. The non-standard failure message is converted into a standard message through the following process.

That is, when the failure message token separation server 22 receives the message protocol from the failure message basic protocol configuration file manager 24, communication with the nonstandard network component 16-1 resumes, and the nonstandard network component 16-1 is resumed. When a non-standard fault message is received, the token is separated and transmitted to the fault message conversion server 23 using the updated message protocol, and the fault message conversion server 23 is newly generated from the fault message basic protocol setting file manager 24. The received message protocol is used to convert nonstandard fault messages into standard fault messages.

In the above-described embodiment, the failure message conversion server 23 and the failure message token separation server 22 may request a corresponding message protocol from the failure message basic protocol setting file manager 24 for a failure message that cannot be supported. Although the information is provided, the failure message conversion server 23 and the failure message token separation server 22 may allow the failure message basic protocol setting file manager 24 to directly obtain necessary data without requesting data.

That is, in step 504, the failure message basic protocol setting file manager 24 reconstructs the data converted by the protocol file analyzer 25 into a union structure, generates and stores the header file, or stores the data. Source header files created in enum and fine form can be stored so that the fault message token separation server 22 and the fault message conversion server 23 can compile the data and obtain the necessary data. .

As described above, the message conversion device of the present invention can easily accommodate a new device or an existing device that is additionally introduced, thereby reducing the cost and effort required when developing a message conversion device and efficiently constructing an integrated network monitoring system. Can be.

Claims (15)

An external network interface server for receiving nonstandard failure messages from a plurality of nonstandard network components; Separating the received non-standard failure message according to the predetermined token separation protocol, and if token separation is not possible, request the message protocol for token separation of the failure message from the failure message basic protocol configuration file manager and receive the corresponding failure message. A failure message token separation server that performs token separation of messages; The failure message token separation server converts the non-standard failure message that is separated from the token into a standard failure message according to a predetermined message conversion protocol. A failure message conversion server that receives and receives a message protocol for conversion of the failure message and performs conversion of the failure message; And Non-standard having a failure message basic protocol configuration file manager that provides a corresponding message protocol upon receiving a message protocol request for token separation and message conversion for a particular non-standard network component from the failure message token separation server and the failure message conversion server Standard message translator for fault messages. The method of claim 1, The external network interface server is a standard message conversion apparatus for a non-standard failure message, characterized in that connected to the plurality of non-standard network components in one integrated network connection module. The method of claim 1, And said failure message conversion server, said failure message token separation server, and said failure message basic protocol configuration file manager communicate in a message passing manner according to a TCP / IP port connection. The method of claim 3, wherein The failure message token separation server may transmit a device type and a device ID of a corresponding non-standard network component to the failure message basic protocol setting file manager and the failure message conversion server when a failure message that cannot be separated is received. Standard message translator for messages. The method of claim 1, The failure message basic protocol configuration file manager reads a description file and converts the data into a transmission message having a device header and a device ID of each of the non-standard network components as a default header, and stores the data in a disk. Standard message conversion device for non-standard failure message, characterized in that for setting The method of claim 5, wherein The fault message basic protocol setting file manager reconfigures the converted data into a union structure and stores the header in the form of a header file. The method of claim 5, wherein The fault message basic protocol configuration file manager is a standard message conversion apparatus for a non-standard fault message, characterized in that for storing the converted data in the form of a source header file made in the form (enum) and fine (define). The method of claim 1, The fault message basic protocol configuration file manager outputs an error message when the requested message protocol is not stored. The method of claim 8, If the failure message token separation server does not have a message protocol requested by the failure message basic protocol configuration file manager, it transmits a signal to the external network interface server and disconnects communication with the corresponding nonstandard network component. Standard message translator for fault messages. Receiving a non-standardized fault message together with information about the non-standard network component from the non-standard network component; A second step of determining whether to convert a nonstandard failure message from the nonstandard network component into a standard failure message; If the message can be converted, the received fault message is converted according to a preset conversion method, and if the message cannot be converted, information on the received non-standard network component is transmitted to a predetermined external device to transmit a fault message of the non-standard network component. Requesting a message protocol for conversion; And And a fourth step of receiving a message protocol from the external device and converting the non-standardized failure message received from the non-standard network component into a standardized failure message. The method of claim 10, And the information on the nonstandard network component includes a device type and a device ID for the nonstandard network component. The method of claim 11, The second step is a standard message conversion method of the non-standard failure message, characterized in that it is determined whether the failure message conversion from the non-standard network component using the device type and the device ID of the non-standard network component. The method of claim 10, The fourth step is a standard message conversion method of a non-standard failure message, characterized in that to separate the token from the received non-standard failure message and convert the token-separated non-standard failure message into a standard message. The method of claim 10, If the message protocol requested from the external device is not received in the fourth step, the communication with the non-standard network component is lost and an error message is output. The method of claim 10, The standard message conversion method of the non-standard failure message, characterized in that the information transmission, message protocol request and reception for the non-standard network component is made in a message passing method according to the TCP / IP port access.