You are not logged in.
Our wireless networking group is looking into WARP as a potential prototyping platform for our research. I have a few questions on existing support in terms of MAC/PHY protocols already implemented.
1. I noticed some implementations of MAC (e.g. CSMAMAC) in the repository. Is there any existing MAC or PHY (or both) implementation compliant to 802.11 a/b/g standard? If not, is there an ongoing effort for the same? (Reading through the past forum posts, I go an impression that there is no 802.11 impl. - but I want to be sure)
2. Assuming that there is no compliant 802.11 implementation for WARP currently existing (or in works), can anyone point to some of the existing implementations that can be useful in building both PHY and MAC implementations which confirm to 802.11a/b/g? Basically, for those familiar with the existing ones, the question is whether any such effort will have to start from scratch or are there useful building blocks already present (I think CSMA MAC and RTS-CTS MAC, OFDM implementation can be leveraged -- but I am not certain)? Also, hopefully all the source code is available through the repository?
3. What are the major design components or features (that do not exist currently), do you foresee as major challenges in coming up with the 802.11 implementation (e.g., lack of queues, high resolution and real-time timers, etc)?
4. Does the WARP platform have the capability to match the commercial NIC performance of 802.11? In other words, is there any physical limitation in achieving highest throughput for 802.11a/g (54Mbps at PHY, ~30Mbps application layer)? 802.11b type throughput (11Mbps) must be achievable as I read through the forums- am I correct?
Any help is appreciated.
Thanks,
Ashwini
Offline
hi Ashwini-
1) The current PHY/MAC designs don't implement the 802.11 standard. This is something the whole WARP community would be very interested in, but it's not an effort we're working on right now.
2-3) Our PHY design overlaps quite a bit with 802.11a (or OFDM-only 11g). We use the same FFT size, same cyclic extension, same preamble length, etc. I think most of our front-end (packet detection, AGC, CFO, etc.) could be used for an 802.11 PHY. But there are a few key differences that would require some design effort to address:
-Our frame format is different (we use a single 24-byte header, for example).
-We use channel training symbols distinct from the preamble. 802.11a uses the LTS in the preamble for channel estimation. We needed more symbols to build the spatial multiplexing MIMO mode.
-Our data scrambling sequence is different. Also, 802.11 uses an interleaver in addition to scrambling.
4) We have successfully tested a 64-QAM link over-the-air, capable of throughputs comparable to 802.11. Our design's bandwidth is currently 10MHz, though we'll have a 20MHz version working soon. The hardware can easily support these kinds of datarates. The current limitation is just in the PHY processing; for example, I'm pretty sure our CFO and phase noise tracking systems can be improved to make 64-QAM work even more reliably.
All of our source code is in the repository. There are a few of us working on various pieces simultaneously. As we get new versions of the code and cores working together, we post updated OFDM reference designs. We're hoping to post v12 in the next week or so.
Offline
Hi All,
We are thinking of developing 802.11a/b/g/n/p in your WARP platform. We have already read this thread, but we have still some doubts.
1--> Could you please detail us the main blocks needed to change apart from the ones mentioned in post #1?
2--> WAVE or 802.11p works in the frequency band from 5.85 to 5.925 GHz. We have already read that the 5Ghz band implemented in the RF transceiver reach up to 5.875 Ghz. Would it be possible to use your current Radio Board to implement WAVE?
3--> 802.11p standard defines a frame field that allows changing the transmission power individually for each packet. Could it be possible to do that with your current block design, or the transmission power is fixed for every packet?
4-->Since the current WARP implementation defines PHY and MAC layers, I assume that the rest of the layers run in the PC connected via ethernet, is that right? So, related with this question, does the WARP platform run autonomously or does it require PC support?
5-->We are preparing our WARP order, could you guide us about what kind of individual WARP boards are mandatory apart from FPGA and Radio boards?
Thanks in advance,
uwicore_6
Offline
1) I haven't studied the 802.11 PHY standard in enough detail to say exactly.
2) The MAX2829 transceiver on the radio board covers only up to 5.875GHz (see its datasheet for more details).
3) This is definitely possible. The Tx power is controlled either via a SPI register write to the MAX2829 (handled by our WarpRadio_v1_TxVGAGainControl function) or via digital pins on the MAX2829. Both methods can adjust the Tx power on per-packet timescales. See the MAX2829 datasheet for details on the power control range and setting times for various carrier frequencies.
4) The WARP hardware is capable of implementing more than just the PHY and MAC. The second PowerPC could be used to implementing routing and transport layer functionality, for example. Our research doesn't require this, so it's not built into the reference designs we post.
5) The minimum configuration is a SISO kit (1 FPGA board, 1 clock board and 1 radio board). Multiple-antenna PHY design requires 1 radio board per antenna, so a 2x2 link would require 2 MIMO kit (1 FPGA, 1 clock, 2 radios each). Analog boards are also very useful during PHY development and debugging. The OFDM reference design, for example, routes the equalized I/Q signals to analog board DACs. This allows us to visualize the received constellation in real-time on an oscilloscope. See our latest demo video for an example of this.
Offline
For the benefit of anyone arriving here via a Google search, the Mango 802.11 Reference Design implements most of the features requested in the older discussion above.
Offline