• 沒有找到結果。

Chapter 4 DEVELOPMENT METHODOLOGY FOR COMMUNICATION SYSTEM

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

can merge the uplink scheduler and downlink scheduler to do the bandwidth allocation together.

In the end, we show our concept of architecture implementation in Figure 5-4.

In later section, we describe the functions of each module with data plane and control plane.

Figure 5-4 BS MAC Protocol Architecture

5.3.2 Data plane

Deconcatenation:

This process handles reception of MAC PDUs in form of PHY-DATA from PHY while validating HCS and CRC, and decryption if needed.

Defragmentation_Depacking:

This process extracts MAC SDUs from MAC PDUs with unpacking and de-fragmentation and delivers them to upper layer in form of MAC-DATA. Extracted

ARQ feedback Information Element (IE) subheaders, and other classified management message PDUs are delivered to the appropriate blocks.

Assembler

This process reconstructs all fragments of SDU to form a complete SDU.

Classifier

This module is used to determine the type of service to be assigned to an incoming traffic. The classification of the incoming data packets is necessary for identifying the service associated with the connection. This identification is based on the IEEE 802.16d.

Fragment:

Responsible for PDU framing is along with packing/fragmentation operation in two versions: ARQ and non-ARQ. Request to send for management-message-PDUs from adjacent blocks, (e.g., ranging messages from Network-Entry block or service control messages from Dynamic-Service-Management), are passed to this block to be shaped as a single MAC PDU for transmission. Header insertion followed by payload encryption and lastly CRC calculation is the ending procedures performed on pass the message through control mechanism to execute the FSM which feedbacks the correspond message. After receiving the correspond message, the process handles all the related functions and set system parameters like CID table, TLV table, service table.

Control_Mechanism Network_Entry:

It conducts the procedures for entering and registering to the network. It follows the initialization flow and maintains the state machines in each stage of the network entry process for signaling appropriate messages.

Dynamic_Service:

It handles configuration and registration functions for preconfigured QoS-enabled service flows and traffic parameters. It also performs signaling functions for dynamically establishing QoS-enabled service flows and modifying the traffic (QoS) parameters of them.

UL_Scheduler:

It is used to schedule the uplink resources between the connections with pending request. The Uplink Scheduler prepares a broadcast message (UL_MAP) containing the identifiers of all the connections being granted to transmit in the current frame.

DL_Scheduler:

It calculates the grants allocated in the downlink direction according to Downlink Queues state and the periodic grants generated in downlink. It handles queuing of MAC SDUs per CID arriving from upper layer in form of MAC-DATA. It constructs the PDUs from SDUs of each connection's queue according to a prepared scheduling table.

Figure 5-5 Deconcatenation Process

5.3.4 Deconcatenation Process

Shown in Figure 5-5, it starts with receiving the data burst from SS during the UL sub-frame. First, it will obtain many CDMA codes of bandwidth requests or initial ranging from different SSs during contention period. Besides, every SS transmit his own burst in his region according to the UL_MAP during contention free period.

In the BS side, it will acquire two kinds of messages, one is CDMA code from contention period, and the other is burst from contention free period. We will get it with two data paths to make these messages separated. Burst_Deformat will interpret the header of these bursts and discard the burst not belong to the system by extracting CID information. Defragmentation_Depacking let the burst fragmented to PDU and interpret message to be an information message list. CID_Dispatcher will arrange the place where the data to by the CIDs of different type such as basic CID, transport CID, primary CID and so on. This step is to distinguish data and message. Message_Pass handle the interpreted message and pass it to correspond process according to the message type. The data tagged with transport CID will be delivered to Assembler to form a completed SDU belong to different SSs. The message tagged with primary CID or secondary CID such as RNG-REQ, DSA-REQ will be transported Message_Management. And bandwidth request header will be leaded into the UL_Scheduler. In another part of this process, the CDMA_Code_Recv is mainly deal with the CDMA code from different SSs. It receives and interprets the CDMA code and then directly passes it to the Message_Pass.

Figure 5-6 Message Management And Control Mechanism Process

5.3.5 Message Management And Control Mechanism Process

This process consists of two major components shown in Figure 5-6, one is Message_Management, and the other is Control_Mechanism. To modulize and distinguish between each function, we separate the control method and message producing into two components. The first component Message_Management handles all the control messages. It read the information of interpreted message and produce correspond message. The second component Control_Mechanism consists of Network_Entry, Handover, Dynamic_Service Management. The functionalities of these function blocks are to manage the flow control of 802.16d without involving message producing and information interpreting. Moreover, there are two parts in the Message_Management. REQ is responsible for receiving the request message from SSs. RSP is responsible for producing response message to different SSs. After REQ understanding the message, it will pass the message to one procedure of Control_Mechanism according to the information of message types and CID. Then the procedure of Control_Mechanism will feedback a response message to RSP.

Finally, RSP produces a complete message format and store parameters in User_Information_Base according to the respond message. Timer management is a timing control mechanism. It handles all the actions related time of the system like timer setup, timer reset, and timeout. We will discuss this part later.

5.3.6 UL Scheduler Process

The purpose of UL_Scheduler is to arrange the uplink bandwidth and make UL_MAP. The process shown in Figure 5-7 will be discussed in the latter.

• Step1, when UL_Scheduler receive the bandwidth request from Deconcatenation, BWR_Dispatcher differentiates between different service type and store these requests into correspond service queues. On the other side, there is a message from Control_Mechanism requesting for bandwidth reserved.

• Step2, Catch_BWR start schedule the bandwidth requests from different service BWR queues using scheduling algorithm. Furthermore, periodic ranging and polling service is a mechanism of reserving bandwidth. These functions respond correspond actions based on different situations.

• Step3, according to remained bandwidth and scheduling algorithm, the User_Dispatcher arranges the bandwidth requests from polling service and BWR queues to store into USER queues.

• Step4、5, it collects the bandwidth requests from USER queues and make a UL_MAP passing to DL_Scheduler.

Figure 5-7 BS UL Scheduler Process

5.3.7 DL Scheduler Process

The purpose of DL_Scheduler is to arrange the downlink bandwidth and create DL_MAP. The process is described in Figure 5-8.

• Step1, we see there are three messages, control message, UL_MAP and SDU from Message_Management、UL_Scheduler and Classifier. After formatting the control message and delivering UL_MAP to DL_Scheduler, SDUs are classified to different SDU queues based on CID type and are grouped in different users.

• Step2、3、4 is a loop, this part manage downlink bandwidth and arrange downlink packets appropriately. Step 2, Catch_SDU grabs SDU from SDU queues by different scheduling algorithms and passes it to Fragmentation_Packing.

Fragmentation_Packing fragments or packs the SDUs. Step 3, due to the SDU fragmented may not form a completed PDU, create queues to save the uncompleted and completed PDUs. Between two queues, the uncompleted PDUs still wait for next SDU, which has the same CID, and keep on fragmenting or

packing to become a completed PDU. Resource_Management calculates the resource units of the completed PDUs according to the DIUC profile provided by PDU's CID. Step 4, it calculates unused bandwidth. If there is bandwidth remained, it will wait until enough bandwidth can be allocated to form a completed PDU.

• Steps 5、6 and 7 are to make a DL_MAP. It collects all the PDUs from different user queues and messages from broadcast queue and then combine these information into a complete user burst. Afterward, it writes each item in DL_MAP_IE according to the information of user burst. Finally, DL_MAP is completed and store in the broadcast queue.

• Step 8 and 9, they format the burst and then transmit the burst to user based on the CID group.

Figure 5-8 BS DL Scheduler Process

5.4 Implementation with SDL

Considering the implementation in SDL, we need to apply design concepts of SDL to the communication system we proposed. The first is the server model utilized in the communication system shown in Figure 5-9. It provides the flow of the message passing without considering the impact from other functions and the priorities of reaction in each module according to the requirements of real-time. The second concept most influence the operation of the communication system is the optimization of timer management and data structure of message. We provide the timer table to simplify the timer control of SDL shown in Figure 5-10 and describe a data structure for the protocol shown in Figure 5-11. The la is the message flow and time flow in MAC layer shown in Figure 5-12 and Figure 5-13.

5.4.1 Server Model

The characteristic of server model in software is that it acts as a hardware model.

It checks the message in the message queue and executes the actions of the message according the finite state machine. We can model the protocol of WiMAX by the concept of the hardware model. In the hardware model, each module communicates with other modules through the electronic wires. The behavior of hardware acts with a finite state machine and will not stop until the hardware crashes. Because the behavior

It checks the message in the message queue and executes the actions of the message according the finite state machine. We can model the protocol of WiMAX by the concept of the hardware model. In the hardware model, each module communicates with other modules through the electronic wires. The behavior of hardware acts with a finite state machine and will not stop until the hardware crashes. Because the behavior

相關文件