![]() |
![]() |
![]() |
![]() |
![]() |
Using ASN.1 in SDL
ASN.1 is a language for defining data types that is frequently used in the specification and implementation of telecommunication systems. ASN.1 is defined in ITU-T Recommendations X.680-X.683. Recommendation Z.105 defines how ASN.1 can be used together with SDL. A subset of Z.105 is implemented in the SDL Suite.
This chapter explains how ASN.1 data types can be used in SDL systems. The following items will be discussed:
- How to organize ASN.1 modules in the SDL Suite
- How to use ASN.1 data types in SDL
- How to share ASN.1 data between SDL and TTCN
Organizing ASN.1 Modules in the SDL Suite
It is recommended to have a special chapter for ASN.1 modules (for example called ASN.1 Modules). If many ASN.1 modules are used, they may be grouped into Organizer modules (which is not the same as ASN.1 modules!), see Module.
Figure 45 shows an example of the Organizer look of a chapter with two Organizer modules containing ASN.1 modules.
We will show with an example how to use an ASN.1 module in an SDL system. Suppose we have an ASN.1 module MyModule in file mymodule.asn:
MyModule DEFINITIONS ::=BEGINColor ::= ENUMERATED { red(0), yellow(1), blue(2) }ENDThis module contains one type definition, Color, that has three values, red, yellow, and blue.
We first add a new diagram of type Text ASN.1 to the Organizer using Edit/Add New (without showing it in the Editor) and we connect it to the file mymodule.asn (using Edit/Connect). In order to use the ASN.1 module in SDL, we edit the system diagram and add use MyModule; in the package reference clause, as is illustrated in Figure 46 below.
Figure 47 shows the resulting Organizer view. The symbol below the MySDLSys system symbol is a dependency link that indicates that the SDL system depends on an external ASN.1 module. Dependency links for ASN.1 modules that are used by an SDL system were previously required by the Analyzer, but now only serve as comments and are optional.
If ASN.1 modules use other ASN.1 modules, dependency links between the ASN.1 modules should be created.
Using ASN.1 Types in SDL
After the above preparations, the data types in MyModule can be used in SDL. As an example, we will make an SDL system that converts a character string to the corresponding color. This is done by two signals:
- Signal GetColor has ASN.1 type IA5String as a parameter.
- When this signal is sent to the SDL system, the SDL system will reply with signal ReturnColor, that has a BOOLEAN parameter indicating whether there is a color that matches the string, and a Color parameter.
The system diagram including these signal definitions is shown in Figure 48 below.
The MSC below illustrates how the system is intended to be used.
In order to know which values and which operators can be used on ASN.1 types, it is necessary to look in Translation of ASN.1 to SDL.
For example, Color is defined as an ENUMERATED type. By looking at the mapping rules in Enumerated Types, we see the list of operators that can be used on Color. These are in this case num, <, <=, >, >=, pred, succ, first, last, and also = and /=, which are always available.
Figure 50 shows a fragment of an SDL process that uses Color. It contains a loop over all values of Color, and illustrates how to declare variables of Color, how to use Color in new SDL sort definitions, and how to use the operators first, last, and succ. Some notes on the fragment:
- The type ColorToString is used to convert a color to an IA5String. In the fragment we do actually the opposite. An alternative solution would be to have a StringToColor Array (IA5String, Color) because then no loop would have been needed (see also Array). However, the purpose of the example was to illustrate how to loop through all elements.
- Operator first in c := first(red) returns the element with the lowest associated number. This ensures that we really get all elements when using the Succ operator. In this case we could just as well have written c := red.
- Note also the use of the predefined ASN.1 type IA5String, which is in fact a syntype of the predefined SDL sort Charstring.
Using Predefined ASN.1 Types in SDL
The predefined simple ASN.1 types can be used directly in SDL. In most cases, the ASN.1 type has the same name in SDL, for example ASN.1's type NumericString is also called NumericString in SDL. However, some predefined ASN.1 types contain white-space, like BIT STRING. In SDL, the white-space is replaced with an underscore, so the corresponding SDL sort is called BIT_STRING.
The operators on these predefined ASN.1 types are described in detail in section Using SDL Data Types.
Using ASN.1 Encoding Rules with the SDL Suite
The ASN.1 constructs defined in ITU-T Recommendation X.690 and X.691 are supported, which is explained in "ASN.1 Encoding and De-coding in the SDL Suite" on page 2831 in chapter 58, ASN.1 Encoding and De-coding in the SDL Suite, in the User´s Manual.
Sharing Data between SDL and TTCN
One more advantage of ASN.1 is that TTCN is also based on this language. By specifying the parameters of signals to and from the environment of the SDL system with ASN.1 data types, this information can be re-used in the TTCN Suite for the specification of test cases for the system.
This has the big advantage of making it easier to keep the SDL specification consistent with the TTCN test specification.
The use of external ASN.1 in TTCN is covered in more detail in the TTCN Suite manual. In this section we will briefly illustrate how to share data between SDL and TTCN using TTCN Link.
Supposing we have to write a test suite for the SDL system with the Colors example, we would add a new diagram - a TTCN Test Suite, for example called ColorTest - to the Organizer. In this test suite we want to use definitions from the ASN.1 module MyModule that contains the Colors data type. For this purpose we need to set a dependency link between the ASN.1 module and the test suite. We do this by selecting the ASN.1 module in the Organizer. By using Generate/Dependencies we connect it to the TTCN test suite ColorTest.
We can also use TTCN Link to generate declarations from SDL system MySDLSys. For this purpose, it is easiest to associate the SDL system with the TTCN test suite. This is done by selecting the SDL system diagram in the Organizer and associate it with the TTCN test suite using Edit/Associate. The Organizer View for the test suite now looks as in Figure 52 below:
We can generate a TTCN Link executable for the SDL system by selecting the SDL system in the Organizer and using Generate/Make select standard kernel TTCN Link. Now we can start the TTCN Suite by double-clicking on test suite ColorTest. By using TTCN Link/Generate Declarations, we can automatically generate the PCOs, ASP type definitions and ASN.1 type definitions. If we look at the result, we can see that Color is present as an ASN.1 Type Definition by Reference. This table is shown below.
Now this data type can be used in creating test cases, in constraints, etc. If at some point in time the definition of Color would be changed (for example if we would add a new color), then, in order to update the test suite accordingly, we can select the TTCN table for Color. In the Analyzer dialog, we should select both Enable Forced Analysis and Retrieve ASN.1 Definitions. Now the TTCN test suite will be updated with the new definition for Color.
http://www.ibm.com/rational |
![]() |
![]() |
![]() |
![]() |