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 broadcast the messages with broadcast CID, 0XFFFF, to all SSs and another is to broadcast data burst of unicast or multicast CID to correspond SSs. The transmission behaviors of the two types in wireless environment are the same due to the broadcasting. But with the software verification, we cannot broadcast the data to all SSs at the same time. So the transmitting data burst using broadcast or unicast are done by software methods. The broadcast in software means copy data to all devices or nodes in proper sequence and the unicast in software means copy data to one device or node. The behavior is shown in Figure 5-3. We can use this behavior on our verification platform to validate the data burst is actually received by two sides. When BS starts to transmit within broadcast period, BS copy data to all SSs. On the other hand, if the BS transmits data burst within unicast period, the BS copy data burst to

correspond SS only. The transmission behavior has some defects for degrading the system performance due to transmit data bursts more times within broadcast period.

5.2.3 Contention Period and Contention-Free Period

The UL sub-frame can be separated into two parts, contention region and contention-free region. The contention region is used to support users for initial ranging and bandwidth request. As the definition of contention, there might have multiple users sending the same CDMA codes simultaneously on the same resource units of the contention region. In that case the collisions will happen so that the requests transmission to BS will be fail. In order to reduce the probability of collision, the back-off procedure is defined in IEEE 802.16d standard, in which when the collision happened, the SSs select a random back-off timer for next transmission.

Consequently, the collision probability will be reduced significantly. In contention-free region, each subscribe user will transmit data in the burst assigned by BS in UL_MAP.

For the same reason, the software can’t allow the data burst transmitted at the same time during the contention period. To verify the behavior of detecting collision during contention period, we need to add some tags that not specified in the SPEC.

The tag shown in Figure 5-3 is the slot number, which SS predicts to transmit during contention period. Each SSs transmit the CDMA code tagged a slot number to BS through channel. The channel has the ability of collision detecting by receiving the CDMA codes from each SS. When the channel receive the same CDMA codes tagged the same slot number during the contention period, it can determine the CDMA codes are collision and discard the CDMA codes. Or channel passes the CDMA codes of no collision to BS.

Figure 5-3 Channel Behavior

5.3 Architecture Design

For MAC protocol design, we provide a guideline to modulize the functions of the protocol. We can briefly divide the functions of MAC into control plane and data plane. According to different protocols in wireless communication, we can partition the functions into some necessary parts and optional parts to modulize the functionality of MAC shown in Figure 5-4. Afterward, we analyze functions of each module to show the flow we proposed.

5.3.1 WiMAX BS MAC Protocol Model

We find the protocol and the architecture of MAC have the same property in wireless communication. Based on the properties and functions in MAC layer, we can divide the properties into data processing and message processing for data plane and control plane.

The data plane deal with the packets fragmented from upper layer to lower layer and the bursts defragmented from lower layer to upper layer. The basic components of data plane are fragment, defragment, assembler and classifier and the optional component are ARQ or other functions provided by other protocol. With our implementation, ARQ is supplement in WiMAX MAC. We can replace the ARQ component with other functions when we apply the architecture to other protocol.

The control plane is responsible for the negotiation with other devices through message passing. To complete the negotiation in MAC layer, there are many functions to go through, like message analysis, producing and flow control. Based on the basic processes of control plane, we divide it into two parts. One is called message management responsible for message analysis and producing, like FCH, DCD, UCD, REQ and RSP. Another is called control mechanism responsible for flow control, like network entry, handover, dynamic service, and timer management. As long as we have some flow control functions that need to add to the protocol of MAC, we can add it to the control mechanism and add some correspond functions of message analyzing and processing to the message management.

Although we can divide the functions of MAC into data plane and control plane, there are still some functions that can’t be divided clearly, like uplink scheduler and downlink scheduler. Cause the two schedulers deal with the bandwidth arrangement for downlink sub-frame and uplink sub-frame and the arrangement involve data fragmentation and messages collection, we need to reconstruct the flow between fragmentation and scheduler to fit the requirement of scheduling policy. So we put the fragment and concatenation together inside the downlink scheduler. On the other hand, to simplify our implementation, we put the uplink scheduler isolated to collect the bandwidth requests and schedule uplink bandwidth. If implementation need, we still