Study Group 17 has been designated the Lead Study Group for Languages and Description Techniques in accordance with World Telecommunication Standardization Assembly (WTSA-20) Resolution 2.

As Lead Study Group for Languages and Description Techniques, Study Group 17 has the responsibility with respect to languages and description techniques for telecommunications:

• to provide guidance to ITU-T members and other Study Groups on the use of languages and description techniques;
• to maintain the set of ITU-T Recommendations and other guidelines for languages and description techniques used for telecommunications;
• to advise on suitable languages available through other channels to be used if an appropriate language is not defined by a Recommendation of
  ITU-T;
• to interact with other recognized bodies such as IETF and OMG that use or define complementary languages and description techniques.

The main reference documents for language use in ITU-T is Recommendation Z.110 “Criteria for use of formal description techniques by ITU-T” and Recommendation Z.450 “Quality aspects of protocol-related Recommendations”.

The main languages developed, maintained and supported within Study Group 17 (collectively called ITU system design languages) are:

• ASN.1 (Abstract Syntax Notation One);
• MSC (Message Sequence Chart);
• URN (User Requirements Notation);
• SDL-2010 (Specification and Description Language);
• TTCN-3 (Testing and Test Control Notation).

These techniques and others mentioned in Z.110 are preferred for ITU work, though on a case-by-case basis other approaches can be used as long as they meet the criteria in Z.110. For example, UML is referenced in the collaborative Open Distributed Processing work (see X.906). Moreover, Study Group 17 is working towards a framework for integration of the ITU system design languages by defining a UML profile for each language, so that UML provides a semantic basis between the languages. However, in general the unrestricted use of UML is not advised, because UML provides too many semantic variations and leaves many items undefined. The UML profiles for ITU system design languages (such as the existing Z.109) constrain UML to remove these issues and bind the UML to the proven ITU language syntax and semantics. In line with this integration is a methodology for using the languages together, a version of which was published in Z.Suppl.1 “ITU-T Z.100-series – Supplement on SDL+ methodology: Use of ITU System Design Languages​" distilling many years of experience. There is a plan to update this document and re-issue it as a Supplement to the Z-series.

In general the languages experts within Study Group 17 do not also have the application domain expertise that is expected within user Study Groups, so that participation in the Study Group 17 languages work by such application domain experts (whether from other Study Groups or ITU-T members or the wider telecommunication industry) is most welcome.

Information concerning language activities and their applications to Recommendations, especially protocol-related Recommendations, is requested from all ITU-T Study Groups. In the case where support for the selection or application of languages is needed, other Study Groups should contact Study Group 17. So that the possible future ITU Mark programme can be supported, it is expected that many Recommendations will be issued or reissued with associated conformance tests for which the appropriate language is TTCN. So that such conformance tests can be written, the requirements within base Recommendations need to be well-defined, which implies the use of languages such as ASN.1, MSC and SDL traced back to requirements using URN.

The definitions of each of the ITU system design languages can be downloaded as PDF files by following the Recommendation links in the descriptions below. Tutorials on the use of these languages and various aspects of the languages can be found via by browsing at Tutorials on the Study Group 17 web site. On request, Study Group 17 will try to organize demonstrations of language tools or provide general information on the languages and their use. In addition, externally there are regular TTCN-3 User Conferences and SDL Forum Society events that cover all of the ITU-T system design languages.

ITU System Design Languages in a Nutshell

• address the market of real-time, distributed communicating systems in general and telecommunications in particular, and specialise in this segment, making them particularly suitable for the specification of protocols;
• pay particular attention to a formal basis, allowing (early) verification and validation, thereby saving cost and improving quality;
• offer user-friendly interfaces geared to engineers, and a graphical syntax wherever the users demand it.

ASN.1 provides a notation for data values that is independent of the encoding of the values, and linked to standardized encoding rules to define how messages are transmitted between entities using a chosen transfer syntax.

MSC provides a notation for showing the sequence of message communication between entities.

URN provides a notation supporting the elicitation, analysis, specification, validation and traceability of requirements with the help of goals and use cases.

SDL-2010 provides a notation for the structure of entities, the communication paths between entities and the behaviour of each entity in terms of how responses are derived for each stimulus.

TTCN-3 provides a formal language that can be used for testing all types of reactive system tests over a variety of communication ports.

For specification in very simple standards, a few URN or MSC diagrams may be sufficient. In more complex cases a model in SDL-2010 that can be fully simulated may bring real benefits ensuring the behaviour given in the standard is well-defined, even facilitating automatic test case generation. The use of ASN.1 allows the data content of messages to be unambiguously specified, and can be coupled with the use of SDL-2010. The use of SDL-2010 allows a specification to be elaborated to the point that executable software can be produced. Experience has shown that a general approach of using High-level MSC (HMSC) and basic MSC diagrams together with ASN.1 and SDL-2010 can bring very effective results both in the production of either standards or systems. URN facilitates the linking of goals and requirements to use cases.

ASN.1 can be used in conjunction with SDL-2010, providing SDL-2010 with the full power of ASN.1 in terms of encoding (see ITU-T Z.105 and Z.104).

MSC and SDL-2010 diagrams describe the same behaviour from two different perspectives. SDL-2010 shows how each communicating entity behaves, while MSC diagrams show how they interact by exchanging messages.

Software tools can generate TTCN tests from SDL-2010. In this process, the specifications themselves are validated as well.  

One of the real benefits of creating and using a well-specified model is that it can be simulated. The simulation is usually traced with a dynamic MSC. This visualisation is appreciated by those who want to understand the behaviour without actually looking into the detail of the model. Live simulations can also give a good focus for discussion and analysis. Modern SDL-2010 tools contain powerful capabilities for checking that a system is well built, for example that it does not contain deadlocks, etc.

ASN.1 in a nutshell

ASN.1 is an international standard for describing the structure of data exchanged between communicating systems (ITU-T X.680, X.681, X.682 and X.683 | ISO/IEC 8824-1 to 4).

ASN.1 has been extensively used in telecommunication standards. Notable examples are protocol standards for intelligent networks, UMTS (3G), Voice over IP, Interactive television and HiperLAN/2. The use of ASN.1 goes well beyond telecom standards and products.

ASN.1 is a formal language for abstractly describing messages to be exchanged among an extensive range of applications involving the Internet, intelligent network, cellular phones, ground-to-air communications, electronic commerce, secure electronic services, interactive television, intelligent transportation systems, Voice Over IP and others. Due to its streamlined encoding rules, ASN.1 is also reliable and ideal for wireless broadband and other resource-constrained environments. Its extensibility facilitates communications between newer and older versions of applications. In a changing world, ASN.1 is core technology, constantly adapting to new technologies. ASN.1 is a critical part of our daily lives; it's everywhere, but it works so well it's invisible!

ASN.1 is a mature notation with a long record of reliability and interoperability. It supports the exchange of information in any form (audio, video, data…) and has full and direct support of international alphabets.

Abstract and concrete syntax

ASN.1 has an abstract syntax as defined in the ITU-T X.680 series of Recommendations, and has several alternative concrete syntaxes as defined in the ITU-T X.690 series. The abstract syntax is the form that would normally appear in a protocol standard and is used to describe Protocol Data Units (PDU) and other data structures at the level of human readability. The concrete syntax defines the specific set of encoding rules that are used in an implementation to convert the abstract form to the actual stream of bits that is sent over a communication media. Typical encoding rules are Basic Encoding Rules (BER) and Packed Encoding Rules (PER).

Tools are available to easily translate ASN.1 specifications into many programming languages such as C, C++, Java. This brings significant productivity gains in product development and maintenance.

The separation between abstract and concrete syntax brings substantial benefits during protocol standard development. Full attention is initially given to the semantics of data, their relations (structuring) and their range or size limits, while details of concrete syntax are deferred for later considerations.

Since tools can check ASN.1 specifications, this approach is in all aspects superior to the traditional way of specifying bit tables. The separation of the data structure from the encoding makes ASN.1 superior to other notations where these are mixed.

Extensibility

One of interesting and important points of ASN.1 is that it offers concepts that support extensibility of protocol data structures that in turn allow older and newer versions of protocols to work together. This is a feature that is lacking in many other data description notations, but is one which is essential to any system which is expected to survive for some time.

Benefits for protocol testing

Many protocol standards are accompanied by related test specifications. ASN.1 data definitions can be directly imported into test suites written in TTCN. While this speeds up test suite development, it is even more important in that it aids the implementation of actual test tools.

What is ECN?

The Encoding Control Notation (ITU-T Rec. X.692 | ISO/IEC 8825-3) is an internationally standardized formal notation used to specify specialized encoding rules for ASN.1. While ASN.1 specifications only deal with data that has semantics for the communicating applications, ECN specification defines the way auxiliary fields that are specific to the encoding are inserted. In specifying the encoding rules with ECN, there are two approaches that can be taken:

• design of a complete set of (new) encoding rules or
• overloading/specialization of standardized rules (such as PER)

MSC in a nutshell

Message Sequence Charts (MSC) is the language defined by ITU-T Recommendation Z.120​. MSC are used to show interactions between system components. MSC diagrams provide a clear description of system communication in the form of message flows.

MSCs have been used for visualization of selected message traces within communication systems for a long time. The simplicity and intuitive understanding has made the notation quite popular.

Despite their simplicity, MSCs are a powerful notation, with built-in mechanisms to portray timers, loops, and alternative, exceptional and optional system behaviour, as is necessary in any protocol description.

What are MSC diagrams used for in standardization?

A set of MSC diagrams describes partial system behaviour. Each MSC diagram represents one scenario of either a typical or an exceptional exchange of messages between system parts.

The language is particularly effective when distributed processing must be managed at several interfaces. For instance, it can be used very effectively in describing basic scenarios of calls and the establishment of connections.

Message Sequence Charts may be used for requirement specification, displaying simulation and validation results, test purpose description and documentation of real-time systems.

Use of MSC tools

MSC diagrams can be developed using any computer application capable of handling simple graphics. However, the use of specialized MSC tools improves all aspects of their development and use. It enforces the use of standardized MSC language elements, while permitting rapid development and maintenance of diagrams. Including MSC diagrams into the text of the standard or a product description is very straightforward.

High Level Message Sequence Charts

The Z.120 standard also defines High Level Message Sequence Charts – HMSCs. HMSC diagrams are used to specify more complex patterns of message flows by showing sequences or alternatives of atomic MSC scenarios, shown only as references to MSC.

It could be said that HMSC diagrams specify what communication activities are needed while the referenced MSC diagrams show how the communication is done in terms of message sequences.

HMSC diagrams can conveniently express options and alternatives in using parts of a complex procedure. Expressing the same thing only in MSC diagrams is possible but is less straightforward.

URN in a nutshell

The User Requirements Notation (URN) is the language defined by Rec. ITU-T Z.151. This notation aims to support the elicitation, analysis, specification, validation, and traceability of requirements. URN is the first standardization effort to address explicitly, in a graphical way and in one unified language, goals and scenarios, and the links between them.

URN models can be used to specify and analyze various types of reactive systems, services, and business processes, as well as telecommunications standards. URN allows modelers and engineers to discover and specify requirements for a proposed system or an evolving system, and analyze such requirements for correctness and completeness.

URN combines the Goal-oriented Requirement Language (GRL) for modeling goal-oriented and intentional concepts (mainly for non-functional requirements, quality attributes, and reasoning about alternatives) with the Use Case Map (UCM) notation for modeling scenario concepts (mainly for operational requirements, functional requirements, and performance and architectural reasoning). In particular, URN has concepts for the specification of stakeholders, goals, non-functional requirements, rationales, behaviour, scenarios, scenario participants, and high-level architectural structure.

URN models do not intend to provide detailed specifications of “how” functionalities, capabilities and features are to be supported but are primarily concerned with exposing “why” certain choices for behavior and/or structure were introduced, combined with an abstract view of “what” capabilities and architecture are required.

Use of URN models

Creating URN models enables different types of analyses and transformations based on goals and scenarios. GRL model evaluation allows for the comparison of alternatives and facilitates trade-offs among conflicting goals of various stakeholders. GRL evaluations can be done qualitatively or quantitatively.

Scenario paths in UCM models can be explored via a traversal mechanism, which enables advanced applications such as scenario highlighting and animation, feature interaction analysis, regression testing of models, and the generation of MSCs, test goals, and performance models.

URN brings formality and executability to use cases while enabling concrete support for goal models, which are useful to derive and analyze non-functional and functional requirements alike. 

SDL-2010 in a nutshell

Specification and Description Language (SDL-2010) is the language defined by Recs. ITU-T Z.100, Z.101, Z.102, Z.103, Z.104, Z.105, Z.106, Z.107 and Z.109. SDL-2010 is used to specify the behaviour of complex systems. Several classes of constructs are needed in order to represent:

• the specification of system structure, that is the co-operating agent part (system, block, processes);
• the specification of the communications with the environment and within the system ("channels" as communications paths and "signals" as messages that are carried over them);
• the specification of the behaviour (the dynamic properties) of each of the parts (process or block agents);
• the specification of internal information affected by and affecting the behaviour of the system (data used internally or carried by signals);
• the specification of types used to define the properties (both structure and behaviour) that are reused in agents.
  

Specification and Description Language diagrams

SDL-2010 takes the form of a set of diagrams. The outer diagrams show the structure within the system showing the channels and references to the components and also the type definitions. A component reference is a symbol containing the name of the component. Inner diagrams show the behaviour as state machine graphs, each of which has a start node and nodes for each of its states. Signals on a channel are delivered to the input port of an agent with a state machine.

When an agent is in a state, the first signal in the input port that can trigger a transition from that state is consumed and the behaviour described by the transition is carried out. A transition leads to the next state or to the termination of the agent. A transition can contain outputs of other signals, creation of other agents, manipulation of data within the agent, remote procedure calls of other agents, branching according to data values, and loops. For a complex agent behaviour, the graph may have several diagram pages.

The structure and behaviour properties of a component are its type. If the type is only used once the properties and the definition of the component can be captured in a diagram for the component. When the type is reused, or defined separately so that it may be reused, the type is given a name and the component contains its own name and a reference to the type definition. The contents of a directly defined component and a type of the same kind are therefore very similar. A type can contain types. In addition to types for agents, there are procedures, data types and state types.

A type can inherit properties from another type of the same kind. Properties can be added to a type. Properties of a type that are virtual can be redefined when the type is inherited. A type can also have formal parameters that are tied to actual items that exist in the context where the type is used. 

Levels of Specification and Description Language use

SDL-2010 can be applied at various levels: from simple diagrams that illustrate the prose description of a protocol, through models that can simulate behaviour at normative interfaces, to actual implementation descriptions.

Each level of use can bring clarity to a specification. However, the full power of the language, in terms of precise, unambiguous description of the intended behaviour, can be exploited only with models that respect all language rules. For such models the static analysis tool can reveal syntax and semantic errors, while tools for simulation and validation may reveal dynamically erroneous behaviour.

TTCN in a nutshell

The latest version of the language is TTCN version 3 (TTCN-3). This is standardized as the Recs. ITU-T Z.161, Z.161.1, Z.161.2, Z.161.3, Z.161.4, Z.161.5, Z.161.6,​ Z.161.7,​ ​Z.162, Z.163, Z.164, Z.165, Z.165.1, Z.166, Z.167, Z.168, Z.169, Z.170 and Z.171. The work of drafting this version was done within ETSI and the results were contributed to ITU-T. The acronym TTCN in TTCN-3 is for "Testing and Test Control Notation" (previously "Tree and Tabular Combined Notation").

Typical areas of application for TTCN-3 are conformance testing of protocols, services, APIs, software modules etc. TTCN-3 is not restricted to conformance testing. It can be used in many areas, for example:

• Interoperability testing;
• Robustness testing;
• Performance testing;
• Regression testing;
• System testing;
• Integration testing.

• Dynamic concurrent testing configurations;
• Synchronous and asynchronous communication mechanisms;
• Encoding information and other attributes (including user extensibility);
• Data and signature templates with a powerful matching mechanisms;
• Test verdict mechanisms;
• Test suite parameterisation and test case selection mechanisms;
• Harmonized with ASN.1;
• Well-defined syntax, interchange format and static semantics;
• Optional presentation forma (tabular and graphical);
• Precise execution algorithm (operational semantics);
• Test suite and test system control.

• The language is specifically designed for testing;
  
• The syntax and operational semantics of TTCN-3 tests are commonly understood and not related to a particular programming language;
  
• TTCN-3 tests concentrate on the purpose of the test and are abstracted from particular test system details;
  
• Off-the-shelf tools and TTCN-based test systems are readily available;
  
• The language is constantly maintained and developed;
  
• Education and training costs can be rationalized and reduced;
  
• Maintenance of test suites (and products) is easier;​
  
• Allows the application of a common methodology and style, both on a corporate level and within standardization.