IBM
Contents Index Previous Next



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.

Figure 16 : Structuring ASPs and PDUs

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:

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.

Figure 17 : Structuring ASPs and PDUs using 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:

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.

Figure 18 : Example of PDU definitions by reference

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.

Figure 19 : ASP Type Definition (N_DATArequest)

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.

Figure 20 : PDU Type Definition (CR_PDU)

Figure 21 : Type definition of the same X_PDU using ASN.1

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.

Figure 22 : Structure Type Definition (VARIABLE_PART)

Figure 23 : Type definition of the same substructure using ASN.1

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.

Case study 10: Type definition of a coordination message.

Figure 24 : CM Type Definition (PTC_RESULT)

Figure 25 : Type definition of the same coordination message using ASN.1


http://www.ibm.com/rational
Contents Index Previous Next