[Top][All Lists]

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

Re: [Discuss-gnuradio] MAC layer questions

From: Colby Boyer
Subject: Re: [Discuss-gnuradio] MAC layer questions
Date: Sun, 3 Jul 2011 13:03:37 -0700

On Sun, Jul 3, 2011 at 8:16 AM, Tom Rondeau <address@hidden> wrote:
On Thu, Jun 30, 2011 at 9:16 PM, Morgan Redfield <address@hidden> wrote:

I've been working on building a CSMA/CA MAC for the past couple of
weeks. I built it in Python, and used ofdm/tunnel.py as a guide. It's
working now, but I don't think it's very efficient. I ended up having
to relax a lot of timing parameters to get it working, so my
throughput is pretty bad. I also get a lot of dropped packets. I think
this is also because my timing isn't very accurate, and I end up with
more collisions than I would expect.

I was wondering if anyone else had had any luck building a CSMA/CA
MAC. I saw a few posts on the mailing list from several years ago
about people who were working on it, but I don't see any example code
anywhere. I also checked out CMUmacs on CGRAN, but that relies on a
deprecated version of GNURadio.

Is my best bet to rewrite the MAC as a block in C++? Can anyone tell
me what kind of speedup that's likely to get me?

Morgan Redfield

Yes, this is an issue with MACs in software radio when you have a bus like USB or Ethernet between the processing and the air interface. These buses have fairly large and jittery latency, so by the time you have received samples, measured the power to determine that the channel is clear, and then sent a payload to be transmitted, but the time the payload actually goes out of the air interface, you decision is so far in the past that it's pretty meaningless to the current state of the channel.

We have a rudimentary CSMA MAC in tunnel.py in the digital examples, but it suffers from the same problems you are seeing.


Discuss-gnuradio mailing list

Perhaps this could be a new feature for the UHD driver interface. There is already a start streaming at clock value X feature. The idea is to augment that and have a start streaming at clock value X if channel is clear; if not clear return an error code. A channel sense block should not be too complicated to put into hardware.

A side note, it would be great if Ettus and company could develop a USRP with a PCI-express interface (the new Thunderbolt interface?). This could possible solve a lot of the timing issues (can the more HW oriented folks comment on this). Also it would a great excuse to sell a more expensive USRP board (with higher margin! $$). :P


reply via email to

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