Establishment of IP Connectivity, Time of Day and Transfer Operational Parameters

A managed SS will invoke the DHCP mechanisms to obtain the IP address and obtain the time and other transfer operational parameters from time server and TFTP server through the secondary management connection. After completing all the parameter adjustments, the SS will transmit a TFTP complete (TFTP-CPLT) massage to the BS. And then the SS will transmit the dynamic service addition request (DSA-REQ) to request to setup the provisioned service flows. The downlink service connection will be maintained just after the DSA-RSP is sent from the BS and the uplink service connection will be maintained just after the DSPACK is sent from the SS. Besides, the dynamic service addition is possible to be requested by the BS. All the messages exchange between the BS and the SS during the initialization process are shown in Figure 2-5.

CHAPTER 3

OVERVIEW OF SPECIFICATION AND DESCRIPTION LANGUAGE

This chapter discusses the applications and method for the use of specification and description language (SDL). Recent years, the size of produced software has increased dramatically. More and more systems are multi-process and distributed, and they execute in a heterogeneous environment. It is increasingly accepted within a steadily growing range of industrial segments that the best way to meet the needs of these systems is through formal methods. Therefore, the formal methods should be internationally standardized. Telecommunications software engineers have developed such methods and tools for the development of complex real-time software.

3.1 Theoretical Model And Structure

3.1.1 Definition

Specification and description language (SDL) is an object-oriented, formal language defined by The International Telecommunications Union–

Telecommunications Standardization Sector (ITU–T) as recommendation Z.100. The language is intended for the specification of complex, event-driven, real-time, and interactive applications involving many concurrent activities that communicate using discrete signals.

3.1.2 Theoretical Model

The basic theoretical model of an SDL system consists of a set of extended finite state machines (FSMs) that run concurrently. These machines are independent and communicate each other with the discrete signals. An SDL system consists of the following components: 1) Structures like system, block, process, and procedure hierarchy. 2) Communication signals with optional signal parameters and channels or signal routes. 3) Behaviors like processes. 4) Data structures like abstract data types.

3.1.3 Structures

In SDL system, we divide a system into a system, block, and process hierarchy is called partitioning a system depicted in Figure 3-1. The objectives of partitioning include the following:

• Hide information and move the detail into lower level.

• Create a correspondence with software.

• Reuse the existing specifications.

Figure 3-1 SDL Structure-System Block Process Procedure

The structure of a system is defined in terms of blocks and channels. A block is defined as a module with the model of black box. The model of black box is defined with the process and the signal route concepts. A process is an independent device that reacts to process the signals.

Each SDL process type is defined as a nested hierarchical state machine. Each sub-state machine is implemented in a procedure. The procedures can be recursive and they are local to be a process or they can be globally available depending on their scope. SDL processes have separate memory spaces. This is a highly important aspect that dramatically reduces the number of deficiencies and increases robustness.

3.1.4 Communication

SDL does not use any global data. SDL has two basic communication mechanisms. The first is asynchronous signals and the other is synchronous remote procedure call. Both mechanisms can carry parameters to interchange and synchronize information between SDL processes and the SDL system with the environment.

Figure 3-2 SDL Communication Interface

In Figure 3-2, SDL defines a clear interface between blocks and processes by means of a combined channel and signal route architecture. This communication architecture with formally clear signal interfaces simplifies large team development and ensures consistency between different parts of a system.

SDL defines time and timers in a smart and abstract manner. Time is an important role in all real-time systems and also in most distributed systems. An SDL process can set timers that expire within certain time periods to implement timeout events when exceptions.

When an SDL timer expires, the process that started the timer receives a notification in the same way when it receives any other signal. Actually an expired timer is treated exactly as a signal. SDL time is abstract that it can be efficiently mapped to the time of the target system as an operating system timer or hardware timer. This makes it possible to simulate time in SDL models before the target system is available. Other aspects of the signaling concept in SDL are as follows:

Signal and process priorities are not within the scope of SDL. These issues are left instead to the implementation phase where the user with special directives can assign signal and process priorities. An SDL signal can only be sent to one specific process instance at a time. To enable broadcasting the user can include a package with some general-purpose functions that will provide a broadcasting mechanism in the implementation.

3.1.5 Behavior

A process itself is specified as an extended finite state machine (EFSM, Figure 3-3) that consumes incoming signals and in turn produces output messages. The behavior in an SDL system is described in the processes. The system/block hierarchy is only a description of the system structure. Processes in SDL can be created at system start or created and terminated at run time. More than one instance of a process can exist. Each instance has an unique process identifier (PId). This makes it possible to send signals to individual instances of a process. The concept is that the processes and process instances that work independently and concurrently.

Figure 3-3 SDL Behavior Model-EFSM

3.1.6 Summary

SDL is a modem high level programming language using object-oriented and graphical design approach that has been used for modeling, simulation and verification of communication protocols for a long time. Especially, SDL is particularly useful in realization of a real-time, interactive and distributed system.

System is described as several processes running simultaneously and communicating via asynchronous signals. Each process is viewed as extended finite

state machine (EFSM) that consists of a number of states and transitions. The state transitions are triggered by receiving a signal from other process with an input queue.

During the state transition, the data manipulation and computation may be executed.

Timer event can also be configured to generate signals automatically at pre-defined period. A FIFO (First-In- First-Out) input buffer in each process is used to queue the received signals and also the timer events.

The hierarchical structure of SDL system allows the decomposition of a large system into blocks and processes. Signal exchanges between blocks are through channels, and from one process to another via signal routes. A process may contain lowest level components in the functional hierarchy, known as procedures.

Hierarchical structure is important for modularization in protocol stack design. Each smaller process and block can be separately developed, verified, implemented, and maintained as individual components. The resulting protocol structure is extendible and reusable.

3.2 SDL Modeling For Protocol Architecture

3.2.1 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.

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.