On Thu, 2008-12-04 at 18:29 -0500, Radha Krishna Ganti wrote:
- How easy is to implement a packet based CSMA/CA on the gnu radio?
Is there any existing code that is public?
You can get a basic idea on how to implement CSMA by looking at the GNU
Radio example in the “digital” directory.
Basically, there are two flowgraphs operating in parallel, one for the
TX side and one for the RX side.
The RX flowgraph has a USRP source, PHY demodulator, and packet
deframer. It terminates in a message sink that turns the received data
into a queue of packets to be queried by non-GNU Radio code.
The TX flowgraph has a message source block into which non-GNU Radio
code deposits packet payloads to be transmitted. The remainder of the
TX flowgraph graph does the packetization, modulation, and transmission
to the USRP via a sink block.
Both of these flowgraphs are continuously running and in separate
threads.
The CSMA MAC is implemented entirely outside these GNU Radio flowgraphs.
When the upper layer wants to transmit a packet payload, the code
queries a block in the RX flowgraph to determine the current RX channel
power estimation. If it is below a configurable threshold, the payload
gets deposited into the TX message source queue. If the power is above
the threshold, the MAC code exponentially backs off and retries.
The upper layer gets its received payloads (again outside GNU Radio
proper, and in its own thread) by querying the RX flowgraph message
sink.
An important concept to understand here is that GNU Radio itself is only
being used to handle the PHY aspects of the link, and is continuously
running in “background” threads. The CSMA MAC code is running
independently and is simply calling functions that have been defined
(and made thread-safe) in either the RX or TX flowgraphs to decide what
to do.
This is a very crude MAC, or in the words of Eric B., “the simplest
thing could possibly work.” Still, it illustrates the separation of PHY
and MAC operation. A more complicated MAC would be implemented as a
state machine that sequences through its logic based on transitions
triggered by packet reception, upper layer TX requests, etc., while the
GNU Radio flowgraphs simply run in the background and do the PHY work.
I have read in some posts about the inband-signaling code. Where can I
find more information about what it is? Will this solve the problems I
have mentioned above without using click.
The in-band signaling code is an effort to add timed transmit and
receive functionality to the existing streaming mode the USRP operates
in. This is absolutely crucial to implement more complicated MAC
functionality such as TDMA, RTS/CTS, etc.
However, the current GNU Radio “infinite stream” dataflow architecture
is not very well suited to working this way. An alternative signal
processing graph architecture has been designed, the “mblock” library,
which works entirely in the message passing domain and fits these needs
very well. The in-band signaling code is built in this domain and works
well. The mblock domain is also well suited for writing MAC layer code
(this was its original purpose in being created.)
Unfortunately, right now, the choice is to either use the mblock library
or use the existing gr-block library, but not both. Several attempts
have been made to bridge these two domains but nothing satisfactory has
resulted. So we are now looking at essentially adding mblock-like
functionality to the existing gr-block library. The lack of this
integration has prevented any real adoption of the mblock architecture.
Once this is done, it will very straightforward to implement either
streaming or message passing semantics (or both) in a gr-block. Writing
integrated PHY/MAC code will be much simpler.
Regarding the Click code, I don’t have enough experience with it to
really say, but one thing going for it is that it exists, is debugged,
and has been bridged to existing GNU Radio PHY code successfully. So,
if you’re trying to get something done now, that will save you a lot of
time.
If you’re willing to work on the bleeding edge, you can work with us as
we start with the above additions to the gr-block architecture.
-Johnathan