On Thu, 2008-12-04 at 18:29 -0500, Radha Krishna Ganti wrote: > 1) 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 Blossom, "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 _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
