1 FORMAL METHODS FOR MOBILITY STANDARDS Daniel Amyot, Rossana Andrade, Luigi Logrippo, Jacques Sincennes, Zhimey Yi TSERG, School of Information Technology and Engineering, University of Ottawa 150 Louis-Pasteur, Ottawa, Ontario, Canada K1N 6N5 e-mail: {damyot | randrade | luigi | jack | zyi}@site.uottawa.ca Abstract - Precise specification and exacting verification and validation of protocol standards are essential for their successful development and implementation. Currently, several languages (called FDTs for Formal Description Techniques) are available to address this issue. FDTs have reached various degrees of acceptance, but their use in standard development in North America has been limited. This paper represents an attempt towards divulging the knowledge of what exists and how it can be used effec- tively based on the methods that were found most useful in our work on mobility protocols. The FDTs considered are, in alphabetical order: the Abstract Syntax Notation 1 (ASN.1), the Language of Temporal Ordering Specifica- tions (LOTOS), Message Sequence Charts (MSCs), the Specification and Description Language (SDL) and the Tree and Tabular Combined Notation (TTCN). Also con- sidered is a new, emerging non-formal technique, called Use Case Maps (UCMs). Keywords : Mobility Standards, Formal Methods, Valida- tion and Verification, Wireless Intelligent Network I. STANDARDIZATION CHALLENGES Numerous industries and standardization bodies (ITU, ISO, ANSI, ETSI, TIA, etc.) are constantly at work to design new telecommunications products and new stan- dards for such products, involving increasingly complex functionalities. These services also require increasingly complex architectures and protocols, especially in a con- text of mobile communication. In the early stages of these processes, many features, services, and functionalities are described using informal operational descriptions, tables and visual notations such as Message Sequence Charts (MSCs) (16). As these descriptions evolve, they quickly become error-prone and difficult to manage. The need of precisely documenting all stages of the design process, which is very important in the industrial environment, becomes critical in the standardization process, where there is an international scrutiny process for which the stages are formalized and must undergo formal review and approval. Inadequate descriptions are likely to hide ambiguities, inconsistencies or undesirable interactions inside or between services, or between levels of abstraction of a given service. These remain difficult to detect with con- ventional inspection methods, and often remain hidden until errors are discovered after implementation, at which point corrections can be very costly. A related issue is the one of interoperability of implementations. Unless stan- dard documentation is very precise and stringently vali- dated, chances that it may be interpreted differently by different implementors are high. Following the practice in several standard groups, the development of each phase of a telecommunication stan- dard is divided in three stages: 1) service descriptions, 2) functional entities and message sequence information, and 3) protocol and procedure specification. Development of Formal Techniques Several of the techniques discussed in this document have become known as Formal Description Techniques (FDTs) because they were formally defined, and in turn they allow to formally define distributed systems. This is the case for ASN.1, LOTOS, SDL, and TTCN. These techniques have different histories. ASN.1, LOTOS, and TTCN were developed in relation to the standardiza- tion effort, within CCITT and ISO, of the Open Systems Interconnection (OSI) protocols and services. At the beginning, the OSI community resolved that formal meth- ods were needed: they would be developed quickly and used in the standardization work. History unfolded differ- ently. First, the development of the FDTs turned out to be a complex project that lasted longer than expected. The languages became available only in the late eighties, when much of OSI standardization had been completed. Second, several languages were developed while only one had been planned. Third, when people started looking at the lan- guages, they found them falling short of their initial opti- mistic expectations. Notably, the languages and the associated tools and methodologies were incomplete, experimental, hard to learn and insufficiently documented. Implicitly, standards developers and industry questioned the wisdom of investing in something unproven (8).