The dissertation is organized as follows. Chapter 2 uses a large-scale system design example to explore the process of starting with a set of informal constraints and mapping these constraints onto a protocol design. Chapter 3 investigates the languages that are used to specify protocols using formal (i.e., mathematical) languages, and presents a taxonomy of execution and communication models for the most well-known formal languages. Given a formal model of a protocol, it becomes possible to address the problem of formally proving properties about the model. Chapter 4 presents a tutorial on the most common formal verification technologies as they apply to hardware and protocol verification, and introduces some recent work in compositional refinement verification that provides the theoretical underpinnings for the following chapter.
In Chapter 5, we consider the methodological challenge of mapping protocols from a high-level, asynchronous concurrent execution, abstract “message-passing”
domain (e.g., SDL) to an implementation-level domain with synchronous concurrent execution. This forms the basis of a “semi-formal” approach to protocol design and implementation that combines SDL modeling with an informal mapping to a high-level model using a synchronous language known as SMV. This high-level SMV model can then be incrementally refined into an implementation, and at each step of the refinement process it is possible to check that a refinement is consistent with the original high-level specification.
Chapter 6 turns to the more general problem of relating an SDL system to an implementation in a mix of hardware and software. The problem is one of mapping high-level message-passing semantics of SDL onto a combination of synchronous
hardware and non-deterministically interleaved software threads, as well as providing the infrastructural resources such as queues, timers, and schedulers in an embedded operating system.
Finally, Chapter 7 provides an in-depth look at the design of the data link initialization and link management protocols for the InfoPad system and outlines the challenges of formally verifying the link level protocols. Chapter 8 concludes the dissertation with an eye to extensions of this work.
C h a p t e r 2
I n f o r m a l S p e c i f i c a t i o n o f P r o t o c o l S y s t e m R e q u i r e m e n t s
2.1 Overview
The first step in any protocol design is to determine the service requirements. That is, what set of services is the protocol intended to provide to external programs (which include higher layers in the protocol stack). Simultaneously one must define required services that the protocol layer of interest will not provide: this defines the dependencies on services from the lower level protocols.
The scope of our methodology ranges from specification through implementation.
To motivate and define the context for the data link and media access protocols, we start by examining a full system design of a wireless communication system known as InfoPad [TPD97][NSH96]. Our goal is to give the reader a feeling for the range of problems that the methodology must address.
The InfoPad system is an example of a large system design in which ad-hoc design methodologies were used. The data link protocols were informally documented using graphical representations of state transition systems. With a few sketches of protocol state machines, an implementation in hardware and software was the next objective, before any high-level performance estimates or formal verification results were obtained. Finally, the implementation was incrementally debugged over a period of several months as the implementation began to stabilize. In hindsight, the strength of an abstract state machine language with clean message-passing semantics and language constructs that are designed to facilitate protocol specification would have greatly simplified the eventual task of implementing the protocol simply because it would be easier to understand what must be implemented.
In Section 2.2, the top-level system is described qualitatively together with the overarching design objectives; from this we derive a set of informal constraints for the link level protocols. In Section 2.3, we outline a functional partitioning of the system that identifies the message-passing interactions between functional units.
For our system, the message-passing entities generally fall into one of 3 categories:
1) network management or mobility support; 2) multimedia server or client; or 3) the mobile device. We consider each of these in Sections 2.3.1.1, 2.3.1.2, and 2.3.2, respectively.
Once the initial system architecture is in place, we turn our attention to the qualitative performance objectives. These objectives define a set of constraints can be broadly classified as either functional or performance-oriented. (A subset of these constraints is discussed in Section 2.4.)
For example, a qualitative performance objective is that the wireless network connection should be maintained transparently to a roving user: cell-to-cell handoffs should, if at all possible, avoid dropping the link. We can split this requirement into the following constraints:
1) Performance constraint: The protocol should minimize the probability of dropping the link
2) Functional constraint: protocol must provide both for handoff without drop-out and for recovery in the case where the link is dropped
The point here is that an informal constraint often translates into a series of formal constraints1, some of which are performance-oriented and some of which are function-oriented. It is important to understand the difference because the tools used to analyze and determine whether the implementation meets the constraint are radically different for the two types of constraints. Performance-oriented constraints are usually handled using a combination of hand analysis and discrete-event simulation; functional constraints must be formally verified.
This abstract view of the system must undergo a series of refinements before an implementation is possible. Since the latter part of our methodology focuses on the implementation phase, it is useful to follow a portion of the system through to implementation, laying the groundwork for the refinement methodology presented in Chapter 5.
1 In this example, we use the word formal in the sense that it is possible to prove whether the constraint is satisfied
Since the InfoPad was designed to be a tool for research in mobile communication systems, there are many features in the hardware implementation that support dynamic configuration for protocol support and would be of interest to a protocol systems designer. Section 2.5 presents an in-depth look at the design of the mobile device, and will be referenced in Chapter 5; however, it is intended primarily as a reference section and may be safely skipped in a first reading.