Changes between Initial Version and Version 1 of 802.11/FAQ

Timestamp:

Jul 23, 2013, 11:14:14 AM (11 years ago)

Author:

chunter

Comment:

--

802.11/FAQ

@@ +1 @@
+= 802.11 Reference Design: FAQ =
+
+== What parts of the 802.11 standard are implemented? ==
+Our implementation focuses on the OFDM PHY and DCF MAC. We tried to choose a subset of these specifications which are feasible to implement and provide the most utility to wireless networking researchers. We plan to continue developing the design. Feedback is welcome on which features in the standard would be most useful in future releases.
+
+The IEEE 802.11 standard is huge ([http://standards.ieee.org/getieee802/download/802.11-2012.pdf 2700 page PDF]). Implementing the entire standard on WARP is infeasible, and frankly not all that useful as a research tool.
+
+The specifics of the current implementation are discussed below.
+
+=== PHY Specs ===
+The PHY implementation is based on the OFDM PHY specified in section 18 of of the 802.11-2012 standard. This PHY is commonly referred to as "802.11a" (at 5GHz) and "802.11g" (at 2.4GHz). Our implementation is OFDM-only (with one exception; see below).
+
+'''Bandwidth:''' 20MHz
+
+'''OFDM Specs:''' 64 subcarriers (48 data, 4 pilots), 16-sample cyclic prefix
+
+'''Frame Format:''' As specified in section 18.3.2 of 802.11-2012:
+  * Preamble (10 repetitions of 16-sample short training symbol, 2.5 repetitions of 64-sample long training symbol)
+  * SIGNAL field as first OFDM symbol (3 bytes as BSPK, rate 1/2 code)
+  * Remaining OFDM symbols filled with SERVICE field (2 bytes) and payload (up to 1500 bytes) at one of the rates listed below
+
+'''Rates:''' The following OFDM data rates are implemented. Each data rate is realized by a combination of modulation and coding rates.
+||=  Modulation[[BR]]Rate  =||=  Code[[BR]]Rate  =||=  Data Rate[[BR]](Mbps)  =||
+||  BPSK  ||  1/2  ||  6  ||
+||  BPSK  ||  3/4  ||  9  ||
+||  QPSK  ||  1/2  ||  12  ||
+||  QPSK  ||  3/4  ||  18  ||
+
+The following rates will be implemented in a future release:
+
+||=  Modulation[[BR]]Rate  =||=  Code[[BR]]Rate  =||=  Data Rate[[BR]](Mbps)  =||
+||  16-QAM  ||  1/2  ||  24  ||
+||  16-QAM  ||  3/4  ||  36  ||
+||  64-QAM  ||  2/3  ||  48  ||
+||  64-QAM  ||  3/4  ||  54  ||
+
+The PHY receiver also implements the 1Mbps DSSS rate specified in the original 802.11 standard (section 16.2 of the 802.11-2012 standard). This receiver allows reception of management frames transmitted by 802.11 devices at 1Mbps. These transmissions are common in deployments of 802.11 hardware at 2.4GHz. For example, Beacon and Probe Request frames are frequently transmitted at 1Mbps by commercial devices. The basic STA/AP association handshake requires reception of these frames.
+
+The current WARP 802.11 ref design does not implement a DSSS transmitter, as 802.11 devices are able to receive management frames at higher rates (including 6Mbps, the lowest OFDM rate, which is commonly used for management frames at 5GHz).
+
+'''Synchronization:''' Our PHY implementation requires no "cheating"- all synchronization is implemented in the FPGA and operates per-packet in real-time.
+ * The AGC block selects Rx gains per-packet and makes no assumptions about inter-packet receive powers.
+ * The CFO (carrier frequency offset) block estimates and corrects CFO per-packet. CFO estimates are extracted from the preamble long training symbols and correction is applied pre-FFT.
+ * The symbol sync block establishes sample-level synchronization using a complex cross correlator tuned to the preamble long training symbols. All Rx timing is established per-packet based on the correlator output.
+ * The channel estimation block computes a complex channel estimate (magnitude and phase) for each subcarrier per-packet. The equalizer applies the channel estimate per-subcarrier. The current Rx PHY uses the same channel estimates for the full packet. Extending this to a decision feedback scheme (where channel estimates are updated intra-packet) would be a straightforward extension. 
+
+'''Multi-antenna support:''' The current PHY Tx/Rx pipelines are SISO, supporting only the modulation/coding rates specified in section 18 of the standard. The PHY implementation does support Tx and Rx antenna selection per-packet. The active Tx interface is selected per-packet by the PHY control code. The Rx interface can be selected per-packet by code or automatically per-packet based on AGC gain settings. This Rx mode is a basic implementation of receive selection diversity.
+
+
+
+=== MAC Specs ===
+The MAC implementation is based on the DCF (distributed coordination function) protocol specified in section 9.3 of the 802.11-2012 standard. This design does not implement the PCF (point coordination function) in section 9.4 of the standard.
+
+
+'''Frames:''' The MAC specification defines many frame formats in section 8 of the 802.11-2012 standard. Our implementation supports a sub-set of these frames.
+
+'''Data/ACK:''' Data and ACK frames are of course supported.
+
+'''Management Frames:''' The following management frames are supported:
+ * Beacon
+ * Probe Request
+ * Probe Response
+ * Authentication
+ * Deauthentication
+ * Association Request
+ * Association Response 
+ * Reassociation Request
+ * Reassociation Response 
+ * Disassociation
+
+'''Handshakes:''' The standard defines many inter-node handshakes for many combinations of ad-hoc and infrastructure networks. Our current MAC implementation supports the common association handshake required for a STA (node) to join the network of an AP. This handshake consists of:
+
+||=  STA  =||=  Direction  =||=  AP  =||
+||  Probe Request  ||  →  ||  ↓  ||
+||  ↓  ||  ←  ||  Probe Response  ||
+||  Authentication  ||  →  ||  ↓  || 
+||  ↓  ||  ←  ||  Authentication  ||
+||  Association Request  ||  →  ||  ↓  || 
+||  •  ||  ←  ||  Association Response  ||
+
+'''RTS/CTS:''' Support for the RTS/CTS handshake is not currently implemented (it will be soon)
+
+
+----
+== What encryption schemes are supported? ==
+None.
+
+This could be an interesting future extension, but falls way outside our areas of expertise. 
+
+
+----
+
+== Is the WARP 802.11 Reference Design Wi-Fi CERTIFIED™? ==
+No.
+
+Wi-Fi® is a trademark of the [https://www.wi-fi.org/ Wi-Fi Alliance], an industry association which seeks to ensure compliance and inter-operability of wireless networking equipement. Our design is intended to be a starting point for researchers, not a wireless device for end-users. The whole point of this design is to enable experiments with extensions to the standard. Pursuit of Wi-Fi CERTIFIED™ status doesn't facilitate this.
+
+----
+
+== How is the WARP 802.11 Reference Design licensed? ==
+
+The MAC and PHY used in the WARP 802.11 Reference Design are distributed under the terms of our [wiki:../License Research License]. Please 
+
+Please see the [wiki:../License Research License] for the formal license agreement.
+
+It is our intention that users should be free to do the following:
+ * Use the Reference Design for teaching and academic research
+ * Modify the Reference MAC and PHY source code
+ * Publish results from experiments using the Reference Design
+ * Share customized source code with other users of the Reference Design
+
+
+
+
+----
+
+== What hardware is supported? ==
+The WARP 802.11 Reference Design is supported on Mango WARP v3 hardware.
+
+Previous generations of WARP hardware are not supported, as the design requires tools and FPGA features which preclude porting to Virtex-II Pro or Virtex-4 FPGAs.
+
+The [wiki:../License Research License] requires the design only be used on hardware supplied by Mango Communications. If you're interested in using the 802.11 Reference Design on different hardware, please contact Mango to discuss alternate license terms.