Protocol Architecture

Communicating systems, especially communication protocols, are the most complex systems to develop. In addition, the tight performance requirements of communicating systems have a major impact on the development of systems. Thus, performance engineering plays an important role in the development of the systems.

For these reasons, and because communicating systems are the prevailing application area for the formal description technique SDL, we focus on communication protocols and protocol architectures rather than giving a general description of the design and implementation of parallel and distributed systems.

The communication protocols are highly critical from the performance viewpoint. The performance of parallel and distributed systems is highly influenced by the efficiency of the protocol implementation, the design and the selected protocol mechanisms. Many of the problems and the strategies described here to improve the performance of protocol implementations are also applicable to parallel and distributed systems in general. In order to support this, we concentrate on general issues of protocol design and implementation rather than going into the very details of communication networks.

3.2.2 TCP/IP Reference Model

The TCP/IP model is a descendant of the ARPANET sponsored by the US Department of Defense. A major design goal of the TCP/IP model was to support communication in the presence of failures of some links or hardware components.

Thus, reliability and fault-tolerance have been major issues. Unlike the OSI reference model, the TCP/IP model is less generic and more specific about the services provided. The TCP/IP model focuses on the following layers:

 Application layer comprising application-oriented higher-level protocols, supporting file transfer (FTP), terminal emulation (TELNET), electronic mail (SMTP), domain name services (DNS), transfer of hypertext (HTTP), and other services.

 Transport layer comprising two important protocols, namely TCP (Transmission Control Protocol) that supports reliable connection-oriented communication, and UDP (User Datagram Protocol) supporting unreliable connectionless transmissions.

 Data link layer providing point-to-point connection establishment, error detection and correction, and flow control, Internet layer with the connectionless Internet Protocol (IP) supporting the detection of erroneous headers, routing and forwarding, and segmentation.

 Physical layer dealing with the transmission of raw bits over a physical medium

3.2.3 Implementation Strategies From SDL

CEFSM represented in a state transition diagram is easy to understand because it describes the states, the events, and the actions clearly. It can also describe the behavior precisely and formally. The formal description can provide several advantages in the tool support for the patterns and the design evaluation of the initial design made by the patterns. We will show the implementation of the patterns in a specific language SDL. We show that this specific implementation will be helpful with potential to be further reused in a real application.

3.2.4 Server Model

3.2.4.1 Object-Oriented Development Process For Real-Time Systems The design phase is divided into the system design and the prototyping design.

The purpose of the system design is to define implementation structure of the system and identify overall design strategies. The purpose of the object design is to create a complete and formally verified description of the behavior of the system. A set of major rules in the conversion is reported below:

Treat the SDL instances, such as block instance, channel instance and process instance, as objects. Treat the abstract data structures of processes as objects inheriting from the process objects. Represent state transitions and data structure manipulations as object method. Identify common methods between objects to derive a common object that the objects with common methods can be inherited from.

Represent the processes inside a block, or blocks inside a super block as a component of the high level object with aggregation relationship.

Above all, we should understand the system architecture and the conditions of the target environment, and then we could model this design using object-oriented.

Afterward we use this concept to set up our knowledge for model the design of communication system.

3.2.4.2 Server Model Basic principles

This implementation principle is called the server model. The principle is graphically displayed in Figure 3-4. The server model provides a straightforward mapping of the layered design with implementation. Protocol processing within protocol architecture can be viewed as follows: there are a number of active entities, in the following called servers, each entity implementing a protocol layer or a sub-layer. The servers are asynchronously executing units, communicating with each other through a clearly defined interface. Communication is also asynchronous, employing buffering to decouple sending and receiving entities.

Figure 3-4 The Basic Server Model

3.2.4.3 Implementation of servers

In the server model, each SDL process is implemented as a single RTOS task in SW, respectively as a separate VHDL entity in the HW implementation, with its own message queue. The server model maps each SDL process to one HW. A typical hardware architecture is implemented as one SDL process according to the server model shown in Figure 3-5. One input interface for each communication channel receives SDL messages with the channel's protocol. The message is put at the end of

the queue. The extended finite state machine is implemented in an infinite loop with two nested case-statements. In turn a message is taken from the queue, the transition belonging to message type and process state executed, and, if necessary, a new SDL message is sent via an output channel.

The server model is a straightforward, semantically correct implementation of SDL. While the EFSM part has to be generated for each new SDL model, the message queue, timers, and the entire interprocess communication can be implemented from a library of reusable components.

Figure 3-5 Basic Component of Server Model

3.2.5 Communication Extended Finite State Machine (CEFSM)

When programmers develop software systems, they often find many similar situations that happened in previous developments. A design pattern provides a generic solution for the recurring problems. This is one of the motivations for using design patterns in software development. In other words, a design solution that has worked well in a particular situation can be used again in similar situations in the future. Therefore, design patterns can improve software quality and reduce development time through experience, reusability, and modularity of patterns.

In the early development phases of reactive systems such as telecommunications systems, designers model the desired behavior of a system at an abstract level, and then implement the model in an implementation language.

Complex behavior can be obtained by combining simpler building blocks: receiving an event from outside, performing a computation in response to the event, and generating output events.

The patterns describe behavioral patterns both informally and using a formal description technique, communicating extended finite state machines (CEFSMs).

3.2.5.1 CEFSM Definition

CEFSMs consist of a finite set of states and transitions between the states. They communicate with each other via telecommunications paths through signals flow. A CEFSM moves from one state into another by an input event while performing actions during the transition. For a transition, the system must receive an event from environment, and then it performs corresponding actions for the event. After the actions, the system produce output signals if it has something to notify to the environment. We consider deterministic behavior, which means that the system has only one next state for an event.

3.2.5.2 Basic EFSM

A CEFSM can be represented by a state transition diagram that is a direct graph whose vertices correspond to states and whose edges correspond to transitions. Figure 3-6 shows a basic CEFSM and its state transition diagram in which there are two states, S1 and S2, and two transitions. The arrow without a source state points to the initial state S1, and the arrow indicates the initial transition describing the actions and output signals during initialization. Transitions that do not alter the state are indicated by an arc that points to itself. The transition is labeled with an event, action list, and output signals. It is denoted by event (parameters)/actions/outputs. The event may have parameters passing information from other entities. Note that all events except the event of initial transition are mandatory while actions and outputs of transitions are option. The ‘-’ symbol in a transition indicates that there is no corresponding value at that field.

Figure 3-6 Basic of EFSM

3.2.5.3 Predicates

A CEFSM can have predicates to control the behavior of the CEFSM so that some similar states can be grouped to reduce the total number of states. Upon receiving an event, the machine checks a predicate that is composed of variables, logical operators such as AND, OR, and comparison operators such as equal to, less than, and greater than. If the predicate is true, the entity performs actions and produces output signals if it has something to notify to the outside entities. In short, the CEFSM with predicates decides its next behavior based on the predicates.

In the CEFSM with predicates, an event is followed by predicates to decide next transition. But in some cases decisions need to be made after performing some actions.

In other words, after performing a sequence of actions for an event, an entity decides its next transition depending on the result of the actions. So the entity needs predicates after the actions. Figure 3-7 shows a state transition diagram for this type of CEFSM in which there are four states, S1, S1', S2, and S3. Note that the actions2 and outputs2 of the transition from state S1 to state S1' is followed by the predicates predicate1 and predicate2. The control goes to a transition depending on the result of predicates. Note also that the transitions from S1' do not have an event field.

Figure 3-7 EFSM Of Predicate After Action

3.2.5.4 Timers

A CEFSM can be supplemented with timers and timer-related operations.

During a transition, the entity sets a timer with a time value. If the timer is not cancelled by the entity, the timer will generate a time expiration signal after the time duration has been exceeded. Generally, the entity handles the time expiration by either sending an error notification or requesting a resubmission of the event. When an event that is wanted by an entity occurs before the time expiration, the entity cancels the

timer and proceeds normally. There are two timer-related operations, set and reset. Set (v, T1) associates a time value v with a timer T1. Reset (T1) cancels the associated timer T1.

The CEFSM with timers has the same definition as the basic CEFSM except it includes timers and operations for the timers. Timer is an element of variable set.

Figure 3-8 shows a CEFSM with a timer and its state transition diagram. During the initial transition, a timer T1 is set with a time value v. On timeout for the timer T1, the entity moves to the state S2 performing actions actions2 and outputting signals outputs2. If the entity receives an event e that is wanted by the entity, it resets the timer and then performs the remaining transition.

Figure 3-8 CEFSM With Timers

3.2.5.5 Translation Into SDL

The translation of a CEFSM into SDL can be done by a mechanical one-to-one mapping. Figure 3-9 shows an SDL diagram fragment for the basic CEFSM of Figure 3-6.The initial transition is converted to a start symbol and a state symbol S1. The initialization actions actions1 and output signals outputs1 are located between them. A transition is represented by an input signal, tasks, and a sequence of output signals of SDL. In the figure, when the state S1 receives an input event with a parameter p, it performs a task actions2 and outputs outputs2. Figure 3-10 shows an SDL diagram fragment for the basic CEFSM of Figure 3-7. Figure 3-11 shows an SDL diagram fragment for the basic CEFSM of Figure 3-8.

Figure 3-9 Translation Of Basic CEFSM Into SDL

Figure 3-10 Translation Of CEFSM With Predicates After Action Into SDL

Figure 3-11 Translation Of Predicates After Actions Into SDL

CHAPTER 4

DEVELOPMENT METHODOLOGY FOR COMMUNICATION SYSTEM

In our thesis, we integrate much concept of design methodology to implement a communication system, like wireless protocol in MAC layer and provide a design flow to verify our design step by step. The design flow starts with specification analysis based on the protocol that we want to implement. We do some verification for the protocol to guarantee the performance of algorithm. After it, we plan the architecture of the protocol and use functional verification with SDL modeling to verify the system. And then translate the SDL model to C or C++ model.

4.1 Specification Analysis

In our thesis the specification is the protocol in WiMAX MAC. This specification forms the basis for analyzing the system requirements and for the high-level description of the system functionality. From the specification the first high-level formal description is generated. This description depicts systems functionality, in most cases, as a hierarchical mixed data/control flow diagram.

System-level simulation or formal verification achieves validation and exploration of algorithms and systems functionality. The purpose of this phase is to analyze the architecture of the system. Essentially the issue of the system analysis is to find out what are the objects needed to implement to meet the requirements of the system.

4.2 Architecture Design

The second step is to refine high-level inter-module communication, including protocol selection. Some design alternatives needed to be identified and need to meet the system constraints. The choices of architecture are made by the user generally.

Once the architecture is decided, the functional specification is mapped into an abstract architectural model. This model may include one or more process.

According to the system we want to design, we need to consider many issues, like verification environment, protocol design with communication system and object-oriented and reusable module design. After considering the issues, we start to work out our architecture to achieve the objectives we proposed.

4.3 SDL Modeling

During this part of the design process, the requirements of the analysis are transformed to a formal specification. The formal specification is a full functional specification in SDL. An automated transformation of requirements to SDL leads to an integrated co-design specification in SDL.

Simulation in the phase will help us understand and debug the behavior of our system. The simulator comprises a code generator and a simulator library. The library comes in versions for discrete simulation, real time simulation, and simulation including the system environment.

The main purpose of the SDL is to specify the behavior of systems, which may include the use of data if necessary. First, the logical view describes the functions and services that the system provides to its end users. Secondly, the process view describes the network of independently executing processes that comprise the system, and how they interact and synchronize. SDL specification includes a set of hierarchical block interaction diagrams. Blocks communicate through delaying or non-delaying channels. Each block is defined with a set of SDL processes communicating through nondelaying signal-routes. Each SDL process is an independently executable entity. The SDL flattening function converts the hierarchical block diagrams into one diagram consisting of interacting SDL processes.

This flattened SDL system specification diagram provides a process view of the entire system’s software architecture. Third, the physical view describes the mapping of the software components to the hardware. The rule for using SDL to specify software architecture in physical view is to put the processes of different computers on different blocks communicating through delaying channels. Fourth, the development/structural view describes the static modular structure of the software code.

A typical screenshot of RTDS with a SDL system diagram, system organizer and simulator is shown in Figure 4-1 and Figure 4-2. The timing constraints, i.e.

deadlines, event streams and event dependencies, are annotated to the SDL specification.

Figure 4-1 RTDS and Project Manger

Figure 4-2 SDLRT Debugger

4.4 System Synthesis

In Figure 4-3, we show an overview of the rapid prototyping design process.

And in out design stage, the SDL tool we used is RTDS ( Real Time Development Suite ) that is provided by PragmaDev. The synthesis flow starts with a specification in SDL, using the RTDS for editing, syntax checking and functional level simulation.

After this, Code Generator provided in the tool chain of RTDS translates the SDL semantic to C language or C++ language. In the Code Generator, there are many options of different RTOS ( real-time operating system ) that developers can choose to meet requirement of the target system. Besides, after code generated, we can add some function call coded by hand to the design of C or C++ model. If the design can not meet the requirement, we can optimize the design through buffer management, data management and timer management. Finally, generate the binary code (image) by compiler and linker and then port the binary code to the verification platform, like PC or embedded system.

Through the synthesis flow we can simplify our loading in system level design by Code Generator. And if we have another target platform to port, we can easily translate the SDL to C code according to the RTOS we want to port.

Figure 4-3 Rapid Prototyping Design Process

CHAPTER 5

A CASE STUDY: WIMAX MAC BS

5.1 Motivation

Cause the WiMAX MAC BS is complicated in the protocol and the architecture, we need to provide an analysis of protocol and the modulization of the architecture to achieve the module reusable and design effort reducing. Due to the implementation of communication system in detail not considering in previous introduction, we need to develop a methodology to realize IEEE 802.16d MAC protocol by integrating the concepts of SDL, the protocol and server model.

5.2 Behaviors Correspond To Wireless Environment

Due to WiMAX belong to a wireless communication protocol, we could verify the transmission behavior in software and make sure that the behavior in software is the same in wireless environment. According to the protocol in the MAC layer and the behaviors in WiMAX, we add some features to meet the operating requirements in software.

5.2.1 Transmission Behavior In MAC Layer

Considering the implementation of wireless environment, we it is difficult to represent the actual transmission behavior in the software platform shown in Figure 5-1. In order to the SDL implementation, we compare the actual behavior of a system operation and data transmission in SDL wireless environment. According to the specification and concept of SDL, the behavior of such a system is based on software functional verification. But in TCP/IP reference model, we find the data is transmitted from layer to layer in which MAC layer pass the data through PHY layer by channel coding and modulating scheme. Afterward, PHY layer deliver the data to every subscribe station through air medium. Due to our system is to verify the protocol in MAC layer, we will not consider the behaviors in PHY layer.

Base on our assumption, we utilize the concept of transmission between BS MAC to SS MAC in ideal environment shown in Figure 5-2. This assumption can be utilized in the software platform to verify the functions in SDL. We transmit data burst from BS MAC to SS MAC through the simulated channel. Through our proposed channel, we can add some assumption features to make our verification environment more completed. The features we added are about the transmission

behavior in WiMAX such as the transmission behaviors between broadcast and unicast and between contention period and contention free period.

Figure 5-1 Real World

Figure 5-2 SDL World

5.2.2 Broadcast And Unicast

Transmission behaviors in downlink can be separate to two types. One is to

Transmission behaviors in downlink can be separate to two types. One is to