What I got from your paper is that the matched filter approach for
fast packet detection would not work in an OFDM setting. What about
fast ACK generation? Would it require an IFFT implementation on the
USRP? Would it help much?
It's a good question, and something I haven't explored, and I'm not much of a DSP guy. So, I'll punt the question to everyone else who has more DSP experience than me. Both are all about signal detection, both the fast-packet detection and fast ACK generation. So what you want to do is first detect the preamble in the USRP without decoding (because it's complex and takes long). So, we propose using a matched filter on the USRP to detect the packet preamble. In 802.11ab, the preamble was done with BPSK (even if the data is sent using OFDM in 802.11a). With 802.11g, it can be a full OFDM preamble. So, with a full OFDM preamble, you can still detect it with a matched filter, but I'm a little unclear about how to generate the coefficients. You essentially are detecting in the time domain with the matched filter. It might require an IFFT on the USRP... anyone? Dan? :)
> This all said... I really think we need a better interface to reduce
> latency. Some platforms take the: run on the board approach, such as WARP
> which puts the MAC on a core on the board. Good luck conjuring up $10-15k
> just for a single WARP board plus frontends though :P
>
Is there anything that would prevent GNUradio developers to push the
MAC layer functionality on the USRP?
The USRP and USRP2, from what I understand, are both tight for space in the FPGA. I'm pretty confident you can't fit an OFDM implementation on the USRP. There are free multipliers and space on the USRP2, but I think it would also be tight, leaving you with not much room for the MAC. Then, you'd be building the MAC in verilog which sucks. Most people who want to do MAC development have CS backgrounds, not EE backgrounds, form which Verilog is black magic ;)
- George