Key-Words: - Wireless, Physical layer, WIMAX, Baseband processing, Software Defined Radio.

Transcription

1 A Novel Approach in Implementation of the WIMAX-D Physical Layer Receiver Blocks BABAK D.BEHESHTI Telecommunications Networks Management New York Institute of Technology Northern Blvd, Old Westbury, NY USA Abstract: - The design flow and methodology for hardware centric radio baseband processors is well established and understood. However, migration to a software centric baseband processor approach is still new to many designers. The paradigm shift of viewing real time events from the point of view of gates and registers to pointers and memory offsets is not often easily grasped. This paper covers a new design flow appropriate for complete software driven baseband processor using the Sandblaster flexible baseband processor. This paper provides an overview of the radio interface physical layer requirements of WIMAX. Worldwide Interoperability for Microwave Access was defined by the WIMAX Forum formed in WIMAX is defined in the IEEE standard. Wireless MAN Standards-based technology enable the delivery of last mile wireless broadband access as an alternative to Cable and DSL. This paper then presents the implementation of the current WIMAX standards on a second generation flexible baseband processor. The implementation will be limited to the receiver chain blocks and will be entirely in ANSI C, written for a fixed point digital signal processor. The underlying assumption of this implementation is to avoid any hardware accelerators that would make the platform for the baseband processing become standard specific. The SB3500 is the second generation of SandBlaster-based low power, high performance System on a Chip (SoC) products developed to serve the Software Defined Radio (SDR) modem applications space. It is a multi-core device, containing 3 'SBX' DSP cores. The software implementation of WIMAX physical layer includes implantation of OFDM and receiver chain processing in ANSI C. The projected processing requirements of a WIMAX terminal on the SB3500 are presented with the expected number of cores needed for the data rates analyzed. The down-sampling filter used for the initial Synchronization and for the fine synchronization, FFT block, and Channel estimation for each reference symbol are included in this analysis. The specific architectural features of the SB3500 and the compiler optimizations to yield a real time software implementation of WIMAX are also presented. Key-Words: - Wireless, Physical layer, WIMAX, Baseband processing, Software Defined Radio. 1 Introduction Reconfigurable radio systems are radios that can change to different communication protocols as they move between different radio environments. An example would be moving from a wireless LAN b to a and then to EV-DO (Evolution Data Optimized). Researching the development of a Reconfigurable Radio Architecture that will concurrently support multiple radio protocols over multiple frequency bands across multiple wireless networking environments is an active area of R&D in the industry. The Reconfigurable radio realizes the convergence of computing and communications by allowing a flexible communications for any handheld computing device. As more digital processing is applied to the radio system, the promise of software based digital baseband processors controlling a reconfigurable RF front end approaches reality. Software Defined Radios (SDRs) offer a dynamically reprogrammable method of reusing hardware to implement the physical layer processing of multiple communications systems and applications. SDRs can dynamically change protocols and accept communications systems and applications updates over the air as quickly as a service provider requires this update. Rapid implementation of numerous multimedia applications and multiple wireless communication protocols is easily accomplished on a single programmable platform utilizing an SDR baseband processor. Furthermore, enhancing the terminal capabilities with new protocols, applications, and functions is achieved through over-the-air dynamic software downloads. This capability reduces product feature support cost, time-to-market, and

2 risk while increasing handset OEMs and ODMs R&D and manufacturing productivity. Software Defined Radios (SDRs) have the potential of changing the fundamental usage model of wireless communications devices. These transceivers are often conceptually divided into two major sections: the Baseband Processing Section and the RF Front End. This division is simply a matter of convenience as the technological states of the two sections are at different stages. The baseband section which is responsible for all symbol level and bit level computations is typically implemented as reconfigurable hardware architecture or a digital signal processor (DSP). The SDR Forum defines five tiers of solutions. Tier-0 is a traditional radio implementation in hardware. Tier-1, Software Controlled Radio (SCR), implements the control features for multiple hardware elements in software. Tier-2, Software Defined Radio (SDR), implements modulation and baseband processing in software but allows for multiple frequency fixed function RF hardware. Tier-3, Ideal Software Radio (ISR), extends programmability through the RF with analog conversion at the antenna. Tier-4, Ultimate Software Radio (USR), provides for fast (millisecond) transitions between communications protocols in addition to digital processing capability. 7. High level partition the code into software threads (tasks) using the API provided by the operating system used. 8. Using the simulator supplied with the tool chain, and possibly an event viewer examine latency requirements 9. Repartition threads as necessary - balance system load 10. Final system integration and hardware testing As can be seen in Figure 1 below the development effort is front loaded, where the cost and risk to system changes are significantly lower than the back end. This significantly reduces risk and development time as well as allowing for tremendous visibility into the implementation because of the host base development environment. 2 Design Flow The design flow for a SDR based baseband processor is somewhat different from the traditional hardware based designs. This design flow relies heavily on host based development throughout the development cycle removing the sequential nature of dependency on the hardware platform availability to make fine-tuning of system performance. The general steps in the development of any air interface waveform using this methodology are listed below: 1. Physical Layer Algorithm Development (floating point) using MatLab, 2. Translation to fixed point ANSI C 3. Simulate for algorithm accuracy in fixed point/ use debugger to debug code 4. Modify code as necessary 5. Profile code for MIPS/MHz requirements 6. Optimize specific functions as necessary (only in C) Figure 1 SDR Based terminal Design Flow Figure 2 shows the Sandblaster tool chain. The platform is programmed in a high-level language such as C, C++, or Java. The program is then translated using an internally developed supercomputer class vectorizing, parallelizing compiler. The tools are driven by a parameterized resource model of the architecture that may be programmatically generated for a variety of implementations and organizations. The source input to the tools, called. the Sandbridge architecture Description Language (SaDL), is a collection of python source files that guide the generation and optimization of the input program and simulator. The compiler is retargetable in the sense that it is able to handle multiple possible implementations specified in SaDL and produce an object file for each implementation. The platform also supports many standard libraries (e.g. libc, math, etc.). The tools are then capable of producing dynamic and static simulators. A binary translator/compiler is

3 invoked on the host simulation platform. From these inputs, it is possible to produce a statically compiled simulation file. If the host computer is an x86 platform, the translator may directly produce x86 optimized code. If the host computer is a non-x86 platform, the binary translator produces a C file that may subsequently be processed using a native compiler (e.g. gcc). Figure 2 - Sandbridge Software Development Tool Chain For the dynamically compiled simulator, the object file is translated into x86 assembly code during the start of the simulation. In single-threaded execution, the entire program Dynamically compiled single threaded simulation translation is done at the beginning of the execution phase. Regions of target executable code are created. For each compound instruction in the region, equivalent host executable code is generated. Within each instruction, sophisticated analysis and optimizations are performed to reorder the host instructions to satisfy constraints. When changes of control are present, the code is modified to the proper address. The resulting translated code is then executed. 3 The Target Baseband Processor The SB3500 is the second generation of SandBlaster-based low power, high performance System on a Chip (SoC) products developed to serve the Software Defined Radio (SDR) modem applications space. As was the case for the prior generation product (the SB3011), it too is a multicore device, however containing 3 'SBX' DSP cores (as opposed to 4), and an ARM926 processor, all interconnected by a high speed network (HSN). The ARM is intended to support protocol stacks and OS function, in addition to all the peripheral device support (such as SDIO, LCD, Camera, USB, PS/2, Smart Card, UART, DMA, AC-97/I2S, Vector Interrupt Controller, GPIO's) and external memory interfaces (Static & Dynamic Memory Controllers). The SBX DSP's each support a high rate Parallel Streaming Data (PSD) interface for the IQ baseband data, and possess the control interfaces (SPI, I2C, interrupt/timer functions, GPIO's) that are typically seen in most radio Front Ends; they are intended to serve the primary function of Mbps wireless radio baseband data processing in software, making for a 'standards agnostic' radio platform. Architecture is defined as the minimal set of properties that determine what programs will run and what results they will produce. It includes the system s functional appearance to its immediate user. It also contains the system s conceptual structure and functional behavior as seen by one who programs in machine language. Architecture concerns the specification of function provided to programmer - addressing, arithmetic, interruption, I/O, etc. Implementation is the logical organization of dataflow and controls. This is sometimes termed organization or micro-architecture. In effect, implementation is the method to achieve the function - parallel datapath, microprogrammed control, etc. Realization is the physical structure embodying the implementation. It is the means to materialize the method - electrical, magnetic, mechanical, optical devices, etc. It is important to be aware of the above distinctions as the SB3500 architecture is discussed. The working store for the SBX core is broken into three spaces: General purpose registers (r) Vector registers (vr) Accumulator registers (acc). The general purpose register file contains 16 entries of 32 bits each. A 16-bit datatype occupies bits 0 to 15 and a 32-bit datatype occupies bits 0 to 31. The vector register file contains eight entries. In SB1, each register file entry is 160 bits, treated as four 16-bit or four 40-bit elements. The SB3011 implementation contains 4 cores each of which has 8 copies of the register state (e.g. 8 threads) for a total of 32 threads and 32 complete copies of the register state. In SBX, each entry is 256 bits and is treated as eight 32-bit vector elements or sixteen 16-bit vector elements. For backward compatibility, four 16-bit

4 and four 40 bit-elements are mapped into each 256- bit entry. Arithmetic is provided for all data types. Operations are available for all scalar and vector types. Some mixed mode support such as multiply signedunsigned is provided. Optionally results from certain operations may be saturated for proper DSP style execution. Particularly, saturation of dot-product-type operations in 4-element vector form produces results guaranteed to be equivalent to serial execution of the operations with saturation after each operation. Thus, with a saturating dot product, four 16-bit elements are multiplied, saturated, added, and then saturated again as if they were scalars. Notably, the 16-element saturating vector dot-product-type operations in Sandblaster 2.0 do not follow this convention but instead maintain maximum precision at each intermediate stage in the computation. Note that the 4-element saturating form is still available in the SB2 architecture. Of notable improvements in this generation of the Sandblaster core one should cite a flexible 16- wide vector processing unit that could execute all the identified algorithms at the desired performances. The key kernels used to drive the design of this SIMD (Single Instruction Multiple Data) unit were derived from the various 3.5G and 4G standards/proposals and includes FIR, Pilot search, Descrambling, Despreading, Derotation, Complex Correlation, complex FFT ( points), Viterbi (constraint length 7 & 9), Turbo, and LDPC. Logical operations are provided for And, Or, and Exclusive-or functions. Vector versions of these are also available including a vector nand. Additionally, vector compare operations set a mask register which can be used to select between elements of a vector. Shift operations are provided both in logical and saturating form. Synchronization is performed with load locked and store conditional operations. From these basic primitives many conventional software synchronizations may be constructed including semaphores. Transfer of control is typically accomplished by a jump operation which may be dependent upon a condition or a compare and branch compound operation which first performs the comparison and then determines if a branch is to be taken. A call instruction is provided with automatic saving of the instruction address register. For many DSP (or streaming) applications it is desirable to loop a number of times on the same set of operations. If scalar architectures are used the number of scalar names in conjunction with typically visible pipelines precludes the usefulness of looping type operations. Each core delivers a peak of 9.6Gmacs/s once operated at 600MHz. The SB3500 therefore is capable of triple this amount or 28.8Gmacs/sec. The element-wise operations supported in this SIMD unit include common operations such as logical, shift and arithmetic operations that read 2 registers, which perform 16 short or 8 integer operations in parallel, and write the results back to a third register. An example would be the element-wise add integer operation, radd32 for(i=0; i<8; i++) vt[i] = va[i] + vb[i]; Complex multiplies treat the register file contents as though they were alternating short real and imaginary values, so that a register contains 8 short complex numbers. A complex multiply uses 4 short (16 bit) multipliers, so implementing 8 complex multiplies in parallel would have required 32 multipliers. Instead, the SBX core s complex multiply operations multiply either the upper or lower halves of 32 bit registers together, writing the complex product to the upper or lower half of the result register. One group of operations is used to implement fastfourier transforms (FFTs). These operations do 4 complex multiplies a cycle, producing 8 complex elements of the result. Consequently, the SBX provides exceptional performance for FFT operations as an inherent architectural feature. The hand written code for the various size complex FFTs yield instruction cycle counts as listed in table below.

5 FFT Size Instruction Cycle Count 64 Points Points Points Points 4736 Figure 3: FFT Cycle Counts Galois field arithmetic support is provided by operations that do polynomial multiply, multiplyreduce and multiply-and-add and compute polynomial-modulus. Viterbi decoding adds operations that perform 16 Viterbi butterflies in parallel, reading 3 registers (2 for the state and 1 for weight) and writing the resulting state into 2 registers. Turbo decoding is supported by operations that compute the forward, backward and likelihood values. The turbo-decode operations assume that the constraint length of the convolutional coders is 3. Furthermore the SBX core is composed of 4 concurrent hardware thread processing units with independent clocking and context registers. Together with a native operating system that provides a POSIX pthreads API for software thread creation to run on these hardware threads, significant parallization of algorithms and tasks can be exploited. The SB3500 offers a pool of 12 hardware threads through its three SBX cores 3 Overview of WIMAX The WIMAX spectrum is defined in the 10 to 66 GHz frequency range. The 2.5 GHz spectrum is being targeted for use in the US. There are two major versions of WIMAX: IEEE d Fixed WIMAX, and IEEE e Mobile WIMAX. This paper focuses on the fixed WIMAX implementation. Figure 2 illustrates the data rate specifications of WIMAX as compared to the 3G and 3.G wireless standards currently standardized or being developed. WIMAX is defined for Line-Of-Sight (LOS) propagation with a maximum range of 70 Km. For non-line-of-sight (NLOS) propagation, the maximum range reduces to 15 Km. The physical layer uses OFDM (Orthogonal Frequency Division Multiplexing) means to overcome challenges in NLOS type environments. The WIMAX waveform then can operate in large delay spread environments (cyclic prefix). It can also withstand selective fading (due to multiple narrowband orthogonal carriers). The data rates supported are 2.9 Mbps to 70 Mbps, even though practically achievable data rates range about 10Mbps at 10 Km. AT the 2.9 Mbps raw bit rate, corresponding useful data rate will be 2.4 Mbps. At this rate mapping is BPSK. Other important parameters are the sampling Frequency of 16 MHz, number of symbols per frame being 26 (24 data symbols, 1 4x64 Preamble, 1 2x128 Preamble), number of subcarriers being 256 (192 - data subcarriers, 8 - pilots, 56 unused subcarriers) and the guard band comprising 64 subcarriers (effectively 1/4 of 256). The symbol Duration is 40 microseconds (1500 thread 150 MHz), consequently resulting in 620 samples per symbol (in case of oversampled by 2). Bits/Second GPRS EDGE WCDMA HSPA HSPA+ LTE Figure 4: Wireless Standards Evolution Orthogonal Frequency-Division Multiplexing (OFDM) is a multi-carrier modulation scheme that utilizes a number of closely-spaced orthogonal subcarriers as the channel for transmission of information. These sub-carriers may indeed overlap in frequency. However they are selected such that there is no interference among them. FFT (Fast Fourier Transform) is used on the transmit side to break up the time sequence into frequency content for the sub-carriers. On the receiver side, IFFT (Inverse FFT) is used to recombine the sub-carriers back to the single time sequence. After the FFT on the transmitter side, each sub-carrier is modulated with a conventional modulation scheme (BPSK, QPSK, ) at a low symbol rate. The low symbol rate along with the large number of sub-carriers allows for data rates similar to conventional singlecarrier modulation schemes in the same bandwidth. The main advantage of OFDM over single-carrier schemes is its ability to cope with severe channel conditions. Channel equalization on the receiver side is significantly reduced in complexity as an OFDM signal is simply a collection slowly-modulated narrowband signals. Another advantage of OFDM is Technology DL

6 that its relatively low symbol rate allows for placement guard intervals between symbols. This in turn reduces the effects of smearing of one symbol onto its immediate neighbors, also called intersymbol interference (ISI). The key to unique performance of OFDM is in the orthagonality of the subcarriers to one another (hence the O in OFDM). Orthogonality is the property of the subcarriers such that there is no inter carrier interference (ICI) among them. The orthogonality also allows high spectral efficiency, approaching the near the Nyquist rate. A major disadvantage of OFDM is that any slight offset between the transmitter and receiver frequencies severely affects the ability of the receiver in extracting the information from the received signal. This is because with frequency deviation, the sub-carriers can no longer be orthogonal. Therefore OFDM requires very accurate frequency synchronization between the receiver and the transmitter. Figure 5: OFDM Orthogonality of sub-carriers An OFDM frame is basically a group of symbols. If a TDD mode is used, a certain number of symbols are allocated for the downlink subframe. Following downlink transmission, a gap is specified by the Transmission Time Gap (TTG) parameter. The TTG is adjusted for timing delays and distance. It allows the transmitter at the BS to switch from transmit to receive mode and vice versa for the terminal. At the end of the frame, there is another gap called the Receive Time Gap (RTG) before the next frame begins for the same purpose. The downlink subframe begins with a preamble that is transmitted for one symbol time. The preamble enables the terminal to acquire the system and keep synchronization. Figure 6: WIMAX Frames 4 Implementation and Performance The receiver chain for the WIMAX-D terminal was implemented as follows: 16 tap FIR filter at the A/D converter output, followed by decimation by 2 (to overcome the oversampling), FFT size point, Viterbi Decoding block length bits input and 88 bits output, followed by miscellaneous functions. The software thread assignment is as follows: IQDMA (1 thread). This thread manages the receiving of the data from A2D. FIR (2 threads): One thread filters the input I stream and the other filters the input Q stream. AGC (1 thread): Tracks the strength of the input signal and adjusts the input gain accordingly. Derotate (1 thread): Performs the frequency correction in baseband based on the computed freq offset. FFT stage 1 (1 thread): Performs the initial sync functions during startup and the first FFT stage during steady state. FFT stage 2 (1 thread): Performs the second FFT stage during steady state. Channel Estimation (1 thread): Computes channel transfer functions, frequency offsets and timing offsets. Viterbi threads (7 threads): Performs channel correction, de-mapping, de-interleaving and convolution decoding. Descrambler (1 thread): Performs descrambling on the convolution decoded data. The I filter and Q filter threads get I and Q data, respectively, from the IQDMA thread. The derotate thread and AGC thread both use the output of the two filter threads. The AGC thread computes the I^2 + Q^2 value and attempts to normalize it by changing the receiver gain. The gain is adjusted by setting a particular register. The derotate thread passes its data down the pipeline. The data flows in this linear fashion until the extract subcarrier thread. This thread outputs data to one of seven channel correction threads in round robin fashion, i.e. to

7 channel thread 3, 4, 5, etc. Each of the seven threads outputs data to the descrambler, which is the last stage of the pure receiver. The descrambler may signal a MAC thread to receive its data if the MAC_LAYER flag is turned on. All pairs of consecutive stages have double buffering implemented. Timing: Since each symbol arrives every 1500 thread cycles, it is necessary for each thread in the receiver to process its data in 1500 cycles and pass it along to the next stage. Note that threads after the pure receiver do not need to take 1500 cycles - this is due to the fact that they operate on multiple symbols at once. For example, an mpeg encoded image uses 66 symbols (approx 1/15 sec), so the threads in the mpeg chain must take up to 66*1500 cycles. IQDMA thread Receives the data from the input I and Q streams and DMAs the data into local memory of filter threads I Filter thread 16 tap filter that performs decimation filtering (decimation by 2) on I stream data De-rotation thread Performs de-rotation on the decimated I and Q data streams to correct for frequency offsets FFT Stage 1 FFT Stage 2 Channel Estimation Computes Channel Transfer function, Frequency offset and Timing offsets Incoming I and Q data streams from the A2D Q Filter thread 16 tap filter that performs decimation filtering (decimation by 2) on Q stream data AGC thread Computes the signal strength on the decimated I and Q data streams to perform AGC Viterbi Viterbi Viterbi Viterbi Viterbi Viterbi Viterbi De-scrambling Decoded Data Viterbi Block * Channel Correction *De-mapping * De-interleaving * Viterbi decoding Figure 7: WIMAX Processing Chain Calculation of MHz numbers is performed as follows. Assume based on standards specifications, the time required to complete activity xyz is Nmsec. Using the coding style guidelines write the optimized C code for activity xyz. Use the profiler tool determine the number of thread cycles used to execute this activity (num_cycles). Viterbi: The RPU (SIMD unit of the DSP core) coded half rate viterbi algorithm has been implemented for wimax (64 states). The RPU instructions are used for the forward path traversal. The viterbi code uses the rhvits class of instructions. The instruction rhvits2 uses an accumulator (act), mask register (mr), and 4 vector registers: one input (vb = h*0*0), two state (vt, va), one output (vc = 0*h*1). It performs 16 viterbi butterfly pairs, each reading from two state elements and writing back to two state elements. The weight calculated for each butterfly is computed by multiplying the first two input values (vb[0], vb[1]) by +/-1, depending on the bits of the mask register. Every butterfly also outputs two path bits indicating which path was chosen for the two state elements written. In total, 32 path bits are computed by the instruction. These bits, represented as two shorts, are shifted into the output register. The instruction rhvits2r also performs a half rotate of the input register as the final step. The instruction rhvitsa2 is identical to rhvits2 except that vb[2], vb[3] are used as the input values instead of vb[0], vb[1]. Each viterbi instruction calculates 32 new state values via 16 butterflies. For the 64 state viterbi it takes two cycles per output bit for the forward computation. The 256 state viterbi would take 8 cycles per output bit, but since not all state vectors can be kept in registers at once, there is additional load/store overhead. With the overhead the computation load is approximately 16 cycles per output bit. Filter The filters use the rmulreds class of instructions, in particular rmulreds1r. This instruction uses an accumulator (act) and four vector registers: two inputs (va, va^0x1), one coefficient (vb), one output (vt = s*act). It performs a saturated multiply and reduce of two registers (one input register and the coefficient register) with the output placed in the accumulator. The previous value in the accumulator is shifted into the output register. The input registers are rotated by 1. For the decimation by 2 filter, the instruction rmulreds2r is used which rotates the input registers by 2. Algorithm

8 FFT The FFT class of instructions all perform 4 complex butterflies. The instructions rfft0s, rfft1s, and rfft2s use 3 vector registers in the following manner: one output (vt), one input (va), and one weights (vb). A butterfly involves a pair of complex inputs used with one complex weight to compute a pair of complex outputs. The three instructions differ in which input, output, and weight indices are used. The instruction rfft0s uses consecutive pairs of inputs and writes to consecutive pairs of outputs. It should be used for the first FFT stage. The instruction rfft1s uses alternate pairs of inputs and writes to alternate pairs of outputs. It should be used for the second FFT stage. The instruction rfft2s uses pairs of inputs with a stride of 4 and writes to pairs of outputs with a stride of 4. It should be used for the third FFT stage. The instructions rfftls and rffths should be used for all subsequent FFT stages. They use 3 vector registers in the following manner: two input/output (vt, va), one weights (vb). For each butterfly, one complex input is used from vt and one complex input is used from va, and the complex outputs are written back to same locations in vt and va. The instruction rfftls uses the lower half of vt and va for inputs and outputs, while the instruction rffths uses the upper half of those vectors. Performance For an N point FFT, each stage requires N/2 complex butterflies, and there are logn stages in total. Since each FFT instruction performs 4 complex butterflies, each stage requires N/8 FFT instructions. For the first 4 stages, there are no additional load/store penalties. For all subsequent stages, it takes 11 cycles per 8 FFT instructions for a total of 11N/64 cycles per stage (approximately N/6 cycles). Therefore a good estimate for the total number of cycles for an N point FFT is (N/8)*logN for N <= 16 and (N/8)*log(16) + (N/6)*(logN - 4) = (N/2) + (N/6)*(logN - 4) = (N/6)*logN - (N/6) for N > 16. Note that this does not include bitreversal which must be performed before the main FFT algorithm. Bitreversal takes 20 cycles per 64 complex elements shuffled, or 20N/64 for an N point FFT (approximately N/3 cycles). The final formula for cycles in an N point FFT is: (N/8)*logN + (N/3), N <= 16 (N/6)*(logN + 1), N > 16. Duo Bit Turbo Decoder The turbo decoder has been implemented using RPU instructions for Wimax (double binary). Algorithm The double binary turbo decoder algorithm is used to decode the outputs of the wimax turbo encoder. The encoder is composed of two double binary RSC encoders concatenated in parallel. The inputs to the encoder are sent as data couples to the the first RSCE, through an interleaver to the second RSCE, and directly as outputs of the encoder. Each RSCE outputs a parity stream. Therefore there are three output streams from the encoder, the input stream (termed systematic) and the two parity streams, each of which is composed of pairs of values. The outputs of the decoder are the best guess of what the inputs to the encoder were, given only the noise corrupted output streams of the encoder. The turbo decoder uses these three streams to iteratively compute likelihood values for its outputs. After a predetermined number of iterations, the likelihoods are used to make a hard decision on the outputs. Each iteration is composed of two half iterations. A half iteration uses as input the systematic values, one of the two parity streams, and input likelihoods. It produces output likelihoods which are interleaved and used as input likelihoods for the next half iteration. Within a half iteration the following values are computed: Alphas: For each input pair, an alpha (8 state) vector is computed from the systematic input pair, parity input pair, likelihood input, and previous alpha vector. For the first iteration, the initial alpha vector is set to have all states equally weighted. In all subsequent iterations, the initial alpha is set to the final alpha calculated in the previous iteration. Alphas are computed sequentially in a forward pass, from the first input to the last. Betas: For each input pair, a beta (8 state) vector is computed from the systematic input pair, parity input pair, likelihood input, and previous beta vector. For the first iteration, the initial beta vector is set to have all states equally weighted. In all subsequent iterations, the initial beta is set to the final beta calculated in the previous iteration. Betas are computed sequentially in a backward pass, from the last input to the first. Likelihoods: For each input, a likelihood output is computed from the alpha vector, beta vector, and parity input pair. Since likelihood outputs have no dependencies, they can be computed in any order. Code Details The turbo code can be compiled for forward or backward computation mode. In forward computation mode, alpha states are computed and stored for each input in the first (forward) pass. In the second (backward) pass, beta states are computed for each input but not stored. The computed beta state is combined with the

9 corresponding previously computed and stored alpha state to generate the likelihood value for that input. In backward computation mode, the backward pass is done first with the beta states computed and stored. The forward pass is done next, with the alpha states computed but not stored, and the likelihoods generated from the computed alpha state and corresponding previously computed and stored beta state. In either case, memory storage is reduced as only alpha or beta states need to be stored. The completion of both passes over all inputs constitutes one half iteration. The final calculated likelihoods for a half iteration are scrambled according to a fixed interleaver and used as the input likelihoods to the next half iteration. We therefore obtain the following performance on the SB3500: Software Block MHz I Filter 12.5 Q Filter 12 Derotation 15 AGC 11 FFT Stage FFT Stage Channel Estimation 14.5 Channel Correction and Convolutional Decoding Descrambler Total Figure 8: WIMAX Performance 5 Comparison to Other Methods This concept has been studied extensively recently and has been named Software Defined Radio or SDR. As the name implies, all algorithms and control code are implemented in software, running on a special purpose microprocessor, called a Digital Signal Processor (DSP). Therefore, the 18 month design cycle for the custom ASIC (Application Specific Integrated Circuit) is removed from the process, reducing the time-to-market to the handset manufacturer substantially as well as reducing the design costs. Moreover, should any design error or bug be discovered in the handset design after deployment in the field, a mere software download of the corrected software (over the air, via the Internet to an infrared port, etc. will fix the problem, eliminating significant cost to the manufacturer. 6 Conclusion Please, follow our instructions faithfully, otherwise you have to resubmit your full paper. This will enable us to maintain uniformity in the conference proceedings as well as in the post-conference luxurious books by WSES Press. The better you look, the better we all look. Thank you for your cooperation and contribution. We are looking forward to seeing you at the Conference. References [1] H. Liu, T. Zhang, Y. Zhou, A Novel Iterative Channel Estimation Algorithm for OFDM Systems, WSEAS Transactions on Communications Issue 8, Volume 5, August 2006, ISSN [2] S. Lee, H. Chen, M. Lin, Y. Kao, A Robust CD3-OFDM Receiver Architecture for DSRC Systems, WSEAS Transactions on Communications Issue 8, Volume 5, August 2006, ISSN [3] K. Oteng-Amoako, S. Nooshabadi, Design of a Modified Bi-Directional SOVA, WSEAS Transactions On Communications, Issue 11, Volume 6, November 2007, ISSN: , [4] D. Iancu, H. Ye, M. Senthilvelan, V. Kotlyar, J. Glossner, S. Agrawal, S. Jinturkar, A. Iancu, G. Nacer, S. Stanley, and J. Takala, Hand Held Analog Television over WiMAX executed in SW, The SPIE- IS&T 18th Annual Symposium on Electronic Imaging (EI 2006), Multimedia on Mobile Devices II Conference (EI124), San Jose, California, U.S.A., January 2007, edited by Reiner Creutzburg, Jarmo H. Takala, Chang Wen Chen, The International Society for Optical Engineering (SPIE) Vol [5] S. Mamidi, M. J. Schulte, Zaipeng Xie, M. Sima, D. Iancu and and J. Glossner, Arithmetic Units for Software Defined Radio, Accepted for publication in Proceedings of the Fortieth Asilomar Conference on Signals, Systems, and Computers, November, [6] D. Iancu, H. Ye, V. Kotlyar, M. Senthilvelan, J. Glossner, G. Nacer, and A. Iancu, Analog Television, WiMAX and DVB-H on the Same SoC Platform Proceedings of the International Symposium on System-on-Chip (ISSOC 06), Tampere, Finland, November, [Paper (pdf 100kB)]. [7] R. Kalavai, M. Senthilvelan, S. Agrawal, S. Jinturkar, J. Glossner, Implementation of GSM/GPRS Physical Layer on Sandblaster DSP, Proceedings of Software Defined Radio Technical Forum (SDR Forum '06), Orlando Florida, November, [Paper (pdf 164kB)]. [8] B. Beheshti, Analysis of a Physical Layer Wireless Communication System Implementation

10 on an SDR Baseband Processor, proceedings of the WSEAS Conference, February, 2006, Madrid, Spain. [9] B. Beheshti, T. Raja, Software Defined Radio Implementation Considerations and Principles Using the Sandblaster SDR Baseband Processor, Proceedings of Software Defined Radio Technical Forum, November, 2005, Anaheim, California. [10] D. Iancu, J. Glossner, V. Kotlyar, H. Ye, M. Moudgill, and E. Hokenek, Software Defined Global Positioning Satellite Receiver, Proceedings of the 2003 Software Defined Radio Technical Conference (SDR 03), HW-2-001, 6 pages, Orlando, Florida, [11] J. Glossner, D. lancu, J. Lu, E. Hokenek, and M. Moudgill, A Software Defined Communications Baseband Design, IEEE Communications Magazine, Vol. 41, No.1, pp , Jan., [12] J. Glossner, S. Dorward, S. Jinturkar, M. Moudgill, E. Hokenek, M. Schulte, and S. Vassiliadis, Sandbridge Software Tools, in Proceedings of the 3rd International Worksop on Systems, Architectures, Modeling, and Simulation (SAMOS.p3), July 21-23,2003, pp , Samos, Greece. [13] Van Nee and Prasad, OFDM for Wireless Multimedia Communications, Artech House Publishers, ISBN , 2000 [14] Ghosh, A. Wolter, D.R. Andrews, J.G. Chen, R., Broadband wireless access with WiMax/802.16: current performance benchmarks and future potential Communications Magazine, IEEE, Feb. 2005, Volume: 43, Issue: 2, pages: , Toronto, Ont., Canada, ISSN: [15] The IEEE Working Group on Broadband Wireless Access Standards, [16] WiMAXForum, Babak D. Beheshti is a member of faculty in the School of Engineering and Computing Sciences, New York Institute of Technology since Babak has over 18 years of experience in R&D for embedded systems and wireless technology industry, where he has successfully managed wireless opportunities with many Asian, European and US companies. Babak has been an active member of IEEE since 1991 having held positions such as Northeastern Region Student Activities Chair, IEEE Tellers Committee Chair, and Signal Processing Chapter Chair. Babak is a recipient of the IEEE Millennium Medal and two IEEE Region 1 Awards. Babak earned his BEEE and MSEE from Stony Brook University in 1985 and 1987, respectively. Babak is a senior member of the IEEE and has numerous conference presentations and publications..