System and method therefor of translating a message having a given format for usage in an operations system

[0002] The present invention relates to message transmission in a telecommunications network and more particularly to the translation of a message having a given protocol to a counterpart message usable in a system operating under a different protocol.

[0003] A synchronous optical network (SONET) provides the flexibility needed to transport digital signals with different capacities in a telecommunications network. A SONET network also provides a standard from which different manufacturers can base the design of their equipment. Thus, a SONET optical interface standard allows the interworking of transmission products from multiple vendors, as it defines the physical interface, the optical line rates known as optical carrier (OC) signals, frame format and the OAM&P (operations, administration, maintenance, and provisioning) protocol. In order to develop a standards compliant operations system (OS) to manage a SONET network, a management information model based upon well known international telecommunications standards must be developed so that the network may be managed in a standards-based environment. However, at the present time there are limited standards-based interfaces, such as Q3 interfaces, to the vendor network elements (NEs). Accordingly, some “bridge-the-gap” solution has to be found to enable the newly developed OS to utilize existing communications language whose operating protocol is different from that of the OS.

[0004] To communicate with the network elements (NEs) of the SONET network in an environment of mixed management protocols, the operations system of the instant invention must be able to receive, transmit, and translate messages which operate under a different protocol than is used internally. To achieve this end, an access module is provided at the front end of the operations system to receive the messages incoming from the SONET network. The incoming messages are assumed to be Transaction Language 1 (TL1) messages, while the operations system utilizes internal messages that have a different protocol, in this instance a common management information protocol (CMIP), which is typically used to exchange information between two management stations.

[0005] To translate an incoming TL1 message into a message which is usable by the operations system, the TL1 access module (TL1 AM) provided at the front end of the operations system has a mapper/parser processing module that parses and maps autonomous and non-autonomous TL1 messages into respective equivalent interface alarms and events messages for use in the operations system. To perform the mapping and parsing, the mapper/parser module retrieves one of the data/mapping tables from a plurality of data tables stored in a memory store. The objects from the table are retrieved by the mapper/parser module and are used for mapping a message based on the incoming message, in this case an OSI message, to be used in the operations system.

[0006] It is therefore an objective of the present invention to provide a system and method therefor of translating an incoming message having a given operating protocol to a counterpart message having a different operating protocol which is usable in the operations system.

[0007] It is another objective of the present invention to provide an access module that has mapping and parsing capabilities for parsing an incoming message, and specifically the different fields of the message, so that a counterpart message may be mapped with corresponding fields from a data or mapping table retrieved from a data store.

[0008] The above-mentioned objectives and advantages of the present invention will become apparent and the invention itself will be best understood by reference to the following description of an embodiment of the invention taken in conjunction with the accompanying drawings, wherein:

[0009] FIG. 1 is a simplified block diagram of the system of the present invention;

[0010] FIG. 2 is a block diagram focusing on the different processes that occur in the access module of the present invention as shown in FIG. 1;

[0011] FIG. 3 is a flow diagram that illustrates the method of the instant invention;

[0012] FIG. 4 is an exemplar data table that provides the translation map for mapping incoming autonomous messages having a given protocol to counterpart messages having a different protocol usable in the operations system of the instant invention;

[0013] FIG. 5 is an exemplar data map providing for the translation of non-autonomous messages having a given protocol to counterpart messages that have a protocol usable in the operations system of the instant invention; and

[0014] FIGS. 6 and 7 are exemplar encoding mapping tables to be used for the instant invention.

[0015] With reference to FIG. 1, the system of the present invention is shown to operate in an operations system (OS), for example a TeMIP® operations system of the Digital Equipment Corporation. As shown, operating within the TeMIP® operations system 2 is a front end module 4 which may comprise one or more conventional processors. Inside front end module 4 there resides a Transaction Language 1 access module (TL1 AM) 6. Within TL1 AM6 is a mapper/parser module 8 that has connected thereto a memory store 10. Further connected to front end module 4 is a database store 12 which may be external of TeMIP® operations system 2. Not meant to be limiting to such, physically, front end module 4 may comprise a rack to which is inserted a TL1 AM integrated circuit card 6. Further, mapper/parser module 8 may comprise the same processor as front end module 4, or a software module whose operation is described below with respect to FIG. 3.

[0016] Albeit front end module 4 may have a number of inputs thereto and outputs therefrom, for the sake of simplicity and the pertinency of the instant invention, only one input 14 is shown to be provided to front end module 4 and specifically to TL1 AM 6 therein. Input 14, as shown in FIG. 1, is deemed to be fault notifications or messages that are transmitted from a network element (NE) 16. NE 16 may be any element that is within the telecommunications network. In the case that the instant invention resides in a synchronous optical network (SONET), NE 16 could be a add drop multiplexer (ADM), a lightwave regenerating equipment (LRE) or a line terminating equipment (LTE), etc. In any event, any notification from NE 16 to TL1 AM 6 is in the form of a message having a TL1 protocol.

[0017] TL1 AM 6 is further shown in FIG. 1 to have an output 18 from which notifications or messages such as alarm messages that are based on the open systems interconnection (OSI) standard are output. Via line 18, the output message from TL1 AM 6 is provided to a notification function module (FM) 20, and more specifically to a queue or buffer 22 in notification FM 20, which in turn resides in the back end 24 of the TeMIP® framework of operations system 2. For the exemplar TeMIP® OS 2, the messages or notifications that traverse therein are assumed to have an open systems interconnection (OSI) operating protocol, which allows equipment from different manufacturers to communicate. An OSI dictionary store 26—which may be referred to as a management information base (MIB)—is also provided in the TeMIP® OS 2 and is shown to be connected bidirectionally via connections 27 and 30 to front end module 4 and back end module 24, respectively. OSI dictionary 26 has stored therein all of the OSI information that is needed for the structuring of the OSI messages or notifications that traverse from front end module 4 to back end module 24. Such structuring of the OSI messages include providing specific values, probable cause, event types and other attributes that are needed for mapping each of the OSI messages, as will be discussed below with respect to the mapping process of the instant invention. Putting it simply, OSI dictionary 26 contains the standard under which the OSI messages are based.

[0018] In a conventional SONET telecommunications system, communication is effected by messages that operate under the TL1 management or operating protocol. However, some vendors have operations system that are not TL1 protocol based. With the instant invention system, an incoming notification having a TL1 operating protocol can be translated into a corresponding or counterpart message having the operating protocol of the vendor's operations system which, for this discussion, is deemed to be based on the OSI protocol.

[0019] To provide such translation, as best illustrated in FIG. 2 and the flow chart of FIG. 3, a combination parsing and mapping process is performed. In particular, with respect to FIG. 2, the TL1 access module 6 is shown to include 3 process modules, namely a mapper/parser process module 8, a communications process module 28 and a back end process module 30. The respective processes performed in each of mapper/parse process module 8, communications process module 28 and back end process module 30 could be performed by the same processor or different processors. As shown, TL1 messages are input to TL1 access module 6 by network elements 16. The interfacing that occurs between TL1 access module 6 and network elements 16 is performed by communications process module 28 in a conventional manner. Upon receipt, each TL1 message is forwarded to mapper/parser process module 8.

[0020] As shown in FIG. 2, there are four components or submodules within mapper/parser process module 8. They are: a parser submodule 32, a site identifier/equipment (SID/EQPT) memory store 34 in which at least one SID/EQPT data table is stored, a equipment/facility identifier/condition text description/type of event (AID/CONDDESCR/CONDTYPE) memory store 36 in which a AID/CONDDESCR/CONDTYPE table is stored, and a mapper process submodule 38. For the instant invention, note that even though SID/EQPT store 34 and AID/CONDDESCR/CONDTYPE store 36 are shown to be within mapper/parser process module 8, in practice, stores 34 and 36 may in fact be a part of memory store 10, shown in FIG. 1 to be part of TL1 access module 6 but external of mapper/parser module 8. Furthermore, although only one SID/EQPT table and one AID/CONDDESCR/CONDTYPE table are shown to reside in mapper/parser process module 8, there may in actuality be a plurality of those data tables, each being different and linked relationally to other data mapping tables, stored in memory store 10. These data mapping tables each are to be used in the mapping process whereby a corresponding TL1 message input to mapper/parser process module 8 is translated or mapped into a counterpart OSI output message.

[0021] Further shown in TL1 access module 6 is back end process module 30 to which the OSI messages from mapper/parser process module 8 are input. These OSI messages are further encoded into a specific protocol, in this instance an identifier length value (ILV) protocol used by the internal components within TeMIP® operations system 2. As further shown in FIG. 2, the OSI message, after translation, is provided to the TeMIP® framework 24, or more precisely buffer 22 of notification function module 20 thereat.

[0022] Exemplar mapping tables that are stored in memory store 10 and which are retrieved into stores 34 and 36 of mapper/parser process module 8 are shown in FIGS. 4, 5, 6 and 7. To elaborate, FIG. 4 is an illustration of an exemplar autonomous message to event map that may be stored in memory store 10. As shown, column 40, entitled “Message Parameter”, provides a number of types of TL1 message parameters such as SID (site identifier) at 42, AID (equipment/facility identifier) at 44, NTFCNCDE (notification code) at 46, CONDTYPE (condition type) at 48 and CONDDESCR (condition of text description) at 50, among others. Column 50 provides the description for each of the corresponding messages listed in column 40. For example SID is described to be the source identifier and is used with AID to identify the node element. Similarly, AID is the access identifier and is used with SID to identify the node element. The third column in the autonomous mapping table of FIG. 4, designated 54, contains data that indicates whether the specific TL1 message is to be used when a counterpart OSI message is to be mapped therefrom. For example, going down column 54, it can be seen that message parameters SID, AID, NTFCNCDE, SRVEFF, OCRDAT, OCRTM, LOCN, DIRN and CONDDESCR are the parameters that can be mapped into corresponding fields of a counterpart OSI message, as indicated in column 56. For those message parameters that are indicated not being used, respective explanations are provided in why those message parameters are not being used. For example, the TL1 message parameter “Date” is not used in mapping a TL1 message into a counterpart OSI message because the corresponding field in the counterpart OS1 message is not used and will not appear in the OS1 message, which for this instance may be an alarm. Note that the autonomous map of FIG. 4 is used for mapping TL1 messages that are provided automatically and/or periodically to front end 4 of the operations system 2 without having been explicitly requested by the manager of the system. Such autonomous messages include notifications such as fault alarms that are transmitted asynchronously to the operations system 2.

[0023] The second type of exemplar data mapping table that is used by mapper/parser process module 8 is the non-autonomous exemplar mapping table illustrated in FIG. 5. Note that most of the message parameters in the FIG. 5 non-autonomous mapping table have the same designations as those shown in column 40 of the FIG. 4 mapping table. For example, column 58 of FIG. 5 shows a number of message parameters including SID, AID, NTFCNCDE, CONDTYPE, SRVEFF, OCRDAT, OCRTM and CONDDESCR all of which have correspondence in the FIG. 4 table. Column 60 of the FIG. 5 mapping table, similar to the description column 52 of the FIG. 4 table, provides descriptive identification of the respective message parameters. Column 62 of the FIG. 5 table similarly indicate which of the message parameters listed under column 58 have corresponding OSI arguments for mapping. However, note that the OSI arguments for the corresponding TL1 message parameters identified in column 64 are different from the respective OSI arguments listed in column 60 for the same message parameters in the FIG. 4 mapping table. For example, for the message parameter SID, the corresponding OSI argument in the non-autonomous mapping table is Alarm Summary Data: Object Identifier. In contrast, for the autonomous mapping table of FIG. 4, the corresponding OSI argument is message parameter SID Managed Object.

[0024] Assume that a plurality of mapping tables similar to those of FIGS. 4 and 5 are stored as files in database (DB) store 12 external to the TeMIP® operations system 2. In operation, upon receipt of a TL1 message from network element 16, the appropriate file is retrieved from DB store 12 by mapper/parser process module 8 as a mapping data table. The operation of the method of the instant invention then proceeds as follows, with reference to FIG. 3.

[0025] As shown in step 66, a TL1 message is provided to communications process module 28 and is output thereby to mapper/parser process module 8. This TL1 message, as is well known, comprises a number of data fields. At step 68, the incoming TL1 message is parsed by parser submodule 32 to determine a given field, for example the first field that contains the SID, from the message. Next, a determination is made in step 70 on whether the SID is in database store 12. If it is not, an error message is provided to back end process module 30, per step 72, and the operation of the inventive process stops. If the SID indeed is found in the database, the remainder fields of the message are parsed, per step 74. From this parsing of the appropriate fields of the message, the correct mapping table is located from database store 12 and retrieved to mapper/parser process module 8, per step 76. The mapping table is then searched to locate the access identifier AID per step 78. If the AID is not found in the mapping table, per step 80, an error message is sent to back end process module 30 and the process stops, per step 82. If the access identifier AID is located in the mapping table, then, per step 84, the mapping table is searched to locate the appropriate condition text description and/or type of event. If neither of those message parameters is found per step 86, an error message is sent to back end process module 30 and the method of the instant invention stops. If either of those message parameters is found, the process proceeds to step 88.

[0026] For the example mapping table of FIG. 4, assuming that the input TL1 message is an autonomous message, the alarm text description parameter CONDDESCR (or the type of event message parameter CONDTYPE depending on the equipment type) is found at 50 and shown at FIG. 6. Thus, according to step 88, the corresponding fields of the counterpart OSI message are mapped by mapper submodule 28 using the corresponding OSI arguments of column 56 of the FIG. 4 mapping table to map the counterpart OSI message. For example, if the TL1 message has the message parameter NTFCNCDE, which is the notification code that indicates the severity of the alarm, a corresponding OSI argument identified in column 56 as the “perceived severity” is provided for mapping the counterpart OSI message. The encoding map referred to by the “perceived severity” argument is shown in section 5.4 of the FIG. 7 encoding map. There, it can be seen that for each level of alarm for the TL1 message, identified in columns 92 and 94 of the 5.4 NFTCNCDE encoding map of FIG. 7, corresponding OSI type perceived severity definitions are provided in column 96. The standard corresponding to the OSI definition from the OSI dictionary are provided in column 98.

[0027] Each field of the incoming TL1 message is parsed and mapped. Accordingly, a counterpart OSI message or object message that corresponds to the TL1 message but with an OSI operating protocol is generated as a result of step 88. This OSI message is output as an OSI notification, message or record to back end process module 30. There, for internal operation, this OSI message is encoded into a ILV protocol message for the internal use of the TeMIP® operations system. As shown in step 88, the four alarm/clearance correlation fields of the counterpart OSI message are the Managed Object, Probable Cause, Specific Problem and Event Type. Examples of these four types of objects are shown as maps 5.1 to 5.4 in FIGS. 6 and 7.

[0028] While a preferred embodiment of the present invention is disclosed herein for purposes of explanation, numerous changes, modifications, variations, substitutions and equivalents, in whole or in part, should now be apparent to those skilled in the art to which the invention pertains. Accordingly, it is intended that the invention be limited only by the spirit and scope of the appended claims.