wiki:OFDM/MIMO/Docs/PHYDetails/FrameFormat

MIMO OFDM | Documentation? | OFDM Frame Format

Overview

The frame format for the WARP MIMO OFDM core is based loosely on the frame format specified in the IEEE 802.11a wireless networking standard.

Each frame is divided into four sections:

The actual format depends on the antenna mode:

SISO Frame Format

Alamouti Frame Format

Multiplexing Frame Format

Preamble

The preamble is a hard-coded 320-sample sequence used by the receiver for AGC, carrier frequency offset estimation and symbol timing estimation. The preamble consists of two 160-sample sections. The first is a repitition of 10 16-sample sequences, called short training symbols (STS). The second half is 2.5 repititions of a 64-sample sequence, called the long training symbol (LTS). The preamble is defined in the OFDM models's initialization script.

In SISO mode, the preamble is transmitted only from the active antenna. In Alamouti and multiplexing modes, the preamble is always transmitted from antenna A and optionally from antenna B. This option is controlled by user software.

The preamble is scaled by a programmed constant. This scaling allows the full-scale swing of the preamble (+/-1 default) to match the swing of the IFFT output. The scaling constant is programmed by user software.

Training

The OFDM core uses hard-coded sequence of pseudo-random BPSK symbols for channel training. Each repetition of the sequence occupies a full OFDM symbol period, including the usual cyclic extension. The number of repetitions is programmable but must be known to both the transmitter and receiver ahead of time. The training sequence is defined in the OFDM model's initialization script.

For SISO mode, the programmed number of training symbols are inserted between the preamble and base-rate symbols. For Alamouti and multiplexing modes, the programmed number of training symbol periods are dedicated to channel estimation and are split evenly between the transmit antennas. In all modes, the number of training symbols must be even.

Base Rate

In order to maintain compatibility with nodes communicating over various distances (i.e. capable of communicating at various rates), the OFDM core uses a number of OFDM symbols modulated using a base-rate. The number of base-rate symbols and the assignment of base-rate modulation schemes to subcarriers must be known to both the transmitter and receiver ahead of time. In multiplexing mode, the base-rate symbols are transmitted only from antenna A. In Alamouti mode, the base-rate symbols are transmitted from both antennas using the Alamouti STBC (just like the full-rate symbols).

Generally, these base-rate symbols contain the packet's header, which enables every receiving node to know the packet's source, destination, full-rate modulation and length.

The number of base-rate symbols and base-rate modulation scheme is programmed by user code and must correspond to the length of the header defined by the user's packet format.

Full Rate

The remaining OFDM symbols in each packet contain data modulated at the full-rate. The full-rate modulation schemes are programmable across subcarriers and antennas. The assignment of full-rate modulation schemes to subcarriers and antennas must be known to both the transmitter and receiver ahead of time.

The number of full-rate symbols is calculated automatically by the transmitter based on the modulation rate and packet length specified by user code. The maximum number of full-rate symbols is 2047 (more than enough for very long packets).

The number of full-rate symbols can be zero, enabling the transmission of header-only packets. User code selects this mode by transmitting a packet whose length equals the number header bytes specified during the OFDM core initialization.

Checksums

The OFDM transmitter subsystem includes a checksum calculation and insertion block. This block will overwrite the last two bytes of the header with a 16-bit CRC calculated over the full contents of the base-rate symbols. For packets with full-rate symbols (not header-only packets), the checksum block will overwrite the last four bytes of the packet with a 32-bit CRC calculated over the full packet, including the header. The receiver uses these checksums to assert its good/bad header/packet outputs.

User code must accommodate these checksum insertions by leaving the corresponding bytes empty in packets loaded for transmission, and by ignoring these bytes when processing received packets. The 2-byte header and 4-byte packet checksums must be included in the header and packet lengths provided by user code. This is handled automatically when using WARPMAC.

Last modified 10 years ago Last modified on Aug 30, 2009, 1:09:29 PM