FREE Subscription to Dr. Dobb’s Digest: Same Great Content, New Digital Edition
Site Archive (Complete)
Development Tools
Email
Print
Reprint

add to:
Del.icio.us
Digg
Google
Furl
Slashdot
Y! MyWeb
Blink
January 01, 2007
Creating an Executable Specification for the WiMAX Standard

The scope and complexity of the 802.16 standard makes it difficult to ensure that WiMAX designs are standard-compliant. This article explains how to build a Simulink model that enables continuous test and verification throughout the development process.

(Page 1 of 2)
Mike Mulligan, The Mathworks
The scope and complexity of the 802.16 standard makes it difficult to ensure that WiMAX designs are standard-compliant. This article explains how to build a Simulink model that enables continuous test and verification throughout the development process.
In January 2006, the WiMAX Forum announced the first products to complete the rigorous test procedures required for IEEE 802.16-2004-compliant certification. The IEEE 802.16 standard ensures compatibility and interoperability between broadband wireless access components. Nearly 900 pages long, it is a comprehensive document that describes both the physical layer and the media access control layer for WiMAX systems.

The scope and complexity of the standard creates challenges for designers of standard-compliant components. Model-Based Design with Simulink addresses these challenges by placing a system model at the center of the development process—from requirements capture to implementation and test. The model is an executable specification that functions as an interactive test harness throughout the design workflow.

In a document-based design approach, requirements are assembled in a product specification that is subsequently elaborated, partitioned, and translated into subspecifications for each design team. Every new document is a translation of the requirements, and can introduce errors or omissions that may not be discovered until compliance testing. An executable specification enables continuous test and verification, making errors of translation much easier to identify and correct.

In this article we use Model-Based Design to build an executable specification for a WiMAX transmitter, focusing on the channel coding described in section 8.3.3. of the standard.

Building and Testing the Channel Coding Model

Since many of a communication standard's technical requirements are mathematical, MATLAB and Simulink are well suited to the task of creating an executable specification. Creating a Simulink model is itself a translation of the WiMAX standard, however, and so we must proceed carefully. Fortunately, section 8.3.3 includes test cases that we can use to build and test our model step by step.

The channel coding section of the WiMAX standard includes five steps: data randomization, forward error correction (FEC), interleaving, modulation, and OFDM symbol creation. Starting with a framework of empty subsystems (Figure 1) we build up the transmitter block by block, using data from the standard to check each block before proceeding.


(Click to enlarge)

Figure1. The framework for the WiMAX transmitter.

In the first WiMAX test case, the input data vector is 35 bytes long and given in hex notation. It is easily expressed in MATLAB using the sscanf function to create a row vector:

input_data =
sscanf(['45 29 C4 79 AD 0F 55 28 AD '...
'87 B5 76 1A 9C 80 50 45 1B '...
'9F D9 2A 88 95 EB AE B5 2E '...
'03 4F 09 14 69 58 0A 5D'],'%x');

This row vector is the source data that we will use to test our model as we incrementally build it. We use a similar technique to import the other test vectors into MATLAB.

As we build each block and run the Simulink model, we compare the generated output with the corresponding test vector. This is a straightforward procedure, but in two places we encounter problems that if unresolved would result in a non-interoperable design.

The first trouble spot comes in the implementation of the Reed-Solomon encoder. The standard states that the Reed-Solomon encoder is "derived from a systematic RS(N=255,K=239,T=8) code" using a variety of shortening and puncturing techniques to achieve different rates. The first test case calls for a RS(40,36,2) code.

Based on the description in the standard, we implement the encoder as a subsystem (Figure 2).


(Click to enlarge)

Figure 2. Reed-Solomon encoder. Click on image to see enlarged view.

Our results, however, do not match the published test vector. Returning to the standard we see that the generator polynomial for the RS(255,239,8) code is explicitly defined. In our design we had assumed that it was the same as the default in our block. We replace the default value with the explicit definition of the generator polynomial in the standard. When we rerun our model and check the results in the MATLAB workspace, the results match.

1 | 2 Fixing the interleaver; building the receiver Next Page
RELATED ARTICLES
No Related Articles
TOP 5 ARTICLES
No Top Articles.



MICROSITES
FEATURED TOPIC

ADDITIONAL TOPICS

INFO-LINK