I totally like and support your idea and would love to help realizing
it. Using the timestamp logic inside UHD as a reference is a great idea
that also came to my mind a while ago.
There are a few things from the architecture point of view though that
need to be discussed. Let's take a CSMA MAC as an example, I guess that
goes into the right direction :-) Just having the "if channel free,
transmit packet"-logic inside the FPGA wouldn't make much sense in a
multi-user environment. What would happen is that if the channel is busy
and multiple nodes have packets in their tx queues, they would all end
up sending their packets more or less at the same time after the channel
gets idle again (assuming all nodes are in sensing range). In a
practical system, one would now start to move parts of the CSMA state
machine, i.e the random backoff, into the FPGA. Trying to control this
via UHD is probably a bad idea as UHD's main business is transportation.
I do think we need something like what you have suggested but I am still
a bit puzzled about the right way of implementing it.
Hi Andre,
Yeppp, the idea is to build part of the MAC in to the FPGA... the part that requires low latency operation. So, after the simple "transmit when idle" logic, you put some basic form of back off in to the logic also.
I have a paper which argues low latency MAC functionality should be built in to the FPGA, but controlled from the host, otherwise it's as good as worthless implementing it on the host. If you try to build this part of the MAC at the host, the latency of receiving the channel state (latency from FPGA -> host), making a decision and performing an action (host -> FPGA), completely makes the information stale. You end up with a decision that is something like 1-2ms old, which clearly the state of the channel changes at a more finer-grain than that.
Sooo... you either implement this kind of functionality in a "split" kind of way where the function sits in the FPGA since it requires low latency, or it's as good as worthless ;) I'd rather have some form of carrier sense that's commonly used in some side-FPGA implementation, rather than throwing in the towel and saying GNU Radio and the USRP's architecture can never support something like this that's usable due to the latency. I get tons of e-mails about my split-functionality MAC work, asking if it's usable but it got deprecated along with the m-block, so there is a set of users out there that I think would be happy with some basic usable carrier sense and back-off. Otherwise we're constantly in the: let's avoid the whole idea of support a true MAC thing, and GNU Radio and USRP continue life as a source/sink.