Forum: GNU Radio How to best use new GR features for TDMA systems ?

0817fa933c74eec9b3fcf3a04e16f418?d=identicon&s=25 Sylvain Munaut (Guest)
on 2013-12-19 20:06
(Received via mailing list)
Hi,

So I've wanted for a while to use GR more for TDMA systems I'm working
with like GSM and GMR and I'm having a bit of trouble figuring out
what the best way to do that.

Back when I started osmo-gmr, GR didn't have many features to deal
with packets and so I rolled my own hack to go from channelized IQ
stream from Gnuradio to my demodulator function that takes sliced
'windows' of IQ samples of known length and ideally I'd like to
replace most of it with GR. I'll try to explain below exactly what the
current code does and what it must deal with and hopefully someone
familiar with all the new packet feature of GR can guide me how to
implement it in GR.

The input comes from GR currently. It's basically a group of
channelized IQ streams that correspond to the various channels. They
don't necessarely have the same sample-rate, some can be N times
larger (N being an integer). All those streams are synchronized and
must be kept in sync (for example it's needed for hopping, or channel
assignements, ...).

Once the process is started, a "sync detection" task is started on
each channel that will try to acquire initial alignement. This
essentially captures a chunk of each channel long enough and give it
as a big sample array to a function that will find sync pattern for
whatever protocol it's configured for. Once it finds that pattern, it
will initialize a TDMA context that basically knows how to slice the
input into frames. Once those initial frames boundaries are known, the
main TDMA scheduler can be started for each context that was created.
This scheduler basically keeps a list of active / running "tasks". An
example of such a task would be a BCCH task that will slice the BCCH
IQ samples (purely based on the samples number and acquired alignement
and the known/specified TDMA scheduling) and hand them off to the BCCH
demodulator function. Each of those task can spawn new tasks, possibly
on other (or dynamic) channels. So if we see an "IMMEDIATE
ASSIGNEMENT" command in the BCCH/CCCH for example, it will create a
new 'SDCCH task' for example that will go and follow this channel with
it's own state ...

Now of course when starting a new task (after having demodulated /
processed the IQ data), it's sometime important to know where in the
IQ stream that command originated and it's important that the TDMA
slicer didn't take too much advance because if it did, we might miss
some of the TCH frames of the newly assigned channel. In the current
code, everything is done in a single thread so I'm sure that the
slicer didn't avance at all while I was processing the current packet.

So, how would you implement this (architecture wise I mean) with PDUs
/ tagged stream / ...

Cheers,

    Sylvain
032d0c37db78313ea467ed8a1d4927a1?d=identicon&s=25 Wayne Roberts (Guest)
on 2013-12-21 06:13
(Received via mailing list)
I suppose airprobe handled that sort of thing for GSM reception, back in
the 3.6 days.

But disturbing is your mention of frequency hopping, since that would
require some real-time performance between the software and hardware, if
it
requires changing the center frequency (PLL synth) of SDR source/sink
hardware.   I'm would assume such latency is not guaranteed even
slightly.
0817fa933c74eec9b3fcf3a04e16f418?d=identicon&s=25 Sylvain Munaut (Guest)
on 2013-12-21 10:33
(Received via mailing list)
Hi,

> I suppose airprobe handled that sort of thing for GSM reception, back in the
> 3.6 days.

airprobe does everything inside one big block which isn't really modular
at all.


> But disturbing is your mention of frequency hopping, since that would
> require some real-time performance between the software and hardware, if it
> requires changing the center frequency (PLL synth) of SDR source/sink
> hardware.   I'm would assume such latency is not guaranteed even slightly.

Read again ... I said I use a channelizer to split a large bandwidth
into several IQ stream and then to handle hopping I just go from one
stream to another, I never retune the hardware.

Cheers,

    Sylvain
0c86c3b09550eaad22e8a35a3a189672?d=identicon&s=25 Ralph A. Schmid, dk5ras (Guest)
on 2013-12-21 15:40
(Received via mailing list)
Following a frequency hopper within the sampled bandwidth shouldn't be
that critical.



Ralph.



From: discuss-gnuradio-bounces+ralph=schmid.xxx@gnu.org
[mailto:discuss-gnuradio-bounces+ralph=schmid.xxx@gnu.org] On Behalf Of
Wayne Roberts
Sent: Saturday, 21 December, 2013 06:12
To: Sylvain Munaut
Cc: GNURadio Discussion List
Subject: Re: [Discuss-gnuradio] How to best use new GR features for TDMA
systems ?



I suppose airprobe handled that sort of thing for GSM reception, back in
the 3.6 days.

But disturbing is your mention of frequency hopping, since that would
require some real-time performance between the software and hardware, if
it requires changing the center frequency (PLL synth) of SDR source/sink
hardware.   I'm would assume such latency is not guaranteed even
slightly.



On Thu, Dec 19, 2013 at 11:05 AM, Sylvain Munaut <246tnt@gmail.com>
wrote:

Hi,

So I've wanted for a while to use GR more for TDMA systems I'm working
with like GSM and GMR and I'm having a bit of trouble figuring out
what the best way to do that.

Back when I started osmo-gmr, GR didn't have many features to deal
with packets and so I rolled my own hack to go from channelized IQ
stream from Gnuradio to my demodulator function that takes sliced
'windows' of IQ samples of known length and ideally I'd like to
replace most of it with GR. I'll try to explain below exactly what the
current code does and what it must deal with and hopefully someone
familiar with all the new packet feature of GR can guide me how to
implement it in GR.

The input comes from GR currently. It's basically a group of
channelized IQ streams that correspond to the various channels. They
don't necessarely have the same sample-rate, some can be N times
larger (N being an integer). All those streams are synchronized and
must be kept in sync (for example it's needed for hopping, or channel
assignements, ...).

Once the process is started, a "sync detection" task is started on
each channel that will try to acquire initial alignement. This
essentially captures a chunk of each channel long enough and give it
as a big sample array to a function that will find sync pattern for
whatever protocol it's configured for. Once it finds that pattern, it
will initialize a TDMA context that basically knows how to slice the
input into frames. Once those initial frames boundaries are known, the
main TDMA scheduler can be started for each context that was created.
This scheduler basically keeps a list of active / running "tasks". An
example of such a task would be a BCCH task that will slice the BCCH
IQ samples (purely based on the samples number and acquired alignement
and the known/specified TDMA scheduling) and hand them off to the BCCH
demodulator function. Each of those task can spawn new tasks, possibly
on other (or dynamic) channels. So if we see an "IMMEDIATE
ASSIGNEMENT" command in the BCCH/CCCH for example, it will create a
new 'SDCCH task' for example that will go and follow this channel with
it's own state ...

Now of course when starting a new task (after having demodulated /
processed the IQ data), it's sometime important to know where in the
IQ stream that command originated and it's important that the TDMA
slicer didn't take too much advance because if it did, we might miss
some of the TCH frames of the newly assigned channel. In the current
code, everything is done in a single thread so I'm sure that the
slicer didn't avance at all while I was processing the current packet.

So, how would you implement this (architecture wise I mean) with PDUs
/ tagged stream / ...

Cheers,

    Sylvain
Ad80d352eb445a3d7dccd5a779db0e43?d=identicon&s=25 Martin Braun (Guest)
on 2013-12-22 17:26
(Received via mailing list)
On Thu, Dec 19, 2013 at 8:05 PM, Sylvain Munaut <246tnt@gmail.com>
wrote:

>
I've been trying to come up with a perfect answer to this, but it
depends
on just too many things.
I think it'll be a mix of all those techniques.

I think GNU Radio apps should look a bit like this:
At the top (think "MAC") blocks pass data as PDUs. The further down you
go
("PHY"), you'll eventually need regular blocks. Here, tagged streams
will
do what you want.
I guess gr-easymac was an early demo of this principle, although its
functionality can now be reproduced with pure GNU Radio. At CEL, we've
developed a FHSS network using pure GNU Radio, which works quite well
(someone still needs to release some code, and I hope they're reading
this
:). There will be a presentation on this at FOSDEM, btw.

Also, I've been working on a way to do TDMA using the OFDM blocks (on
one
of my lower-priority branches, though, so don't get too excited right
now).
In principle, the idea is:
* At MAC level, create a package with a tx time stamp as a PDU
* Pass this to the OFDM mod. The time stamp will propagate along with
the
length tag, and stay at the front of the streamed packet (this feature
was
merged into GNU Radio a while back and is available in the latest
release).
* The hardware driver should take the streamed packet and the metadata
in
the tags (the tx time, though it could also be the centre frequency for
FH)
and tx accordingly.
* At the receive side, all we need to do is remember the rx time of
samples
when we do a packet modulation.

There's a couple of things that are hard here: On the TX side, we just
hope
that the packet will reach the hardware in time. What if it doesn't?
Well,
bad luck.

Bottom line: GNU Radio has only recently become capable of doing these
things. This means we are still in the process of figuring out of how
exactly to write TDMA PHYs with corresponding MACs, which is a feature
that
we've always wanted and now seems achievable. I guess the more we try
out,
the more we will identify what's missing in order to do this.

MB
This topic is locked and can not be replied to.