discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Enabling the cognitive radio with GNU Radio+USRP


From: Tom Rondeau
Subject: Re: [Discuss-gnuradio] Enabling the cognitive radio with GNU Radio+USRP
Date: Mon, 12 Apr 2010 08:44:02 -0400
User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4

On 3/7/2010 3:31 PM, Eric Blossom wrote:
On Thu, Mar 04, 2010 at 02:45:54PM -0500, Jakub Moskal wrote:
Hi everyone,

I am trying to use the GNU-Radio+USRP to implement a cognitive radio
use case in which radios exchange information (XML-based documents)
between each other in order to achieve a defined goal (e.g. to improve
connectivity), without disturbing the usual communication. I have
several questions regarding this scenario..

In a packet-based communication (e.g. tunnel.py) I imagine that I
could transmit my own packets which would include the "cognitive
information" and then receive them on the other end. It would require
some special marking of the packets (binary level?) to distinguish the
cognitive information from the regular data, so that it could be
filtered out on the receiver side. I looked into the tunnel.py, but it
seems that it doesn't implement anything higher than the MAC layer -
therefore I cannot use it to reliably transfer data, packets get lost
or are too small and I would have to split/merge data manually. Would
it be possible to combine the tunnel.py with the TCP source/sinks in
order to achieve a reliable link?
In reality, you'd need some kind of FEC to get the packet error rate
down to something you can deal with.  Then you could run TCP across
the interface.  No need for TCP sources or sinks.  You've got a
(virtual) network interface with an IP address.  Just run something
that uses TCP on that IP address.

Definitely follow Eric's advice and apply some kind of FEC to reduce the packet error rate. When you've done that, the tunnel.py provides you with a TUN/TAP interface, which is a networking interface like eth0 (that is, once you get it working with your Mac, for which I can't be of any help). This will allow you to use a TCP/IP interface to the GNU Radio physical layer. Instead of trying to interleave your cognitive radio control bits into the PHY-layer stream, you should be able to use a TCP port specifically for those purposes. So you'd have two logical links on the TCP layer over the single physical link.

Tom






reply via email to

[Prev in Thread] Current Thread [Next in Thread]