CH683474A5 - A method of processing on data transmission systems to be transmitted records, and an application. - Google Patents

Description

5

10th

15

20th

25th

30th

35

40

45

50

55

CH 683 474 A5

description

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

When data is transmitted between two digital data transmission systems, as is the case, for example, in telecommunications systems based on ISDN (Integrated Services Digital Network) standards, data records of different complexity and / or are used between a subscriber's terminal and a telecommunications office or between two telecommunications offices Transfer length. In particular, the recommendations issued by the CCITT are used for signaling. These recommendations include the basic functions and protocols for the D-channel - level 3 of the OSI (Open Systems Interconnection) reference model - intended for signaling between the terminal and the telecommunications office - as well as the ISUP (ISDN user) intended for signaling between telecommunications offices Part) - Level 4 of the OSl reference model -, in particular the procedures necessary for creating, maintaining and deleting connections in the user network interface or network network interface. Detailed information can be found in recommendations Q.931 or 1.451 and Q.932 or I.452 or, as far as the functions and procedures for protocols and relationships with other layers of the OSl reference model are concerned, in recommendations Q.930 or I .430 specified.

All possible parameters transmitted during the signaling are divided into groups which perform similar tasks during the signaling process and which are referred to below as messages. Such a message basically consists of a data record subdivided into data units, which contains data corresponding to the required performance feature. For example, if you look at the SETUP message, it means all features that are related to the establishment and termination of connections. In the example mentioned, this includes 23 different data records such as REPEAT INDICATOR, SENDING COMPLETE, BEARER CAPABILITY, CALLING PARTY SUBADDRESS, etc. (CCITT recommendation Q.931). However, not all records are clearly identified by their names. Based on the values stored in the data records, the structure of the data records formed from the data units can also change in addition to the size. If, for example, one looks at the different execution options of the BEARER CAPABILITY data record, one finds that on the one hand the length of this data record can vary between four and thirteen bytes and that on the other hand different combinations of data units in the data record are determined by values stored in previous data units. As a result, there are changes in the structure of the data records which are brought about during the course of the procedure described by this message and which must be taken into account accordingly by the receiver or the sender when reconstructing or constructing and further processing the data.

Obviously, in particular for data reconstruction, would be a procedural processing of the data records carried out with the aid of a computer program, in which a data record is processed with the help of the rules specified in the CCITT recommendations in such a way that the values contained in the data units of the data records are assigned to predefined variables . These variables can then be used for further processing in a conventional manner. A prerequisite for procedural processing is compliance with all of the rules describing the structures of the possible data records, which makes complex processing necessary. In addition, the potential for errors in the implementation of the CCITT recommendation is very large with this method, with which a large part of the probability of misconduct of the overall system must be attributed to the implemented rules.

The present invention is therefore based on the object of specifying a method for processing data records transmitted between data transmission systems, the structure and length of which results from the values stored in the data records.

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.

The invention is based on a higher programming language known per se, such as Pascal, Fortran, C, C ++, Modula, SDL (Specification and Description Language), etc., a subset of the language SDL, which is normally used as the specification language, can be used as the programming language . In each of these languages, data can be stored in named variables. These variables simplify the handling of the data considerably, since the names and the values can be accessed directly with the help of the names without having to specify the physical location of the variables in the memory of a computer system. The only requirement is that a data type is assigned in a so-called variable declaration in a program before the variables or their names are used for the first time. The data type specifies the permissible values or the range of values of the variables, which on the one hand improves the readability of the programs and on the other hand shows incorrect values assigned to the variables if they are outside the range permitted for this variable or this data type. In particular, a translation program (interpreter or compiler) that is used to translate into higher

2nd

5

10th

15

20th

25th

30th

35

40

45

50

55

60

65

CH 683 474 A5

Programs written in programming languages are required in machine-understandable instructions, recognize or display any assignments of variables not declared with the same data type as errors.

For these reasons, it is advisable to summarize the data types used if possible, if they are not so-called standard data types given by the programming language itself, in type definitions. These composite data types can then be used again and again for the variable declarations.

In the following, the terms just introduced are used exclusively in the manner described: data types are therefore basically "defined", whereas variables are "declared" by specifying a data type.

With all these programming languages, the data types can only be specified statically, i.e. the data types can no longer be changed after the translation with the translation program. For this reason, according to the invention, a programming language is expanded with various data types that do not fix the structure or the length of the variables declared with these data types at the time of translation with the translation program. The definition of one of the data types specified in the variable declaration as a selection is only made when the program is executed.

These additional data types can be used to formally describe the data records which are transmitted as messages between telecommunications systems, the data types being selected in accordance with the values contained in the data units. Instead of the laborious and time-consuming procedural processing of the individual data records, the values of the variables declared using the flexible data types can be accessed directly. An illustrative representation of this method would lie, for example, in that a general pattern with various selection options is overlaid on a data record, which, on the basis of the values of the data units, is converted into a special pattern limited by the selected structure, in which the values over those with this special pattern-declared variable names are immediately available without the need for value assignment as in procedural processing. The variables declared with the flexible data types eliminate the error-prone rule implementation of procedural processing. In addition, a type check can be carried out each time the value of a variable declared in this way is accessed, which also reduces the malfunction of the overall system.

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

1: a data record, the structure of which is not known before the values stored in the data record are processed

2: a data record, the length of which is not known before the values stored in the data record are processed

Fig. 3: a syntax diagram to show all possible forms of a data type CHOICE

Fig. 4: a syntax diagram to show all possible forms of a data type SEQUENCE

5: a syntax diagram to show a syntactic unit “field list” used in the data types SEQUENCE and CHOICE

6: a test system for testing system units

1 shows a section of a data record BC consisting of several words BY1 to BY4b. Each word BY1 to BY4b - often referred to as an octet - includes eight bits B1 to B8, which can be combined in any data units. For the sake of simplicity, in this exemplary embodiment only adjacent and / or individual or several bits B1 to B8 belonging to the same word BY1 to BY4b are combined in data units DE1 to DE15. For example, a data unit DE2 can consist of all eight bits B1 to B8 comprising the whole word BY2 or, like the data units DE3, only of two bits B6 and B7. However, the data structure specified by the data units DEO to DE15 is not limited to the structure specified in FIG. 1. Rather, it can be seen from the context of the application that, for example, individual words BY1 to BY4b or individual data units DEO to DE15 have no meaning and are therefore omitted. For practical reasons, which result from the organization of memories in computer systems, omitting or adding data record parts in the present example always affects whole words BY1 to BY4b. For example, the two words BY4a and BY4b contain the data units DE7 to DE11, DE14 and DE15, which need not be present in this data set BC in the given case. The decision, for example, when the word BY4a with the data units DE7 to DE9 and DE14 is present, is made on the basis of the values of the preceding word BY4 stored in the data unit DE13. Likewise, the presence of the word BY4b is indicated by the values of the preceding word BY4a specified in the data unit DE14. This means that the structure of the data record BC defines itself based on values in structurally already defined parts of the data record BC. The number of possible data record structures is limited in the present example insofar as the values determining the data record structure are stored in the preceding words BY4a and BY4b, respectively. So that is

3rd

5

10th

15

20th

25th

30th

35

40

45

50

55

60

CH 683 474 A5

if the word BY4b is present, the word BY4a must also be present. If one also wants to take into account the general case where the words BY4a and BY4b can occur individually, this means that the values required to decide whether they exist are stored before the optional words BY4a or BY4b.

In the following, data types according to the invention required for the description of the data record BC are to be explained in the higher programming language SDL expanded with the data types using two examples. At the same time, it should be mentioned that the language SDL, which is usually used as the specification language, has been expanded by the possibility of specifying bit representations in type definitions. Such a type definition through bit representation can be seen in the first program section.

As a first example, the data record BC shown in FIG. 1 is to be used, which represents the data record BEARER CAPABILITY of the message SETUP in accordance with the CCITT recommendations Q.931. For clarification, the data units DEO to DE15 have been provided with the data types bc_identifier, bc_length, etc. that represent them, which correspond to the designations used in recommendations Q.931 and which are also used in the following SDL program sections for data type definition.

As a basis for understanding the specified SDL programs, reference is made to Volume X of the “Blue Book” published by the CCITT. To make it easier to distinguish the keywords STRUCT, NEWTYPE, etc. belonging to the SDL programming language, from the data types bc_identifier, bc_ length, etc. of the data record BC, the keywords are consistently large and the data types are consistently written in small letters.

All data types describing the data units DEO to DE15 are first defined in a first definition level by listing all possible values that the relevant data unit DEO to DE15 can assume. As an example, the data unit DE4 is given below, for the further data type definition of which a data type info_transfer_ capability is first defined:

NEWTYPE info_transfer_capability / * Example of a DE4 type definition * /

UTERALS

speech

[00000B],

unrestricted

[01000B],

restricted

[01001B],

audio3.1

[10000B],

audio7

[10001B],

Video

[11000B];

/ * All other values are reserved * /

ENDNEWTYPE;

NEWTYPE ext_bit ext [OB],

end [1B];

ENDNEWTYPE;

For all other data units DEO to DE3 and DE5 to DE15, corresponding data types identifier, length, configuration, etc. are defined in the same way, which will later be used to define the data types bc_identifier, bc_ length, bc_ configuration, etc. After this first stage of the data type definition, the actual definition of the data record BC takes place in a second. For this purpose, the data type extensions carried out according to the invention in the SDL programming language

4th

5

10th

15

20th

25th

30th

35

40

45

50

55

60

65

CH 683 474 A5

CHOICE and SEQUENCE used for the description of data records with variable length and / or changeable structure. The data type referred to as CHOICE is used for selection from a number of different data types based on the specification in a previous data unit. This selection has already been explained in the general description of FIG. 1 with regard to the words BY4a and BY4b. In the following program listing, the data record BC is defined using the data types identifier, length, configuration, etc. defined in the first stage and using the additional data type CHOICE. To better understand the program listing, the corresponding data units DEO to DE15 have been inserted in a comment column on the right-hand side of the page:

NEWTYPE BearerCapability_Q.931 STRUCT [CODESET 0 00000100B] / * BY3 * /

SPARE (1B); bc_coding_standard bcJnfo_transfer_capability / * BY4 * /

ext_4

bc_transfer_mode bc_info_transfer_rate

/ * BY4a * /

CHOICE ext_4 (ext):

ext_4a bc_structure bc_configuration bc_establishment

/ * BY4b * / CHOICE ext_4a (ext):

SPARE (1B);

bc_symmetry bc_info_transfer_rate ENDCHOICE;

ENDCHOICE;

coding_standard; info_transfer_capability ext_bit;

transfer_mode;

info transfer rate;

ext_bit; structure; configuration; establishment;

symmetry;

info transfer rate;

/ * DEO, DE1.DE2 * /

/ * DE12 V / * DE3 * /

/ * DE4 * /

/ * DE13 * /

f * DE5 * /

/ * DE6 * /

/ * DE14 * / / * DE7 * / I * DE8 * / / * DE9 * /

/ * DE15 * / / * DE10 * / / * DE11 * /

ENDNEWTYPE; / * BearerCapabillty_Q.931 * /

Basically, all data types belonging to data set BC are combined in a standard data type STRUCT. In this the individual occurring data types are in the order

5

5

10th

15

20th

25th

30th

35

40

45

50

55

CH 683 474 A5

listed their occurrence. The two words BY1 and BY2 are automatically defined by the information between the brackets after the keyword CODESET. These two words BY1 and BY2 containing the data units DEO to DE2 are followed by a non-changeable bit combination in the data unit DE12 of the word BY3 reserved by the keyword SPARE. For the words BY3 and BY4 there are no other properties that deviate from the normal type definition. The following data types are only selected for the words BY4a and BY4b using the data type CHOICE based on the values in the data units DE13 and DE14 declared as data types ext_4 and ext_4a. In the present simple case, the selection of both the word BY4a and the word BY4b is limited to its presence or to its absence. The word BY4a or BY4b is only present if the value of the variables declared with the data type ext_4 or ext_4a matches the value ext of the data type ext_bit. The fact that the word BY4b can only exist if the word BY4a is present is expressed in the nested CHOICE data type when the word BY4b is defined. It is precisely this nesting of several identical or different data types combined with any selection from other data types with the help of the data type CHOICE that opens up great possibilities and flexibility in the definition of data types.

As already mentioned, the values in the variables can be accessed directly via the variable names used in the data type declaration.

2 shows a data record CPSA used as a second example, which also belongs to the SETUP message and is referred to in the recommendations Q.931 as CALLING PARTY SUBADDRESS. Like the data record BC shown in FIG. 1, the data record CPSA also consists of several words BT1 to BTn eight bits BI1 to B1 in length, which in turn are divided into different data units DE20 to DEm. The first two words BT1 and BT2 are constructed identically to the words BY1 and BY2 shown in FIG. 1. While the actual data record identification is contained in the first word BT1, the word BT2 contains the length of the entire data record CPSA. Both words BT1 and BT2 are automatically defined by the information given in square brackets after the keyword CODESET. The word BT2 is followed by the word BT3, which in turn is divided into different data units DE23 to DE25, which is followed by a number of identical words of the type BT4 resulting from the total length in the word BT2. While the words BT1 to BT3 are always present in this data record CPSA and can be provided with conventional data types, the data type SEQUENCE is suitable for the description of the remaining part of this data record CPSA. With this, a repeating data structure is specified once and provided with the maximum number of repetitions. In the present example, the maximum number of repetitive data types cgps_subaddress_info is limited to twenty, i.e. the data record CPSA can be up to 23 words long. A possible definition of the CPSA data record is again given in the SDL programming language in the following program section:

NEWTYPE CallingPartySubaddress_Q.931 STRUCT [CODESET 0 01101101B]

/ * BT3 * /

SPARE (1B);

cgps_type type_of_subaddress;

cgps_oe odd_even_id;

SPARE (000B);

/ * BT4 * /

SEQUENCE (cgpsjength <= 20)

subaddressjnfo NATURAL [8 BITS];

ENDSEQUENCE;

ENDNEWTYPE; / * CallingPartySubaddress_Q.931 * /

As with the CHOICE data type, any data types can be defined within the SEQUENCE data type.

/ * DE26 * / / * DE23 * / / * DE24 * / / * DE25 * /

/* maximum length */

6

5

10th

15

20th

25th

30th

35

40

45

50

55

60

65

CH 683 474 A5

3, 4 and 5 show the syntax diagrams frequently used to represent syntax rules of a programming language for the two data types CHOICE and SEQUENCE newly introduced in the programming language SDL as well as for the syntactic unit “field list” used in these data types. With the help of syntax diagrams, the syntax rules of a programming language can be described conclusively and in a compact manner. In particular, all composite type constructions can be easily displayed. The SDL programming language in the “Blue Book” Volume X written by the CCITT was also described using syntax diagrams. The syntax diagrams for the data types CHOICE and SEQUENCE given in FIGS. 3 to 5 are also based on this description. The syntactic units represented by a rectangular box combine further, frequently recurring syntactic units in one. Only those that are represented by a box equipped with round elements or by a circle cannot be further divided.

Further information on the interpretation of syntax rules of programming languages shown with syntax diagrams is also contained in the “Blue Book” Volume X by CCITT.

3 shows the syntax diagram of the data type CHOICE. As an additional possibility of this data type CHOICE not used in the example of FIG. 1, a variant initiated with the keyword ELSE can be used to summarize all the cases contained in the syntactic unit “field identifier” that do not answer to one of the cases in the syntactic unit “answer »Listed cases belong, as this is defined by the syntactical unit« field list »following the keyword ELSE. It should also be mentioned in particular that any other data types, including another CHOICE data type, can be used within the CHOICE data type. This possibility becomes clear when the syntactic unit “field list” is replaced by the syntax diagram shown in FIG. 5b.

Fig. 4 shows the syntax diagram of the data type SEQUENCE. In this too, the possibility of using nested data type definitions can be seen by using the syntax diagram of FIG. 5b instead of the syntactical unit “field list”.

6 shows a test system for testing functional sequences of a system unit SE used in telecommunications systems. The test system essentially consists of a workstation AS and an expansion unit EAS. The work station AS has an input unit ED, a storage unit DB and a translation program IP which translates the programs entered via the input unit ED and stored in the storage unit DB. The expansion unit EAS, which consists for example of two interface units SS1 and SS2, takes over the translated programs from the workstation AS and controls a connection between the system unit SE and the interface unit SS1 or SS2 according to the execution commands of the program. If different system units SE are tested, only the expansion unit EAS has to be adapted to the new system unit SE thanks to the modular structure of the test system. The creation of test programs can be carried out in a considerably simplified manner using the data type definitions described in FIGS. 3 to 5. In the case of the data record structures (FIGS. 1 and 2) of messages which are complex in telecommunications technology and which run in equally complex system units, a simple and clear representation of data is of enormous importance. Because with a simple representation errors can be avoided or at least found and corrected faster.

A conventional computer system, such as a PC (personal computer), can be used as the workstation AS.

The interface units SS1 and SS2 in the expansion unit EAS simulate, for example, data transmission systems of a telecommunications system in the test system. The systems directly involved, i.e. the interface units SS1, SS2 and the system unit SE can perform both transmitter and receiver functions. However, it is not essential that all systems involved process the data records using the method according to the invention. Rather, it is also possible for a system part, for example only the transmitting part or only the receiving part, to process the data records using a method other than that according to the invention.

Basically, the data processing of the receiver is therefore independent of the transmitter and vice versa, which enables a combination of a transmission system operating according to any method with the transmission system operating according to the method according to the invention.

The method according to the invention is not limited to use in the test system described. Rather, the described method can be used in other data transmission systems with the same task.

Claims (6)

Claims 1. A method for processing data records to be transferred between at least two data transmission systems, which are subdivided into any data units, characterized in that in at least one of the data transmission systems involved, the data records are subdivided (BC, CPSA) in the data units (DEO, ..., DE15; DE20 DEm) specified data structure is declared in a program with the help of data types and that the definitive data structure of the data records (BC, CPSA) at the latest at the time of transfer between the Data transmission systems is set. 7 5 10th 15 20th 25th 30th 35 40 45 50 55 60 CH 683 474 A5 2. The method according to claim 1, characterized in that a data type allows the repetition of any other data type as often as required before or after the translation of the program value. 3. The method according to claim 1 or 2, characterized in that a data type makes a selection from several data types intended for the same area of the data record (BC, CPSA) and that the selection of the data types is based on a value specified before or after the translation of the program he follows. 4. The method according to any one of claims 1, 2 or 3, characterized in that the data types are interleaved as desired. 5. Application of the method according to claim 1 in a test system for testing system units (SE), in particular units of a telecommunications system. 6. Application according to claim 5, characterized in that the test system consists of a work station (AS) and an expansion unit (ED), that the work station (AS) has an input unit (ED), a memory (DB) and a translation program (IP) contains and that the expansion unit (EAS) has at least one interface unit (SS1, SS2) connected to the system unit (SE). 8th