Re: m-block timeouts, time passed, or

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.

Thanks.

  • David Li

Eric B. wrote:

What your asking for would be hard to do using the existing
framework.
I still don’t understand where you want to do this from. That is,
which code would be making the determination that it was time to
pause

or unpause the timer.

For instance, a new node enters a backoff state and decides that it
needs to wait for the channel to be idle for 10ms before it can
transmit
(802.11 like). It starts a one shot timer for 10ms, and with each
new
RSSI reading from the PHY, which comes at variable times due to
processing and queues, the protocol checks if the new RSSI reading is
greater than some CCA threshold. If it’s greater, it needs to pause
the
timer because the timer represents the time at which the node must
wait
when the channel is idle, not busy. Once the RSSI drops below the
CCA

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 :slight_smile:

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

David Li wrote:

Hi George,

I browsed through cmac.cc and got a few questions:

  1. Can you explain more about “Without m block to gr block connection,
    all raw samples are forced thru the MAC layer”?

Ahhh I need to change that comment. That comment is no longer true.
The samples hit the PHY first, and the PHY sends the MAC a bit stram.

  1. What kind of applications are needed to interface with your MAC code
    to do CS configuration and data transfer/receive?

Right now there is nothing to actually connect with the TCP/IP stack.
The test applications are GNU Radio applications.

  1. What are those PMT related macros? Perhaps it’s easier if there
    exists documentations explaining the current mblock implementation.

Right… the PMT is a polymorphic type that was implemented in GNU Radio
to simplify data passing in the m-blocks. It’s not actually in any of
the m-block documentation. I think this is documentation that would be
extremely beneficial. I will write up some documentation on PMT in the
GNU Radio wiki and send out a link tonight or tomorrow.

  • George

Hi George,

I browsed through cmac.cc and got a few questions:

  1. Can you explain more about “Without m block to gr block connection,
    all raw samples are forced thru the MAC layer”?

  2. What kind of applications are needed to interface with your MAC code
    to do CS configuration and data transfer/receive?

  3. What are those PMT related macros? Perhaps it’s easier if there
    exists documentations explaining the current mblock implementation.

The bottom line is this is interesting enough and I 'd like to give it a
try. You can email the directions to me offline.

Thanks.

  • David

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs