Standards & Protocols

What is SDL?

SDL is an internationally standardized language for specifying and describing systems. Its first version was released in 1976 by the former Comitı Consulatif International Tılıgraphique et Tılılphonique (CCITT), now known as the ITU-T (International Telecommunication Union, Telecommunication Standardization Sector). The language has evolved considerably over time, with a new version released approximately every four years. SDL is ITU-T Recommendation Z.100 and its most recent version, SDL-2000, was ratified in late 1999. SDL is now a formal, object-oriented, graphical language for the specification of real-time communicating systems.

SDL offers the ability to describe systems in terms of:

• Architecture. The static structure of a system can be described in terms of decomposition into functional blocks, which may be further broken down until processes are eventually specified (see Figure 1).
• Behavior. Processes describe the dynamic behavior of a system and are modeled as parallel, communicating finite state machines (FSMs), which are extended to use data variables and time.
• Communication. The interaction between the system and its environment and between entities within the system can be specified.
• Data. Abstract data types used within a system can be fully described using SDLıs native type notation or Abstract Syntax Notation One (ASN.1) (ITU-T X.680).

SDL is a formal language, which means it is possible to analyze and interpret SDL descriptions unambiguously. Although SDL defines operational semantics, it is a high-level language that is completely independent of the implementation language and target environment.

The languageıs features and formality make SDL suitable for use within the development of communication protocol standards.

Using SDL

SDL is the preferred formal language of the European Telecommunications Standards Institute (ETSI). ETSI has successfully used SDL as a normative part of intelligent networks, broadband ISDN, GSM, and TETRA standards.¹ ETSI says it has seen increased technical quality in the specifications and has made more early detections of errors in documents prior to release.² SDL is also being used in the definition of the Third Generation Partnership Project (3GPP), which will establish a specification for third-generation (3G) wireless networks.

The Institute for Electrical and Electronic Engineers (IEEE) is also beginning to adopt SDL to define its standards. SDL was first used within the IEEE 802 (LAN/MAN Standards Committee) in the 1997 publication of the 802.11 wireless LAN (WLAN) standard for the MAC and PHY layers.

Even though the SDL model in the publication was used as an informative notation and did not describe the complete protocol, it proved useful in ex-plaining the protocolıs behavior. The experience in the WLAN standard was an important first step and convinced many on the committee of the merits of SDL as a tool for specifying, simulating, and validating protocols.

IEEE 802.15

SDL has also had an important impact on the development of the IEEE 802.15 WPAN specification. The IEEE 802.15 Working Group is currently defining a standard for WPANs. WPANs are short-range ad-hoc RF networks that will replace current cable and infrared (IR) connections between many common devices. Part of the 802.15 charter is to incorporate the Bluetooth specification.³

The IEEE 802.15 Working Group has decided to create an SDL model that will form a normative part of the 802.15 specification. The decision has several implications for development of the WPAN standard.

Using SDLıs formal syntax and semantics, the 802.15 committee can convey protocol concepts concisely and unambiguously. Users of the standard can then refer to the SDL model to clarify the written text, reducing the risk of the standard being misinterpreted.

Describing data

SDL also allows 802.15 to employ the ASN.1 language. ASN.1 is a language used extensively within communication standards to describe data types in an abstract fashion (independent of their implementation). SDL supports the use of ASN.1 definitions (under ITU-T Recommendation Z.105) and the IEEE 802.15 standard may make use of this notation.

While the formality of SDL protects the protocol standard from misinterpretation, there is no guarantee that the standard is describing a sensible protocol. However, the SDL approach can assist in assuring the correctness of the 802.15 specification. SDL tools allow the SDL model to be simulated on a host, allowing protocol developers to test the behavior of the standard itself. The ability to simulate an SDL model has long been exploited by product developers to test designs and detect errors earlier in the development cycle than traditional methods allow.

Finally, the 802.15 WPAN specification development may also take advantage of the object-oriented nature of SDL. This protocol allows nodes to function as either a master or a slave, depending on the context. The object-oriented features of SDL let standard developers define an SDL type representing a generic WLAN node and then build a system which includes, for example, two instances of the node type where one functions as a master and the other as a slave (see Figure 2). Thus, the end-to-end behavior of the protocol can also be tested as part of an SDL simulation.

Developers of standards tend to use descriptive SDL, which is a view of the SDL system that does not specify all the lower-level behavior of the system. Thus, the model published in a standard leaves room for creativity on the part of the adopters of the standard, and does not prejudge an implementation.

A typical example of the advantages of descriptive SDL can be seen in the area of decisions. Descriptive SDL defines a decision construct (c.f. if-then-else) that, for the purposes of simulation, can be replaced with an informal decision. The informal decision may simply contain a textual description of the necessary decision. Then, during simulation of the SDL model, the user can manually decide which branch of the decision to take and steer the simulation down the path of the userıs choosing.

Validation

SDL tools can also assist the IEEE 802.15 standard development in the area of protocol validation. The behavior of an SDL system is captured as FSMs within processes. SDL tools let the user consider all combinations of states that all processes within the system may be in at any time. The tools will then automatically explore this state space to detect potential run-time problems. This technique supports the automatic detection of numerous problems, including signal race conditions, deadlocks, and queue overflows.

SDL validation tools can also determine whether a certain scenario captured in a message sequence chart (MSC) is capable of occurring given an SDL model in a certain initial state. If the scenario is viable, the MSC is used to steer the navigation through the system state space.

The protocol conformance tests for Bluetooth will be defined in Tree and Tabular Combined Notation (TTCN). TTCN is a black box test script language originally designed within a framework of conformance testing of OSI and ITU protocols.

The Bluetooth Special Interest Group (SIG) and the IEEE 802.15 Working Group found that there would be significant, mutual benefits in attempting to run the Bluetooth TTCN test scripts against the IEEE 802.15 SDL model. Some SDL tools support this host-based testing of the SDL model with TTCN test scripts. In addition, TTCN has support for ASN.1, so ASN.1 definitions could potentially be reused across both the IEEE 802.15 SDL model and the Bluetooth TTCN test suites.

Benefits to designers

Wireless product developers will obviously benefit from having a source standard that has been clearly defined, simulated, validated, and tested by its developers. However, there are a number of other benefits for those who use this rapidly emerging technology.

The first benefits lies in design. Since the SDL model to be published in the IEEE 802.15 standard will have gone through a degree of simulation, validation, and testing, developers may bootstrap their own project by using this model as a basis for their design.

As mentioned earlier, the SDL model in the standard will not include all implementation details, but will contain a signifi-cant portion of protocol behavior. Therefore, the developer can simply add the appropriate implementation details to the existing SDL model and produce a complete SDL system. Once the design is complete, the SDL model may be simulated, validated, and tested in a similar fashion to the steps taken during development of the standardıs SDL model.

Many SDL tools also support code generation, whereby the complete SDL system can be converted into another high-level language, such as C, then compiled and linked with appropriate target and real-time operating system (RTOS) libraries to create a target executable. Using SDL for design and deciding to reuse the standard SDL model means developers can significantly reduce cycle times by streamlining the design phase and virtually eliminating the coding cycle.

And thatıs not all

SDL also offers simulation benefits when used in the design process. If a product developer creates an SDL model from scratch, there are still benefits to be had from using the original SDL model published in the standard. These benefits can take the form of testing, whereby the product developerıs SDL model can be run in simulation against the model from the standard.

Simulating models against standard models can be particularly useful in the case of Bluetooth because of the dual master/slave nature of all nodes. The same test setup could cover both master and slave modes of the SDL model in development. This approach allows the developer to use the published model as a form of behavioral benchmark against which the new SDL model might be measured.

Finally, developers of WPAN products may experience benefits in the area of testing. As mentioned, the Bluetooth TTCN test scripts may be run against the IEEE 802.15 SDL model. These scripts could be run against a simulation of the developerıs SDL model in the arrangement described earlier (regardless of whether that model was derived from the standard or created from scratch).

In a further example of reuse, the TTCN test scripts can also be used to test the target implementation of the product. In the case of target testing, it is irrelevant whether the system was designed using SDL, since the TTCN test script will treat the system as a black box. Most TTCN tools support the generation of test executables from TTCN test suites, which may be run against target implementations.

Full speed ahead The use of SDL within the development of protocol specifications is steadily increasing because it noticeably improves the quality of the final document. The development of the IEEE 802.15 WPAN standard stands to benefit from the use of SDL. SDL also promises to deliver additional benefits to product developers because SDL tools can simulate designs, automatically generate code from those designs, and exploit the synergy with Bluetooth TTCN test cases. These benefits should translate into savings in the design, implementation, and test phases, and ultimately yield quality and time-to-market improvements for product developers.