[Discuss-gnuradio] in-band signaling project overview

[George Nychis]

Hi all,

I've gotten an e-mail asking what exactly is the in-band signaling 
project, and since I'm asking for people to help contribute... I think 
that's a fair question for me to answer :)

Overview:

We're making significant changes in GNU Radio and the USRP FPGA to 
create a control channel between the two to support packet processing.

Previously, the USRP interpreted all data over the USB bus to it as 
samples.  GNU Radio blocks also only handled fixed length data with no 
meta-data.  This is a great architecture for streaming, but not for 
packet based radio.  You can't send samples to the USRP and say 
"transmit at time X,"  "before transmitting this packet, switch your 
center channel to Y," or "perform carrier sense before transmitting this."

You also received no information about samples you were receiving, such 
as the RSSI or even just a timestamp when the samples were received. 
Requiring fixed length data between GNU Radio blocks again is ok for 
streaming, but one of the key aspects of packet processing is variable 
length data with meta-data like a priority, a timestamp when it should 
be transmitted, or simply anything you can come up with.

BBN proposed and implemented with Eric a completely new GNU Radio block, 
the m-block, which supports variable length data and meta-data that you 
can read about here:
http://acert.ir.bbn.com/downloads/adroit/gnuradio-architectural-enhancements-3.pdf

It was really the first great step towards packet processing in the 
architecture.  But, it left the gap between GNU Radio and the USRP. 
There was still no per-packet control over the USRP.  That's where our 
in-band signaling work comes in.  All samples over the USB are now 
encapsulated within a new packet structure:
http://gnuradio.org/trac/browser/gnuradio/trunk/usrp/doc/inband-signaling-usb

This allows variable length data between GR and the USRP, and it 
provides additional information about the samples.  We've modified the 
FPGA to now interpret these packets, parse them, and of course... do 
what they say :)  The timestamp field, for example, gives you much 
tighter timing.  You can send samples down with a timestamp and they are 
transmitted at that time.

We also have carrier sense working, which is not really reflected in 
that packet structure yet, where you use in-band signaling command 
packets to write an RSSI threshold to a register and any packets that 
come down with the carrier sense flag the FPGA waits until the RSSI goes 
below the threshold to transmit.  We also built in a deadline feature 
where you can specify that the FPGA only wait X clock ticks before it 
throws the samples out and moves on.

It's really opening up a whole new level of processing between GR and 
the USRP that truly facilitates wireless MAC protocol development, 
packet processing, per-packet control over the radio, and more precision 
scheduling for TDMA.

If you have any other questions, just let me know!  We hope to 
officially release it soon after profiling, so again, we would 
appreciate any help :)

- George