Enabling the cognitive radio with GNU Radio+USRP

GNU Radio
1

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?

It looks like some of the examples don’t use the concept of a packet
(eg. usrp_tv_rcv.py) – how would I add my own data and filter it in
such streams? Would it require writing a C++ block? If so, how would I
ensure the reliability then?

Last question… I own to USRPs and I successfully installed the
gnuradio with grc on two MacBooks (10.6.2). Examples run fine, but
when it comes to the tunnel.py I cannot make the TUN/TAP interface to
work on OSX, has anyone had luck with that? I browsed the list
archives, but I couldn’t find a tutorial to make it happen. After
reading the
http://lists.gnu.org/archive/html/discuss-gnuradio/2009-01/msg00047.html
I tried the tuntaposx and Tunnelblick, but with no luck. For now I
replaced the tun/tap with a STOMP/JMS layer.

I have a CS background and the digital communication is rather new to
me, I would appreciate any help or links to resources.

Thanks,
Jakub

2

On Mar 4, 2010, at 2:45 PM, Jakub M. wrote:

Last question… I own to USRPs and I successfully installed the
gnuradio with grc on two MacBooks (10.6.2). Examples run fine, but
when it comes to the tunnel.py I cannot make the TUN/TAP interface to
work on OSX, has anyone had luck with that? I browsed the list
archives, but I couldn’t find a tutorial to make it happen. After
reading the [Discuss-gnuradio] Re: tun/tap OS X for tunneling
I tried the tuntaposx and Tunnelblick, but with no luck. For now I
replaced the tun/tap with a STOMP/JMS layer.

I have no answers to your previous questions, but I’ll address the one
above. tap/tun on OSX works differently than it does on Linux; I
don’t remember the details. I’ve (still, as per the link about) never
gotten it to work for me, though admittedly I haven’t tried very hard
either. If you can find a way of doing the equivalence of tap/tun on
OSX, then I say go for it & good for you & let us know what it was &
how you did it. - MLD

3

Michael,

Thank you for the response. What I am doing right now is forwarding
the packets from the tunnel.py to a JMS (Java Message Service) server
using the STOMP (http://stomp.codehaus.org/) protocol, available for
python. JMS server is pushing packets from its clients to the
tunnel.py. What JMS gives me is the asynchronous message-based
communication and reliability. The JMS server can talk to clients
written in a variety of languages (Java, C, C++, C#, Ruby, Perl,
Python, PHP). At this point the only issue is that I forward packets
from the PHY/MAC layer almost directly to the application layer… I
guess using the TUN/TAP would forward packets through the kernel’s
network stack and provide implementation of the higher levels of the
OSI model, so I wouldn’t have to worry about things like lost packets
and segmentation…

Jakub

4

On Thu, Mar 04, 2010 at 02:45:54PM -0500, Jakub M. wrote:

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.

It looks like some of the examples don’t use the concept of a packet
(eg. usrp_tv_rcv.py) – how would I add my own data and filter it in
such streams? Would it require writing a C++ block? If so, how would I
ensure the reliability then?

Good question, see below for reading suggestions.

I have a CS background and the digital communication is rather new to
me, I would appreciate any help or links to resources.

To really grok s/w radio, folks need to have a decent clue about
software, dsp, digital comms and RF. Sounds like you’ve got the
software part wired, so that’s handled. Other folks come with the
digital comms background but lacking experience in s/w. There’s always
something new to learn :slight_smile:

Take a look at this list of suggested reading, and spend some time
with a few things that capture your interest:

http://gnuradio.org/redmine/wiki/gnuradio/SuggestedReading

For DSP, I’d suggest starting with Lyons. For Digital Comms, try Sklar.

Thanks,
Jakub

You’re welcome!
Eric

5

On 3/7/2010 3:31 PM, Eric B. wrote:

In a packet-based communication (e.g. tunnel.py) I imagine that I

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

6

Tom,

That is actually what I was going to do. I installed Ubuntu as a dual
boot on my Mac and I must say the installation of gnuradio went very
smooth, much faster than on the OSX. Too bad this approach is not
platform-independent, although it will do for now.

Thank you for the advice!
Jakub