discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss-gnuradio] in-band signaling & dependent packets (i.e., ACK gene


From: George Nychis
Subject: [Discuss-gnuradio] in-band signaling & dependent packets (i.e., ACK generation)
Date: Tue, 27 Nov 2007 17:17:03 -0500
User-agent: Thunderbird 2.0.0.6 (X11/20071022)

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]