[Top][All Lists]

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

[Discuss-gnuradio] New GNU Radio features and PHY/MAC coding

From: Johnathan Corgan
Subject: [Discuss-gnuradio] New GNU Radio features and PHY/MAC coding
Date: Fri, 1 Mar 2013 11:36:04 -0800

With the recent (and not so recent) additions of stream tagging, asynchronous message passing, and PDU blocks, there are now much better facilities for handling packetized data in GNU Radio.  Some of this will be seen in the OFDM transceiver code that started at the last hackfest and will be integrated into 3.6.5, though it was started before the async message passing was completed so it doesn't use PDUs yet.

Our intent now (after completing the 3.7 API transition) is to improve the existing transceiver implementations with these in mind.

The concept of PDUs is to encapsulate a vector of data along with a dictionary of key/value pairs describing the data.  For a packet-based transmitter, these PDUs would be received from a source of packets, such as the TUNTAP virtual network interface, a MAC layer block that generates PDUs, a TCP or UDP network socket, or some other source of "data with boundaries".  The PDU metadata could be things like transmission time, requested modulation parameters, transmit frequency, or other parameters you might wish to pass along to your own custom downstream blocks.  Packet handling (like adding CRC, header, FEC, scrambling) will be done in the PDU domain by PDU oriented blocks that use asynchronous message passing to consume and emit PDUs.

At a certain point in the flowgraph, the processing becomes stream oriented, and the traditional streaming blocks can take over.  However, with stream tagging, the upstream PDU metadata can still propagate as needed through these blocks.  In addition, we'll be looking at how to make the streaming modulation blocks smarter by having them respond to inline streaming tags to change their function.  In this way, then, an overall transmitter hierarchical block will be able to accept discrete PDUs and stream out baseband RF, with any tags that are meaningful to the transmitter hardware generated or propagated onward.

A packet receiver would work in reverse, receiving streaming RF baseband with whatever hardware supplied metadata was tagged onto the stream.  These would go through the various streaming synchronization and demodulation blocks (which might add tags about what they did) until payload boundaries are determined, at which point PDUs would be used to process things like payload FEC, descrambling, checking CRC, etc.  A overall hierarchical packet receiver block would accept streaming baseband RF and emit PDUs.  A MAC layer block listening to this PDU traffic could then forward these on to some consumer of the payloads, like the TAPTUN block, etc., or the MAC layer block could recognize one of its own packets and handle accordingly.

One benefit of this architecture is that since everything will be done in blocks (PDU or streaming), all of them can get GNU Radio Companion wrappers and users will be able to experiment with them much more easily than today's essentially Python-only code (like benchmark and tunnel and supporting code).

Some of the ideas here have been experimentally prototyped in the gr-extras code by Josh Blum and John Malsbury of Ettus Research.  We (Tom and I) will be working with them to understand the knowledge they've gained from this work to see how it can be re-cast using the new, standard capabilities of GNU Radio as I described above.

Exciting stuff ahead.

Johnathan Corgan
Corgan Labs

reply via email to

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