![]() |
![]() |
![]() |
![]() |
![]() |
Defining ASP, PDU and CM Types
ASPs are derived from the relevant standardized service definitions. When using the distributed method, for example, ASP definitions are needed for both the (N) and the (N-1) service. There should be one ASP definition for each ASP used in the test suite.
PDUs are derived from the relevant protocol specifications. There should be one PDU type definition for each PDU used in the test suite. If, for the purposes of testing, it is required to use non-standard PDUs then these too should also be defined in the test suite.
Coordination Messages are also defined by the test suite specifier.
TTCN has tables that allow the definition of ASPs, PDUs and CMs using either the simple TTCN tabular format or ASN.1.
Complex TTCN Types
TTCN has tables for the declaration of the following complex types:
Using these complex types we can define arbitrarily structured ASPs and PDUs (structured types are substructures of ASPs and PDUs). In essence there is no real difference in TTCN between the composition of the body of an ASP, PDU or structured type. Note the following:
Chaining
Normally, the ASP parameters, PDU fields and structure elements will be predefined or simple types (note that this includes the use of ASN.1, if wished). However, as noted above, the parameter, field or element types may also be PDUs or structures to allow the chaining of these types to build complex definitions.
Complex ASN.1 Types
In ASN.1, constructors such as SEQUENCE and SET are used to build arbitrarily complex types. ASN.1 definitions may be used in the following tables:
- ASN.1 Type Definitions;
- ASN.1 ASP Type Definitions;
- ASN.1 PDU Type Definitions;
- ASN.1 CM Type Definitions.
It is always possible to express the TTCN tabular format in ASN.1, but not vice versa. The two formats can be used in combination, if wished. A common example is to use a tabular ASP to carry a structured PDU defined in ASN.1.
Local Type Definitions
There will always be at least one type definition in an ASN.1 table. This is the main definition, and it is named in the table header. However, these ASN.1 tables may also include any number of local definitions which are only available to the type definitions defined within the table itself, i.e. the main definition and other local definitions (if any).
Note that local definitions begin with typereference ::=. This is not the case for the main definition as the type identifier already appears in the header.
Type Definitions by Reference
In order to save repeating PDU and other type definitions that are specified in another standard TTCN allows the following types to be declared by reference rather than explicitly:
A single table is used for all references to a particular type. The reference tables are:
- ASN.1 ASP Definitions by Reference;
- ASN.1 PDU Definitions by Reference;
- ASN.1 Type Definitions by Reference.
Note that because the entries in the Type Reference column and the Module Identifier column follow ASN.1 syntax they may contain the dash character. Note also that the module identifier may be followed by an optional object identifier.
Defining ASPs
OSI service primitives are often defined in a standard as a tuple, i.e. the primitive name followed by a list of parameters. Each parameter is defined using natural language descriptions and may represent service control information or service user data. Some parameters are mandatory (i.e. must always be present) while others are optional and, under certain circumstances, may be omitted.
In TTCN service primitives are called Abstract Service Primitives (ASPs) and are declared in ASP Type Definition tables.
Case study 7: A service provider ASP type definition.
The PDU Metatype
The above example uses the PDU metatype. This indicates that any type of PDU, and not just a particular type of PDU may be embedded in this ASP.
Defining PDUs
In most OSI standards PDUs are usually defined using either:
In the first case the specification may be rather loose, and typing of PDU fields and substructuring of the PDUs is not always obvious. The test suite specifier must transpose these definitions to the more powerful and precise formats available in TTCN.
For example, a standard may describe a particular field as comprising 8-bits, implying that it shall be encoded as a BITSTRING. If none of the bits in this BITSTRING need to be referenced individually, it may be adequate for testing purposes (and easier to understand) if this field is defined as an OCTETSTRING.
In the case of ASN.1 the types and structure of PDUs and their fields is usually complete and well-defined, and may be taken directly from the protocol standard, either by copying them or by reference.
Case study 8: Type definition of an X_PDU using the TTCN format.
Substructuring ASPs and PDUs
TTCN structured types (which we will sometimes refer to simply as structures) are only used to substructure ASPs, PDUs, CMs and other structured types.
If ASN.1 is used then the ASN.1 type definition table may be used not only to substructure ASPs, PDUs etc. but also to define types general to the entire test suite.
Case study 9: Type definition of a PDU substructure using the TTCN format.
Defining Coordination Message Types
Coordination messages are special to each test suite and are created by the test suite specifier. Either the tabular format or ASN.1 may be used.
http://www.ibm.com/rational |
![]() |
![]() |
![]() |
![]() |