Hi all,
I was looking to kick some discussion to the board to get some ideas
here. The in-band signaling code is likely to be used by many to
research MAC protocols, and one thing crucial to CSMA style protocols
are dependent packets which have very strict timing requirements. For
example, an ACK is a dependent packet, it relies on a DATA packet to be
generated.
Generating these packets using the in-band code and the framing of some
physical layer at the host using GNU Radio will be no problem. However,
the latency across the bus will almost guarantee that these packets will
never be transmitted and received in time to meet the strict timing
requirements of most protocols such as 802.11. I'm not saying we're
trying to meet 802.11 specs, just to giving an example.
So what I would like to discuss are techniques to generating dependent
packets in the USRP without placing the full physical layer in the FPGA.
This would inhibit flexibility, which is a major goal of a development
platform such as GNU Radio. If we wanted to meet 802.11 specs, sure...
we could try this. But it's not our goal. We want the to keep the
flexibility of using any physical layer.
What I had discussed with Jeff (CC'ed) previously when asked how we
would handle these situations, was the possibility of a technique using
some sort of sample pattern matching. I don't know how possible this is
in reality, this is at a level I'm still not very familiar with... but
trying to learn :) There could be space in the FPGA where patterns
could be stored that could be used to look-up incoming streams of samples.
For example, after decoding one frame successfully in GNU Radio, is it
possible that the host has some general idea of what the start of frame
bits and its address look like (given its framing format) in sample
space? If so, it could pass some amount of samples back to the FPGA to
use in pattern matching.
Of course, it is difficult to tell for sure if the packet can be
successfully decoded without going to the host and using the physical
layer. It may turn out that some of the bits are incorrect using a
checksum, for instance, for which an ACK would not be generated.
Generating a false-ACK could have negative impacts, but it is not so bad
as generating an ACK for data not truly destined to you ;) The higher
layers such as TCP could be used to recover from this error. These are
all trade-offs that are great research material for SDRs and packet
radio which can't meet timing specs, in my opinion... which I'd love to
explore.
While we cannot detect for sure whether the full packet can be decoded
properly, SNR and other values could be used to make a ballpark guess.
And again, if we guess wrong OK, it's a performance trade-off that can
have negative impacts if wrong.
Penny for your thoughts. I don't even know how realistic sample pattern
matching is in the FPGA... I'm open to "you're crazy" responses, I don't
typically work at this level. :) But maybe there's some other technique
that could be used to generate these packets without incurring the bus
latency.
- George
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
