GNU Radio / Software Radio conceptual question

Hi all,

I have a relatively high level question regarding gnuradio and software
radio in general. Is it a fair generalization to say that gnuradio is
operating at the application layer and is essentially emulating a
physical
layer implementation (or the implementation of other lower layer
protocols)? For example, if I have a link between two USRPs (more
specifically, N series USRPs), the digitally sampled received data comes
in
on the ethernet NIC and moves up the stack to the software radio
“application.” The signal processing that would typically be done in
lower
layers is then handled by the application.

The second part of my question is, given a flow graph in gnuradio, what
sort of steps would be necessary to “push it back down the stack” or
implement in a chipset such that it can be used as an interface in a
typical network stack? Is this something that anyone using gnuradio has
considered or should I assume the next step would involve
re-implementation?

NOTE: This is by no means for a commercial product, but rather for
demonstration. My research has led me to use gnuradio for some proof of
concept implementations and I’m curious how much additional effort would
be
required to port the work to a practical device - for example,
implementation on a smart phone. (you can read this as “will it cause me
to
postpone graduation a few weeks? months? years?”)

Thanks in advance - any input is greatly appreciated.

Regards,

Michael R.
PhD Candidate
Boston University, Boston, MA

On 06/16/2014 10:24 PM, Michael R. wrote:

typically be done in lower layers is then handled by the application.
of concept implementations and I’m curious how much additional effort
Boston University, Boston, MA

This presentation is several years old at this point, but I give it to
ham-radio clubs from time to time:

http://www.sbrac.org/files/sdr_introduction.ppt

On 17.06.2014 04:24, Michael R. wrote:

I have a relatively high level question regarding gnuradio and software
radio in general. Is it a fair generalization to say that gnuradio is
operating at the application layer and is essentially emulating a
physical layer implementation (or the implementation of other lower
layer protocols)? For example, if I have a link between two USRPs (more
specifically, N series USRPs), the digitally sampled received data comes
in on the ethernet NIC and moves up the stack to the software radio
“application.” The signal processing that would typically be done in
lower layers is then handled by the application.

In most cases, GNU Radio handles pretty much what comes out of the A/D
converter (well, not quite, there’s some decimation and filtering in
there. But for the sake of this argument, this is irrelevant).

So, we have this:

ADC -> GNU Radio -> DAC

To say GNU Radio “operates at application layer” would therefore be not
good description of what it does; it doesn’t “emulate a PHY”, it is
the PHY for all intents and purposes.
This is the software radio principle: Using A/D converters, we bring the
software very close to the antenna.

This is not an academic view on things. While most wireless devices (and
I guess that means mobile phones) are what you could call “hardware
radio”, i.e. they have dedicated circuits to do the PHY, many other
applications such as base stations are actually driven by software.

So when you say data “moves up the stack”, it’s not going up the stack
in terms of ISO/OSI layers. The means of getting the sample data (which
is the raw signal, even before the PHY layer) to the software are just
slightly more elaborate than having the PHY chip connected directly to
the ADC.

GNU Radio was specifically designed to implement PHYs, it can also
implement MACs. Above that, you would probably use something else.

The second part of my question is, given a flow graph in gnuradio, what
sort of steps would be necessary to “push it back down the stack” or
implement in a chipset such that it can be used as an interface in a
typical network stack? Is this something that anyone using gnuradio has
considered or should I assume the next step would involve re-implementation?

I’m not sure what you’re trying to do here. Maybe what you’re trying to
do is what Balint and John have done with their gr-mac module, which
allows you to create a TCP/IP connection over your own user-defined PHY?

NOTE: This is by no means for a commercial product, but rather for
demonstration. My research has led me to use gnuradio for some proof of
concept implementations and I’m curious how much additional effort would
be required to port the work to a practical device - for example,
implementation on a smart phone. (you can read this as “will it cause me
to postpone graduation a few weeks? months? years?”)

GNU Radio works on some embedded devices, which might be what you’re
interested in. If you have no experience in embedded development, it can
take you months to years to figure out, but if you’re a smart guy you
might be able to get some results sooner than that. Note that I’m not
talking about smartphones here, but rather commercially available
embedded SDR devices, such as the Ettus E100.

Martin

Thanks for the quick replies. I can see how putting the SDR in a block
directly before the DAC or after the ADC is a PHY implementation, and
how
this is the case when using embedded devices such as the E series USRPs
and
the embedded SDR components in a base station.

My confusion is when gnuradio is operating in an OS where the sole
purpose
isn’t the comms link (i.e., running on my PC rather than on an embedded
linux micro). In the case of the N series USRPs, my understanding is
that
the signal chain wraps whatever is implemented in gnuradio (PHY, MAC,
etc)
within network and Ethernet packets to send to the USRP, the USRP
unwraps
this and places the samples on the physical channel and vice versa at
the
receiver. To me, the wrapping and passing of digital samples seems to
put a
stack within the stack. The ends of the chain are unaware of the
internal
message passing and act as if the samples were directly passed to the
DAC
and ADC, which is why I see it as an emulation of the PHY. Perhaps this
is
strictly a case of my definitions being incorrect (and I definitely
realize
that network layer models are models rather than standards), but please
confirm if my sense of what is occurring in the signal chain is correct.

Thanks again,

-Mike

On Tue, Jun 17, 2014 at 5:31 AM, Martin B. [email protected]

On 17.06.2014 13:52, Sylvain M. wrote:

emulation as well ? The way the samples are transported from one
endpoint to the other is largely irrelevant here …

I agree, this is the point I was trying to make. Somehow, the samples
have to get from the ADC to the PHY. In the case of a networked device,
it’s by Ethernet. On an embedded device, there might be an AXI
connection.

The PHY is where the physical signal is handled (or samples in case of
digital systems), hence the name, regardless of where the samples are
from. Of course Ethernet has its own PHY and MAC, but our comms system
doesn’t care about this.

M

To me, the wrapping and passing of digital samples seems to put a
stack within the stack. The ends of the chain are unaware of the internal
message passing and act as if the samples were directly passed to the DAC
and ADC, …

Yes, and ? These are un-related stacks.

Some highend DAC/ADC have high speed serial interfaces and
encode/packetize the data before sensing them to the CPU/FPGA/ASIC
that will deal with the samples, would you consider that a PHY
emulation as well ? The way the samples are transported from one
endpoint to the other is largely irrelevant here …

Cheers,

Sylvain