David Li wrote:
Hi George,
I am interested in your MAC work. Does it run in the kernel or user
space? Does it interact with IP?
Is there a branch that I can download and play with it? I have two USRP
2400 boxes.
Hi David,
Put your reading glasses on.
To do MAC work in GNU Radio, you need to use the m-blocks which allow
meta-data with message passing in the framework. They're extremely
flexible blocks. These blocks have been officially released with GNU
Radio and I have been using them for quite some time with no issues.
However, to do MAC work, you also need to use what we call inband
signaling. This functionality is a work in progress within GNU Radio
and is scheduled to be released with the next major GNU Radio release.
The inband signaling functionality adds a control channel between the
host and the USRP, as well as meta-data which as passed on the USB
blocks of samples for tighter timing control for TDMA and such.
Additionally, my research group at CMU has made additional FPGA and host
changes to support time-critical common MAC functionality in the FPGA,
with completely control at the host using the control channel. It's
sort of like an addon in terms of functionality of the in-band
signaling. For example, we implement a 96 coefficient matched filter in
the FPGA to support several things:
- squelching of samples to the host until a sequence is detected
(prevents constant demodulation at the host, great for packet detection)
- generation of dependent packets --> for example, when a packet is
detected in the FPGA and it's detected that its for this host, trigger
the transmission of pending samples (like a pending ACK). This reduces
ACK turnaround time, which in turn increases capacity. This could also
be used to generate some sort of synchronization responses in TDMA quickly.
We also implement carrier sense on the board, with control by the host
on a packet basis, to reduce the size of the carrier sense "blind spot"
introduced by the bus latency.
Our goal has been to argue against the traditional streaming based
architecture of software-defined radios, for a new architecture which
can support MAC development.
There are 2 more "gotchas" in terms of GNU Radio. There is no
m-block->grblock connection, which means you can't use 99% of what is in
GNU Radio with the in-band work or our additional work so far. Lastly,
there is no C++ daughterboard control which limits things even further.
I wish I could give a timeline of this functionality being available,
but I have no clue :)
Our group, with the help of Dan (another student at UW), has worked
towards temporary work arounds while waiting on this functionality. We
implemented a hacked up version of GMSK in an m-block, so its the only
PHY currently supported, and we hacked up initialization of the
daughterboards in python and passing the reference to our m-blocks via SWIG.
We have a simple file transfer application working on the USRP with any
daughterboard using a basic CSMA protocol:
https://moo.cmcl.cs.cmu.edu/trac/cmu_sdrg/browser/macs/cmusdrg_macs/trunk/src/lib/cmac.cc
It does addresses, ACK's, ACK timeouts, and carrier sense. Some
students in a class are working on extending it to random exponential
backoff (fairness) and sequence numbers (ACK-loss resilience).
I'm also working on a TDMA MAC right now, sort of layed out here:
https://moo.cmcl.cs.cmu.edu/trac/cmu_sdrg/wiki/TMAC
If you're interested in playing around with it until the missing GR
functionality is implemented, you can contact me off list and I can pass
you a series of patches. That's my own personal support towards my own
work which I want people to use. Once it hits GNU Radio mainstream,
then you will be able to find support on the list.
- George
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio