Method and Apparatus for Encoding and Decoding a Data Unit Whose Structure Is Defined by a Description Conforming to Abstract Syntax According to a Prescribed Encoding Rule

1. Field of the Invention

The present invention relates to a method and apparatus for converting data between an abstract syntax and transfer system and, more particularly, to the generation of data conforming to a prescribed transfer syntax in accordance with a prescribed encoding rule from data whose structure is defined in a prescribed abstract syntax notation, and also relates to the decoding of data in said transfer syntax format.

2. Description of the Related Art

In the Open Systems Interconnection (OSI) Reference Model, the presentation layer carries out data conversion between an abstract syntax format used at the application layer and a transfer syntax format actually used for data transfer. For example, in network management protocols such as the common management information protocol (CMIP), CMIP over TCP/IP (CMOT), and simple network management protocol (SNMP), to permit network management under multi-vendor environments where data transfer machines from different manufacturers are connected, the structure of an application protocol data unit (APDU) is defined using a description conforming to a standardized abstract syntax notation known as abstract syntax notation number one (ASN.1), and at the presentation layer, encoding and decoding are performed in accordance with the ASN.1 basic encoding rule (ASN.1 BER).

In ASN.1, the use of variables of a structured type, such as a choice type (CHOICE) that indicates a value selected from a set of values, is permitted in addition to the use of variables of a simple type, such as an integer type (INTEGER) and a true or false logic type (BOOLEAN). In order to generate data in a transfer syntax format from a protocol data unit (PDU) whose structure is defined in an abstract syntax notation such as ASN.1 where the use of variables of a structured type is permitted, and also to perform the inverse processing, one approach that can be considered is to store conversion tables associated with individual variables of structured type used in the abstract syntax and perform encoding and decoding operations by referencing these tables.

This ordinary method of storing the conversion tables in the main memory, however, presents a problem in terms of memory resources available for storage. On the other hand, if the conversion tables are to be stored as files on an external storage device, there arises a problem in terms of the processing capacity since a large number of files are required for storage of such tables. Furthermore, with any of these methods, data management is difficult and it is not easy to update the tables when data structure definitions are changed or added.

It is, accordingly, an object of the present invention to overcome the above problems and provide a method and apparatus for efficiently generating data for transfer in a transfer syntax in accordance with a prescribed encoding rule from data whose structure is defined using a description conforming to an abstract syntax notation, and for efficiently analyzing and decoding the transferred data.

According to the present invention, there is provided a method of encoding a data unit, whose structure is defined by a description including a label and an assignment thereto conforming to a prescribed abstract syntax notation, into data for transfer conforming to a prescribed transfer syntax, comprising the steps of: entering a plurality of records, each containing the label and an assignment thereto, into a database; retrieving records entered in the database one after another by reference to the assignments contained in the records; and encoding the data unit in accordance with the assignments contained in the retrieved records.

According to the present invention, there is also provided a method of decoding transferred data constructed conforming to a prescribed transfer syntax and whose structure is defined by a description including a label and an assignment thereto conforming to a prescribed abstract syntax notation, comprising the steps of: entering a plurality of records, each containing the label and an assignment thereto, into a database; retrieving records entered in the database one after another by reference to the assignments contained in the records; and decoding the transferred data in accordance with the assignments contained in the retrieved records.

According to the present invention, there is also provided an apparatus for encoding a data unit, whose structure is defined by a description including a label and an assignment thereto conforming to a prescribed abstract syntax notation, into data for transfer conforming to a prescribed transfer syntax, comprising: a database into which a plurality of records, each containing the label and an assignment thereto, are entered; means for retrieving records entered in the database one after another by reference to the assignments contained in the records; and means for encoding the data unit in accordance with the assignments contained in the retrieved records.

According to the present invention, there is also provided an apparatus for decoding transferred data constructed conforming to a prescribed transfer syntax and whose structure is defined by a description including a label and an assignment thereto conforming to a prescribed abstract syntax notation, comprising: a database in which a plurality of records, each containing the label and an assignment thereto, are entered; means for retrieving records entered in the database one after another by reference to the assignments contained in the records; and means for decoding the transferred data in accordance with the assignments contained in the retrieved records.

FIG. 1 is a block diagram showing a network management station as an example of an apparatus incorporating an encoder/decoder according to one embodiment of the present invention;

FIG. 2 is a diagram for explaining a type identifier name field;

FIG. 3 is a diagram showing an example of an abstract syntax;

FIG. 4 is a diagram showing the structure of a database corresponding to the abstract syntax shown in FIG. 3;

FIG. 5 is a diagram for explaining an additional information field; and

FIG. 6 is a diagram for explaining referenced label, value information, and value fields.

FIG. 1 is a block diagram showing the configuration of a network management station as an example of an apparatus incorporating an encoder/decoder according to one embodiment of the present invention.

In the figure, 11 is a database, 12 is an encoder/decoder section, 13 is an operation/display section, 14 is a communications controller, 15 is an encoder, 16 is a decoder, 17 is an operation/display controller, and 18 is a database management section. The database management section 18 is responsible for the management of the database 11, and data is updated as necessary. The encoder/decoder section 12 includes the encoder 15 and decoder 16, and performs conversion between an abstract syntax and a transfer syntax by referencing the database 11. The operation/display section 13 includes a keyboard at which an operator performs input operations, and a display device for displaying the result of data retrieval from the database 11, input information, etc. The operation/display controller 17 provides an interface between the encoder/decoder section 12 and the operation/display section 13. Information input by an operator via the operation/display section 13, is supplied to the encoder/decoder section 12 via the operation/display controller 17, based on which information the encoder 15 searches the database 11, and the result of the search is supplied via the operation/display controller 17 to the operation/display section 13 for display. On the other hand, transferred data received at the communications controller 14 is supplied to the encoder/decoder section 12, and converted in the decoder 16 into an abstract syntax format by referencing the database 11. The functions of the encoder/decoder section 12, communications controller 14, and operation/display controller 17 can be implemented, for example, using software in a personal computer or a workstation.

Each record stored in the database 11 consists of six fields, a "label" field, a "type identifier name" field, an "additional information" field, a "referenced label" field, a "value information" field, and a "value" field, as shown in FIG. 1. The "label" field carries a label assigned to a variable or a constant included in the data structure definition in ASN.1. As shown in FIG. 2, the "type identifier name" generally has a one-to-one correspondence with the type in ASN.1, but there are some names, such as SID and EID, that do not correspond on a one-to-one basis. The type identifier names are classified into several groups, as shown in FIG. 2, details of processing being different for different groups. The details of processing will be described later.

To facilitate understanding, the relationship between data structure definitions in an abstract syntax and records stored in the database 11 will be explained by way of example.

When a protocol data unit (PDU) is defined in the abstract syntax shown in FIG. 3, for example, in the present invention the records shown in FIG. 4 are stored in the database 11 for the encoding and decoding of the PDU. In the abstract syntax example shown in FIG. 3, part of the definition in ASN.1 of the PDU for the remote operations service element (ROSE) providing the remote operation service that the common management information service element (CMISE) uses in the previously mentioned CMIP, as well as part of the definition of the PDU for the CMIP, is shown in a simplified form for convenience of explanation. As can be seen from the example of FIG. 4, for variables ROSEapdus and ROIVapdu assigned thereto a structured type such as "CHOICE" or "SEQ", records (30 to 33 or 34 to 37) the number of which is equal to that of available choices or component elements are stored with the same label. In cases where assignable values are enumerated in an abstract syntax, such as a record assigned thereto a label "OPERATION", records (40 to 45) the number of which is equal to that of assignable values are stored. In the case of an "ANY DEFINED BY" type (type identifier name is SID, EID, or AID) such as a record "argument", records (46 to 51) the number of which is equal to that of values that define the type are stored.

The third field in each record carries "additional information" that additionally specifies the details of processing. As shown in FIG. 5, the additional information has different meanings for different type identifier names. If the type identifier name is "SEQ", for example, the additional information field carries an integer (1, 2, . . . ) which indicates the order of appearance of the component element of the SEQUENCE type variable corresponding to the record. In the example shown in FIG. 4, the four records with the label "ROIVapdu" carry additional information "1" to "4". Additional information "0" indicates that the associated variable is of a "SEQUENCE OF" type. For the type identifier name "SET", if the additional information is "1", this means a "SET" type, and if it is "0", this means a "SET OF" type. If the type identifier name is "BOLN", "INT", "OCTS", or "GTIME", the additional information indicates that, of the plurality of records having the same label, those carrying additional information "0" correspond to a value stored in the database but not used currently, and that the user or application process should select a value from those carrying additional information "1". If the additional information in all records is "0", or if there is only one record and its additional information is "0", this means that the user or application process should assign an actual value. If the type identifier name is "ENUM", "CHOICE", or "REF", the additional information indicates that, of the plurality of records having the same label, those carrying additional information "0" correspond to a choice stored in the database but not used currently, and that the user or application process should make a choice from those carrying additional information "1". If the additional information in all records is "0", it is treated as a NULL value. If the type identifier name is "SID", "EID", or "AID", the additional information indicates the operation-value ID number, the event-type ID number, or the action-type ID number corresponding to the associated record.

The "referenced label", "value information", and "value" fields also have different meanings for different type identifier names. If the type identifier name is "SEQ", "SET", "CHOICE", "REF", "SID", "EID", or "AID", the referenced label field carries the label of the component element or choice corresponding to the record. If the value information field carries "0" or "16", this means that no tag is assigned to the corresponding component element, and "0" is stored in the value field. If the value information field carries "0", this further means that there is an optional or default specification. If the value information field carries "1", "2", "17", or "18", this means an implicit tag, an explicit tag, an implicit tag with an optional/default specification, or an explicit tag with an optional/default specification, respectively, and the tag number is stored in the value field. If the type identifier name is "BOLN", "INT", "OCTS", "GTIME", or "ENUM", the referenced label field carries the label assigned to the value, and the number of bytes of the value is stored in the value information field while the value defined for the label is stored in the value field. The above is the case where the additional information field carries "1". On the other hand, if the additional information field carries "0", the value is assigned by the user or application process, as earlier described.

Referring back to FIG. 2, when the type identifier name is "BOLN", "INT", "ENUM", "OCTS", or "GTIME", as described above, if the additional information field carries "1", the user or application process selects a value from a plurality of values; if that field carries "0", then the user or application process enters a value in the number of bytes specified in the value information field. If the type identifier name is "SEQ", the label carried in the referenced label field is referenced in the order of the value stored in the additional information field. If the type identifier name is "SET", the referenced label is repeatedly referenced. If the type identifier name is "CHOICE", the user or application process chooses from the referenced labels of the records whose additional information field carries "1". If the type identifier name is "SID", "EID", or "AID", the referenced label is referenced in accordance with the operation-value ID, event-type ID, or action-type ID, respectively, of the additional information. If the type identifier name is "REF", the referenced label is uniquely referenced.

The roles of the fields in each record stored in the database 11, described above, will be more fully understood by proceeding through the following detailed description of the encoding and decoding processes.

First, the encoding process when the APDU structure is defined in the abstract syntax shown in FIG. 3 is described. The records shown in FIG. 4, constructed based on the abstract syntax of FIG. 3, are stored in the database 11. In encoding, first the records with label "ROSEapdus" and additional information "1", the four records 30 to 33 in the example of FIG. 4, are retrieved. The referenced labels, "ROIVapdu", "RORSapdu", "ROERapdu", and "RORJapdu", of the four retrieved records 30 to 33 are displayed on the operation/display section 13 (or output to the application process) for selection by the operator (or the application process). It is assumed here that "ROIVapdu" is selected. Since the "value information" is "1" and the "value" is "1" for the record 30 with referenced label "ROIVapdu", an "implicit tag" is specified for the variable ROIVapdu, and the tag number is "1". Next, a search is made for records having the label "ROIVapdu". Since the type identifier name of the retrieved records 34 to 37 is "SEQ", ROIVapdu is of type "SEQUENCE", but because of the specification of the implicit tag, type "SEQUENCE" is not encoded, and the T field in the transfer syntax is defined as ›CONTEXT-SPECIFIC: 10; Structured: 1; Tag number 1: 00001!, which is encoded as "A1h". Since the type identifier name of ROIVapdu is "SEQ", SEQUENCE type processing is performed. More specifically, since the referenced label of the record 34 having the smallest "additional information" value of the records 34 to 37 is "InvokeIDType", search is made for records having label "InvokeIDType". The record 38 is retrieved, whose "type identifier name" is "INT" and "additional information" is "0", so that the user or application process is requested to enter an integer value. Assuming that "ssh" is entered, it is encoded as "02h, 01h, ssh". "02h" is a universal tag of an integer type and "01h" the number of bytes of the entered integer. Of the remaining records 35 to 37 with label "ROIVapdu", the record 35 has the smallest additional information value. The value information of the record 35 is 17, which means that there is an optional/default specification, so that it is left to the user or application process to decide whether encoding is needed or not. If it is decided that encoding is not needed, the processing of this record is terminated. Of the remaining records 36 to 37 with label "ROIVapdu", the record 36 has the smaller additional information value. Since the referenced label of the record 36 is "OPERATION", a search is made for records having the label "OPERATION". The type identifier name of the retrieved six records 40 to 45 is "INT" and their additional information is "1"; therefore, the user or application process is made to select the one it needs from the referenced labels of these records. It is assumed here that "m-Get" is selected. Since the "value" of the record 41 having that label is "3", it is encoded as "02h", "01h", "03h". The only remaining record with the label "ROIVapdu" is the record 37. The referenced label of the record 37 is "argument" and its value information is "16". Since the value information of 16 means that there is an optional/default specification, the user or application process is made to decide whether encoding is needed or not. If it is decided that encoding is needed, search is made for records having label "argument". Six records 46 to 51 are retrieved, whose type identifier name is "SID". Of the records 46 to 51, the record 47, which has additional information equal to the value "3" selected as the value of "OPERATION", is selected. Since the referenced label of the record 47 is "m-Get-apdu", search is made for records having label "m-Get-apdu". Since the type identifier name of the retrieved record 52 is "REF" and its referenced label is "attributeID", a further search is made for records having label "attributeID". Record 53 is retrieved, whose type identifier name is "OCTS", additional information "0", and value information "3"; therefore, the user or application process is requested to enter a 3-byte character string value. Assuming that "xx yy zzh" is entered, it is encoded as "04h", "03h", "xx yy zzh". "04h" is a universal tag of "OCTET STRING" and "03h" the byte length of the character string data. With the above procedure, the SEQUENCE type processing of "ROIVapdu" is completed. Since the encoded data length of ROIVapdu is "0Bh" (11), the final code is given as "A1 0B 02 01 ss 02 01 03 04 03 xx yy zzh".

The decoding process in the present invention, that is, the process of analyzing transferred data constructed in a transfer syntax, will be described below by taking as an example the decoding of the transferred data "A1 0B 02 01 ss 02 01 03 04 03 xx yy zzh" whose structure is defined in the abstract syntax shown in FIG. 3. As in the encoding process, first the records with label "ROSEapdus" and additional information "1" are retrieved. The type identifier name of the retrieved records is "CHOICE", and "A1h" at the start of the transferred data means that the tag class is CONTEXT-SPECIFIC, it is a structured type, i.e. nested structure, and the tag number is 1. Accordingly, the record 30 whose value information is neither "0" or "16" and whose value is "1" is selected from the retrieved records. This indicates that ROIVapdu has been selected, and since the value information is "1", it is found that the encoding of the universal tag has been omitted. Next, a search is made for records having the label "ROIVapdu", as a result of which the records 34 to 37 are retrieved. The type identifier name of the records 34 to 37 is "SEQ", but from the above, it is found that the universal tag of "SEQUENCE" is omitted. Since the value information of the record 34 whose additional information value is the smallest of the records 34 to 37 is "0" and its referenced label is "InvokeIDType", a search is made for records having label "InvokeIDType". Record 38 is retrieved, whose type identifier name is "INT", additional information "0", and value information "1". These coincide with the third and fourth bytes, "02h" and "01h", of the transferred data, and it is found that InvokeID is "ss" at the fifth byte of the transferred data. Since the value information of the next record 35 is "17", it is found that the record has an implicit tag, there is an optional/default specification, the value is "0", and therefore the tag number is "0". However, since there is no match with "02h" at the sixth byte of the transferred data, it is found that the encoding has been omitted. Since the value information of the next record 36 is "0" and its referenced label is "OPERATION", search is made for records having label "OPERATION". Records 40 to 45 are retrieved, whose type identifier name is "INT" and value information "1". These coincide with the sixth and seventh bytes, "02h" and "01h", of the transferred data. Since the eighth byte of the transferred data is "03h", from the record 41 whose value coincides with that value it is found that it indicates m-Get. The value information of the next record 37 is "16", which means that there is an optional/default specification but there is no tag. Accordingly, a search is made for records having the referenced label "argument" of the record 37 as their label. From the retrieved records 46 to 51, a record whose additional information value is equal to the value "3" of m-Get is selected. Since the referenced label of the selected record 47 is "m-Get-apdu", a search is made for records having label "m-Get-apdu". Since the type identifier name of the retrieved record 52 is "REF", a further search is made for records having the referenced label "attributeID" of the record 52 as their label. Record 53 is retrieved, whose type identifier name is "OCTS" and value information is "3". These coincide with the ninth and 10th bytes, "04h" and "03h", of the transferred data, and it is found that argument is not omitted. From the transferred data, it is found that m-Get-apdu is "xx yy zzh" at the 11th to 13th bytes. With the above procedure, the analysis of all data of data length "0B" is completed. The result of the decoding is that, in the abstract syntax shown in FIG. 3, ROIVapdu is selected for ROSEapdus and, of the component elements of ROIVapdu, invokeID is "ss", linked-ID is omitted, operation-value is "m-Get", and argument is "xx yy zzh".